Begin with editor or "main" game?

Started by
13 comments, last by MaulingMonkey 18 years, 7 months ago
Hello there! Planning my first bigger game project (a 2D Action-Adventure like Flashback or Another World, but with 3D engine) with my friends I´m wondering what is better to start with: The main game app or the editor? Since both should use the same engine (editor perhaps with some cutdowns on detail like lighting and stuff) I would need the engine up and running anyways, at least in a very basic way. If the engine was able to perform the most basic tasks, should I then start to write an editor first (which means getting a map file format settled and being able to produce test levels more easily afterwards) or should I start writing the game (which means input handling, character movement) using something like a hard-coded "template" map. I really dislike the hard-coded template map thing about the second approach, so I´d rather choose to write an editor first, since this would literally force me to get a map format done and would allow me and my friends to create some test levels for various things in the game. By the way I´m not talking about writing something like a modelling tool, "just" a level editor for use with pre-made models as tiles. I think I´m going to use Blender as a modelling tool. Any opinions and / or experiences on this? All input is appreciated. Thx for reading!
Advertisement
You could build the editor into the engine, perhaps?

Edit:- I have time to add more detail.

For one instance of Manta-X, I build the editor into the engine using some crude GUI components. I could fire up the editor at any time and alter the level, even whilst the game was being played (which was paused when the editor was active). This was useful in altering the various scripts that were run (the editor really only reloaded the scripts from outside, but a full implementation could even include an in-built script editor).
I guess you'll need a render first and then use it in both game and editor.

So, you might start you're game and make it render a few triangles, set up some math, then use the render to start an editor (or make a simple tool to convert a blender model into a simple map, ... so you'll have the map format and a simple map for tests and plenty of time to develop you editor without forcing others to wait for the editor, that's of course if you'll still need the editor after you make the conversion tool ;) )
It's a bit like the chicken and egg paradox, flip a coin on it.
-----------------------------Language: C++API: Win32, DirectXCompiler: VC++ 2003
I would try doing both at the same time because it will be easier to define your goals. It's very hard to predefine everything up front otherwise. Also, seeing your engine run rudimentary parts of your game in steps does good for your motivation. Writing tools is very hard work because the apis are anything other than game related which can be fun at first but then grows tedious after x rewrites. The only drawback of doing both at the same time is that the engine will undergone changes as well so it takes longer to write but it's better than working on the editor in isolation hoping that you covered all the bases when it comes to writing the engine. It might happen that a discovery in engine will prompt rewrite in editor. The map format won't stay stable as days go by and you think of new ways to do or add new features.
Obviously, I would define the format of the actual map file first. Once you have that, you could either start on the game or the map editor. In my opinion, I would create the editor first so that you have game levels to work with once you start working on the actual game. This is what I did when making a sidescroller action game and it worked out well.

Good luck.
I made a 2d map / level / campaign editor a while back for a game, but never actually used the editor for that game. However, I started a small project a little while ago, and found that the editor really really sped up the game creation process ... since I knew the map format, and how the levels would be pieced together, also it let the the artist in the project put levels together while I got the game running.

I suggest putting the priority on the editor first, it will save you the time of re-coding your game if you do this the other way around.
Most of you seem to second my thought about starting off with the editor... so I guess I´ll start implementing a very basic version of the engine that just displays the background and some platforms. Then I will implement an editor that allows me to build this basic kind of stuff and start with a game app that displays these basic maps.
After that I would increase the capabilities of the engine, then the editor again and then the game. Seems like a feasible approach I guess to do this iteration over and over again until the engine has most features needed for the game.
A bit like JD´s approach I think...

thx for your opinions!
Sounds like, one way or another, it's basically a tile map.

Therefore I strongly encourage you not to write an editor, instead use another tilemap editor, of which there are several already installed on your machine (I promise) if you think laterally. Candidates are notepad and mspaint (Assuming you are using Windows - if not, you will have equivalents anyway).

There is likely to be some map-editing which is not easy enough to be done with notepad or paint, but you can probably worry about that later (setting object coords, properties etc)

Write the game (or at least the main bits of the engine) first. In the meantime, have a hard-coded map which you create at runtime (could be random too, or generated according to a pattern).

Mark
i wouldn t start with the engine and especially i would share the same renderer for the editor with the engine this makes things too complexe

before starting with an engine or a editor i would build a library which features most of the things needed to get something going

e.g.:
- a file system with pak file support
- a general purpose image loading class
- several manager classes that coordinate the core of the engine
- a network wrapper if you plan to integrate a network at all
- math library vector2d vector3d matrix plan bbox cylinder sphere...
- math library with several other implementations you might need to in your future projects
- a pool allocator implementation compatible with STL list and STL vector
- bitpacking class for fast bitpacking of network packets
- maybe a compression lib huffman .... whatever you like
- a shader implementation that allows you to specify how to use a certain texture in your renderer

these are a few things most engines need and designing them properly with a consistent implementation will spare you are lot of time and trouble so you can start of with your engine/editorproject without interupting your work for a ton of side by problems to solve

http://www.8ung.at/basiror/theironcross.html

This topic is closed to new replies.

Advertisement