Game Editor architecture,
Members - Reputation: 248
Posted 03 February 2013 - 12:40 PM
Crossbones+ - Reputation: 3117
Posted 03 February 2013 - 02:45 PM
I was curious as to why you decided to use MFC over wxWidgets? I am personally a huge fan of Qt for GUI applications.
My advice when it comes to architecture is to design your editor using flowcharts/UML before attempting to code it. At the minimum avoid adding features for the sake of adding features. Use your editor in the context of creating a game and you will have features that grow organically (and that are actually useful for something).
If I were to design an editor I would make some form of scripting language a core feature. The ability to script game logic, write triggers, and create new tools without having to change the source code for your editor will in my mind make the editor a lot more flexible. I might even suggest having your game's importers and exporters defined in a scripting language as well.
Have you checked out Ogitor? It is a Qt based scene editor for Ogre.
Members - Reputation: 4601
Posted 03 February 2013 - 09:19 PM
Make sure your classes only do one task. If you have to use the word 'and' to describe what a class does then you should split it up into multiple classes. Keep the parts as disconnected as possible. The code that does the drawing shouldn't depend on code for collision detection and vice versa.
I would only make an editor if it were to facilitate making a game that you are already working on. Don't try to make a generic game editor that is capable of making every type of game. The game editor should use as much code that makes sense from the actual game. This could be the drawing code, collision detection, ect. Also, don't add features to an editor unless you actually need it. You can spend a lot of time adding features to a game editor or game engine but if you don't have an immediate use for it then it is a bit of a waste.
Also, I would like to give out a warning against global or singleton managers. Adding global objects makes code less flexible and testable. Global objects are tempting because they make access to them really easy. It takes less work to plan out the code. In the project I am working on now I have made it a point to not have any singletons and it has been great. Before I would have a singleton resource manager, that way all loaded resources are cached in the same place. It seemed like a reasonable use for singletons. The project I am not doesn't do that. Instead I pass a resource manager wherever loading resources is needed.
Just the other day I realized how easy it would be to put all of my resources into a single file because of this. Instead of having all resources loaded from a non-changing global object. I can pass it different types of loaders. One loader takes a resource path and finds a file in a folder, or I can pass in a loader that loads the resource from a single combined file without making any change to the code that uses the resource loader. This is especially useful because the game I am working on is an HTML5 game letting me work with my resources organized nicely onto folders, then when I finish it, I can merge all resources into a single file letting them be loaded in a single request.
Some of my thoughts.
Members - Reputation: 248
Posted 04 February 2013 - 03:52 AM
Thank you for replies.
In conclusion i decide to use plugin architecture.
It would give a lot flexibility and it`s like all editors do. But i never before faced with that. So i will try to tell you what i think about it.
Host App contain
- load/unload plugins
- base interface to add frame/window and other UI
- base interface to communicate with other plugins
- collect all events and EventListeners
- send specific events to it listener
It's all what host app contains. But, how to implement it? I mean all communication. How to load and save files. Edit object with different plugins. I'm thinking to use QT, is it better than MFC or wxWigets.
Can you give me some advices please.