Contribution ideas - more GAME samples!

Panda Features in Development
181

Once we have some really nice and catchy samples working I’m certain that more would be motivated to join the chat! As is right now it’s been a lot of basics and comp-sci theory, I can see where most might want to stay silent. Normally things ‘perk up’ once there are shiny toys to play with!

But you’ve helped the final product greatly so far, so I appreciate the participation, even if the forum doesn’t!!

I do agree here partially - once the sample code is closer to completion I propose we do some test-refactorings to see how much we can improve readability (I’m happy to do this with my own code as well).

In the mean time - I do want to be sure we’re being open minded as well. Forcing a user to scroll up / down in a massive source file isn’t always ideal, sometimes it’s better for a user to maybe flip between tabs in an IDE…

My thoughts here - once code get’s to a certain size ‘some’ compromises need to happen, that can result in excessive scrolling, vertically, for a user to read code - (since it can’t all be onscreen at once), but I also postulate that at times, switching to another IDE tab, which may feel more like a ‘horizontal’ action - is also acceptable in some cases. Not all cases of course - but the minutiae here we can debate deeply once we get to the point of assembling the code into a ‘official sample’ pull request. At that time as well we might want to pull in many other eyes to make sure we’re doing what works broadly for the panda community. I wouldn’t want my own personal opinion (or a select few) to make the wrong choice… agreed?

Thanks again for all the awesome discussion! I’m excited to see where things go here :slight_smile:

182

It’s not really an issue only specific to this topic; indeed, I’ve seen the same warning before. It’s something that turns up when one has been replying a lot in a single thread, I gather.

Thank you; I appreciate that. :slight_smile:

That’s very fair, I think. :slight_smile:

Of course–but Roaming Ralph in its original form wasn’t a massive source-file, I’d argue. Indeed, it was short enough that I was quite comfortable to have it in a single file.

Also, note that not all new devs are familiar with IDEs–some may still be using basic text-editors.

Otherwise, I do very much agree! Don’t take my qualms here to mean that I prefer to have everything in one file regardless of size! ^^;

183

I guess I’m not being warned since I created the thread. Nonetheless, if a mod gets angry let me know, I’ll vote to keep the most productive contributors going - always! :slight_smile:

For sure, agreed here… especially with some code cleanup we could potentially even make it shorter and even easier to ingest in a single file.

What I’ve done now is actually create several samples (including refactored the Ralph sample) so that they actually all share about 80-90% of the code.

Going with the single-file sample idea, I’d have to duplicate the shared code - several times to paste it into each application’s main file. And if I find a bug (or refactor a piece, like physics or networking) now I need to go into each file and copy/paste that fix. As you can imagine it could turn into a maintainability nightmare. At least during the development phase of this.

For release - we could do the recombination - and create a bunch of standalone samples with no imports - which I’m supportive of. If we feel it helps each individual samples’ readability I’m OK to do this. Maintenance of these samples might get problematic, bug fixing / etc - so I would feel really terrible for the Panda team or contributors to copy/paste bug fixes into several samples constantly, but - if we feel this is necessary I’m still open to the idea.

Totally open for more ideas here, if you have them please do send!! Promise that I’m totally flexible here. The main goal is to get more ‘game samples’ into the Panda distro to benefits it’s future users, anything that helps use get to that goal I’m totally supportive of!!

Thanks :slight_smile:

184

@svf We may have extended the conversation to the point that other developers here are fatigued by the volume of posts – just a consideration. Also, as I said before, we have quite a lot of more practical work to do on the engine besides updating samples, which is not even in the list of officially recognized open issues, if I recall correctly. My impression is that any time spent on your effort is “extra” time.

That said, I have a few concepts I’m working on, which may eventually improve the program samples. One is a Bullet Vehicle demo (repeated effort to some extent, because we already have a Bullet Vehicle sample in the SDK I believe) where the player can drive a truck around uneven terrain or roads. No guarantee when or if I will finish it. Here’s some work I did in a similar vein already: Intersection Simulation with 18 Bullet Vehicles (made in 5 days)

In regards to putting “full games” in the sample directory, I feel we should address @Thaumaturge 's concern that it may be out of scope to teach developers game design, game theory, or the advanced practices of our trade. I think I basically agree with this.

The tension here is between whether we’re trying to impart trade skills or if we’re trying to impress newcomers with the sophistication of our engine. The later is an unmitigated win, I think, while the former has some scope issues.

185

Are we saying that a ‘game engine’ shouldn’t have ‘game samples’ included? You can see where this might seem… odd ? :slight_smile:

If (assuming if) said samples can be made simple enough, I don’t see the harm here in giving it a shot. At least the efforts here allow us to explore the option. I totally understand if they end up being too complex or to bloated to include, in that case they might get packaged differently.

You’ll have to understand your point is self-contradictory here. You’re saying that ‘we’d like to impress newcomers with the sophistication of our engine’ but you need /game/ examples to do that, hello world/rendering samples alone won’t get you there.

186

Thank you–although I think that it’s an automated warning, not a mod thing!

I can definitely see that modularisation would be helpful during the development phase!

That said, how many samples do reuse the same elements? If it’s a great many, do they perhaps share too much?

This is also a possibility–this has been a long thread, with a fair bit of text at times.

These do sound interesting, I think! :slight_smile:

My own feeling lies somewhere between the two: I see the samples in part as impressing newcomers, in part showing them some of the cool things that they can do with the engine, and in part providing them with examples of certain basic elements of using the engine. Things that they might trip up on, like moving a character over uneven terrain, or that they might not know exist, like mouse-modes.

Not necessarily: whether it’s odd depends, I daresay, on what you perceive such samples to be and what you perceive their purpose to be.

Right now the samples appear to be primarily a feature-showcase; in that case, full games would seem largely superfluous.

That said, I do agree with having some “full games”, of roughly the scope of the “Asteroids” sample or simpler. However, I would also want them to be in the minority, I think.

I disagree: one can impress via a show of features–especially when attempting to appeal to devs, not players.

187

Ahh and here is the crux, because it’s been done this way in the past isn’t justification for the future - as one might imagine maybe there just hasn’t been bandwidth to implement the idea. Or the design, which is why I volunteered!

We have to be careful here - on user expectations.

Say, one purchases a coffee machine, the ‘impressive feature’ would be to make good coffee. If it only came with the ability to say - heat water, one might say ‘is this a great coffee maker, or hot water heater?’

The same goes for a ‘game engine’. It should showcase how some impressive games could be made or… one might assume that making full games is outside the scope of the ‘game engine’. (Rather consider it a nice renderer that might make games one day, or with much effort…)

I think this effort here proposes to go very far to fix this gap. I fear I’m repeating myself too much on this… but I think it’s important to lay this foundation so we can make some progress!!

188

And with the long silence I shall declare, at long last, we have reached vehement agreement!!! :slight_smile:

189

Er, no, going by the time-stamp I think that I had either shut down my computer for the night or was close to doing so. One way or another, I only just saw the post before the one just quoted, I believe; it may be similar for others.

Disagreement incoming. :stuck_out_tongue:

Of course; I don’t think that I was attempting to say that said past approach necessarily justifies keeping things so. Rather, I believe that my point was to use that previous approach to show that there are perspectives from which omitting full games isn’t odd.

While I agree to some degree that having full games to display is likely a good idea, where I disagree is on those games being included in the samples.

Rather, to my mind impressive games would be better displayed in a showcase, where we don’t have to worry about their being overwhelming to new devs.

The showcase–something likely seen on the website, before the new dev even downloads the engine–can say: “Look! Here are things that can be made with this engine! Imagine what you can do!” Or something like that.

The samples, on the other hand, seen once the new dev has downloaded the engine and is starting to investigate it, say: “Here are neat things that can be done in the engine–impressive or useful features that you might not know, techniques that might help you, that sort of thing. Learn from these.”

190

To rephrase this exchange - this is how I interpreted it:

Point 1: ‘a coffee machine should demonstrate how to make coffee, it would be odd if not’

Counter Point: ‘This coffee machine has never been able to demonstrate how to make actual coffee. It’s always been this way, therefore not odd at all’

You can see from the ‘users’ perspective (not the manufacturers) that this comes across as odd. Worse yet it would discourage users from using that coffee maker - and who would blame them? Their expectation is valid and understandable.

I propose we continue with the former, while also keeping the latter ‘as a potential goal’. But re-evaluate the latter once the former is complete, as we’ll have concrete code in hand we can analyze and better determine if it actually is not suited for the latter. I do feel this is very doable with the right coding practices and design, but willing to prove this with actual code - philosophically I don’t think we can make this determination, so lets look at the code.

If the code doesn’t end up fitting in the ‘official sample repo’ I would be open to look at other methods to package it as well. As that still helps resolve the original goal ‘more GAME samples’, but in a slightly different way.

Yes agreed that this should be an option. But we already have ‘Roaming Ralph’ in the official sample repo. I think its fair to say that other samples of /roughly/ equivalent complexity should be allowed in the official repo as well.

We do agree that there is some artificial level of complexity/size that which moving beyond necessitates moving to a showcase repo - but we don’t know yet that the proposed samples cross that line, hence my proposal to give this a shot. And if it fails - not really huge harm done, we then think about how ‘official showcases’ might look once we get to that point.

Yes absolutely love the idea and we should leave this on the table. But let’s not scratch the idea of extending the ‘official samples’ yet - we haven’t yet fully determined whether these samples actually are unsuited.

We have to be cautious here - because although that may be the intention (And its well intended) what the user may actually interpret is:

“Here is a game engine, but only with samples of rendering, because actually making games is actually way too complicated for us to show you, hence go google it and hopefully you’ll find some crazy SOB who has figured all that complexity already”

Completely agree that these samples are indeed helpful. But consider also that some of these existing samples /are/ already actually simple games, and extending that set isn’t against any of the canonical principles that Panda has already set - hence the proposals to extend these.

Let me know if you still disagree, happy to discuss further!!

191

There’s a difference in complexity: one can easily convey how to make a cup of coffee in a single page; that just isn’t feasible for a game much more complex than, say, Asteroids.

As a result, what’s reasonable for the coffee machine–including full operating instructions alongside discussion of special features–just isn’t all that feasible with game-dev.

To hyperbolise slightly, imagine that your coffee machine came with a “quick start guide” that was three hundred pages long, all required in order to produce your coffee. Would that not be intimidating? Especially if you’d never used a coffee-maker before?

Further, the best coffee-maker analogy to the samples would, I think, be feature-inserts on the box–those things that show cool stuff that one can do with a coffee machine. The actual instructions provided within would be more like a tutorial: a textual description, possibly illustrated, of how to go about a given task.

This is… not an accurate reading of my counter-point, I don’t think! XD;

Rather, I think that I was saying that it if one perceives the samples to be intended to show off features, then it’s not odd that there are few to no full games amongst them.

That’s fair; let’s see what happens when you’re done!

Also fair. I’ve been saying, for one, that full games of larger scale might work well in a showcase on the website.

Yup–as long as they don’t overwhelm the “feature” samples. There’s also the question of how close falls into “roughly equivalent”–but I’m content to consider that when we have something in front of us.

Let me just add here–not in opposition, just in general–that I do really want to see a new showcase on the site! Something with plenty of cool stuff made with Panda that people can immediately see.

I think that we foresee likely new-dev responses somewhat differently!

Indeed–but as with many things, such can be taken too far. I do agree–and I think that I’ve said before–that having some games, of limited size, is not a bad thing, and may even be a good thing.

And… well, we do have some games. We have Asteroids, and we have Ball-in-Maze.

Should there be more? Maybe. But not so many that they drown out the feature-samples (which I think are overall more important), and not so complex that they drive away new devs who are using Notepad to code and are just getting their feet wet.

But as you suggested, I’m content to wait and see what you come up with.

192

Awesome!! I think we’re both actually in full agreement on the approach we should take here!

So to clarify clearly we’ll proceed with a good faith effort to solve the need here of creating ‘official game samples in the official’ repo … WITH the stipulation that, if the work done doesn’t look to fit an official sample (after reviewing the completed products), we can push it to a some sort of official showcase repo or otherwise.

Thanks for all the great discussion, I do think the final strategy here is very fair!!

193

And thank you for being open to discussion!

And indeed, I’m interested to see what you come up with in the end! :slight_smile:

194

Awesome! Back to code then :slight_smile:

One other idea here, I’ve been toying with. Do we want to support the following sample layout:

  • samples/ai_sample
  • samples/collision_sample
  • samples/camera_sample
  • samples/game1
    • main.py
      • imports code from samples/ai_sample
      • imports code from samples/collision_sample
      • … custom game logic here …

If that makes sense. Do we want to allow in some cases for a more advanced sample to use any code from another? The idea here - we can have the best of both worlds, lots of fundamental rendering/feature samples, but also showcase them in a game without duplicating all that code.

Just an idea!

195

Hmm… I’m intuitively against it, but I think that you’ve made a good case for waiting and seeing what the outcome looks like. So I’m going to defer opinion until then, I think!

196

I’m on the fence with this one - we’d need to violate too many existing conventions. Doing an import of code from ‘main.py’ is confusing, and we’d need to litter the samples folders with init.py files to make this work… so I don’t know its even practical. But just in case anyone has some ideas here, feel free to post.

1 Like
197

It seems __init__.py files are no longer required from Python 3.3 onwards to identify a folder as a Python package. There are reports that their omission does cause issues with certain Python tools, though, but I don’t know if we need to worry about that?

Perhaps it would be acceptable to first import all of the main.py modules into a, say, samples/basic.py module like so:

from .ai_sample import main as ai
from .collision_sample import main as collision

and then do the imports within samples/game1/main.py as follows:

from samples.basic import ai
from samples.basic import collision

What do you think?

198

Actually __init__.py is needed if you want to create a package with the ability to import from its scope.
That is, the concept of package and the path to the class is now separated.

199

That would work, I daresay. However, it seems even less easy to learn from, to my mind, having two steps of indirection between source and reference. Further, I could see it being potentially-confusing to inexeprienced devs! ^^;

200

It would be true of the ‘complex’ samples, but the simpler ones, ie - what we have today - wouldn’t be changed in any way. (Other than the folder-littering of the init.py files… which is the part I don’t have a solution for…)

For more ‘complex’ samples - leveraging code of a former sample is better than creating or duplicating the same, I think is a great idea… overall for the user it’s less code for them to understand, and fits logically into the sample layout we have today. Also less maintenance overhead for folks who need to keep the more complex samples up to date.

Would love to find a way to make this work. (If not, no biggie… there are a few other ways to organize code to keep things manageable, for sure.)