Take the 2-minute tour ×

What I am trying to figure out is what is the best way to integrate the editor(level, effects, model, etc...) in the most effective way?

Now the first thing I thought would be to create the game engine(*) extremely modular. For example I took the example of game states. You could have multiple game states that all have their own update() and draw() methods among others. Each game state class would inherit from a base GameState class. This allows for a more modular approach and a useful one at that.

Now would the most efficient approach be to implement the editor along with the modular engine, or create two different designs for both the game, and editor? I thought to take the game state example and extend it to window states, and well could be used for a lot more systems. Is there a better implementation of this design(game state) for use in other systems used in the engine?

*: Now I know the term game engine is sorta irrelevant, and misused in many situations. What I am referring to as the "game engine" is the combination of the systems that the game must interact with for short.

Also this is more of a theory / design question than an implementation. Even though both mix, i'd rather like to have a more general idea on how the editor is built in an efficient way and still using the same engine code as what the game uses.

P.S If you need more clarification or extra bits just leave a comment.

share|improve this question

1 Answer 1

up vote 4 down vote accepted

I think your question is more about design, but usually you don't want to design something that can't be implemented, so implementation shows up every now and then.

As for the editor, I think it depends on what the run-time game engine library can support. Does it support some kind of general application architecture (e.g. event system, exception handling, GUI, etc...) or is it more focused on running a particular type of game that it was made for? If it supports such an architecture, I think one would implement the editor similar to a game. If it didn't, the editor could be a stand alone program using some established framework.

You might want to check out Game Engine Architecture, by Jason Gregory. In this book, the author points out that UnrealEd is an example of an editor built using the engine that it supports and that such a design has pros and cons. (pro: everything is native, so it's easy to hit 'play' and jump right into the game from the editor. con: if your engine isn't stable/in development, the usage of the editor can be affected.)

Below is a picture of an engine's architecture from the same book, for an example. To integrate an editor, you would probably want to add a generic GUI to the Frontend. You might also want an application Event system (that can be turned off/on) that sits somewhere between the HID and the Frontend. You could probably get a decent amount of functionality out of just that, but there might be an Editor/Generic Application - Specific Subsystems bubble next to the game one and other preexisting bubbles might be extended, as needed.


share|improve this answer
Thank you for some good insight. I'll be sure to pick that book up as it's been suggested multiple times. –  Daniel Jun 17 '12 at 6:22
Game Engine Architecture is an amazing book, but it stretches itself too thin. It talks about subsystems, but never in much detail. Nevertheless, I would recommend it for anyone wanting to build their own engine. –  knight666 Jun 17 '12 at 6:38
Thanks. Understanding on how to build an engine, and roughly how the implementation process goes would be my first task since I would want to get some more games under my belt to really understand of what I need and don't need. –  Daniel Jun 17 '12 at 6:50

Your Answer


