Before I mention anything, Panda3D is a great game engine that is easy to use for people who are new to game dev, like me. I’ve been using it for about a month and I really enjoy it.
However, there is one part of Panda3D which is annoying and, in my opinion, needs an update: the Direct Session Panel and the Direct Tools, Panda3D’s placement tools.
When you look at other game engines, they usually have an interface where you can place objects within the world. Panda3D also has this, but you can tell it is old (Copyrighted in 2004 and probably hasn’t been updated since then). The camera controls are a bit off, placing the objects don’t work as intended, and there is no quick way to apply changes made in the direct session panel to your code (I might be wrong about this).
Because of this, placing objects have to be done by trial and error. This is fine if there are not that many things, but if there are a lot of objects to place, this is a pain.
I might be out of my place saying all of this, as I started learning programming last year and still in high school, but an update to these tools seems like something that I hope will be done in the future.
In fact, these tools are easy to write for a specific case by the developer. Than to have a universal SDK, which, as a rule, will have unexpected limitations or lack of thought. You need to understand the development of the game includes the creation of tools. As far as I can remember with panda3D, I have never been interested in Direct Session Panel and the Direct Tools.
I would argue that, while visual editors have their limitations, they can also be very useful indeed. I wouldn’t discard them entirely! Indeed, I think that the provision of a visual editor is perhaps one of Unity’s greatest advantages.
As to an editor for Panda, I believe that there are a few community-driven editor-projects floating around the forum. I don’t think that I’ve used any of them myself, so I can’t speak for or against any such, but if you search around perhaps you’ll find something of use to you.
For myself, I use Blender as my “level editor”, combined in some cases with custom tools (such as serega-kkz suggests).
As to DirectTools, I think that I’ve found it to be very useful not as a level-editor, but rather as an occasional debugging tool–a means of checking whether NodePaths are being cleaned up properly, for example.
Of course, but you need to implement most of the logic instead of the user on which the work of the SDK will be based. In fact, this is a wide range of gaming solutions. And bringing them to the patterns of one thought is not right.
I wanted to say who can create the game, he can also create utilities.
Hmm… I’m honestly not quite clear on what you’re saying in your first paragraph.
I think that you’re saying that different games have different requirements, and that it’s bad to try to force all games into the pattern assumed by a single editor? Is that right?
If so, then I somewhat agree–but I also think that a very large set of games can be made in a single, well-made editor. Just look at all the varied games made using Unity, for example!
On top of which, there’s space for the creation of multiple editors for specific types of game; just look at specialist tools like Adventure Game Studio, for example.
To some degree–but making a good tool is quite different from making a good game. Someone who’s good at one won’t necessarily be good at the other, I think.
Plus, there’s the argument in favour of “making games, not engines”–I think that the same might be said of tools: time spent making a tool like an editor is time that could perhaps have been spent making the actual game, if an editor had been provided.
I think we have to distinguish the DirectTools from an actual editor; while writing a full-fledged scene editor for Panda3D will be quite a challenge (but I’m sure will be useful for many), there’s a strong case for having debugging tools that you can use to quickly find an object, inspect its properties, and things like that.
I’d personally like to see a new kind of debug overlay implemented in Panda3D that allows inspecting the scene, PStats, the rendering pipeline, etc. I think this will help users quickly track down visual issues in their game while the game is running.
A full-fledged editor is on the roadmap, but given the challenge of designing an editor that will be useful in a wide range of games (as the others have alluded to), it probably won’t appear in the near future. In the meantime, I expect that Blender-based workflows will continue to be popular for scene editing.
Well, that’s what my GameSaver module does: it’s a general-purpose saving-and-loading module. (Although I’ll note that a security issue has been pointed out that I haven’t yet gotten around to dealing with, so I don’t right now recommend it for others to use.)
But otherwise, I don’t know how Unity handles this (it’s been far too long since last I used it), but it presumably has some format for storing its level-data. There may be other data that the editor doesn’t handle, and that the developer ends up saving themselves–but they’d presumably have to do so whether they used an editor or not.
An editor may not handle absolutely everything–but that doesn’t mean that it’s not a very, very useful tool to have.
Oof, that would be wonderful! DirectTools and PStats already handle this to one degree or another–but to have something as integrated, convenient, and extensive as you seem to describe would be a significant improvement, I do feel!
That’s good to read!
I daresay that it will be quite a challenge; good luck with it, and I hope that the project goes well!
But as you look at the fact that this creates a binding to the python. As you see, it excludes the possibility of migration to another engine. How do you store terrain and bullet objects?
This will actually work for your game. If someone tries to use your GameSaver, I assure you will get 1000 questions.
Of course, I’m a bore, but we need to think about completing the main classes, such as terrain and more.
It would also be nice to deal with a rendering system. For example, implement at the C ++ level RenderPipeline.
Maybe I don’t know about the terrain system that can be edited in the SDK?
There are 1000 more questions on request.
If you’re referring to editors here, then, well, yes–an editor is expected to work with just one engine.
If you mean GameSaver, then I think that as long as you’re using Python, it shouldn’t be too hard to port it. There’s little that’s Panda-specific in there. (Just the file-io stuff, I think.)
But one way or another, switching engines is seldom a quick-and-easy task, I suspect–even if you don’t use an editor.
I usually store such things in my model-files, I think.
(Although I’ve not worked much with heightmaps, so I haven’t given much thought to how I might store them. Likely just as images to be loaded, and referenced by file-name in the level-files, I imagine.)
It’s worked for several projects of mine, I believe. I’ve expanded and improved it over time, but so it goes.
In any case, I suspect that most tool-projects get those thousand questions, especially early in their lives when many unforeseen issues lurk within them.
Oh, I suspect that developing an editor is quite low down on the list of the Panda-devs’ priorities! ^^;
I mean a format that can be read in C ++ or in any language, using a different engine. For example, the text version does not depend on the language of the program, the same engine.
Ah, I see. Honestly, I’d consider that someone of a nice-to-have in a file-format, rather than an important feature.
That said, the file-format used by GameSaver should be perfectly readable. You’d have to engineer your own reading code in the target language–but I’m pretty confident that the same is true of nearly any file-format.
GameSaver uses Python to read and write; for the most part the files themselves don’t contain Python. (I forget offhand whether there are any exceptions; they’d likely be rare, I imagine.) They may reference game-classes, which would presumably be Python–but I’m not sure of how you’d get around having it be so. In any case, it may be feasible in many cases to have the custom reading code look for those class-names and interpret them as desired.
