Contribution ideas - more GAME samples!

That is good to read! I do think that there’s the potential to come up with some neat stuff for such samples! :slight_smile:

(I would suggest that some version–possibly updated–of the Asteroids sample remain. I think that such a thing does provide a very simple sample of a functional game.)

‘Teaching’ I think is the key concern here. I wouldn’t say samples ‘teach’ - that’s more suited for tutorials. (or lessons, classes, college degrees, etc.). These things/assets that would be external to an official distribution of a game engine (maybe the help manual an exception, but even those tutorials would likely be on the web someplace, maybe with live videos / etc. included.)

I would also go so far to recommend, that any sample in the ‘official’ Panda distro that isn’t an actual playable game (or part of one) might eventually get removed. You wouldn’t want a user to open up the Panda ‘samples’ and get confused / intimidated, and think ‘oh my gosh, this rendering demo is so complicated already, how do I go from this to a real game?’ panic, and then run from what’s a perfectly awesome & capable game engine.

Rather, I’d like to see the user open the sample folder and say ‘Look at all these great game ideas I can make with Panda!’, and then tucked away in maybe some subfolder - some really exotic low level rendering demo or 2, if needed. But even then, I think all mechanics around collision, rendering, animation, networking, etc - could just be part of an actual game sample of some sort, this would frame those concepts much better being in a game scenario.

Absolutely!! Totally agreed!! Now we can dive into some execution ideas, fun stuff =)

So here’s (just a proposal) of where I’d like to contribute a good portion of work (And happy if others would like to help!!!)

  • First start with a fix to Roaming Ralph (either update and deprecate, or make a new sample) I’m OK with all those options. This sample covers lots of great things (animation, collision, 3rd person camera stuff)

  • Next - extend the sample code by adding potentially more samples, that could add some code for:

    • AI - add some things that move into the Ralph scene. Without duplicating any code already within Ralph, since it already has all that’s needed (a scene, collision meshes, etc.) make a very small sample that runs the Ralph demo with some new scene elements of sort roaming about. Some logic for what happens if Ralph bumps into them
    • PIcking - user can click things in the scene, and - things happen in the Ralph universe
    • Sync the states of the nodes in the scene over a socket - there is now a multiplayer game demo
    • Add some UI so players can chat - now a UI sample
    • Change the camera angle, now you have a 1st person game sample
    • Change the camera angle again, and we have a top-down game - user can move ralph by clicking around
    • Change the camera angle yet again - tweak controls, shows how Ralph might move around in a side scroller or 2.5d game
    • Swap out the meshes for any of the above with sprites/billboards and now we have 2d equivalents of all the above

… etc … essentially adding some ‘game samples’ without introducing much more code than you really already have in a Ralph sample.

Of course all just my opinions here! I’m happy to change them - and likely will, for the short term for me really is patching Ralph up so it just works well, removes the bugs.

Love to hear ideas (or from anyone that wants to help hack on this stuff!!)

If samples don’t teach, then there’s no concern about showing good code practices–after all, the only people who are going to see the code are the devs. :stuck_out_tongue_winking_eye:

Conversely, if the intent is that new users see the samples and learn from them, then they’re teaching tools.

I’m pretty confident that the current samples are at the least used as learning tools–as examples of how things are done in Panda.

It’s not clear to me whether you mean the samples or the tutorials here; I’m thinking of samples that might be included in the official distribution, just as the current samples are–indeed, in some cases replacing those samples.

To my mind that’s more the province of a showcase. A showcase, by virtue of not immediately showing its code, can hold examples that are too complex to be a beginner’s first introduction to the game. Since they can be more complex, they can show some of the strength of the engine.

Likewise, one doesn’t want the user to open up the sample folders, see examples that build on examples, none of which they yet understand in a structure that they’re not yet familiar with, panic, and run from an engine that’s more simple to use than they realise. :stuck_out_tongue:

I very much agree with reworking Roaming Ralph. The question, however, is that of how it’s to be done.

You thus far have advocated for a modular approach; for Roaming Ralph, and for samples in general, I’m opposed to that. I would rather have everything for a given sample in a single sample-file (aside from variants of a given sample), and the sample itself kept to simple approaches.

Basically, I’d likely keep the core idea of Ralph much the same, just better-implemented.

Again, this is where I disagree. I do think that some of the things that you propose are good ideas (picking being a good example, I think), but I would rather that they each had their own sample.

I actually like all of these ideas. It will likely take somebody besides me to update it though; I do not have much experience working with the internal collision system. I wouldn’t even know what to suggest to start, actually. There was a post a few months ago by a member here who posted an automatic collision generator for the internal collision system (is that the formal name we’re using?). It seems like we have “the internal collision system”, Bullet, and ODE which is being deprecated.

From my practical perspective as somebody who just needs to prototype 4-dimensional designs on a regular basis, and who is a lifelong gamer, what I find important in a sample program is the actual workflow being presented. If you do not have a clear way of adding assets and modifying assets, it crystalizes the sample.

I think this is perfectly doable, especially for the /main/ sample application code! (Other imports, like of engine modules… won’t ever go away, but I’m assuming those are OK since all samples have those to function today).

Awesome! Right now I’m looking into similar, just poking at Ralph’s code trying to smooth out the collision bugs and fix the camera control. Currently still colliding with anything paralyzes Ralph completely, unable to move. So looking at how to best smooth some of that collision/response logic out better. I’ll post as I go for sure! Happy to collaborate!

Agreed here. I’d also love to help flesh this out better in some docs/tutorials/samples . I do have some experience writing Blender plugins so if need be, happy to automate that workflow.

Back when Blender Game Engine was a thing I did mess with that as well. I’d like to see if we can integrate Panda more tightly, possibly even a Panda preview button from Blender… just ideas for later (once some sample code is running here)

I just wanted to say this thing is REALLY cool. I would totally love for this to work like jsfiddle where we could collaborate on some Panda code, share the links with each other here. And work on Panda code together.

Is the code for this easily hackable? Can one pull it, add some hacks and redeploy?

There were not many games completed with it, as I remember.

Blender and Panda3D do seem to be pretty mixed at this point. One as a framework for logic and the other as a modeling and skeletal animation interface.

As for the preview in panda, I remember @moguri doing something similar in his plugin. However, this is slow, you need to pass the context to panda, call the frame, take back the buffer output. This is clearly not something to think about, it is a passed stage.

I think the existing is OK, with just working physics. But I don’t have any experience yet with ‘Panda’ physics, so not sure yet if it’s faster to swap the terrain out with something better (happy to whip it up in Blender) or, gen it procedurally, or other (there is a terrain engine, I’ve noticed! has collision been implemented there yet?)

The collision is the grid data. In the role of this is the usual geometry, which is usually easier than for rendering geometry.

And yes, collisions are not physics. A math intersection of geometry.

One thing the built-in collision system does is straightforward character welding, which is not necessarily the case with the current state of the Bullet methods.

Here’s an example of a more sophisticated Ralph variant:

1 Like

Need to add to the examples :slightly_smiling_face:

That’s fair–and a good argument for overhauling what we currently have, I believe.

Oh, of course! I’m not suggesting that I want the entire engine replicated in one file! XD;

Would you like some help there (whether advice or reference-code), or would you prefer to work on it yourself?

Let me note that we do have a few Blender exporters around–for two, we have “blend2bam” and “YABEE”, albeit that the latter only supports versions of Blender before 2.8, I believe.

That said, a better one, or an improvement to one that we have, could well be excellent! :slight_smile:

Right, there’s no need to reinvent the wheel. I do think there is an elegance of the Blender plugin system ingesting a .zip file and having all of our modeling and animation needs met at the Blender export stage, without running a command line program for instance.