There’s probably a bit of cleanup that could be done in the code, too, I imagine–but nothing huge, I suspect, and overall I agree with you.
Yes there is a problem with the approach in the code:
if len(entries) > 0 and entries[0].getIntoNode().getName() == "terrain":
self.ralph.setZ(entries[0].getSurfacePoint(render).getZ())
else:
self.ralph.setPos(startpos)
The condition is superfluous, you need to detect the collision of the beam with the entire geometry. And then do the desired behavior.
1 Like
Or rather, to my mind, use a bitmask to control what collides.
(An “else” can be useful in such simple approaches as this, handling cases of the ray slipping into geometry gaps. However, I’d change what’s actually there, I think.)
I meant to make more extensive use of this data. In any case, you need to know what the beam is aimed at. It is useful for playing sounds, walking on the surface, and much more.
For what it’s worth, I don’t think I can modify the Ralph assets myself because of the formats.
I had an idea to model the global level. However, the problem is with the terrain.
GeoMipTerrain is already deprecated. And ShaderTerrainMesh does not support collisions.
Creating a geometry in a blender is not an option.
Ah, I see what you’re saying, I believe.
In that case, I’m inclined to keep Ralph simpler than that, myself: just stick to running around on an uneven surface.
Honestly, I’m thinking more along the lines of replacing them entirely.
Why is Blender geometry not an option? For so small an area, that would be my inclination, I think.
That may be easier. We could at least make it a seamless animation, instead of so twitchy.
1 Like
# Set up the environment # # This environment model contains collision meshes. If you look # in the egg file, you will see the following: # # <Collide> { Polyset keep descend } # # This tag causes the following mesh to be converted to a collision # mesh -- a mesh which is optimized for collision, not rendering. # It also keeps the original mesh, so there are now two copies --- # one optimized for rendering, one for collisions. self.environ = loader.loadModel("models/world") self.environ.reparentTo(render)
So it seems like, in the case of the Ralph program, we might be able to use this tag to mark geometry for ODE collision from a current-day .bam file? I am not familiar with this procedure.
This is not necessary, as I said before. For other game mechanics, we need a different example.
I looked at some of the fully animated characters from https://quaternius.com/ and they are pretty small, low poly, and don’t look terrible. Textures around 200k, and the meshes as low as 500kb in OBJ format up to 2MB in .blend format, with several animations included. I’m sure we could cut out 90% more fat / anims we don’t need them!
Ralph is almost a nostalgic museum artifact at this point, we might almost want to keep it and spin up a new 3rd person sample (I think we could do several ‘full games’ with procedural and lo-fi media as @Simulan stated, this is an awesome idea!!)
I’m cracking open the IDE and blender now to see if I can get some quaternius media to load. Just to see if it’s even compatible with Panda.
Weekends off! You folks are funny. Software industry has been very unlike Banking in my experience =)
10,000,000 lines over 30 years, given a 40 hour work week (which I’ve never had the luxury of unfortunately) = 166 lines per hour written. I’ve seen folks fired for having ‘more’ code output than this!
Keep in mind most of this will have been before things like ‘git’ or ‘github’ even existed, it’s not actually possible to tally all the code one’s written so far back. I’m just guessing, and for an old greybeard programmer, who knows how many brain cells are still up there, maybe its way off =) But it honestly feels like it’s been much more. There are 2 million lines in unreal engine 4 for reference.
Here’s the crux of where I disagree. Panda being a game engine, should have samples that show how to make games. If one is just looking for a renderer there are many out there (Ogre3d had Python extensions, Crystal Space), aside from using OpenGLES or one of the many wrappers like Three.js. You’d typically reach for a ‘game engine’ for game building, not to be a renderer.
One /might/ go so far to say the ‘renderer’ samples should be punted out into some 3rd party add-on repository, what comes with Panda should be only ‘game’ samples, starting from the very basic (tic tac toe style) to the very complex, ie - 1st person or 3rd person samples. etc.
In fact, Panda has many examples that teach you how to create games and advanced graphics.:
The examples should show how to use the Panda classes and no more. Logic is an individual concept and should be in the background.
The dialogue has already dragged on, and I haven’t seen any suggestions other than what needs to be done “cool”
And more specifically? Ralph’s cons? Please list them.
Honestly, I wouldn’t suggest using ODE at all–from what I gather, it’s somewhat of a legacy inclusion at this point.
And anyway, for simpler purposes Panda’s built-in system is likely more than enough; I’d rather stick with that for something like Ralph.
Honestly, if we don’t use Ralph as a “proper” example, then I’d rather not keep it–I really don’t want new users looking at it and thinking that it’s a good demonstration of what Panda can do! ^^;
Ouch! I’m sorry to read that this has been your experience thus far! :/
(To be clear, while I doubt that I have as much time in the industry as you, I do speak as someone with some experience of it.)
I don’t think that anyone is suggesting that we only have rendering samples. After all, Roaming Ralph itself is a gameplay sample! So too is Asteroids, and the ball-in-maze sample.
I just think that a fuller-scale lesson on “how to make a game” is perhaps better left to the detail of a tutorial–and further, is not one of the first lessons that a new developer has set in front of them.
I want new devs to start off with small, easily-digestible lessons before moving on to bigger things. Once they’ve seen those, then I’m comfortable with presenting them with one or more tutorials that detail the hows and whys of a larger project.
We were discussing the ‘official’ repo (included with engine). These seem to be more rendering samples rather than ‘game samples’
I’d add … ‘to make games’. (Being that Panda is a game engine)
Sometimes positive change can be slow and painful =)
The thread is long - lots of great ideas are bubbling up as we work through ideas. Some I stickied into the original message… wonderful samples built by folks in this thread!!
Also see my post a bit back, regarding media for improving a sample like Ralph.
My original post listed this I thought in great detail. It has a few bugs / needs a few improvements.
As always thanks for all the amazing help and feedback!!! Excited to see where this goes.
Only those who can program can create games. The official samples are not a programming textbook. This role is performed by other web resources.
Your post has an idea to create a new sample that looks like Ralph. This does not affect the old example in any way. At the moment, at least, there are not enough sketches, art works.
I propose to solve the first stage.
- Level, terrain … this already needs to be worked out. At this stage, the style of the code and so on does not matter.
What is included in it and how do you imagine it?
Yes agreed, but to clarify - for a game engine they should be lessons on making ‘games’ not on basics of rendering/ etc.
It’s totally OK to have the latter, but we’re currently in need of more in the area of the former as well. This is the main focus of starting this thread and where I’d love to contribute. Improving Pandas official ‘game samples’.
And I’m in the code now to keep progress. Love to hear any ideas and feedback here ! I’m happy to tweak all of this work so it fits what we all feel is best. More minds always gives better results, for sure!!
However, it is worth recognizing that it is easier to learn programming by creating games. On this basis, you can create many step-by-step lessons.
I’m not sure that I agree. I would argue that it makes sense for the samples for an engine to teach the use of that engine, to teach the elements of the engine that they might expect to deal with–and since Panda tends to not provide a lot of game-logic elements, its samples don’t provide a lot of game-logic lessons.
The more-general teaching of game-making is, I think, something separate from any one engine, and outside the scope of the samples of any one engine.
That said, it might be worth thinking about which elements it’s important to have samples for.
- A few basic games does seem like a good idea.
- And we have that: Roaming Ralph, Asteroids, and Ball-in-Maze; that seems fine to me.
- Otherwise, some fun visual flash seems like a good idea, to once again show the engine being capable
- But indeed, perhaps we do lean too heavily on rendering with things like the Firefly and Render-to-Texture samples.
- Things that might seem tricky, but that are fairly straightforward, might be wise.
- Collision comes to mind–good samples for both internal collision and Bullet physics seems like a good idea.
Hmm… I’m not sure offhand of what else…
FWIW, even though there might be sentimental values in some of the classical samples, I’d be happy for us to get rid of some of the samples to replace them with more modern and interesting-looking ones.
I’m certainly more than happy to kick Fireflies out, since it’s way too complicated and not really a good reference for deferred rendering.
I agree with sticking with the built-in collision system instead of ODE.
Let me know if I can help with the code at any point.