‘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.
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.
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?
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?)
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.