As the design behind my game changed over time, becoming more complex (feature creep == bad, but that’s another topic) I began to realize my editor was falling behind my game. I didn’t want to limit my game by using mediocre tools that took a long time to make, and were difficult to maintain, so I decided to go back to the drawing board.
First this meant rethinking what an editor should do, why it should do those things, and how it will do them.
Why have an editor?
This is the first question any developer should ask themselves before plunging into writing code. Why am I writing this, why do I need it? Sometimes asking this question leads to the realization that you don’t actually need to write anything, because the idea is unnecessary. If your game is small enough that you can create the amount of content you want using some other tool faster than writing an editor, you don’t need an editor. Similarly, if your game is simple enough that an editor doesn’t help you make better assets, you don’t need an editor.
Another reason to have an editor, is the ability to use the same editor to create assets for multiple games. In the long run, the time required to make an editor can pay off if you use it enough. If this sounds like you, there are some key things to keep in mind when you’re building your editor. Which we’ll discuss momentarily.
What should an editor do (and what shouldn’t it do!)
Once you’ve decided you need an editor, you need to think about what kind of things it should do. Since I want my editor to be reusable for many games, I have to be vary careful to think of it as a distinct project, separate from actual game project. It can be a huge pain to finish something, and try to use it on another project only to find out that the editor won’t work without a ton of game specific features and code.
In a simple outline I decided that my editor should allow users to:
- Create in-game objects (Potentially from a library of pre-created objects, or the ability to create new objects)
- Move/Rotate these objects
- Create very specific objects that are game dependent (Just because we want the editor to be distinct from the game, we don’t want to gimp the editor, thus limiting how unique and vibrant our game will be. This means we need a very dynamic and modular way of handling these types of objects)
- Undo/Redo support. (I had an old editor without these features, because they didn’t seem worth the trouble of implementing compared to features that would directly effect the game. Boy was I wrong! It was a time consuming mess, and try getting someone who isn’t a programmer to use it..)
- Export/Import the scene to some format that is readable by the game and the editor.
This was the basic feature-set I decided my editor should have. Notice that none of these things specifically mentions anything unique to any game. Its all very generic, and thus will be reusable.
How should an editor do these things?
This for me at least, brought on a question I still don’t know if I have the correct answer to.
At first, as you can see in some of my older posts, I thought the answer was simple:
“I will create a beautiful WinForms application with all the bells and whistles any good commercial editor would contain! It’ll be easy to use because it’s just like any program we’re used to using on a computer, and it will be powerful enough that we can do lots of amazing things with it.”
The editor, actually succeeded on a lot of those things, but the more I used it to actually design scenes for my game, the more I felt that I had gone about it the wrong way. It felt too separated from the game, it was difficult to gauge how the scene would actually play out once I loaded it into the engine. Sure I had a feature where it would launch whatever game I was working on and create the scene just like it looked in the editor, but it just felt clunky somehow.
I decided to try a little experiment.
WinForms vs. GameComponent
Maybe WinForms wasn’t the way to go about this. To me it wasn’t even a question when I first started, even though it should have been. It seems like most people in the XNA community, myself included, just assume that is the best way to go. After all, that’s how the professionals work! Right?
Compare the number of topics asking about how to get things working with WinForms to the number of topics about in-game editors on the XNA Forums and you’ll see what I mean.
So far I can say that implementing the editor through a GameComponent type of system has huge benefits over the WinForms way of doing things. Combined with my console component, all I have to do is type “editor” in my console and I instantly have a fully featured editor overlayed on top of my game. I can do all of the things I outlined above, and instantly switch back to playing my game, and try out my changes. This allows me to make much more informed design choices, which results in levels that are much more fun and challenging.
To anyone who has tried to use XNA in a WinForm setting, it’s clear that it is possible to do it this way (and getting better with each new realize of the XNA Framework) it doesn’t feel like it was designed to do it this way. Gone are the familiar Update and Draw loops. Gone is the ‘Game’ class which makes using many great components/features/services difficult or impossible to use. The ability to use all of the XNA Framework to create the editor without ugly hacks to get things working with WinForms made development much quicker.
Another potentially huge reason to use this type of design is that the editor can be included with games for release. That means adding potentially limitless replay value. Combine that with online sharing of levels (even over Xbox LIVE!) and it could be a recipe for a more successful game.
I’ll end this post with a summary of my opinions on the GameComponent way of doing things:
Pros:
- Instant design feedback
- Access to familiar design paradigm (Update/Draw/Components/Game/etc)
- Xbox 360 compatible
- No need to use obscure hacks and bad code to get things refreshing properly
- Edit with full animation at 60fps with no extra work, you can do whatever your game can do. (Great for editing particle effects, etc)
- More user friendly (if done well)
- Don’t have to re-implement some WinForm compatible versions of code that already works in your game
- Have access to any parts of the XNA Framework that you have access to when making a game.
Cons:
- Have to create some things that already exist as part of the WinForms library (E.g. PropertyBox, TextBoxes, ListsBoxes, other UI stuff)
- If you do decide to ship the editor with your game, it needs to bug/crash free.
- It goes against your desire to have a pretty Windows application!
I’d love to hear comments on how other people have done editors, or their thoughts on which way of doing this is better.
Also, would anyone be interested in seeing how I structured the system for my editor? If so, would you like to see code samples, tutorials or some other format?
Posted by AntiForceKyle 
