next »

[trybaj]

I'm wondering how other people have solved this problem:

I am writing both a game engine and the support tools that create assets to be used in the engine. The most important tool is the level editor, but I think my strategy for connecting the engine and the editor is costing me too much effort. There has to be a better solution.

Right now, the only thing binding the two is that they both follow the same standard for reading and writing level files. The tools both agree what needs to be in the file to represent an enemy with 3 tentacles and 100 health, for example. The problem is that I have to create a lot of translation code every time I add a new entity type. For example, let's say I create a new enemy type in the engine. To create this enemy, I need to know his position, his size, which waypoints he follows, and his name. This means that the engine needs to be able to read this string from a level file, and create an instance of the correct enemy in the game. The editor also needs to be able to create new enemy objects to manipulate within the editor, but these objects are necessarily different than the object found in the engine. It doesn't contain AI logic for example, instead it contains the code that tells it how to react to being manipulated by the editor's different tools. When the level is saved, it needs to be able to write the proper string, and when a new level is loaded it needs to read the string and place the correct editor entity into the scene.

I can save myself some time because a lot of the information is standard across enemy types, but many of the entities require something unique, which leaves me writing parsing code for both the engine and editor.

I'm sure this is a solved problem, so I'm wondering what processes other people are using. Does anyone use Lua files to describe their levels? Does anyone have an interesting method for describing game entities in data files for use in both the engine and the editor? Maybe even automated methods for generating those data files?

As a single person trying to make games, I think the number one priority has to be efficiency. The faster I can turn ideas into reality the better, and what I'm doing feels very inefficient.

[increpare]

Does anyone use Lua files to describe their levels?

Hah; I do sometimes actually

Usually (for any complicated project) I have the editor be within the engine (or sitting on top of it).  No point in writing a bunch of stuff twice.  I wouldn't worry too much about a bit of redundant editor-only data/code sitting about in the final game myself.

[Afinostux]

Usually (for any complicated project) I have the editor be within the engine (or sitting on top of it).  No point in writing a bunch of stuff twice.  I wouldn't worry too much about a bit of redundant editor-only data/code sitting about in the final game myself.

Oh god. age of mythology did this. you could edit the map while battles were happening and everything. It was kind of annoying if you were trying to make a scripted battle that would only happen when the player came within viewing range, and forgot to disable their AI

Basically, if you do this, make a way to make the dudes not fight :|

[george]

This isn't really an answer to the question, but are you familiar with Eskil Steenberg's tools for his game LOVE? It seems like they're designed for integrating the engine + work flow like you're asking about.

[BorisTheBrave]

Writing serializing/deserializing stuff shouldn't be as huge a pain as it sounds it is to you. The problem is you are getting parsing mixed up with data. You shouldn't (often) need to change your parser because you need some new unique piece of data. Write, say, a parser capable of arbitrary key-value pairs, and you never need change it.
This is why it's preferable to use an understood format, such as XML, parsers are already written for you. Even if you still find yourself writing code to convert from XML to your game objects, it's at a higher level so shorter.

Also, serializing in dynamic languages like Lua should be pain-free, as you can loop over all properties of an object.

[trybaj]

@Boris

The low level parser isn't the problem. It's converting from parsed text to object properties that's a pain. Also, I'm serializing C++ objects, not Lua objects. I only mentioned Lua because I was wondering how many people used that rather than text based (XML, JSON, etc...) level files.

I'm sure there are serialization solutions that are easier than what I'm doing, that's why I'm asking for how they work

Maybe I should talk about what I'm doing now in a little more detail. All of the entities in my level editor have a WriteTag method. This method just needs to describe which parameters to put into the tag and what order they need to appear in. By itself, this isn't too big of a deal.

There is also a class called LevelReader. This uses parser functions to read each element from a tag. For a given entity, it needs to know which parameters it's reading and what order they will appear in the tag. When its done reading a tag, it creates an instance of the correct editor object.

The engine also has a LevelReader. It reads the tags using the same parser, but when its done reading a tag it needs to create engine objects rather than editor objects. So I end up repeating the code that connects parsed tags to game objects.

Each engine object also needs to be able to write tags so I can create a save file, or preserve information between rooms as the player moves through different areas.

I suppose maybe the key would be creating both editor objects and engine objects from a shared serialization object that handles both the reading/writing of data files. The base object wouldn't need to know anything about what the various values are used for- it would just need to know that a specific object has a given list of key/type/value information.

@george
Yeah, I've seen those. I'm so jealous 

[BorisTheBrave]

The base object wouldn't need to know anything about what the various values are used for- it would just need to know that a specific object has a given list of key/type/value information.

Exactly. Separation of serialization and logic.

Some more thoughts:
If you are using C++, and insist on using real C++ class members for all properties, and don't overlap editor and game objects, you can add "annotations" to class members for de/serialization, using some template magic.

E.g.
class A
{
  int b;
  float c;
}
class_<A> A_("A");
property(A_,"b", &B::b);
property(A_,"c", &B::c);

See Boost::Python for how succinct this can get. Because you don't need repeat type annotations, it's more convenient than a special file, or method.

Having made game objects, and made their contents available for introspection, you do not need to any further work for editor objects. Except for where the properties also affect the editor, you DO NOT need to duplicate the functionality of game objects. You just need a single editor object that which can read and write based on that property information.

The aim of the game is to avoid repeating yourself at all. Unfortunately, you must list still everything twice (once in the class definition, and once to declare it as a property) in C++, but that still sounds better than the 5 copies you appear to be doing (LevelReader, EditorObject::Write, GameObject::Write, GameObject class defintion, EditorObject class definition).

It's just a thought, though, I certainly haven't tried it.


Edit: There's a few C++ serialization solutions out there. Unless you are doing something special, it sounds like it's best to let someone else do the hard work for you.

[Triplefox]

I think the broader question here - not exactly the OP's question, but a similar one - is "how much do you want to define things in the tool vs. the game code?" It's easy enough to write a tool that only lets you edit a small, fixed set of properties for everything - a tile-based game, for example, where background art and entity spawns are both defined by unique tile values on the same grid. Such a format is simple to edit even with a hexeditor.

At the opposite end of the scale, you operate on what is effectively an exact instance of the playable scene on its first frame, with every property available for editing via runtime reflection. Doing it all in-game means that results - for the actions you write tools for - are fast, but if the data structures are complex you will quickly find yourself writing a lot of additional UI code to tune all properties, and you have to design the runtime representation so that everything is read/write, rather than read-only, which gives you the bonus of an extremely granular save/load system during play, but also leads to a raft of additional complexity.

In picking a point on this spectrum, you make tradeoffs on performance, design iteration and coding time.

I've moved towards a external model where entity definitions start from some form of property list. The tool holds everything in JSON and creates tool-specific representations by looking for magic-named properties. Then, at runtime, the archetype is spawned by bolting new runtime data on top of the original property list. There's no translation in my case because the language is dynamically typed, so the original JSON data maps 1:1 to fields of an anonymous object. It's a very simple and stable way to add diverse data, which for me is ultimately more important than sheer iteration time.

[BorisTheBrave]

I agree. Property lists and dynamic typing make all these problems go away. Though for a certain class of games, an in-game level editor actually understands all the properties can work must better.
I was just trying to offer a solution within the constraints given.