New Data Format

[DivFord]

Iain mentioned in the level editor thread that we would need to decide what the new data format is going to be. I thought I'd better give that task it's own thread.

To start things off, here is a list of what I think the data files need to include.

Block Data (all of this is in the existing block files).

• Name
• Block Code
• Solid
• Coefficient of friction
• Bounciness
• Layer
• Texture Y-index (I think this is technically a V index, since texture coordinates are traditionally UV rather than XY, but whatever).
• Effect Results
• Flammable?

Prop Data

• Name
• Prop Code
• Solid
• Coefficient of friction
• Bounciness
• Layer
• Sprite Map
• Animation Map
• Effect Results
• Flammable?
• Mass
• Gravity Direction
• Collision Dimensions
• Collision Offset
• Sprite Dimensions
• Metadata Tags

Unit Data

• Name
• Unit Code
• Tactics
• Acceleration
• Max Speed
• Toughness
• Sprite Path
• Guns
• Collision Dimensions
• Collision Offset
• Sprite Dimensions
• Sprite Map
• Animation Map
• Mass
• Gravity Direction
• Can Jump
• Solid
• Coefficient of friction
• Effect (Effect of the unit on other units?)
• Metadata Tags

Pickup Data

• Name
• Pickup Code
• Layer
• Collision Dimensions
• Collision Offset
• Sprite Map
• Animation Map
• Effect (The effect of the pickup - e.g. Give key).
• Metadata Tags

Further Notes

• I previously said that I wanted to add an allowed zones entry to each data type. Thinking about it, we might do better to add a Zone data type, and list in that the blocks, props, units and pickups available.
• Do we need to store all of this information in the data files? For example, in the case of units, could we bundle acceleration, speed, mass and gravity into a single "move mode" variable?

[Fyll]

I'm thinking it would be a good idea to give every Object both Effect and EffectResult elements, as we were planning on absorbing lethality into Units being susceptible to smashing or pulling or whatever (thus removing isLethal as well).

Personally, I like having it in terms of relative sizes. It makes it easy to say, "this is the same size as a block", or "this is twice as tall, but only half as wide as a block", and it saves the code form having to translate it all. Then again, I may be biased, as I wrote it...

[DivFord]

Good point. Would flammable be rolled into the new system as well?

Eh, I'm biased the other way. Since I draw the sprites, it's easier for me to think of them in terms of pixels. If you want to keep sizes as-is, we'll do that.

[Fyll]

Flammable could be.... That's a good point (I hadn't thought of that). Fire is still a complete mess at the moment though, so I won't say anything certain about it.

One thing that would be a problem with using absolute dimensions is that it'd have to have an additional piece of information: the dimensions of the spritesheet. Using relative coordinates, that's already built in to the coordinates.

[DivFord]

Right, forget the absolute dimensions.

[mspraggs]

I suggest something like JSON or XML files, as these allow a hierarchical data layout whilst still being human-readable.

In my research we use XML as the configuration files for running simulations. This works quite well for structuring the various parameters etc that are fed in. There are C++ libraries for reading XML data that we could take advantage of. I haven't checked for JSON, but I expect there'd be something similar. Looking at JSON, it also seems like a good bet.

EDIT: I don't mind writing the data parsing code. I'll make it generic enough that you can sub-class the parser and create some arbitrary data format that can be parsed in. That way we can always develop some proprietary binary format if/when it comes to packaging and delivering this.

[mspraggs]

Had a comment here, moved it to #93

[mspraggs]

Actually thinking about this more could we not just abstract all the game configuration stuff into some configuration file? Meaning sprite sheet file names, sprite sheet offsets, etc.? That way you could specify the various animations as a spritesheet filename and a set of spritesheet coordinates in the configuration file, without the pain of messing around with the spritesheet map, for example.

On the C++ side the blocks, animations, spritesheets etc. would be labelled with tags specified in the configuration file. These same tags could be used elsewhere in the configuration file to refer to the sprites, blocks, animations, effects, etc. There would need to be some mapping/dispatch mechanism on the C++ side to map things like effects onto hard-coded functions, but that would be fairly easy to handle I think.

Thoughts?

EDIT: An XML example:

<potentia>
  <spritesheets>
    <path tag="sprite1">/some/path</path>
  </spritesheets>
  <animations>
    <animation tag="defaultSprite">
      <spritesheet>sprite1</spritesheet>
      <offsets>(0, 0)</offsets>
    </animation>
    <animation tag="animation1">
      <spritesheet>sprite1</spritesheet>
      <offsets>(0, 0) (1, 3) (2, 5)</offsets>
    </animation>
  </animations>
  <effects>
    <effect tag="run">
    </effect>
  </effects>
  <blocks>
    <block>
      <name>Earth</name>
      <animations>
        <animation effect="default">defaultSprite</animation>
        <animation effect="run">animation1</animation>
      </animations>
    </block>
  </blocks>
</potentia>

Something along these lines. The tags can be any string, which gives great flexibility, e.g. you could compartmentalise the tags according to the blocks like "earth/default", that sort of thing.

EDIT: The levels could then refer to this configuration file in some way. Or the configuration file could point to the level data. I think this would offer us great flexibility in how we link things together, as we wouldn't have to recompile each time, and it's more human-readable.

[Fyll]

Okay, I've moved lethal and flammable into EffectResult. The only real consequence as far as game design goes is that now there can be things that can be ignited, but not doused.

[mspraggs]

What do you guys think to the configuration file idea?

[Fyll]

We sort of pulled out the file names already (into FilePaths.hpp). Pulling out everything would probably be quite nice (I'm assuming that you mean that, for each Spritesheet, instead of just having a .bmp file sat outside of the code, which gets read in and built up using the hardcoded offsets etc., we'd have the .bmp file outside, as well as a .txt or .xml file or something that contains the offsets etc., that then gets read in at the same time as the Spritesheet), but I'm again worried about any challenges with reading it into the code.

I've got no problems with it, on the grounds that somone else code it. :P Any problems I would have would be wrapping my head around implementation and what connects to what, so if someone else did it, then I imagine it'd be good in the long run.

[mspraggs]

Okay, sure. I'll take this on then. I can't forsee having enough time before the end of term, but once that happens I'll try and make a start.

[mspraggs]

@DivFord how does the data format stuff relate to what the level editor is outputting? Can you expand more on what the level file format is? Or is this kind of stuff in the wiki?

EDIT: This relates to issue #93

[DivFord]

Oops. I forgot about that. I'll add it to the wiki.

[DivFord]

Here is a link to the new wiki page. https://github.com/mspraggs/potentia/wiki/Data-Format

Hopefully that covers everything. I updated "New Notation.txt" in the design folder when I wrote the editor, so that should have all the info on codes. I'll try to copy it into the wiki at some point.

[Fyll]

Oops! I forget to read this thread before starting on this. >.<

Well, I've used absolute dimensions, not done it in XML, and haven't read the wiki page or the New Notation file.... Ah well, it'll hopefully be okay.