TANX (Iron Strike)

[savage]

Just wondering, will the level editor and the game share the same level rendering code, or are you keeping them as separate entities?

[Huehnerschaender]

They are seperated from each other... Rendering in editor is 2D while engine renders in 3D.

Actually, my level editor uses Graphics32 and my engine uses Asphyre eXtreme.

The leveleditor is just drafting the level as some kind of visual concept.

The following scene in the editor



could give this rendering:



Greetings,
Dirk

[Traveler]

This thread makes up for an interesting read.
Its great to see how it's all coming together.

Keep it up!

[WILL]

We're gonna try.

Thanks to Dirk's awesome Mission Editor, I'll be able to now work on my mission maps. Which I've been really itching to do since I joined up with the 'TANX Team' aka WJD or 'was just Dirk' [size=9px](and Reid too! He made some very nice models for IS!)[/size].

We are gonna need you guys to help us 'beta' the missions/engine for us. Find bugs/glitches and critique missions; too hard, too easy, easy/hard to understand objectives, too long, too short, cool, boring, etc, etc...

I think we have a few interested parties so far, but the more the merrier they say.

Also a 2nd 'assistant' map designer would be of benifit. Just simple stuff like putting together a nice ground layout with trees nicely placed, etc to match the forrestry/buildings/walls req'd for the mission to take place in. The missions are already defined, we just have to design the mission maps in the editor.

[Chebmaster]

I want to expand the structures with some "at the moment unused" variables which I save with dummy values. In addition I will create some "dummy" structures which will also be saved (just the amount, no data).

IMHO, the "micro$oft approach" is better. The first field of a structure is the structure's size. If you add some new fields, the structure that you read from the file will be shorter than the current version of the same structure, and you just fill the missing "tail" with zeroes.

Why is it better?.. You won't limit yourself with pre-set structure sizes, always able to expand them as you wish.

[Huehnerschaender]

My first approach was going into that direction (eg. Blockwrite(file, structure, sizeof(structuretype)); ). But it stopped working when I was in need of storing data of variable size (e.g. string You'll never know how much chars belong to the string, so you cannot say structure XY has size YX.
That would work with something like limited strings (string[100]), which I don't want to use.

If there is another approach please let me know. Maybe some source? But however, I am in a horrifying hurry to get everything working until September, so I will use my solution for now. No time to change anything that is not absolutely necessary.

Greetings,
Dirk

[Chebmaster]

Well, I just finished a grand thing dedicated to saving/loading of complex data structures. The sources are available - but I'm afraid it would be of little use to you. It's too deeply integrated into my engine. You'd need to do a lot of montage work to cut the system out, plus implement a lot of dummy plugs for various functions.

You may look at the sources : this link > cge_test_012.zip > core/src/mo_classes.pp and all the *.inc inc files it uses (mainly, mo_registrator.inc, mo_basket.inc and mo_trulypersistent.inc).

In short, I spent last months resolving exactly the problem of storing complex data structures and backward compatibility of data files. The main idea that all used types are registered, and divided to "binary" (which are saved/loaded as is) and "complex" (each has a custom loading/saving procedure). Then all fields are registered. While saving, all the adjacent "binary" fields are saved as a solid block of bytes, and for all the "complex" fields a corresponding procedure is called. For the string, for example, it first stores the length, then, if the string isn't empty, its contents - and so on.

Maybe you'll have an idea how to apply similar approach to your own engine. Or maybe it's too complex for the amount of time you have. Anyway, I created this stuff because I never saw anything similar being done, but the demand for such things, I presume, is high.

It always irked me that every time you add a new data structure, you need to spend a lot of effort on the boring, non-creative background work of creating the save/load mechanism for it - if you wish it stay persistent. And the published properties are no help. Mainly because there is no mechanism to check if you forgot to include something.

[Chebmaster]

Maybe you can do a simpler thing: for each data structure create a "scenario" structure filled with commands for saving/ loading it.

Like "Write from field a to field b", "write field c as a string", 'write from field d to the end" - something like this. Both simple and effective.

Or just use additional routine that will treat the strings separately.

[Chebmaster]

so you cannot say structure XY has size YX

..not to say that the strings are pointers and storing them directly would be disasterous.

[Huehnerschaender]

Hi Chebmaster,

thanks for the information about your efforts.
I will surely take a look at it after the IGF, but I think for now its too much effort for a thing which is already working. There is no time to "just make it perfect". Only three weeks left until entry deadline and I have so much things to do. All the new features which are already in the editor cannot be handled by the engine at the moment. This is much more important, otherwise I will have an editor, but no game for the IGF

Greetings and thanks again,
Dirk