I’m less asking after the best or most efficient way to do it, but rather after what we want to show off. Do we want to show off that we can support glow-maps, and displacement maps, and other maps besides? Do we want to keep it simple, or show off as much as possible, or something in-between? That sort of thing.
Indeed. Hence it seems to me to be a good idea to reduce the likelihood of it. If a model is made once and is then done, then it may be more likely that it’ll be finished–or at least, that’s my intuition, which may well be mistaken.
Well put! My thoughts here: Whether we design step 3 or step 9, We still need to perform steps 1 and 2. And in my experience with software development, once you have steps 1 and 2, all plans you had previously for anything beyond that changes!!! (And more ideas come to mind). I’m OK to tunnel-vision on the next couple steps, and worry about the complex stuff once we get there. My thoughts are we need a lot of boiler-plate basic stuff - I don’t think we have a sample that actually has fully working player & NPC collision/physics for example, it might be a good place to start. For most game engines things like this are considered basic features - that Panda doesn’t have this in a sample yet is a nice big gap we can fill.
However, thinking/designing that long-term vision can be extremely exciting and motivational. I wouldn’t want to kill the fun - if that’s what folks would like to focus on, by all means, I’d love to see more ideas there. (and long-term vision always does help to ground your design.)
One of my coworkers loves to say ‘perfect is the enemy of good’, which is a fun concept, since everyone’s definition of ‘perfect’ and ‘good’ varies, but point taken - most importantly results are what matter, for sure. Bias for action is a great rule to work by.
Well put, again!! I think you’re hitting the crux of the idea here.
Consider there are ‘samples’ for a game engine and ‘official samples’. ‘Samples’ just need ‘to work’ and it’s, after all sample code of how one could use the engine. ‘Official samples’ however typically need to go beyond, actually showing clean / elegant code structure and serve as models for best practices for many things like code re-use, modularity, clean code structure, understandability - overall, an official sample is what shows how the entire game engine’s design comes together to deliver a good user experience (for the developer) to build a game. If official samples are difficult to understand, or lacking features, it leaves little hope the engine can do much more / can scare away new folks that see things done easily elsewhere. (Not to spell doom and gloom here, but TLDR: sample quality is important)
Ideally we’d like to open the ‘official’ samples for Panda and say ‘wow this engine is so nice to use, is intuitive, etc.’ and it inspires one to tweak and start to build.
To expand on this a bit further (apologies if this sounds super pedantic but I’m a stickler for well written code). Consider this article for a moment. There are many ways to write the ‘same’ piece of code, some ways much more intuitive than others.
Let’s take for example an imperative style:
#here is a sample 1st person app
#this is all pseudocode, not Panda specific
def main():
node1 = makeNode(x,y,z, parent=root)
node2 = makeNode(x2,y2,z2, parent=node1)
myshader = '''
vec4 gl_Position;
float gl_PointSize;
float gl_ClipDistance[];
...
'''
scene.addShader(myshader)
keypressmap= {"k":"jump", "k_down":"stopjump", "w":"forward" ...}
node2.loadMesh("first_person_char.fbx")
node1.loadMesh("first_person_scene.fbx")
#insert here : lots of collision detection setup code
#insert here : lots of lighting setup
def updatescene():
if kepressmap["foo"].bar.blah.bam:
node1.moveSomplace(x,y,z)
#insert here: lots of AI, frame processing, etc.
scene.run (updatescene)
At first glance I think many wouldn’t see much issue with that style of code. But from the perspective of one who may have much more experience with other game engines / code styles they could think a few things:
Why do I need to setup super basic shaders in my game main setup code? Isn’t there some default or basic rendering supported by the engine that allows me to just load media? It’s definitely the case for other engines. I can just model some media and load, no need for writing shader code.
Likewise for input and camera handling for a 1st person game - does this really need to be written from scratch every time? It seems like this could have been abstracted already into a very basic input class
First person, third person, top-down camera management, pretty much encompasses the majority of game styles out there - one would expect not to have to write this from scratch for each game as well
On the style of the code written here - everything is in one / few methods, hard to re-use or split out logic. Hard to decipher which part of the code is for which task (scene setup vs, input setup, vs AI, etc.) Also the user could go down the wrong path by adding even ‘more’ code, and this method/file would become complete unmaintainable.
Anyhow - this is why I think it’s good to have some thought put into the sample code design. To flesh out more along the right path - consider the ‘declarative’ DSL style of writing code that is in this article that I referenced.
If things were more modular, and a declarative style was used, code could look like this:
#3rd person game example
import .... deps ....
def main():
MyApp(loadScene="myscene.blend",
controller=3rdPersonController(playerMesh="player.fbx"),
sceneNodes=[
NPCNode(model="mynpc1.fbx", ai=HostileAI()),
Node(model="button.fbx", collisionLogic=OpenDoor(id="door1"))
]).run()
#1st person game example
import ... deps ...
def main():
MyApp(loadScene="myscene.blend",
controller=FirstPersonController(playerMesh="player.fbx"),
sceneNodes=[
NPCNode(model="mynpc1.fbx", ai=HostileAI()),
Node(model="button.fbx", collisionLogic=OpenDoor(id="door1"))
]).run()
Note how to go from a ‘First person’ to a ‘Third person’ game style you only had to change one line of code. Likewise we could open the .py source (in the samples folders) for each of these classes and see how they work, change/customize, etc.
It’s also comforting to know, that at least in a simple sample, a game could be working in ~15 lines of code, with advanced functionality. These samples could have fully working collision, camera management, etc.
Happy to hear more thoughts here. I know this is probably a lot more code-engineering and architecture than most might have expected to put into game engine samples, but I think the little extra effort here goes a very long way to making Panda infinitely simpler to use.
Conversely, I suspect that with no solid idea of where one wants to go, it can become easier to get mired in earlier steps or spend one’s efforts on things that end up unused. (Of course, some of that is likely to happen anyway, in most projects for that matter. I just suspect that it’s more likely under such circumstances.)
It’s fine of the end-goal changes over time–but I don’t think that this means that the end-goal is of no value before its reached.
I would argue that if it’s intended to be a sample of how one could use the engine, then readability is still important.
Even if it’s not an “official” sample, it seems likely that people will want to learn from it. As a result, a sample that isn’t readable might confuse and frustrate new users, direct them to producing low-readability code, and potentially scare them away.
I think that the general philosophy with Panda has been that games vary so much that there’s a preference here for giving the developer the freedom to develop the elements that they want, even if that means that the developer has to do more themselves.
Even within camera controllers there are quite a few variations: Third-person in particular has over-the-shoulder, top-down, distant isometric, free-roaming separate from the character, and perhaps more. Then there are cases in which the game might require a switch between third- and first- person cameras. And likely so on besides!
In this way, providing an array of small, modular elements is arguably preferable, as it allows a developer to assemble more-granular parts, thus allowing something closer to their vision.
You can use the built-in shader system, my example is nonstandard in that regard. Just call self.render.setShaderAuto() and you will not need more shader code. I’m not an expert on this implementation but I believe it generally applies built in shaders on the entire scene. There are some cool ones, like Cartoon Ink. However this way does not yet support features such as metalicness and a few others that I believe are important.
These examples are not representative of the range of all possible games, which I hope I am not alone in thinking is the general idealistic goal of our framework.
I get what you’re saying, I want my code to be readable too. I will, at least, switch to using underscores instead of camelCase (I don’t care stylistically either way and I’ll probably get used to it).
However it seems that you want my code examples (or @Thaumaturge 's) to actually be part of the framework and called as built-ins. This is, simply, not the case today. Panda3D requires a little more work on the developer’s part and I don’t see an issue with that as of yet.
Not to downplay the shortcomings of our codebase, but this is really not the case. I have written several programs which solve the NPC state. It’s not a problem for me. It is a problem for me to present this quite convoluted code to the whole world as some kind of perfect, general solution. It’s just not natural for me to do this. There are many, many ways of solving the state. I suggested three or four different ways of approaching a more general solution in this regard in the Arena post.
I definitely wouldn’t want to take the steam out of the effort here. I may be able to think of a way to reduce my AI code to something more applicable to arbitrary NPC configurations. However I must warn yet again that we are quite close to that scary world of opinionated template games. There is, I believe, a strong case to be made for not overspecifying. And much more generally, I question the ability of a developer to write an entire game in native code if they cannot produce the most basic AI mechanics from scratch. “The Basics” are not well defined for the range of all possible games, I think.
Agreed! So many balances and trade-offs exists with software dev. I’ve been in too many similar discussions in the vein of waterfall vs agile, iterative progress vs. design-first. All arguments for either are valid, based on scenario, for sure. Good judgement is key!
Agreed here as well! I’m just also trying to be sensitive, ie - if folks are ‘afraid’ to make samples for Panda due to fear of not being able to meet some impossible architecture standard, then we get less progress. I wouldn’t want folks to be afraid to contribute. Its best to keep the fire-hose on, let the flood of samples come through and we can always refactor later. But we should have some idea of what the ‘standard’ is we’re trying to hit, so folks have a goal to aim for. The more structure we’re agreed to apriori the less rework we have later.
Agreed, and this is one of the creative aspects of software design - when building a framework you’re always making some subjective decisions to handle a generic case, but also allowing users to work more granularly to handle any other case. (This topic near to my heart as its also my day-job, so I understand the pain one feel when trying to make these decisions for sure.)
A good rule of thumb here - is to try not to ‘generalize the exception’. For example, in 0.01% of games, we may want a very eccentric camera angle, but given this probability is low, we wouldn’t make fundamental design decisions in a game engine to target that 0.01%, rather we’d like to optimize for the 99% or majority use cases. With clarity in code, users can always customize to tweak things for that 0.01%. Again it’s a balance - I for one feel it’s very doable to have the best of both worlds - ie components that handle the majority use cases, but also the ability to customize those components to handle the minority cases. It does take some up-front thought though, just ignoring this aspect or sweeping it under the rug doesn’t get to a design solution there.
Agreed here as well - see the previous point here - I do think it’s possible to solve for both cases. I want to be careful not to create a false-dichotomy in our minds, that says a framework is either opinionated or flexible, but can’t be both, as I don’t feel that’s true.
Sorry if I gave that impression! I’d never expect / ask anyone to do something a certain way. My questions are mostly for myself to guide my own work - as I plan to write a significant amount of code for Panda, I like to work out some design first - and if there is a standard to meet so I can get my own samples in the official codebase I’m happy to comply - to maximize the benefit of my contributions. I have written much code that has fallen to the dust-bin of Github, over the years have learned that some understanding can help your code live on in a much more impact-ful way, if that’s the goal, anyway.
I tend to assume if I have these questions, others might too, so it’s good to try to get to answers. If others would like to collaborate on a common standard as well, that’s amazing!! But I’ve been a part of many opensource projects through the years, one can only control their own contributions (and choose to understand or match the standards of the project they contribute too) - the worst thing to happen is to discourage contributions altogether, as any volunteer effort / code written for Panda is good at the end of the day for the entire Panda ecosystem (imo.)
Don’t feel pressure to change your code! I wasn’t trying to suggest this, just asking questions to guide my own work. I don’t know we came to any consensus yet, but this discussion has definitely got us closer, and I appreciate everyone’s feedback!
By all means, if we have the desire to crank out some sample code let’s do it, not worry about over-design just yet.
I’m getting closer to the point where I can start to crank out some code myself - everyone here has posted such great example code, or ideas to work off of, we now have some free art/media we can use. I promise to have some samples of my own to review here very soon!
I have uploaded the initial case changes. There are a few examples that were not easy to switch over.
Oustanding issues switching from camelCase:
lerp_pos_hpr_interval is not defined
mouse_watcher_node is not defined
lerp_func is not defined
global_clock is not defined
cam_lens is not defined
bullet_character_controller_node is not defined
That’s a fair concern, I do think. That said, I don’t mean to argue for a serious standard, as such–just readability.
Panda has generally (at least to my knowledge) taken a different tack: to not generalise at all; to not constrain devs to one paradigm or another above a certain level of the engine.
It’s one of the reasons, as I recall, that there has been resistance to the idea of an official level-editor in the past.
Don’t get me wrong, I am 100% for more developers writing Panda3D games. It’s a great engine as it stands.
We already have a very capable set of tools which solve the general case and the specific case (the framework). This is not a shortcoming, it’s the primary feature of Panda3D, if I may say so. Look at the 50+ built in functions I used in a 600 line example program. That’s the flexibility of Panda3D. Examples of specific AI techniques are just examples in a sea of possibilities.
Please respond more specifically to my/our statements about generality, if you would, @svf . Do you not find it appropriate that a developer in an engine quite explicitly designed to be code-first, code-only even, which uses Blender at most as a GUI, could also write their own character controller? This is fairly basic comp sci.
Which is great! I’m of the opinion that you can have both flexibility as well as ease-of-use & feature completeness - they aren’t opposite ends of a spectrum. For example, having physics support in an engine sample - one could argue that it ‘biases’ the game to have gravity and work in games that are on planet Earth (most physics libraries assume a -default- 9.8m/s gravity acceleration rate after all). Which is true, but the user could choose not to use that sample or its code - they still have the option. Not having the sample in the first place doesn’t make the engine more ‘flexible’, it just leaves the user with more work to do for some basics - that they might expect from a mature game engine, like physics. (Not to beat on physics support at all, and totally unrelated to my experiences with Roaming Ralph sample coughcough)
I don’t think we should be afraid to make Panda easier to use - but I think we all agree here =) My only reason to push the point is I’m seeing a lot of hesitation from folks to improve on Panda’s scripting interfaces due to a fear that the engine becomes less useful somehow. Improvements should be just that - improvements!! With some careful thought I’m sure we aren’t restricting users in any way, but giving them more help to make great games.
On a side note I was planning out some of my initial Panda sample code contribution ideas. Here is where I’m currently going. I’ve found some javascript/three.js code that does a lot of what I was looking to do, and being that I prefer Python over JS (and three.js isn’t there yet) I’d like to rewrite the code for Panda.
Check this video out, it’s a tutorial for building a full-out 3rd person multiplayer RPG (with combat, etc.) in JS. I highly recommend this channel for folks that are interested in game dev algorithms in general. This video is particularly amazing .
Code is here as well. And that sample has full Blender media, models, textures, etc - so this helps. One thing that might be missing is the procedural terrain capability, but I’m thinking to swap for a simpler Panda supported option.
I think my approach will be to just work on some basics now, controls and physics to start. Then start loading media and working over to some of the nicer features like networking. The other major dimension though is I’d like to work in small increments - each increment a standalone Panda sample that has code incorporated into the end-sample game. So the actual end-sample game should come in at less than a couple dozen lines of code if abstracted correctly.
The thing is, as originally worded, it looked (to me at least) like you were advocating for the engine itself having things like “first-person camera controllers”.
Having an array of samples available is, indeed, something that I’m in favour of!
As I said:
I suppose the question then is whether a change to the engine’s interfaces is an improvement.
Again, external samples or modules I’m in favour of. Adding such controllers to the engine itself I’m rather more hesitant about.
That’s interesting, and ambitious! I’m interested to see how it turns out!
For something of that size, I might suggest taking a look at the various things already offered by the community that might be useful for or as part of it–GUI designers, exporters, keymapping modules, and so on.
I guess its a matter of perspective, if there’s a ‘first person camera controller’ as part of a scripting example that one can import or re-use, users might consider that ‘part of the engine’. I don’t know most users really know/understand which pieces exactly are C++ vs Python, nor do they mind either way. From a user perspective, they either need to write all that code manually, or import it from someplace. I think the point here is, given that ‘first person cameras’ are so common in games, there’s no harm in having one available.
I don’t think it ‘opinionates’ the engine in any way. As it’s an optional component. If that component also is extensible (ie, you can inherit from the object, override methods) due to OO paradigms one can also completely customize the behavior of it - or, take the source and modify.
The intention for all changes to an engine is to improve it, correct? Not sure I follow.
For sure - there is less harm in modifying an engine sample to have some re-usable code. But it is very common for game engines to take very time-intensive or CPU hungry scripting logic and eventually nativize it. (Convert to C++ or otherwise). If a scripting component proves to have enough usage and needs the optimization, no harm done. Again if the component is optional - the user isn’t forced to use it. Its about giving the user more options overall, not constraining them at all - whether its a Python or C++ feature.
Again, I don’t think there’s an ‘either / or’ option here, of ‘opinionated’ or ‘flexible’, you can have both. I don’t know we should be so concerned. I do agree other game engines may have been designed poorly or have this wrong, but I don’t feel like we are doomed to follow there. (This discussion a perfect example of why we wouldn’t easily fall down the wrong path!)
Absolutely, and the fine work by yourself and @Simulan are incredibly useful as well, thank you for all your feedback / ideas. I’ll definitely post as things progress!!
Sorry if I missed any points Simulan. Let me know what I missed an am happy to deep dive on.
Word of warning though I am super passionate about software architecture and game API design, as it is my day job, so I can talk about this stuff forever. Lol !! Feel free to ask away, I can clarify any opinion.
Well, you must understand that with your 4 days? of Panda3D development experience, you’ll find some significant learning curve to get to the level of the community’s existing developers, in a 20 year old engine. If I may say so, it comes across slightly strange to begin to demand we add first person controllers and so forth to the engine, then circle back on that idea, you just meant we should do what we’ve already been doing for a decade, which is providing free examples of our personal work. Great.
Don’t take this the wrong way, I just need to see some evidence that you really appreciate what Panda3D is about and have some respect for the long standing traditions, as I try to have, despite the direction of my own work.
We should be clear that you’re not saying “Panda3D is not Unreal 4 or Unity, therefor it is inferior”. Because the goals of different software are different. “We should strive to make Panda3D exactly like Unreal 4, with a really good editor, because that’s good for game design! Don’t worry, you’ll still be able to call C code in a super constrained way after 5 years of focusing solely on the GUI” Sorry, just attempting to be specific.
Consider also the opposite may also be true, the person giving a new idea may have 30+ years experience in game engine development, potentially work on AAA game engines at their day job, and possibly have great new ideas that could improve Panda, I know quite a few folks like this, and would love to invite them over here to help us out one day. It would be a shame to discount their ideas since they’re new to a forum.
Also note that f there are some basic issues in a 20 year old codebase, maybe a fresh perspective is exactly what’s needed! =) Note it wasn’t just me in this thread that agreed Panda’s samples need significant improvement.
Surely a game engine supporting ‘first person games’ isn’t a bad thing? I do understand the motivation here, to keep the engine flexible, but to the point of not supporting ‘first person games’ directly is a bit strange - it is a ‘game’ engine after all, not just a renderer. We can agree to disagree here - but I will cling to my opinion here - first person (or third, or other) support in Panda’s samples (or engine) would not make it any worse of a game engine. Many games use these perspectives and it should be something with first-class support. Forcing devs to implement these basic things isn’t a great design idea for a game engine in my opinion.
Not sure I catch your point here - yes I’m totally supportive of folks who want to contribute personal work in any way. Not sure how that relates to the discussion of game API design. If you can focus on the technical / computer science principles of what was proposed and what you disagree with I can give much more useful feedback. I can only detect that you disagree with a proposal, though not sure on which or why. Maybe try to rephrase as a technical / compsci type of discussion? I’d love to deep dive on the aspects of this.
Completely agree! All contributors should respect the design decisions of the project they contribute to. And be sensitive to the reason on why those decisions are made.
On the contrary the existing folks should also realize that there might be things that need to be fixed, and newcomers might bring the solutions! And not to be offended if a newcomer finds flaws, in the end of course everyone benefits from improvements to Panda right?
Again I’m not sure which point you’re making here, but I’m happy to dive in on each topic. I do have Unreal/Unity experience (among many others - its my day job to work with them) but don’t remember any discussion on editors or GUIs… although I do have strong opinions on both those topics as well! But probably better to debate that on other threads, I think engine sample improvements are a big first task to work on.
Side note, I do love the great debate, and do think this discussion definitely helps to get things to a better place! Thanks for all the feedback!
I have updated the Arena FPS sample program submission to include some randomly colored “collision cubes” which the NPC and the player can push around. This demonstrates various objects interacting with different systems in the same collision environment. The player’s gun is now far less likely to clip through walls or boxes because of an extended collision radius.
Unfortunately, I do not quite understand where you are coming from @svf . If you want to make an Editor-based version of Panda3D, you could just do it, like several other people have demoed here over the years. Or equally you could just build upon those existing examples of more conventional editing interfaces for Panda3D. You have so far just stated you are a AAA game developer, not actually shown it. 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. If you are a full time developer and by extension quite busy, I’m not sure why you are bothering with our primarily (though, not entirely) hobbyist and scientific framework.
I do actually use Panda3D as “just a renderer” sometimes to test algorithms or run simulations. It is quite useful for that purpose. Panda3D is also massively smaller than Unity or Unreal, can you imagine installing those huge engines over pip3? Providing the community demos of your artwork or programming structures would alleviate my skepticism. I am of course, looking forward to anybody’s future example posts, and who knows where Panda3D will go in the future. There are already something like 7 forks of it, and quite a few somewhat serious projects such as the recently updated, super cool, VR implementation: VR with Panda3D: panda3d-openvr - #2 by eldee
It’s not really a C++ vs Python issue; a number of engine-elements are implemented in Python, as I recall! (See the Python “Actor” class, for one.)
I see little harm, too–as long as it’s not a core part of the engine, and just an example of how such a thing might be built.
Essentially what I’m saying is that even if something is intended to improve, it may not actually be an improvement.
Thus the fact that something is intended as an improvement isn’t by itself enough to have it taken on-board; the thing in question is first considered, to determine whether it is in fact an improvement.
True, but this sort of camera-code isn’t really all that CPU-hungry, I daresay.
For one, a basic first-person camera in Panda is really little more than attaching the camera to whatever node is being used to move the player-character (or some child-node thereof), and likely adjusting the near- and/or far- planes.
For another, consider that the test-program for my “simple third-person camera-controller”, above, runs about just under 700fps on my machine.
I really don’t think that these are components that require the optimisation of conversion to C++.
And again, making dedicated in-engine elements for these things runs counter to the (I gather) general Panda philosophy of not really providing gameplay-specific elements in the engine, but instead providing a lot of tools and saying: “Go on, make it to your specifications!”
But Panda already does support “first-person games”: as we’ve seen recently, it’s perfectly possible to create a first-person game in Panda!
I realise that this isn’t quite what you meant–but that’s kinda the point: it is the way that Panda means it, so to speak.
This is true: it provides far more than just rendering. Device-input, tasks, file-handling, threading, collision, and so on are provided by the engine. It just doesn’t provide gameplay–that is intended to be provided by the dev.
All that said, let me note here that I do agree with you on one thing: New people can very much bring in new and useful ideas! For myself, I may disagree with your position, but the fact that you’re new here is irrelevant to that.
Not sure why this editor thing keeps coming up - I don’t think I’ve ever mentioned it. There are some improvements I think that could be made to the Blender->Panda workflow however. More on that later =)
Try not to make technical discussions personal. Normally this is a sign that you can’t make the case for / against a technical proposal and have to resort to other rhetoric. This is not meant to be offensive at all, I’m happy to talk about my personal experience (nothing to hide there) - but I want to caution against turning technical / computer science discussions into personal ones, it doesn’t reflect well on the person making the argument. I think you have great ideas and are doing great work here on Panda! I just want to make sure you’re aware of this - it helps with communicating your ideas.
But since we’re on the topic, yes, I’m on a team of developers that builds APIs for AAA game engines. My team does need to work directly with / write code for Unity and Unreal engines. Hence my passion for game dev - its not only my job but also a hobby!
Try to make the discussions about an idea’s merit - again not on the basis of a personal judgement (someone’s experience, etc.). Note the same goes the other way around, I wouldn’t take your technical suggestions based on your personal merit - if I did I wouldn’t have much evidence to work with after all. You’ll have to justify technically why your idea has merit - and I promise I’ll take all such arguments fairly!
There is potential here, for a great engine, with the right improvements, hence why I’m here!
Do you have a link to docs (or any design guideline) that states this is the case for Panda?
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).
For example:
Engine written in C++, scripting is done in Python. There are many in industry that might prefer C and LUA, or C++ with JS as a script layer. Many would make the argument that Python isn’t well suited for game development. Note I don’t agree with that, but - just to make the point here.
Strong use of scene graph architecture - for many years now industry has viewed scene graphs as an antiquated way of representing render pipelines. It was common back when OpenGL was a state machine - but now most modern engines use non-graph batched render-state optimized pipelines. Render order is determined by performance optimized sorting of shader states and media batches, render hierarchies get in the way of this.
Choices of media formats, asset pipeline formats. The developer does need to struggle a bit here to get media into Panda as the formats are fairly custom.
So in summary - Panda does enforce many, many choices on the developer. But I’m noticing that when a missing feature is identified, the immediate response is ‘we don’t have that feature because the engine is designed to be generic’. As you can imagine, from an engineering perspective, the code looks to specify the opposite case.
I’m just looking for some clear justification here - as from my perspective Panda does already in fact offer many opinionated features to simplify development, and for future critical game features more may be needed - and the argument that ‘panda is generic’ doesn’t seem to stand here. 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.
I think that is an assumption you’re making - and I do see the logic behind it. But see my previous point, Panda does in fact force restrictions on developers in many ways - I’m asking to back that assumption up with some proof. The only thing that stands to reason now is that Panda lacks a lot of gameplay features - but the ‘lack of’ a feature isn’t an argument not to ‘implement a feature’. Its a self-defeating argument, surely enhancements can be made to Panda, but some engineering principles are needed to guide this. Again - dogma isn’t something that should drive engineering.
For example, if a feature has been missing from Panda for 20 years - we shouldn’t assume that ‘it was done that way on purpose to keep the engine generic’. Let’s challenge that thinking by backing up on a feature-by-feature basis why something should or shouldn’t be in the engine. I think if we analyze it on a feature basis you’ll find, we can indeed design feature such that those features are optional, and a developer isn’t forced to use it.
Do you have evidence that this is intentional? Maybe the dev team omitted this due to lack of manpower (or otherwise)? Without that evidence - or some design principles, this is just an assumption that isn’t based on technical principles.
It may be easier to work with some sample code scenarios to understand how a feature might be implemented in a way that is both generic and flexible, I’m happy to do this! Let me know thoughts.
