Jump to content

  • Log In with Google      Sign In   
  • Create Account


Game Editor architecture


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 Towel   Members   -  Reputation: 122

Like
0Likes
Like

Posted 03 February 2013 - 12:40 PM

I'm creating 3D Game Editor for my own use. As rendering i took Ogre3D and MFC as UI. 
 
I faced with architecture problem. 
 
I am using Document/View architecture and for each Doc. i create new SceneManager and for each View i create own viewport, camera, my own local Input manager which send input data to local camera. Also it's sending input data and pointer to SceneManager to global ToolManager which contains some base tools like Move, Select etc. and the pointer to active tool, if it's NULL he is sending input to SelectTool by default.
 
I'm only at start but i'm thinking of the future. 
I think that this strategy of passing some data to the global manager is not so good how it looks now. Can you give me some design advices or articles and share with me your experience. 
 
Thank you for your time.


Sponsor:

#2 shadowisadog   Crossbones+   -  Reputation: 2443

Like
0Likes
Like

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.



#3 HappyCoder   Members   -  Reputation: 2567

Like
0Likes
Like

Posted 03 February 2013 - 09:19 PM

A few tips that I would give about design in general.

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.

#4 Towel   Members   -  Reputation: 122

Like
0Likes
Like

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

 

  1. PLuginManager:
    • load/unload plugins
    • base interface to add frame/window and other UI
    • base interface to communicate with other plugins
  2. EventListener
    • 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.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS