It’s the inverse, the game framework like entity component hides complexity for you, your code is shorter and you only code the essential object behavior.
In Unity you don’t have to deal with main or setup resolution or physics engine, you add a script to some object and you got the start() and update() ready to use, as physics ready to use.
Collision masks is also setup in a graphic table with checkbox for example. It’s faster , easy to visualize and understand and less code to write.
I mean better, more maintainable for bigger games. I can’t imagine you would make some mmo with character classes , inventory and lot of things the way you made the tutorial with all code in one or two files.
Objects or prefabs with their own scripts is lot more easy to manage and lot more maintainable.
For example inventory script, HUD script, Player script, etc …
You seem to prefer old graphics and old way of coding LOL
This also means you don’ t want to distribute a game with better graphics with lot more chances to sell.
BTW, the tutorial could have been modified with ECS and new graphics, making it lot more modern and less outdated. I hope those will become default in Panda 3D and some scene editor will also be made otherwise it will not gain popularity.
But the section of my post that you quoted for that reply wasn’t responding to the idea of Entity Component Frameworks in and of themselves, but to your suggestion (as I read it) of adding further lessons. It’s that–adding lessons–that I was objecting to on the grounds of making too long a tutorial.
And I’m still not convinced that the Entity Component System is necessarily better in all such cases.
I mean, making an MMO (without a specialised MMO-building engine) is a pretty mammoth task anyway, I think. It’s the sort of thing that calls for huge teams. Even if we accept that Entity Component Systems are strictly better for such games–which I doubt–should we also be advocating the sort of team-management systems that such projects likely employ? A one-man developer building a little indie first-person-shooter doesn’t really require SCRUM meetings, or a dedicated “producer”, for example.
Different games, of different scales, may be well-served by different methods.
Thus, even if you’re right about the methods that you advocate being as you describe, why teach methods suitable for huge projects, when there’s no reason to think that all of our developers will be building games of such scales?
This line baffles me a little. You seem to be inferring that, because I split a tiny game with tiny classes into only two files, that I’d similarly split a huge game with complex, detailed classes into only two files. This isn’t the case.
Now then, personal jabs–especially unsupported ones–aren’t terribly useful. Nor are you likely to shift my viewpoint with them.
It’s my pleasure! I hope that they’re helpful!
Hmm… That’s a good idea, I do think. That said, I do worry that it might encourage readers to just jump in at some arbitrary point… I’ll think about this further, I intend.
Either way, thank you for the suggestion!
I believe that a new render pipeline is in the works already.
A scene-editor has been mentioned as something that the developers would like to do, I believe, but it’s also been mentioned as a particularly large task for them to undertake.
(I think that there are one or two community-made editors around, but I don’t know what the current state of any of them might be.)
I do not know how to convey the very idea of why a panda without an editor can be easily used. I will begin However, since the “egg” format can contain the entire scene, you can view the .blend files that are delivered, render pipeline and understand how it works. You can watch this video and solve the puzzle.
To be honest, that is my intention But I would say that, after I have read all the lessons of a tutorial, I like to go back and reread more carefully certain parts that I did not understand (or misunderstood) the first time, and so the ToC is handy as I never remember if a topic was described in part 10 or 17 or … You could put the link only at the end of the last lesson so that only if you have read all of them you can access the ToC
Are Blender objects instances in some scenes, imported in Panda 3D as Gpu instanced objects ?
Another thing missing thing is the object properties, when you need to tweak object values or scripts values, Blender only export a scene it does not know about Panda 3D scene or object and their scripts or properties; or you would need to extend Blender to work with Panda 3D.
BTW, i stop talking ECS, rendering or scene editor.
There are just some things i found very old school about coding, graphics or level editing with code; when i could read more about the tutorial.
I’m going to be working on this feature within the next few weeks. Though, when you use external references effectively, it’s not hard to get them loaded in as instances in Panda today.
Actually, in Blender you can use custom Game Properties, which can be read out in Panda via the tag mechanism. This is a very versatile and flexible system, and I heavily rely on this whenever I make a game that uses Blender as a scene editor, since you can use it for pretty much anything you want.
There is no jabs, the non ECS code is just something i find outdated and i’m not fond of.
It’s just some things that could be added to get people directly starting with better code and better graphics.
You did a big and great tutorial, it must have been lot of work to write all lessons, and this is still the best Panda 3D tutorial available. It will will help a lot to understand Panda 3D very basics coding.
I think it’s great as it is , i stop making suggestions.
Hahah, fair enough! I do think that doing so is a little dangerous, however: For one, you might miss out on fundamentals by doing so, and be tripped up by the lack of them at some later stage. For another, the code examples assume that you’ve been through the code of the previous lessons, meaning that you might lack code-context for them if you jump ahead. (Although the reference code may help in the latter case!)
That’s a very good point, I do think! Hm… But in this case, if I put the links at the end of the tutorial, people wanting to jump backwards partway through might still be lost, having not discovered it. Perhaps, then, it’s wiser to just place the table of contents at the start–indeed, on the “About Page”, and let people choose for themselves.
Fair enough, and I apologise if I misread you, then! :/
One last thing then, if I may: I won’t gainsay you finding ECS to be better for you. However, I do feel that there’s a gap between “this works better for me” and “this will be better for all developers, in all contexts”–and it has seemed to me that you’ve been arguing the latter.
I’m pretty sure that I’ve tried ECS before myself, and never quite liked it. Perhaps more study is called for, perhaps it just doesn’t suit me, I don’t know. But the way that I code seems to work for me, even for moderate-sized projects.
Thank you very much, I really appreciate that! (And yes, more work than I realised! Even so, however, I am glad that I did it.)
Please don’t! We may disagree on one point, but that doesn’t mean that you can’t make suggestions on others!
You can! In fact, that’s what I usually do! Aside from tags that YABEE automatically recognises and turns into special egg-syntax tags, you can add various strings, integers, and floats, then handle them in your code. It’s not always elegant, but it does work, I do find.
(Except with Actors, if I recall correctly; something about the way that Panda handles them results in tags sometimes being lost. But I may be misremembering.)
A “How to Use Blender with Panda3D” tutorial wouldn’t be a bad idea, I think. (Although I’ll leave it for others to do, I think! ^^; )
And the tutorial now has a table of contents, stored on the “About” page (and thus visible on the home-page, too).
Why not in Blender ?
For example some model is a creature category.
You create a tag in Blender with key and value like “type” : “creature A”.
In Blender copying one object with such tags, would also copy the same tags, but you could modify some of those tags values.
It’s like prefabs system.
I find it better to define objects properties at level design.
Like change some attack tag value of creatures that would be in some scene specific zone, you need to visualize the scene to see what creatures are in some specific zone.
I should mention that you can also use arbitrary ObjectType in Blender, which have a user-defined meaning. For example, you can give some objects an ObjectType of “scaryMonster”, and then you can define what this means in the resulting .egg file using “egg-object-type-scaryMonster” configuration variables (which can replace it with any egg syntax desired, so it could include assigning tags, collision bitmasks, instancing in an external model, etc.)
This is a really useful way to create levels because you can change the meaning of these object types without having to edit each individual object that uses it.
With only a small amount of glue code in Panda, you can also use this to effectively assign different scripts/classes in your code to a particular model, similar to how you would do this Godot; ie. you could create a tag or object type for your enemies called “enemy.py” which would load in the Enemy class from enemy.py in order to control this model’s behaviour.