Building an editor for a specific game is usually a time consuming job. As long as you use your own engine with your own routines you have to create the editing tools yourself. There are many projects where people build their own codebase around a specific format (like we used to do in an older project with the Quake3 level format BSP) which allows you to use already existing level editing tools. This one won’t work on our project 🙂
Let’s see what we need to get started. First of all we have a 2d game in XNA. Then we have our level format (it’s XML). Then we have our XNA renderer (sprite draw calls are not rendering but it sounds cool though). So here we go with the options we would have so far for our editor:
- Extend the game application with a build in editor where the game designer or the artist could create his map directly in the game engine so he would see it how it actually looks. This idea would be great.
- Create a stand alone application let’s say in C# WinForms, WPF or whatever language you prefer. This one was my preferred option in the past.
- Use a already available editor. This option is not but could be the most limiting option since you would have to create a loader for the output of this editor. This means that you cannot integrate all of your custom ideas and features since they have a fixed file format.
- Don’t allow anyone to create/modify the levels so no editing tools are necessary. (this one is the worst decision)
Let’s start with analyzing the options. The first one sounds good and seems to be the most adequate solution for the editing tools. Creating your application with a build in editing feature is covered in some of the more advanced XNA tutorials out there and is technically easy to integrate. You build your editing tool on top of your framework and so you are able to use all game objects directly. Another benefit of this solution is the live preview of your levels and the short development time. Definitely our number one choice isn’t it? But let’s see what the others have to offer.
The second solution, a stand alone application was my personal number one choice. Separating the editing tools from the game itself has some advantages I will discuss later in this post. The main disadvantage is that you have to create everything from scratch. Do you remember the good old QeRadiant (or GtkRadiant) for Quake3 editing? It could look something like that. Maybe a good solution or what do you think about this?
The third solution, using something already available isn’t that good. Maybe you have a different opinion on this but usually when building a game you have some or many ideas and features you want to integrate which are simply not possible with available editors. I helped on a project some time ago where we have been able to use an already available editing tool like TilED
and it did a great job. We simply had to build a small console app to transform the TilED level format to our custom level format. For this game TilED simply doesn’t provide the features we need so let’s skip it.
The fourth and last solution is not a serious option. I want the artists and designers to work on the game, not myself. I just want to develop the app
So what option should we choose? Someone who thinks about it, would definitely choose the first option which is the best and most appropriate solution for our editor. I won’t. I went with the second option. WHY THE HELL DID YOU DO THIS? you will ask me now. Easy. While indeed the first option is a lot better comparing developing time, comfort and all that, the second has some advantages we didn’t mention above. We did completely forget about the ContentPipeline (man I will never get used to this). While the artists would be able to load existing levels and edit them with existing assets how would the create new ones? How would they load new sprites into the running app? What changes would be necessary to load them directly? It’s easy to use the OpenFileDialog to choose a sprite but how will you load the selected sprite into the content pipeline of XNA? So comparing the development time of a standalone editor with the time I would need to learn how to solve this issue I decided it would be better to go for the second option. I already said I’m new to XNA and don’t have a solution on this I would be more than pleased if someone who already solved this problem could give me a hint. But this cannot be the only reason. No it isn’t. Separating the game application from the tools is in this case (and in most of private projects) recommended. This is my personal opinion. The main reasons (beside the technical problem above) is that building tools as separate apps allows you easily to reuse the code for future projects. You can go different ways on a Windows application and wouldn’t have to care if you break things up in your game application. Separating also improves code maintenance and allows other developers to continue work on the tools and the main team on the game. Since we will build a C# windows application the most important thing is that the editor can be developed in half the time it would take to make work as a build-in solution. This is also important the bigger the project gets. Again, this is my personal opinion. Other developers my argue completely different which is ok. It’s more a question of design philosophy I think as long as the result is the same.
The decision was taken and a C# Winforms Application will be used. Yeah. I love my job. More work than I expected but hey… that’s why we are programmers
