When developing a small project, the time cost of making an editor can become very significant, and only 6 months ago, I would have encouraged anyone to avoid it completely. I would have asked “is an editor absolutely crucial to the development of your game?”. If you can avoid the requirement for a custom editor, you can avoid a laborious process of content creation – go for procedural generation or a 3rd party editor. Look at Minecraft and Frozen Synapse – procedural programming generates the content for you. This doesn’t just remove the need for an editor, it removes the need for an artist, meaning you only need a single programmer to create the game. Awesome.
The use of an editor, its role in a pipeline, and how it integrates into the game itself are actually really important and complicated decisions. There is a huge effect on productivity, game design, and ability to make changes late on. The more complicated the software, the more essential and complicated the tool components.
Sure, some games can get away with out an editor, but at what cost? How can you tell when making tools will save you time or effect the quality of a game.
The more you look at the design problem, the deeper it gets. This article details my experience and opinions, but is really intended to highlight some things to think about. This topic is highly subjective so every point will have a counter point.
Procedural vs authored environments
Procedural environments are generated using algorthims, while authored environments are created by people.
My experience lends heavily to having authored levels. The first internal version of Terrorhedron had procedural generation, where you could generate a level based on a key, and it worked, but at a cost. The expense was the inability to fine tune levels – you just had to play a bunch of seeds until you found one that was good, and even then, the levels could only have a certain style. To take the game to the next level, the levels needed designing rather than generating.
Designing a game using procedural generation is difficult as getting the environments generating how you want can take time, so there is an up front investment in time. This is expensive when you are still researching and experimenting. Artist authored environments also have an up front development time, and has its own design considerations.
Why you shouldn’t use 3rd party editors
3rd party editors usually bear the limitation of not understanding or visualizing game logic. This is a big limitation where a designer needs to engineer actions, events, logic routes etc. into a scene or animation. Perhaps we can hack this in somehow? Also, probably going to have to write a custom exporter for the 3rd party editor. What would the additional effort be in making your own editor?
Terrorhedron ended up using google sketchup to develop and design the levels, 3dsmax to prepare and convert the data then export to game-loadable formats (.x for graphical assets, physx .xml for physics and logic data). This worked well as I was experienced in preparing models in 3dsmax, and had planned on using pre-baked ambient lighting which looked good in game. The down sides were converting z up to y up (see previous blog post), which was a confusing task and took a while, and the lengthy process involved in exporting the various layers and components and then recombining them in game.
By the time I had done the 6th level, I was getting fast at the process but was also fed up of making the levels – the painful exporting process was taking the joy out of the creative process. The simple style of the maps begged for a simple editor that understood the art style. 3DSMax was completely overkill for this and the exporting process was completely unnecessary as the raw data being handled was so simple.
How much better would it have been if game included an editor and levels could be created by users? What if the level creation process was as simple as it could be, and took raw creative input and handled everything else?
Why you should create your editor in-engine
By creating the editor using the game engine, you get to see the content as it is created, how it will be experienced in game. You will only have one code base and a lot of the functionality will be tested twice – once with the editor, and again with the game. You can use a lot of the game framework to create the editor code.
Tool design and iterative development
When developing an editor, there is a fair amount you need to know about what the tool needs to be able to save out, as well as how it will be used. Changing this specification later is painful and time consuming, so where possible, develop a basic hard coded scene to test scene features and get to grips with the way the scene is organized and what data it contains. This will clarify the task and make it clear the task you are simplifying – probably replacing hard coding with a visual interface.
The tools used with a game engine to create a game are very subjective and must suit the work style and tastes of the developers. They are integral to the code architecture and require plenty of foresight and design. It is just one of those things you have to have done a couple of time already before you really know what suits you.
Tools take an investment of time, but can return that time back by improving productivity. They can have good and bad effects on the quality of a game. Weigh up these factors carefully when designing your tools.
Reddit discussion by Badsector, author of Runtime World
Interesting article. Since i have spent a great deal working on game tools, i want to comment on a few things.
3rd party editors usually bear the limitation of not understanding or visualizing game logic.
This is true, but this will not be the bulk of where the game’s logic will be spent and a world editor does not really need to provide this functionality, even if it is a custom editor for a custom engine for a specific game. This is part of the game’s scripting and can be done in a separate tool – you could even make a visual scripting tool that uses graphs and such if you feel your designers are incapable of writing code (if they’re worth their salt, they shouldn’t be – basic scripting skills are necessary for a good level designer).
Also, probably going to have to write a custom exporter for the 3rd party editor. What would the additional effort be in making your own editor?
Tragically more effort. Runtime World in its current state took me ~2 years (and if i include the complete-from-scratch rewrites, that goes to ~5 years) and still only has the bare essentials for making game levels (essentials that were only available since the last version!).
I’m not spending all my time on the editor and it would be usable much faster if i was working on it full time every day, but still even a simple editor is much much harder to write than an exporter.
In fact, writing an editor is much harder than writing a 3D engine, especially if that editor has to be usable (Runtime World wasn’t the first editor i made and even that took me a few rewrites to get right). Want proof? Just go to DevMaster’s engine database and check how many engines have editors vs how many do not have. Even including those that have editors but are hard or unusable, the engines that have editors are vastly outnumbered by the engines that do not.
How much better would it have been if game included an editor and levels could be created by users?
While it depends on the game, i’d say that generally it would be much better. Custom user-made content, mods, etc add a lot of value to your game (well, ok, it depends on the game – an adventure game would hardly see more value there, at least beyond fan-made stories with the game’s characters).
However using a 3rd party editor doesn’t go in contradiction to that. You mentioned using Google Sketchup to make the levels – well, now your players can use that too since it is free. And while 3ds max is expensive, you can write an exporter for Blender which is free (writing Blender exporters is easy – personally i learned Python by writing an exporter for my own format some years ago). If you can use a common format (even as an intermediate format) it is much better – for example if your models are static then OBJ files are a standard format to use, supported by almost every 3d modelling package out there.
Hey you could even use Runtime World!
Why you should create your editor in-engine. By creating the editor using the game engine, you get to see the content as it is created, how it will be experienced in game.
This is something i am personally against – and not because it sounds like a bad idea (actually it doesn’t, almost everyone would agree that the idea sounds good), but because i have actually tried it for years and experienced first hand why it is a bad idea.
The major problem is that you try to make the same code do things with two opposite priorities (the editor’s priority is to do things easy for the designer while the game’s priority is to do thing fast and proper). Additionally you add a lot of extra unnecessary code to your game that is not needed by the game itself, but by the editor. You could try to keep them as separated as possible, but this makes the code be designed to be as “purpose agnostic” as possible (think classes and stuff), which complicates the overall architecture.
It is a much better idea to simply keep the codebases separate and make the editor’s output be close to the game’s output but have the game’s code be strictly about the game and the editor’s code be strictly about editing and all the diagnostics and stuff the editor needs.
This way you also get to minimize the game’s source code which is a good thing because there is less of a probability to create bugs. A bug in a tool isn’t as much of a deal as a bug in a game.
This topic is highly subjective so every point will have a counter point.
You didn’t added any counter point to the points you mentioned 😛