3D Map Editor Design

You should have a model manager (or a higher level resource manager) which you load models into, meaning each model is only loaded once. Objects in your map will contain a pointer to a model, and then transformation information and any other info it needs.

The reason maps are "random symbols" is because they typically store their data in binary format. They usually just serialize C/C++ structs directly to a file so in your runtime when loading a map you don't have to do any unnecessary parsing/calculations.

For terrain you'd just use heightmaps and include tools in your editor to raise/lower sections, smooth out parts etc.

A map editor is supposed to do, what you want it to do.
What does your game need? I discourage you to make a map editor just for its own sake.

Make a game, make the editor with it. Design the editor in a way, that you can easily add more and more features later, as your game needs more and more stuff.

Building a map editor for it's own sake is almost like building an engine for its own sake.

But maybe I misunderstood something...

It's not easy, I can tell you that. At least not easy the way I (tried to) made my own once.

I used OpenGL and vertex arrays. I made it out of quads that I stored in vertex arrays of 8x8 quads and that I culled against a sort of threedimensional quadtree.

The way I stored the vertex data ended up being a complete mess, primitive classes with pointers to the values in the array. Completely un/mantainable/modifiable.

I got to being able to do some mountains with an sphere algorithm and got stuck trying to do multipass rendering and never went back to it again.

I hope you luck though!

Quote:

You should have a model manager (or a higher level resource manager) which you load models into, meaning each model is only loaded once. Objects in your map will contain a pointer to a model, and then transformation information and any other info it needs.

So basically I would have an array ready with all the models, then the map would just have references to them right?

Quote:

The reason maps are "random symbols" is because they typically store their data in binary format. They usually just serialize C/C++ structs directly to a file so in your runtime when loading a map you don't have to do any unnecessary parsing/calculations.

So like this?

#include <fstream>struct myStruct {  char name[12];  int age;};int main() {  myStruct myRecord;  fstream iofile("C:\\MYFILE.DAT", ios::binary | ios::out | ios::app);  iofile.write((char*)&myRecord, sizeof(myStruct));  iofile.close();}

Quote:

For terrain you'd just use heightmaps and include tools in your editor to raise/lower sections, smooth out parts etc.

Got any good links on the best way to do a height map? Google didn't give me any good results.

Quote:

I discourage you to make a map editor just for its own sake.

I'm not...

[Edited by - CDTMD on July 3, 2010 8:41:15 AM]

Some tips:
make a good entity system, you probably will need several types of 'objects' in a level (meshes, lights, npcs, physical objects, inter-object-connection data,triggers and so) - try to handle them the same way, so adding a new one is going to be more easy.

Serializing plane struct is very good, but this can be evil when you got a bunch of level, and you add or remove a variable from a struct, so the loader will die, or just won't work. This can easily be solved with some exra data describing the content the file have. I use a simple chunk system, it has a header for every element: 1 byte for the id for the var, 1 byte for the length of the data. With this an older level can be loaded, the missing elements can be set to default. An older loader can use a newer level too, skipping unknown chunks (with the length).

btw if you just want some rapid stuff, use an existing editor, a good example is Blender, you can export scene data (mesh orientations, lamps, cameras) with a couple lines of python code.

imho a decent tool for feeding an engine can be as complicated as the actual game.

Writing an editor is indeed almost as much work if not more than the game [engine] itself. I worked on a commercial product that was almost nothing but an editor and it was an endless uphill change and maintance battle for 3 years before it reached the point were it was usable on a constant basis without people outside the development team moaning for a new feature or another way of process flow. The data structures changed from day to day and were not backwards compatible for some time until we switched to using a declarative binary file format. We called it FLOW (File Loading and Output Wizard) as a nod to the people that would want the program flow to change all the time.

You described data structures in a FLOW script and "compiled" them in cpp/h files capable of now saving or loading that data file. The interesting thing was that if the field names stayed the same but changed format there were converters if they were single like int to float or double to string. You could also define conversions if they were a little more complicated.

Our main goal was to basically add and try not to take away making it easier to support previous file formats we created. This also allowed to some degree older versions of the program being able to open up files created with a newer version as well.

We also had an abstraction from the editor object and the runtime object. The runtime object was basically just what was needed to allow for end user interactions and rendering. The editor object changed constantly more so than the runtime representation and we had a final "process" to distill all the info for the release data. So in many ways we had two very distinct views of an object.

Another thing to consider is that a lot of work will have to go into the user iterface itself no matter if it is fully graphical or not. Historicaly from many source this turns out to on average to be almost a 3rd of all your code and when things go wrong it will also account for more that half of all the bugs you will encounter with your own work.

The most important thing to think when making a map editor is 'Do I need this?'. Not just for individual features, but for the whole thing.

Could you get away with writing some plugins to place entities from within a 3D modelling package? Could you just write a simple UI to place entities from within the game? Both of these are substantially easier, and just as (If not more) powerful than most editors that are written from scratch.

I went down the 'whole seperate level editor' path, and I can honestly say it's taken up more than half of the development time of my engine, and it's not even very good. Go with what you absolutely need, and that way you can write a game rather than a toolset.

Indeed "Do I need this?" is something you should be asking youself all the time. Never do more than you have to and always think what is already at hand that with little or no work will give you the same outcome or something close enough that is acceptable. Simplest thing I ever did was use MSPaint as an editor. I basically created and arbitrary set of rules like each pixel represented so many world units and each color represented a different object to be placed in the world and wrote a small script that converted this into something that my engine could easily use. Also look at using file formats that already have code available to load and use free tools that export into this format. And if you are still set on doing your own editor look into leveraging available libraries like AntTweakBar to speed up development and even just to ease your own usability even if it is just for yourself. Never feel bad about using what is out there because even the professional game companies do and even license other peoples libraries all the time.