So we have a new look for the brand new 1.10 (Yay!), but we still have the same old samples that look as if they were made 10 years ago (and they where). Maybe it’s time for something new?
Here’s my idea:
The samples should be a small tutorial, starting from simple things like importing ShowBase and loading models to more complex stuff like intervals, tasks, clicking on objects and player controls. Each step in the tutorial should introduce 3-4 new things and expand on what was made in the previous steps.
The style of the models should be simple, but not cartoon, so that it looks good without lights (FFP), looks better with lights and shadows and even work with PBR (probably with a different set of textures).
I can make some models, I can help plan out what should be in the tutorials, but I don’t think I’m the best person to actually write the code (my code style… well, let’s just say it’s not all that PEP8 compliant).
If I remember that the idea is not new, I saw how the new ralf was redone and everything was forgotten. I think that you should show by example how the new style of models should look. I can at least generate a few sounds, because recently I have been learning VST synthesizers.
I like this idea! (And the new site looks rather slick, by the way!)
I’m tempted to offer to help, but I’m not sure that I have the time to dedicate to a tutorial that was quite that extensive.
I might be able to contribute a small tutorial program–I was thinking of a simple top-down “endless enemies” score-shooter. It would demonstrate basic Panda usage (extending ShowBase, disabling the default camera controls, running the game, etc.); simple key-handling via “accept”; basic enemy- and player- classes, perhaps showing derivation from a shared base-class; simple collision via Panda’s built-in system; and some basic DirectGUI usage.
Regarding coding style, I’m not in a position to speak to whether my style is idiomatic; I have my own style.
I’m a beginner in panda3d and I can tell you anyway the difficult points that need a tutorial.
what technologies are used and avoid wasting time in old obsolete codes.
For example, use Bullet physic engine not ODE or native panda physic.
I can do it.
Create terrain with collision detection ! I lost 1 month to understand how to make ralf walks on a ShaderTerrainMesh !!!
I can do it.
Today I would like a tutorial that explains how to display trees and grass in a optimise code
There is currently no panda3d project that displays a grass field or a forest !
In 2019, however, it is something “basic”
I can not do it.
But, with lot of work i was able to create a mini game with
But I think an example to present to the community would be nice
I can do it.
The graphics game
If there hadn’t been the beautiful images of RenderPipeline I wouldn’t have used panda3d
Without RenderPipeline, panda3d is uglier than Quake2, it hardly attracts people
I’m not a graphic designer/texture, I can not do it.
A last tutorial with the all-combined tutorial :
A little technical demo like Crysis could be really nice, not game, a pretty landscape with snow mountains, a forest, an ocean…) run with RenderPipeline
An example that explains well : You have put a lot of renderer pipeline beautiful images on the official panda3d website, but nothing of a real game like YORG
Because Yorg is good game but it’s very ugly.
the pretty but useless mountain of RenderPipeline attracts more than an ugly but functional game
I’m datascientist and i not use AI library of panda3d, i use scikit learn and tensor flow for develop complex AI.
I don’t think it’s useful to do complex tutorials on artificial intelligence, because Python has many libraries better than what panda3d offers (like scikit learn and tensor flow)
The current basic tutorials are sufficient I think
I don’t think that Panda’s built-in physics system is obsolete, myself: I find that it’s perfectly fine for simple games. Further, it feels to me to be a bit simpler to use than Bullet–although that may be due to familiarity, in all fairness.
For more complex projects, Bullet is indeed quite effective.
Indeed, I currently have two projects underway: a large, complex game that uses Bullet, and a much simpler project that uses Panda’s built-in physics. In both cases I find that I’m happy with the results.
For simple games, and especially ones that don’t use a close third-person camera, I think that one could easily use a much simpler controller.
That said, if it “just works” out of the box, and isn’t too performance-intensive, then I can see this one being useful as a catch-all.
I’m inclined to disagree: I think that much comes down to the models and textures used. (Especially when a stylised aesthetic is used.) I fear that many of the examples on the Panda website are somewhat old, and thus may give the impression that they’re all that the engine can handle without RenderPipeline.
Setting up ShowBase, config variables, loading assets, setting position, rotation, scale, changing a color and a texture of a model, playing animations, parenting nodes to other nodes.
-how to import panda3d (from panda3d import core? from panda3d.import *? import panda3d.core as p3d?)
-how to use ShowBase ( ShowBase.__init__(self)? ShowBase.ShowBase()?)
-snake_case, CamelCase, properties?
Making a task that controls camera and player movement.
-what is the proper way? key map? input_state?
Loading and playing sounds and music. This is so late because I first would want to show a way to run a function after a key press, so that sounds can be played when a key is pressed.
A flyby cutscene using sequences, parallels, intervals.
Intro to Bullet collision detection, clicking on 3D objects
Make objects fall, collide, slide, etc. Control a kinematic object - making the player not run through walls.
I like that idea, but I feel that it might be a good idea to start with a smaller, simpler tutorial–something that produces a complete (if basic) game after only a few lessons. That way the reader has the encouragement of an early success, rather than only receiving that after a long, uncertain series of lessons.
Specifically, I’d likely omit steps 4 through 10, inclusive. (With regards to step 5, I’d just do much the same with Panda’s physics system, and leaving out clicking on 3D objects.)
That said, I would like to see something like your outline too, as a more advanced tutorial. To that end, my main critique is that I might separate out the “terrain” step into its own tutorial: plenty of games don’t require heightmapped terrains, so the specifics of that can be left for those who are making such games, I feel.
Hmm… I’d suggest inheriting from ShowBase, myself–but I’ll confess that I don’t really have a good argument one way or another.
To this, I’m inclined to suggest that we not worry about it, beyond a given tutorial being consistent throughout. A given programmer’s style doesn’t seem terribly important to me, beyond readability in a team environment.
And if different tutorials end up having different styles, then that might just reinforce the idea that different programmers have different styles, rather than there being a single “correct” style.
It does seem to me that there may be a concern that this would make the tutorials seem inconsistent overall; in this case, the tutorials could perhaps be given by-lines, or even just a line at the start indicating the chosen style.
… I’ll confess that I’m not sure of what you mean by “input_state”. Is this an approach that I’m not familiar with? ^^;
Here I would suggest starting with simple custom shaders–maybe a custom toon shader, or a rim-lighting shader–before getting into the more complex stuff. Thus I suggest making two steps of this.
That really depends on whether we do actually select a new GUI toolkit, to my mind.
Otherwise… For basic usage, DirectGUI… works. It’s clunky, but it does the job. For a beginner tutorial, I think that it would likely be fine. But if we do treat your tutorial as an advanced one, maybe it would be worth considering having this introduce the reader to the integration of some other GUI toolkit.
Honestly, I’d forgotten about this! Good point. ^^;
As to a simpler “beginner” tutorial, I’m inclined to stick with what I suggested above, which might look something like this:
Much as with your tutorial, this would involve setting up ShowBase; basic model-loading; parenting; positioning, rotation, and scaling; and Actors and animations (including the caveat about keeping a reference to them!).
“Accepting” key-events; likely a basic key-map setup
Setting up a simple class-hierarchy–likely something like this:
A (Showbase-derived) “Game” class, which holds an instance of a “Level” class.
A base “GameObject” class, from which is derived simple “Enemy” and “Player” classes
– The base class would handle health, damage, the object’s nodes, and movement
– The enemy class would have AI to seek and attack the player
– The player class would handle input
Perhaps a simple “Weapon” class with some derived specifics, to show how that might be used
Using Panda’s physics system to prevent the player from moving through walls, and to implement weapons-fire hitting things. Responses to collision events for weapons-fire. Perhaps a note that Bullet can be used for more-complex gameplay.
As you said: loading and playing sounds, and having them occur in response to things.
Score, health, and perhaps ammo/weapon UI elements. This is followed by a simple “main menu”, and a “game-over”/“score” dialogue box.
As you say, using setuptools
You may note that I leave out lighting, shaders, etc… In the interest of simplicity, I envisage this tutorial-game using a simple unlit art-style, with textures being used to distinguish objects.
If there’s a concern that this looks too simplistic, and thus may mislead readers as to Panda’s capabilities, we could perhaps add basic usage of the automatic shader-generator.
Finally, I’m not quite sure of where best to fit introduction to the camera. Perhaps in the first lesson, where we might set up a basic “top-down” camera. Later, if desired, it might be parented to the player-character.
By input_state I had in mind from direct.showbase.InputStateGlobal import inputState. You tell it to watch for some key events inputState.watch_with_modifiers('foobar', 'x') and later check if it happened if inputState.is_set('foobar'): do_foobar('bacon', 'spam')
I’d like to put in lights, shadows and some shader-foo because I’d like it to look if not ‘good’ then at least modern(-ish), and that’s also why I have my doubts about DirecrGui - it can be made to look good, but it takes many steps and a lot of spaghetti code.
I’m not sure about putting in AI in the tutorials - it would be nice, but PandAI ain’t nice. It could be AI implemented in Python and that could be a good way to introduce concurrency but I have this feeling some people will flee in terror at the first sign of async/await.
About the camera - I think it’s important to show a good replacement for the default camera driver because frankly the default camera driver is rubbish.
In general I agree - shorter and simpler is better.
Ah, I didn’t know about this mechanism! (Is it new, or have I just been unaware of it all these years? ^^; ) In that case, I’ll bow to those who know both systems well for an opinion on which to use in the tutorial.
That’s fair. In which case, I stick with my suggestion of using the built-in shader-generator for a “beginner” tutorial: it’s simple, it shows what Panda can do “out of the box”, and it can look decent, I think. Maybe have a single shadow-casting light and some models with normal-maps, perhaps even glow-maps or the like.
Again, largely fair, I think. However, I think that for a simple game, it could be made to look fine, at least: a single image-backdrop for the main menu; some buttons with images for each state and text overlaid; and a few labels for UI, score/game-over, and titles. It would be minimalist, but should be acceptable, I think. And I think that it wouldn’t be too complicated: the most complicated bit would be the state-images, but presuming that they’re provided, they should be easy to load via the “frameTexture” keyword argument.
That said, I am open to a new GUI system, should we settle on one.
Ah, there perhaps I worded myself poorly. I didn’t mean PandaAI, or even a third-party toolkit. I just meant basic logic: “Turn towards the player. If in weapon-range, shoot. If not, move forward.” Maybe some basic side-stepping to add a bit of challenge. Simple stuff.
I do agree! I didn’t mean to suggest that it be left out, I believe–just that I wasn’t sure of where to place it in the tutorial.
Thinking about camera-perspective, I’m tempted to suggest that a more-complex tutorial, such as your proposal, might take on a first-person camera: there are one or two tricks there that might be worth tutorialising, such as changing the near-plane to prevent the player from seeing through walls.