Contribution ideas - more GAME samples!

[Thaumaturge]

@svf

After some cursory review of Panda’s C++ and Python code I can gather the opposite. Panda actually does make a lot of assumptions / does enforce a lot of choices on a developer (as does every game engine).

Note that I said “gameplay-specific” elements–the things that you listed are lower-level technical elements.

One way of looking at it is that Panda handles a lot of the low-level technical stuff, but leaves the gameplay implementation to the developer.

@svf

… for many years now industry has viewed scene graphs as an antiquated way of representing render pipelines.

“Antiquated” is, I think, a bit of a loaded word, implying disparagement. I know that I find the scene-graph to be a useful tool when developing.

That said, note that Panda does, as I recall, internally batch based on render-state and (I think) on culling-bin.

@svf

I think a bit more evidence / justification is needed before making any assumptions, we wouldn’t want to make technical decisions based on dogmas - clear engineering principles would be better.

As I’m not one of the engine’s developers, I’m not in a position to speak to why the developers made or make the choices that they have and do. I’m just conveying what I’ve gathered of those choices.

@svf

I think that is an assumption you’re making - and I do see the logic behind it.

Not really. It’s based on my interactions with the Panda devs over time.

And please don’t make assumptions about why I’m making the statements that I’m making. :/

@svf

Do you have evidence that this is intentional?

I’m afraid that it’s just something that I recall from various (I think) interactions over the years; primarily on the forums, I think.

Maybe there’s something in the docs somewhere; I don’t know–I don’t think that I’ve looked.

As to justifications, again, I can’t speak for the Panda devs.

My own thought is that having Panda provide less of the gameplay stuff encourages devs to make things in their own ways, and thus increases the variety of the results.

Now, it’s true that devs could do things by themselves nevertheless. But consider the case in game-dev of the “dominant strategy”: even if it’s less fun, and other, more-fun options are available, people will often tend to pick the “dominant strategy”.

Providing gameplay implementations in the engine itself provides a “dominant strategy” of just using those implementations. That then encourages devs to use implementations that might not be good fits for their games, and increases uniformity, reducing the variety in the gameplay developed, so I would expect.

Samples might have a similar effect–save that they’re a little less convenient, a little less immediately available, which might mitigate the “dominant strategy” effect a bit.

[svf]

@Thaumaturge

Note that I said “gameplay-specific” elements–the things that you listed are lower-level technical elements.

One way of looking at it is that Panda handles a lot of the low-level technical stuff, but leaves the gameplay implementation to the developer.

I found an AI implementation in the source tree as well. It would stand to reason that AI is on the side of gameplay logic, I might argue even more so than some basic camera manipulation (like 1st person or 3rd person perspectives).

I’m not trying to nitpick - just want to make it clear here, that there is definitely room to improve Panda, and add ‘fundamental gameplay’ feature enhancements, we shouldn’t scratch these ideas off the list immediately. I’d agree we should scrutinize - but let’s keep an open mind here.

Again this is from review of the C++ code itself - evidence is here to support this notion. I’m not suggesting this based on any assumption or nontechnical concept.

@Thaumaturge

And please don’t make assumptions about why I’m making the statements that I’m making. :/

This is fair. Likewise, I promise my feature ideas come with a fair bit of homework put behind them, don’t assume I am looking to disrupt any core Panda design principles - just improve on features.

@Thaumaturge

Providing gameplay implementations in the engine itself provides a “dominant strategy” of just using those implementations. That then encourages devs to use implementations that might not be good fits for their games, and increases uniformity, reducing the variety in the gameplay developed, so I would expect.

Not having those implementations also proposes a ‘dominant strategy’, which is that all users of Panda or now required to write all basic, fundamental game mechanics from scratch. It’s still enforcing a strategy, and not one that is necessarily ideal.

I think a much better strategy would be - offer two options 1) Do it yourself from scratch 2) Here are some helpers you could use ‘if you should so choose’. Just as we have with the AI implementation, I’m not sure folks are forced to use it. In fact I almost always write AI code myself from scratch, as I’m an avid AI buff! But some basic camera and shader logic I do expect as a game dev (and designer) for engines to support.

Agreed? =)

-Sal

[Thaumaturge]

@svf

I found an AI implementation in the source tree as well. It would stand to reason that AI is on the side of gameplay logic, I might argue even more so than some basic camera manipulation (like 1st person or 3rd person perspectives).

That’s fair–but it’s also a feature-set that, as far as I’ve gathered, is little-touched and little-maintained.

It’s also exactly one feature, and so more an exception than a rule.

Finally, I might note that AI is perhaps rather more complex than a camera-controller, and thus something that many devs would prefer to avoid, or may not feel up to working on. AI is a bit like physics in that way, and, like physics, it’s one of the things that I’m happy to have as an exception to the rule.

@svf

Likewise, I promise my feature ideas come with a fair bit of homework put behind them, don’t assume I am looking to disrupt any core Panda design principles - just improve on features.

Ah, if I suggested that I thought otherwise, then I (genuinely) apologise!

I fully believe that you aim to improve the engine. Indeed, I don’t gainsay your intentions, as far as I perceive them!

It’s just that we disagree on what would constitute an “improvement”.

@svf

Not having those implementations also proposes a ‘dominant strategy’, which is that all users of Panda or now required to write all basic, fundamental game mechanics from scratch.

I would argue that it’s less a “dominant strategy” than a lack of a strategy; it says: “There are many potential strategies–you pick one.”

@svf

I think a much better strategy would be …

Agreed? =)

Not in the slightest, I’m afraid! XD;

My point about was not that people would be forced to use the built-in elements. Rather, that common human behaviour would likely result in many using those elements even in the presence of another option. Further, the use of such elements might be poorly fitted to some games, leaving those games potentially worse off. And finally, the likely-wide adoption of such elements would increase uniformity, and thus decrease variety.

[svf]

@Thaumaturge

@svf

I found an AI implementation in the source tree as well. It would stand to reason that AI is on the side of gameplay logic, I might argue even more so than some basic camera manipulation (like 1st person or 3rd person perspectives).

That’s fair–but it’s also a feature-set that, as far as I’ve gathered, is little-touched and little-maintained.

It’s also exactly one feature, and so more an exception than a rule.

Finally, I might note that AI is perhaps rather more complex than a camera-controller, and thus something that many devs would prefer to avoid, or may not feel up to working on. AI is a bit like physics in that way, and, like physics, it’s one of the things that I’m happy to have as an exception to the rule.

Totally understand your points here! All you’ve said is true.

But keeping this discussion grounded in solid engineering principles - you can understand that as a contributor seeing this code in the source tree, its fair for us to make an assumption that gameplay extensions are possible in some cases.

Totally understand if folks have ‘opinions’ otherwise, and everyone is entitled to have opinions!

But I feel making some gameplay enhancements is totally in line here, and I think would greatly improve Panda’s sample set as well. More importantly I don’t see ‘evidence’ that this is against Panda’s principles (also yes, I do understand there are opinions otherwise!)

@Thaumaturge

It’s just that we disagree on what would constitute an “improvement”.

Its OK to disagree on topics of subjective opinion, in fact I think these disagreements often lead to better software! Totally OK for folks to disagree on subjective things.

I was moreso looking for non-subjective evidence that the enhancements proposed in this thread go against core Panda principles, if so would take a different path. Given that we found the contrary - I think its OK to proceed.

@Thaumaturge

I would argue that it’s less a “dominant strategy” than a lack of a strategy; it says: “There are many potential strategies–you pick one.”

Subjectively both perspectives are correct! And I do agree with both perspectives - as well. It’s important to identify when a perspective is subjective and let it be - as engineers we just take note and move on to making decisions on what’s non-subjective as best we can right?

@Thaumaturge

@svf

Agreed? =)

Not in the slightest, I’m afraid! XD;

My point about was not that people would be forced to use the built-in elements. Rather, that common human behaviour would likely result in many using those elements even in the presence of another option. Further, the use of such elements might be poorly fitted to some games, leaving those games potentially worse off. And finally, the likely-wide adoption of such elements would increase uniformity, and thus decrease variety.

In this I feel I do agree! As with the AI implementation in the Panda source tree, it’s already been determined that in some cases its OK for this to be the case. That is mostly what I was looking for - some non-subjective guidance that this path is an option for us to take.

Thanks for all the great feedback as always!! And I love the passion folks have for Panda here, a great community here that will definitely help Panda move in the right direction.

Side note, I’m wrapping up some bigger projects at work now - and I should have some proposals in code very soon! Will update this chain ASAP. Also love to see any other ideas or code folks have for samples!!

[rdb]

I’m happy this discussion is taking place. Unfortunately I don’t have the bandwidth to keep up with the volume of posts here. I’ll just touch on a couple of things that I saw fly by as I skimmed the thread. If anyone needs my opinions specifically, feel free to @rdb me.

At a high level, Panda is not at all opinionated regarding how you structure your game logic. As such, I also don’t think we need to necessarily promote a particular way of architecting a game’s codebase as the “one true way”. That said, this doesn’t mean there isn’t a difference between ill-structured and well-structured code. Many of the samples follow a style of a single monolithic class inheriting from ShowBase, which is fine for a simple sample program but the problem is that people keep building on this same premise, adding more and more to the same class, making it not only harder to debug and understand as you add more things, but also making it really hard on yourself to implement behaviours such as pausing, saving, restarting, multiple levels, etc. down the line.

So it would be good to set a good example of how a codebase could be structured sustainably. In the most typical OOP way, this would probably include a game FSM class, which pretty much every non-trivial game will want to start with, so that transitioning between menus and game states becomes easy to implement and reason about. Furthermore, there needs to be a clean separation between world-specific logic and game logic, so that implementing loading/unloading multiple levels without side-effects becomes easy. Characters should probably have their own class so they can be their own FSM and implement their own logic, etc. Right now we have no resources at all teaching this kind of thing, which is arguably because it’s out of scope for the Panda samples, but I think we do have a real opportunity here to teach people how to create a game in a more scaleable manner.

About the scope of Panda and adding gameplay features to it: while DIRECT has historically provided a few high-level game logic features, most notably the poorly-documented and seldom-used input controllers, I do have the general feeling that there is an expectation for Panda to stay somewhat generic and devoid of game logic, aside from perhaps some generic building blocks to build game logic on top of (like FSM). To me it’s less a matter of principle and more a reality of management: we barely have enough dev resources to keep developing the core engine, let alone to maintain a bunch more high-level stuff on top of the engine.

That said, many people from the community have been publishing add-ons for Panda3D to PyPI adding more high-level game logic functionality (some examples are panda3d-wecs, panda3d-stageflow, and Ursina), which is really great to see and we don’t need to shy away from pointing people to those.

For what it’s worth, the “AI” that you saw in the codebase is PandAI, the result of a CMU student project that contains pathfinding. Despite the name “AI”, it really contains purely pathfinding code and does not contain game logic. Besides that, it is mostly a pragmatic matter that pathfinding, a computationally heavy task, is useful to offer to people as a C++ module as it may be too slow for some applications if it were implemented in Python.

[svf]

@rdb

I do have the general feeling that there is an expectation for Panda to stay somewhat generic and devoid of game logic, aside from perhaps some generic building blocks to build game logic on top of (like FSM). To me it’s less a matter of principle and more a reality of management: we barely have enough dev resources to keep developing the core engine, let alone to maintain a bunch more high-level stuff on top of the engine.

@rdb Thanks for this insight! I think it helps clear up some of the confusion we’ve been talking through. You’re absolutely right here - that to make dramatic improvements in the samples some code modularization is needed, a re-vamped, well written sample set necessitates some OO, and cleanup.

With this in mind - a few questions, if you have a moment - I think there is a lot of enthusiasm here to help improve the situation here, but some guidance would help much!

• What you’ve outlined is exactly what smacked me in the face when first loading up Panda’s samples. And the improvements you’ve recommended (modularity, FSM mechanics, etc.) are exactly what one would expect from a well made game engine package. Not having this I feel hurts the perception (and therefore adoption) of the engine. Is there any possibility (hitting the right quality standards, and with your code review) for this work to be made part of a standard Panda distribution? Or is this something that you feel the Panda team wouldn’t have the bandwidth to maintain, so efforts here should be done as a separate project?

• Does having any community members that ‘sign up’ to help maintain this code affect the decision on if it should be part of an ‘official’ distribution?

My motivation to seek this work (potentially) being distributed with Panda officially is for visibility, possibly the nice improvements bubble up into Panda’s website and other materials, increasing the chance it lives on and continues to grow, having good exposure. I’ve lurked around Panda for the past couple-dozen years or so and eager to see the engine evolve / grow! I really think this would help.

Thanks!!

-Sal

[rdb]

@svf

What you’ve outlined is exactly what smacked me in the face when first loading up Panda’s samples. And the improvements you’ve recommended (modularity, FSM mechanics, etc.) are exactly what one would expect from a well made game engine package. Not having this I feel hurts the perception (and therefore adoption) of the engine.

Before I can answer your questions, could you clarify what exactly you expect Panda to have here? Panda does have FSM and other basic building blocks to allow people to implement appropriate modularity in their game logic. Nothing in Panda compels users to implement all their code in one class (other than the samples suggesting they do so). So I am not sure what you are envisioning Panda do differently.

[svf]

@rdb

Before I can answer your questions, could you clarify what exactly you expect Panda to have here?

My question is two-fold. The first- I was speaking mostly to your recommendations - ie:

@rdb

it would be good to set a good example of how a codebase could be structured sustainably. In the most typical OOP way, this would probably include a game FSM class, which pretty much every non-trivial game will want to start with, so that transitioning between menus and game states becomes easy to implement and reason about. Furthermore, there needs to be a clean separation between world-specific logic and game logic, so that implementing loading/unloading multiple levels without side-effects becomes easy. Characters should probably have their own class so they can be their own FSM and implement their own logic, etc. Right now we have no resources at all teaching this kind of thing, which is arguably because it’s out of scope for the Panda samples, but I think we do have a real opportunity here to teach people how to create a game in a more scaleable manner.

Did you envision that this was intended to be part of Panda’s sample code officially? Or a community project? For the first piece.

The second part is in expansion of Panda’s existing samples. Earlier in the thread we agreed that the current crop of samples isn’t indicative of what the engine can really to, and could be improved. Would this work be part of the official distro as well? And if so can it use the code from the prior point ? (Assuming that we add a sample complex enough, say 1st person or 3rd person game it might need some of the same supporting code that was used in the aforementioned work.) Say we have shared utility classes, etc.

[Simulan]

@svf

The second part is in expansion of Panda’s existing samples. Earlier in the thread we agreed that the current crop of samples isn’t indicative of what the engine can really to, and could be improved.

Well, one issue that’s worth considering with regard to including more high-quality samples in the official code is size. My little Arena sample program is already, I believe, several times the size of the panda3d pip install. That’s just one, rather simple program. Adding huge sample program bloat to the pip install is not good, I think. We already have other methods of distributing examples. I’m not so sure what your suggestions are, specifically.

[Simulan]

@svf

@Simulan

I’m not sure if the time commitment required to really learn Panda3D for an experienced developer is measured in weeks, months, or years. But it is some amount of time, no doubt.

Try to make the discussions about an idea’s merit - again not on the basis of a personal judgement (someone’s experience, etc.).

This was not a personal judgement, indeed, it was a statement of fact. In the same way that no person, no matter how gifted, takes a certain amount of time to read a novel, it will take you a certain amount of time to understand everything about Panda3D. That said, I’m not analyzing your suggestions based on how long you’ve been here, or how many decades you’ve been writing API code.

@svf

There is potential here, for a great engine, with the right improvements, hence why I’m here!

It is, already, a great engine, with a rather small development team. The fact that you are here and so interested in Panda3D is a testament to how great, it is, already. It can be improved, of course, but I am rather alarmed at the idea at chopping up the core engine and making it into a small version of Unreal 4.

[svf]

@Simulan

We already have other methods of distributing examples. I’m not so sure what your suggestions are, specifically.

I was asking moreso the recommended way to approach @rdb 's suggestions here (which are totally awesome). For example:

@rdb

You’re definitely right that the samples aren’t representative of what Panda3D can do, and that even some minor love could go a long way. I welcome this effort to make some improved samples.

also:

@rdb

it would be good to set a good example of how a codebase could be structured sustainably. In the most typical OOP way, this would probably include a game FSM class, which pretty much every non-trivial game will want to start with, so that transitioning between menus and game states becomes easy to implement and reason about. Furthermore, there needs to be a clean separation between world-specific logic and game logic, so that implementing loading/unloading multiple levels without side-effects becomes easy. Characters should probably have their own class so they can be their own FSM and implement their own logic, etc. Right now we have no resources at all teaching this kind of thing, which is arguably because it’s out of scope for the Panda samples, but I think we do have a real opportunity here to teach people how to create a game in a more scaleable manner.

To what extent can we put this work in Panda’s official repo? Or what should we intend to be external? If the goal is ‘not’ to improve the samples in the official repo and spin up community projects that’s OK too - I just want to understand which contributions can fall where. Both are definitely options for me that I’d love to take on!!

[svf]

@Simulan

I am rather alarmed at the idea at chopping up the core engine and making it into a small version of Unreal 4.

Oh goodness! This sounds terrible. Totally agree =) Especially with Unreal 5 right around the corner, it would be out of date before release!

[Thaumaturge]

@svf:

It looks like my part in the discussion regarding Panda and in-engine gameplay elements has been obviated, now that an engine-dev has weighed in. After all, it’s no longer me reporting second hand! ^^;

I’ll leave my part of this there, then.

@rdb

this would probably include a game FSM class, which pretty much every non-trivial game will want to start with

Without gainsaying this, I’ll note with a little amusement that I don’t think that I’ve actually used the engine’s FSM features beyond a bit of tinkering at some point. Even “A Door to the Mists” doesn’t use it! ^^;

I suppose that it’s just the way that I tend to develop, however. ^^;

@svf

And the improvements you’ve recommended (modularity, FSM mechanics, etc.) are exactly what one would expect from a well made game engine package. Not having this I feel hurts the perception (and therefore adoption) of the engine.

For the sake of clarity, let me reiterate as rdb said above that these aren’t proposed improvements–these are things that the engine has already, I do believe.

(Well, “sort of” in the case of modularity; that’s less something that the engine provides than that the dev does or does not engage in.)

Samples showing how these things are used do seem like they might be good ideas, however!

Hmm… But conversely, it seems infeasible to me to have samples for absolutely everything that Panda offers. The engine has a huge list of features and modules and convenience classes!

@Simulan

My little Arena sample program is already, I believe, several times the size of the panda3d pip install.

Hmm… Where is that size coming from at the moment? I wouldn’t expect the code to add much, and last I saw it, there were only a few assets in place.

In terms of assets, it might be a good idea to have a single, small-ish pool of assets that’s used for all samples.

That said, this needn’t be done at the outset–assets can be replaced as we go, I think.

[Simulan]

@Thaumaturge

Hmm… Where is that size coming from at the moment? I wouldn’t expect the code to add much, and last I saw it, there were only a few assets in place.

It’s about 100 megabytes of models, because I am including the full assets and in some cases a few versions of the asset. IE, a bound armature and an unbound armature. I feel this is pretty basic to learning, considering there is now seemingly so much focus on helping people learn Panda3D.

As an aside, I did just basically learn entirely from the Panda3D manual and pure math concepts at the beginning. The forum is a great assist but not strictly necessary to learn the engine; this should be at least said once, I believe.

I’d like to see some data behind any proposed fundamental changes to the engine. You shouldn’t make architectural arguments without data, in my opinion. We need to measure stuff and see how fast it is, whether fast means prototyping layout speed or how fast we can press mouse1 to launch the sample. Or, I suppose, how fast someone can learn the engine or get results with it, which I think Panda3D is already best at among the various engines, but that’s just me.

In terms of the existing sample programs in the official repo, I think anybody could at this point, just post an updated version of Roaming Ralph or something to the discussion forum here. The asteroids demo is so old school it’s actually kind of funny. But it is fun to play.

[Thaumaturge]

@Simulan

It’s about 100 megabytes of models, because I am including the full assets and in some cases a few versions of the asset. IE, a bound armature and an unbound armature.

Ah, I see.

Why have two copies of the armature, however? I’m guessing that you mean that you have two copies of one or another of the models that you use–but why not just use animations to achieve the desired effects?

Still, I think that this is indeed a case in which having the samples draw on a common set of assets–like the current “panda” and “Ralph” assets, but flashier–would be quite helpful. It would, after all, allow a fair few samples without significantly increasing the size of the download.

@Simulan

The asteroids demo is so old school it’s actually kind of funny. But it is fun to play.

I will say that it’s perhaps valuable to have something extremely simple, yet complete: it demonstrates starting small, and it provides a lightweight example of a functioning game.

[Simulan]

@Thaumaturge

Why have two copies of the armature, however? I’m guessing that you mean that you have two copies of one or another of the models that you use–but why not just use animations to achieve the desired effects?

They are keyframe animated armatures, one model is the armature bound to the model, which is difficult to unbind once bound. The unbound example contains the detached armature so that a person could build upon it, for instance, and then join it to their model with automatic weights (or whatever they like) later. Without this separation of files I find it gets unmanageable with multiple actors, and so forth.

[svf]

@Thaumaturge

@svf

And the improvements you’ve recommended (modularity, FSM mechanics, etc.) are exactly what one would expect from a well made game engine package. Not having this I feel hurts the perception (and therefore adoption) of the engine.

For the sake of clarity, let me reiterate as rdb said above that these aren’t proposed improvements–these are things that the engine has already, I do believe.

My mistake - typed that out too fast. I was actually agreeing with rdb that the concepts are lacking from Panda’s official samples. Not that the features didn’t exist already. I’d like to possibly take a crack at it as well, it’d be fun!

I am still curious though as to where to draw the line between an ‘official sample’ and a ‘community sample’ as I would really like to improve both areas!

[rdb]

Ah, you’re not talking about Panda3D features, but about the existence and “officialness” of samples.

I would be very happy if both the official samples could be improved and we could have some bigger game demos to show people how a bigger Panda game is structured. For the latter, I’m not entirely sure how much sense it makes to have it as part of the distribution; we could include it with the SDK exe, but it wouldn’t make sense to include it in the pip install, and it would probably be inconvenient to have it in the main GitHub repo.

Regarding the demo, let’s create something cool and see where things go; I’m reluctant to commit to giving any kind of official stamp of approval before it is even finished.

[svf]

@rdb

I would be very happy if both the official samples could be improved and we could have some bigger game demos to show people how a bigger Panda game is structured.

Agreed! very cool - And both are exciting prospects!

On the first topic (improving the official samples), my first gut-reaction is that there is opportunity to do some serious code cleanup, potentially split some of those samples up into multiple python files, and potentially share some code between samples. Am I going overboard here? This is where the previous conversation went a bit into the weeds - once you start to share code between samples, things get much more neat and tidy, but might start to look a little ‘opinionated’. Can you give your thoughts here?

On the second topic - I can’t wait to see what the community comes up with! Maybe work done here that is high quality can go into some sort of showcase on Panda3D’s website. Together with beautiful screenshots and visuals, folks can just click into it, grab the code. Being on the site might be a good balance between feeling ‘official’ and getting that exposure, while also keeping the bloat out of official distributions.

(edit: follow up thought -) Maybe we’re looking at a concept like this:

• Official samples = small, minimal footprint, part of all distros
• ‘Showcases’ = very visually appealing (and well written) apps listed in a new section on website could show some screenshots, clicking on takes you to binary and code downloads. Can have much bigger media footprints, maybe in hundreds of meg
• Community samples = like #1, but not suitable for inclusion into all main distros. Maybe we just sticky these in a forum post, and link to it from this page

Just some ideas!

Thanks!!!

-Sal

[Thaumaturge]

@Simulan

They are keyframe animated armatures, one model is the armature bound to the model, which is difficult to unbind once bound. The unbound example contains the detached armature so that a person could build upon it, for instance, and then join it to their model with automatic weights (or whatever they like) later. Without this separation of files I find it gets unmanageable with multiple actors, and so forth.

Ah, I think that I follow you. (I’ll confess that I’m pretty tired right now. ^^; )

Fair enough, then!

@svf

My mistake - typed that out too fast. I was actually agreeing with rdb that the concepts are lacking from Panda’s official samples. Not that the features didn’t exist already.

Aah, I see! Fair enough, then, and thank you for clarifying!

@rdb

Regarding the demo, let’s create something cool and see where things go; I’m reluctant to commit to giving any kind of official stamp of approval before it is even finished.

That… actually makes a lot of sense. I’m inclined to support this position, then!

@rdb

For the latter, I’m not entirely sure how much sense it makes to have it as part of the distribution; we could include it with the SDK exe, but it wouldn’t make sense to include it in the pip install, and it would probably be inconvenient to have it in the main GitHub repo.

Perhaps such things might instead be linked from the manual, as we currently do with community-provided tutorials and the like?

@svf

On the first topic (improving the official samples), my first gut-reaction is that there is opportunity to do some serious code cleanup, potentially split some of those samples up into multiple python files, and potentially share some code between samples.

Honestly, if we’re talking about the current samples then I’d be tempted to simply throw out a number of them.

The rest I feel are simple enough that factoring elements out makes little sense to me.

@svf

Being on the site might be a good balance between feeling ‘official’ and getting that exposure, while also keeping the bloat out of official distributions.

This is not a bad idea, indeed!

@svf

(edit: follow up thought -) Maybe we’re looking at a concept like this:

Likewise, I can see this working.