Sign in to follow this  
matches81

Begin with editor or "main" game?

Recommended Posts

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!

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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 ;) )

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Quote:
Original post by Basiror
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


I considered that to be part of implementing the engine, though you´re surely right most of these things are not strictly part of the engine itself.

Quote:
Original post by markr
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


good point to use some small "hard-coded" map or some extremely simple map format which can be stitched together in notepad or something like that. But I´m quite positive there are lots of things I´ll need an editor for when the engine and the game progresses, e.g. placing triggers, items, NPCs, logic entities and so on around the map. Also I want to use seperate meshes for the background of the tile and the platform (i.e. floor / ceiling) in that tile, which would be quite painful to do with something like notepad on the long run.
Oh, and yes, it will definitely be a tile map. Though it´s not 100% settled whether we need a simple 2D tile map, or perhaps we need a 3D tile map, because we might want to be able to connect 2 different halls in the Z-direction, would add something to the game... but that´s not settled yet and is probably something to be added quite a time later on.
At least that simple "handcrafted" map will serve well while implementing the most basic features of the engine.
Thx for the input!

@evolutional:
A nice idea, too, I think. So you essentially fire up the game app and enter some kind of "edit mode" where you´re able to change the map the way you want it? Will have to think about that when the complexity of the game itself becomes more clear, don´t know yet, whether it´s a feasible approach for that project, since it might well include many scripts... but an in-game editor with scripting functionality would be great :)

Share this post


Link to post
Share on other sites
you can consider the whole shader and image processing implementation relevant for your editor

why writing 2 implementations for one and the same thing

this gives you the possibility to test you implementation before you use it in the engine

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Assuming you've got your libraries and support stuff down, the editor. You will save a lot of time in the long run if you know you can quickly make good test data.

Share this post


Link to post
Share on other sites
I did the first period of game development with a routine that would build a map from a simple text file.

Here is an example :


group map
{
string 000 = "eeeeeeeeeeeeeeee";
string 001 = "ehhhhhhhhhhhhhhe";
string 002 = "ehhhhhhhhhhhhhhe";
string 003 = "ehhhhhhhhhhhhhhe";
string 004 = "ehhhhhhhhhhhhhhe";
string 005 = "ehhhhhhhhhhhhhhe";
string 006 = "e--------------e";
string 007 = "e-HHHHHffHHHHH-e";
string 008 = "e-HHHHHffHHHHH-e";
string 009 = "e-HHHHHHHHHHHH-e";
string 010 = "e-HHHHHffHHHHH-e";
string 011 = "e-HHHHHffHHHHH-e";
string 012 = "e-HHHHHffHHHHH-e";
string 013 = "e-HHHHHffHHHHH-e";
string 014 = "e--------------e";
string 015 = "eeeeeeeeeeeeeeee";
}

group entities
{
string 000 = "eeeeeeeeeeeeeeee";
string 001 = "ehhhhhhhhhhhhhhe";
string 002 = "ehhhhhhhhhhhhhhe";
string 003 = "ehhhhhhhhhhhhhhe";
string 004 = "ehhhhhhhhhhhhhhe";
string 005 = "ehhhhhhhhhhhhhhe";
string 006 = "e--------------e";
string 007 = "eHHHHHHffHHHHHHe";
string 008 = "eHHH%HHffHH*HHHe";
string 009 = "eHHHHHHHHHHHHHHe";
string 010 = "eHHHHHHffHHHHHHe";
string 011 = "eHHHHHHffHHHHHHe";
string 012 = "e-HHHHHffHHHHHHe";
string 013 = "e-HHHHHffHHHHHHe";
string 014 = "eHHHHHHf&HHHHHHe";
string 015 = "@eeeeeeeeeeeeeee";
}



I also had other sections to define what each letter represented.

This way I could flesh out the game before diving into the editor.

Now that I have a real editor, I switch back and forth all the time as I add features to both the editor and game.

Share this post


Link to post
Share on other sites
I tend to advocate iterative development, which would mean I'd answer "both".

Write a base framework for the game. Prehaps it does nothing more than parse and store a crude tilemap format. Create a stub "editor" which prehaps does nothing more than view it using Qt components (or whatever you choose). Create a stub "game" framework which does the same thing using OpenGL (or whatever you choose).

Viola. Add in more pieces on top as you desire. You get to provide maps using the editor to test out the next piece of the game, and you get the game to test that you and the editor are on the same page :-).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this