Contribution ideas - more GAME samples!

For sure, the more samples, demos, tutorials, docs that exist for Panda the better!

So to summarize what I’m hearing on the thread (great discussion from everyone by the way):

  • Folks agree the current crop of Panda samples aren’t indicative of what the engine can do
  • It seems many people (from this thread alone) have ideas and would like to contribute to building out some better samples (including myself!)
  • The range of sample complexity desired, from this thread looks to be across the spectrum: from very simple/concise, to fully functional mini-games and mini-demos. And it looks like folks agree with the idea of doing both simultaneously - break the bigger samples up into smaller ones and have them import each other.

So let’s talk some ideas on how to execute? A few questions from my side (new to Panda dev here, although I’ve done lots of opensource through the years…)

  • Quality control - is there any persons that can review contributions from folks? If we have a growing set of samples that fit together, it would be nice if they were all well designed for this level of modularity. Who would those persons be if any? My guess is we would get a flurry of nice samples started but need to pass some bar of quality before they get into an official Panda source tree? It would be cool if some really senior/knowledgeable Panda devs could put eyes on this so things are put together well
  • Should we spin up a github repo and collaborate there until things are ready for submission?
  • Should we just plan to add to Panda’s existing sample folder? Or is this warranted to be some new structure someplace?
  • Although I’d like to get to fully-working 3rd person or 1st person mini games, I’m fond of the idea of starting with smaller, simpler samples that fit together to make the bigger ones. We could release early/release often and get a lot of feedback on the fundamentals before building the bigger pieces.

Thanks all for feedback!!

-Sal

Another quick idea - I was thinking along the lines of how to make these new samples a bit more consistent, and try to keep an eye for visual appeal (so that folks new to Panda like what they see).

What do you think about the following free media packs for most of the 3d art? https://quaternius.com/

License seems good - almost public domain CC0.

It has animated characters, of a few different game genres, and lots of low poly static stuff (vegetation, etc.) to boot. Seems to fit Panda’s style already and being low poly would help with folks on lower hardware - good for samples to perform well right? And should work on mobile as well.

Just an idea, or if there are other more complete 3d art packs feel free to post here, I have a lot of scattered media that is of different formats and styles, but it’s hard to find something that is comprehensive and consistent.

This statement is somewhat amusing.

I seriously doubt we’ll be able to make a great tech demo in the same vein as Half Life or Prey (2006) without doing entirely custom artwork. This kind of work takes a lot of time and is generally speaking not free of charge!

I am with you until this Act 2 part. This seems like a tractable yet ambitious demo. I’m imagining the aesthetic is like a Jim Burns painting. I think by far the hardest part would be making art assets to the quality level expected by the audience, which seems to be poorly defined at this point. How good is good enough?

I would suggest that this–whether housed in a single repository or multiple–be kept separate from the Panda repository. For one, it is a community project, not an official one. Whether the samples end up becoming official or not, I’m inclined to keep the initial phases of the work, at least, external to anything official.

I will note here that I think that even the small samples might benefit from having some sort of demonstrative program to show them off. A third-person camera-module, for example, doesn’t do much of interest without something to move it about, something for it to show, and something for it to potentially collide with.

These demonstrative programs needn’t be complex, however, let alone full games. Taking again the hypothetical third-person camera-module as an example, I imagine its individual demo being nothing more than the camera following a single character around a single, simple environment.

Hmm… My feeling is that I would want a showcase to impress with what the engine is capable of. And while the models there are good and often appealing, I’m not sure that the style used there is conducive to that end.

I do like the idea to use free art, and it may be worth looking for it, but I’m not sure that I’m a fan of that specific set for this purpose.

(Which is not to say that I think that they’re bad, let me clarify. Those models could indeed work well for a variety of games, I daresay!)

I mean, I don’t think that we’re talking about making anything anywhere near that big! This is a showcase, and potentially a tech demo–it needn’t be a full AAA game twenty hours long! (And indeed, I suspect that it would be better that it weren’t that.)

This is a question that I have, too. Specifically, what should the models include? Colour and normals, I imagine–but gloss maps? Glow maps? Other sorts of map?

What are our asset-goals here?

Please forgive the double-post, but I thought it relevant to this thread to note that I’ve just set up a repository providing a simple third-person camera-controller, along with a very simple demo showing the controller in action.

Said demo isn’t pretty, I fear, and so doesn’t at time of writing meet the suggested standard for an official sample, I daresay. (I simply didn’t put much effort into creating good models for this purpose.)

However, it would be easy enough to swap out the models used, should better become available.

The thread for the controller should be in the “Code Snippets” sub-forum, here:

And the repository itself should be available from GitHub, here:

1 Like

Wow very cool! And this is the second great set of example code we’ve gotten since starting the discussion.

I went ahead and started to update my original post to aggregate these links, also adding Simulan’s first person shooter example. I don’t want any of this great work to get lost in discussion. Thank you both for jumping right in and rolling up sleeves here.

I’m about to grab the code for the 3rd person cam example and kick the tires as well.

Thanks!!

-Sal

Here’s the update:



1 Like

Thank you very much! I’m glad that you like it, and glad to have it listed in the first post! :slight_smile:

Indeed, I think that aggregating such things in that first post is a good idea–as you say, that way they’re less likely to get lost as regards being part of this effort. :slight_smile:

I’m working under the assumption that some bar of quality likely needs to be met for samples to get into Panda officially. Of course - any samples (Even hosted on github) are better than none - but, I’d really like to see Panda’s official sample library to grow as well! But not at the expense of quality, of course.

In my mind - more samples → easier to use engine → more contributors → ‘all panda users benefit!’

Just speaking from personal experience, especially with open-source projects there can be a lot of opinions on how to structure code, to keep things high-quality and consistent (regarding an official repository) there usually needs to be some sort of process.

Agreed here, for sure. From what I gather on this thread however - it looks like folks are supportive of the idea of building things out in pieces - smaller / simpler samples might only need simple little 3d meshes to make a testable app.

Once those smaller pieces are built out we can aggregate into some much bigger / more complex demos, and create media. I’m thinking working in small ‘baby steps’ helps to deliver lots of nice results and also - if these fit together well - give all the building blocks needed to put together the much bigger exciting stuff we all are eager for as well. (Just my opinion here!! Happy to hear other ideas of course!!)

Agree here. Simply out of curiosity (and since I’m so new) I’m wondering if there is any advice / guidance floating around that might help us structure things to ‘eventually’ be considered official, I’m just thinking that a nice secondary-goal is to help ‘all’ new users of Panda with better samples. Right now I feel like the out-of-the-box samples give the wrong impression. If that makes sense.

I’m open for other ideas as well! Or if there are any alternatives available. My thoughts here (all opinion, happy to hear others). Its nice if the samples ‘look nice/professional’ as well as ‘work well’. Having some art to draw from may help give a quality/consistency that helps to sell Panda, nice visuals are always good for 3d game engine demos. But not to go overboard, if the user needs a very modern GPU just to run a collision sample, then that may be overboard. Myself being a coder, I know that if I ‘made’ the art it would look much more terrible than if I used an artist’s. Also - making art can slow things down - it’s nice to have quickly available media.

Unreal engine uses a simple, animated blue character and cubes for the most part. And that’s a AAA game engine - so very basic stuff. Other samples do have themed/curated and very professional assets integrated, when they’re showcasing advanced features. Just ideas / food for thought!

I do see what you’re saying, indeed, I do believe. While a few of the samples are perhaps fine, some of them really do not convey well what the engine can do, I fear.

That said, I really don’t know what guidelines there might be for something to become “official”! For that I’ll defer to other forum-members!

Hmm… We do have a few assets already available, I believe: not long ago there was a similar drive to this, and while it didn’t get very far, it did end up resulting in a few things, as I recall:

I remember trying to create a convention for the documentation programming style. However, I am not a native English speaker, and it is difficult for me to write a text for it.

  1. Panda uses several versions of python. So the code should work for everyone.
    For example for formatting strings it is optimal to use format()

  2. Avoid unnecessary dependencies, such as the gltf format, for python only. You can replace it with bam, so that C++ users are not left behind and can use these resources.

  3. By programming style.
    This is a transparent style.

from direct.showbase.ShowBase import ShowBase
from direct.task import Task

class Player():
    def __init__(self):
        pass

    def update(self):
        print("update player")

player = Player()

class Ai():
    def __init__(self):
        pass

    def update(self):
        print("update ai")

ai = Ai()

class MyApp(ShowBase):

    def __init__(self):
        ShowBase.__init__(self)

        self.taskMgr.add(self.update, "global update")
        
    # Global update.
    def update(self, task):
        player.update()
        ai.update()
        return Task.cont
    
app = MyApp()
app.run()

bad style

from direct.showbase.ShowBase import ShowBase
from direct.task import Task

class Player():
    def __init__(self, base):
        base.taskMgr.add(self.update, "player update")

    def update(self, task):
        print("update player")
        return Task.cont

class Ai():
    def __init__(self, base):
        base.taskMgr.add(self.update, "ai update")

    def update(self, task):
        print("update ai")
        return Task.cont


class MyApp(ShowBase):

    def __init__(self):
        ShowBase.__init__(self)

        player = Player(self)
        ai = Ai(self)

app = MyApp()
app.run()

And much more.

The cherry on the cake is that the ShowBase needs to be rewritten for a certain style of play.

Let’s not get lost in the weeds with regard to style and code structure. If it runs and runs well it is acceptable in my opinion. One can make arguments for and against many style guidelines. Unfortunately what doesn’t happen when style policing is, actually getting work done and presenting working solutions. Good code runs fast, compiles with a minimum of warnings and errors, contains tight logic structures.

I am personally excited about @Epihaius 's idea of the spaceship tech demo. Would it be technically possible to generate geoms to a specified shape? As in, I make a spaceship model outline and then your procedural geom code generates to that shape? I’m just trying to think through the actual implementation of a procedural spaceship which is then also a real game asset which we can walk around inside of and so forth.

@svf have you ever actually used the Unreal 4 default mannequin armature in Blender? Last time I worked with it, it was a cobbled together nightmare. My simplistic Armature in the Arena demo is superior, already, in terms of speed of building solutions upon it. If we defined actual quality standards for the assets I’d be more than happy to provide models to that standard. It is totally trivial to add some boxes, including collision simulated ones, to be beyond the standard of the Unreal 4 base environment within a few days or weeks.

While for the most part I agree…

Here I don’t. I think that there’s a strong argument to be made that “good code” is also readable: Readability eases understanding–even of one’s own code, and especially in large code-bases, I daresay. That in turn makes it easier to to spot potential issues and opportunities, to maintain code over time (especially–but not only–the code of others), and even simply to find where one left off or to build on what’s already there.

Indeed, I’d argue that in many cases it’s preferable to have code that’s readable but not ideally efficient than code that’s fast but impenetrable. (Barring performance-critical sections, of course.)

Okay, I’m not sure if this will affect my work though. I’m sure it’s possible to build a bunch of Classes around my logic to make it more readable, but it’s not something I’m likely to do myself. I am probably in the minority of programmers in that I find most Class groupings beyond the framework unnecessary or difficult to read. That’s just me, I just wouldn’t want to throw great code examples in the dust bin because they’re not 100% matching somebody’s rubric of quality.

And that’s very fair.

Note that I said that good code is “readable”–not “readable to everyone” or even “readable to the majority”. As long as the code is readable to those who use it, then fair enough, I say.

Indeed, if changing your style would make the code less readable to you, then there’s a fair argument to be made there that doing so would make it, for you, worse code.

(Although that it is potentially worth being aware that one’s code might not be readable to others, of course. In some cases, comments might help in code that’s to be seen by other developers.)

All I was arguing, really, was that there’s at least that one more thing to code being “good”: readability.

The description I gave of the different acts might have given the impression that I wanted something that takes hours to complete, but that really wasn’t my intent. Each act could last for only a few minutes, with a minimal amount of assets needed to give the feeling of a single scene from a fully fleshed-out game.

As I’m not all that great myself at texturing and using special effects, I’m not in a position to judge what is “good enough” with regard to what others would want to contribute.
But generally speaking, while using all of these different kinds of maps could show what Panda can do with them, I think it depends on how much of a visual difference they make, per model. For example, a complex normal map can add lots of detail to a low-poly mesh, but if the model is high-resolution, then it won’t have the same impact and may even be redundant. Another example that comes to mind is the use of a gloss map for a wet stone wall. If the effect is too strong it can end up looking like plastic, while toning it down could make it barely noticeable. In that case it might be better to just not bother with it.
What I’d suggest then, is to start out with simple, low-poly models without any maps or effects and gradually enhance them and see what works and what doesn’t.

Indeed. And as such, it seems a bit early to me to already start worrying about details like what effects, maps, materials etc. to use for which models – I mean, have we already come to a consensus regarding the actual content of the tech-demo? It’s great if you want to use my ideas, of course, but maybe others would like to offer alternative ideas as well.

In terms of coding, one thing I would keep in mind is that to some extent, a tutorial or samples or anything that is meant to teach in some way, is responsible for potentially shaping the coding habits of new, inexperienced programmers. It happens often that someone new to programming starts a project by copying code from such instructional material and deems its style to be more-or-less authorative. Even if not, they will usually code around it in a way that adheres to that style, simple because “it works, so why not”. That would be one reason to have some kind of “standard”, I guess.

Apart from that, when I see things like a Panda method – e.g. attach_new_node – being used in some places written like that, while in other places it’s written like attachNewNode, then I worry a little bit that new Panda users are going to get confused – and might ultimately settle on a name that will get deprecated at some point (the camelCase version, to be precise). Yeah there I go again – I can be such a nag sometimes :stuck_out_tongue: .

One reasonably straightforward way would be to create the model as a collection of 3D primitives (spheres, cylinders, boxes, etc.), which can easily be built up procedurally. My proposed geometry sample pack already contains an example where you can see this happen (primitives_assembly.py). In fact, it’s while making that particular sample that I got the starship-in-hangar idea.

If a shape consisting purely of primitives is unacceptable, the alternative would be to create the model in a modelling program as usual and clear its GeomTriangles primitive. Then it would be a matter of deciding on the exact order in which to re-add the triangles to it over time.

That’s fair! I have no argument with that scale, I think!

My quoted reply was, I think, in response to a mention of Half Life and Prey (2006)–both full-scale games, not brief tech-demos.

While I hear you, my thought is that this is intended to be a demo that impresses, that shows to a potential new user what Panda can do. If the assets are generally low-poly and without fancy effects, it may appear that such is all that the engine supports.

Polishing assets as we go might work, but I do then fear that they might be left half-complete.

Further, it might help to have some idea of what we’re aiming for in the end.

For my part, I’m less concerned with what is applied to what specific models, than with a general idea of what we’re aiming for. I’m not going to advocate for glow-maps on simple rocks, but should we be looking to have them on, say, neon-bedecked robots or glowing-eyed monsters? Or would we look for other approaches to keep it simple? And so on.

So less a fine-grained “let’s list what textures we’ll apply to everything, right now”, than “what level of flashiness are we aiming for?”.

Totally agreed!

That’s a risk in general with such an ambitious project, I fear. It needs people who are truly motivated to continue their part, to be sufficiently dedicated to see it through.

If you mean how to achieve a specific effect technically in the most efficient way possible (e.g. the use of shaders, appropriate material settings and the like), then I have to admit that I’m not the most qualified to answer this, I’m afraid. So I’m hoping that others more knowledgeable in that department will chime in on this.

Obviously, the flashier the better I’d say. Because, as you rightly said, it’s all about impressing people. There is the consideration that Panda3D has always prided itself of being able to run on lower-spec hardware though, but having certain effects (and model resolution) user-configurable should take care of that, I think.

So in conclusion – and assuming that my idea for the intro of the tech-demo is accepted – I’d suggest to go all out in whatever way the contributors feel most comfortable realizing those fancy visuals. The hangar itself, for example, could be littered with small blinking lights, glowing circuitry, screens with animated content and perhaps an additional layer of bloom on top of all that. That’s the kind of thing I’d like to see, but if you ask me the best, most efficient way to realize all that, then I must confess I don’t really know.

Great info! I started to keep track of the samples we’ve built in this thread as well as the links that are coming up to useful resources for building samples. Here’s the latest update:


New samples created by the community here! (Updated as we build them):

Resources for helping folks create samples:


Great progress folks, let’s keep all the great ideas coming!

I’m less asking after the best or most efficient way to do it, but rather after what we want to show off. Do we want to show off that we can support glow-maps, and displacement maps, and other maps besides? Do we want to keep it simple, or show off as much as possible, or something in-between? That sort of thing.

Indeed. Hence it seems to me to be a good idea to reduce the likelihood of it. If a model is made once and is then done, then it may be more likely that it’ll be finished–or at least, that’s my intuition, which may well be mistaken.

A good update, and thank you for it! :slight_smile:

Well put! My thoughts here: Whether we design step 3 or step 9, We still need to perform steps 1 and 2. And in my experience with software development, once you have steps 1 and 2, all plans you had previously for anything beyond that changes!!! (And more ideas come to mind). I’m OK to tunnel-vision on the next couple steps, and worry about the complex stuff once we get there. My thoughts are we need a lot of boiler-plate basic stuff - I don’t think we have a sample that actually has fully working player & NPC collision/physics for example, it might be a good place to start. For most game engines things like this are considered basic features - that Panda doesn’t have this in a sample yet is a nice big gap we can fill.

However, thinking/designing that long-term vision can be extremely exciting and motivational. I wouldn’t want to kill the fun - if that’s what folks would like to focus on, by all means, I’d love to see more ideas there. (and long-term vision always does help to ground your design.)

One of my coworkers loves to say ‘perfect is the enemy of good’, which is a fun concept, since everyone’s definition of ‘perfect’ and ‘good’ varies, but point taken - most importantly results are what matter, for sure. Bias for action is a great rule to work by.

Well put, again!! I think you’re hitting the crux of the idea here.

Consider there are ‘samples’ for a game engine and ‘official samples’. ‘Samples’ just need ‘to work’ and it’s, after all sample code of how one could use the engine. ‘Official samples’ however typically need to go beyond, actually showing clean / elegant code structure and serve as models for best practices for many things like code re-use, modularity, clean code structure, understandability - overall, an official sample is what shows how the entire game engine’s design comes together to deliver a good user experience (for the developer) to build a game. If official samples are difficult to understand, or lacking features, it leaves little hope the engine can do much more / can scare away new folks that see things done easily elsewhere. (Not to spell doom and gloom here, but TLDR: sample quality is important)

Ideally we’d like to open the ‘official’ samples for Panda and say ‘wow this engine is so nice to use, is intuitive, etc.’ and it inspires one to tweak and start to build.

To expand on this a bit further (apologies if this sounds super pedantic but I’m a stickler for well written code). Consider this article for a moment. There are many ways to write the ‘same’ piece of code, some ways much more intuitive than others.

Let’s take for example an imperative style:


    #here is a sample 1st person app

    #this is all pseudocode, not Panda specific
    def main():
          node1 = makeNode(x,y,z, parent=root)
          node2 = makeNode(x2,y2,z2, parent=node1)
          myshader = '''
vec4 gl_Position;
  float gl_PointSize;
  float gl_ClipDistance[];
...
          '''
         scene.addShader(myshader)
         keypressmap= {"k":"jump", "k_down":"stopjump", "w":"forward" ...}
         node2.loadMesh("first_person_char.fbx")
         node1.loadMesh("first_person_scene.fbx")

         #insert here : lots of collision detection setup code
         #insert here : lots of lighting setup 

         def updatescene():
              if kepressmap["foo"].bar.blah.bam:
                  node1.moveSomplace(x,y,z)
              #insert here: lots of AI, frame processing, etc.
         scene.run (updatescene)

At first glance I think many wouldn’t see much issue with that style of code. But from the perspective of one who may have much more experience with other game engines / code styles they could think a few things:

  • Why do I need to setup super basic shaders in my game main setup code? Isn’t there some default or basic rendering supported by the engine that allows me to just load media? It’s definitely the case for other engines. I can just model some media and load, no need for writing shader code.

  • Likewise for input and camera handling for a 1st person game - does this really need to be written from scratch every time? It seems like this could have been abstracted already into a very basic input class

  • First person, third person, top-down camera management, pretty much encompasses the majority of game styles out there - one would expect not to have to write this from scratch for each game as well

  • On the style of the code written here - everything is in one / few methods, hard to re-use or split out logic. Hard to decipher which part of the code is for which task (scene setup vs, input setup, vs AI, etc.) Also the user could go down the wrong path by adding even ‘more’ code, and this method/file would become complete unmaintainable.

Anyhow - this is why I think it’s good to have some thought put into the sample code design. To flesh out more along the right path - consider the ‘declarative’ DSL style of writing code that is in this article that I referenced.

If things were more modular, and a declarative style was used, code could look like this:


    #3rd person game example
    import .... deps ....
    def main():
        MyApp(loadScene="myscene.blend", 
              controller=3rdPersonController(playerMesh="player.fbx"),
              sceneNodes=[
                 NPCNode(model="mynpc1.fbx", ai=HostileAI()),
                 Node(model="button.fbx", collisionLogic=OpenDoor(id="door1"))
              ]).run()

    

    #1st person game example
    import ... deps ...
    def main():
        MyApp(loadScene="myscene.blend", 
              controller=FirstPersonController(playerMesh="player.fbx"),
              sceneNodes=[
                 NPCNode(model="mynpc1.fbx", ai=HostileAI()),
                 Node(model="button.fbx", collisionLogic=OpenDoor(id="door1"))
              ]).run()

Note how to go from a ‘First person’ to a ‘Third person’ game style you only had to change one line of code. Likewise we could open the .py source (in the samples folders) for each of these classes and see how they work, change/customize, etc.

It’s also comforting to know, that at least in a simple sample, a game could be working in ~15 lines of code, with advanced functionality. These samples could have fully working collision, camera management, etc.

Happy to hear more thoughts here. I know this is probably a lot more code-engineering and architecture than most might have expected to put into game engine samples, but I think the little extra effort here goes a very long way to making Panda infinitely simpler to use.

Thanks!