Game development is becoming more and more of a hobbyist endeavor, and engines are beginning to target individuals and beginners, rather than just professional game development teams. While Panda3D is an exceptional engine by technological merit, it falls behind in accessibility to the more artistic/design-oriented users. Modern engines are focused on providing a"WYSIWYG" experience, allowing a basic game to be created even with no programming knowledge whatsoever. This style of game engine design is also far more attractive to larger teams as well: it empowers the content creators on the team to make edits with less programmer"hand holding" and consequently speeds up development time.
In order to do this, Panda3D should offer more of a framework that manages the lifecycle of game objects and allows developers to focus more on game logic and less on game infrastructure. This would mean Panda3D itself would have an actual entity model, so that an entity can be(de)serialized, in turn allowing the engine to provide saving/loading support, better networking capability, and easier introspection by development tools.
To save us from"subclassing hell", I'd personally like to adopt an entity-component system(ECS) architecture, allowing behaviors on an object to interact, rather than intermingle. Tasks and event-handlers(i.e. messenger.accept) can belong to specific components, allowing profiling tools(pstats, et al.) to aggregate not only by task name, but by broader function - what collection of tasks is doing what, what objects are taking the most performance, etc.
With the majority of the game behavior moved to composable ECS components, and with the engine being entity-driven rather than burdening the application developer with having to develop their own initialization code and object model, Panda3D becomes much more usable as a 3D rapid development platform in general, and far more consistent as a game engine in particular.
This model would not(necessarily) obsolete the direct tree, but would instead provide developers with an alternative framework for building their application that doesn't depend on direct whatsoever. This is also much more attractive to the users of Panda3D who do not wish to(or simply cannot) use direct but still want to use a high-level interface on top of the low-level functionality afforded by Panda3D.
Finally, an entity-centric framework enables the development of scene editors which can target not only basic scene graph modifications, but also higher-level application edits. In other words, scene editors can now be used by the level designers on a game team to place item pickups in addition to just static geometry, all with minimal involvement from the programmers on said team.
Roadmap
So, in programmer terms, the roadmap is:
Proper entity model
Work on a few composable/subclassable components(e.g. FSMs, an equivalent to direct's Actor, etc.)
Serializing entities to .bam, such that you can take a running game, save it to .bam, shut down the engine, start it back up, load the .bam, and continue where you left off.
Give the engine itself a"main runtime" that just loads an entity file and starts playing - the goal at this point should be that you can double-click one of your"saved games" and the runtime picks up right where you left off. The main runtime can also have a few fancy developer features, such as:
Runtime config(i.e. .prc) editor
Python REPL(i.e. InteractiveConsole)
Log output window(can even be a nice GUI so you can filter logs via checkboxes)
Come up with a nice default"project structure" - some standardized way for developers to keep their resources and custom components, perhaps with the additional option of letting programmers subclass the standard runtime(e.g. if they want to add a main menu or if they want the option to launch the game as a headless"dedicated server")
Start working on the Blender plugin to edit these"saved games" files.
Develop an"unbaked scene" format so that the scene editor plays nice with source control.
Get the Blender plugin to the point that it can be used to connect to a running application and live-edit and live-inspect entities.
Build tools to manipulate scenes and inspect components, eg. allow PStats to profile on a component-level.
Design
ECS system
The core of the ECS system should be implemented in C++, so that it's usable by both Python and C++ programmers. Entities don't necessarily have a(single) representation in the scene graph; this is up to the components(a"render" component might need to have a node in the render graph, but an"audio" component might not). This means it's important to note that entities aren't nodes, but exist in a different layer of abstraction altogether.
Scene format
We need a way to store scenes and entities in a high-level description format. A good candidate is Panda's native serialisation format, .bam, since the infrastructure for storing to files and streaming over a socket is already there and most Panda types can already be serialised to this format.
However, to facilitate collaboration, we need to consider the ability to merge the formats via version control, which is difficult to do in a binary format.
cfsworks suggested that the scene format is a directory with each entity in a separate file, which would make merging easier.
Another(not mutually exclusive) suggestion is to allow BamWriter to operate in"text mode" where the index of objects and relationships between them are stored as plain text, and so would be diffable. It could use unique string IDs instead of the existing file-local short integer IDs to better deal with relationships between different files.
For distribution, scenes would be"compiled" into a single .bam file.
Editor GUI
Choice of toolkit?
In-panda UI or out-of-panda UI?
References
An example(Python) ECS in Panda can be found as part of the panda-bamboo project
Rationale
Roadmap
Design