Magical Ground Finding

Our level editor is shaping up and this week I was able to contribute a small but important piece, the automatic ground finding algorithm.  We have defined a spritesheet of ground tiles and defined a naming convention for each piece based on the player clip location and angle.  We have also created corner pieces and have all 45 and 30 degree angles possible.  My job was to analyze all these pieces and great an optimized set of lines for the physics engine.  Instead of having each tile's coordinates put into the engine, we want to condense all straight lines to just 2 points, and get rid of all the intermediate points that basically give us no new info.  For example, we have a set of tiles that should have a ground clip like this:

           ._._._._.
                         \.
                          |._._._.
                 

The dots represent current vertices, and the lines are adjacencies.  Using a map, where each dot is a node and each line is interpreted into an adjacency list, the algorithm becomes simple.  Our desired output is:



           .____.
                     \.
                      |.___.
                 

As you can see, the dots are located at 3 distinct types of locations: end of a line, start of a line, and points where there is a change in direction that can be identified by the following rules:

    Start/End of a line: Node has only one adjacency.
    Change of direction: The previous adjacency has a different direction than the next adjacency.

My algorithm first picks a Node remaining (it does this smart by picking one that has only one adjacency) and begins to walk the map.  Each step it takes it removes the adjacency it used to walk in order to avoid backtracking.  When it can no longer walk, it has reached the end of a connected segment, and moves on to any remaining nodes, picking it's next item in a way to avoid starting in the middle of a line.  So far it's working well, but the limitation is that at most a node can have two adjacency.  This limits our level design to not having any 'T' or 4-way intersections in the terrain.

-Dave

Tripleslash Studios!

Our team is creating a business and we've decided to call it Tripleslash Studios!  It will be our pleasure for the next few months create our first game Attraction!  We've created a website and facebook page to help keep everyone in the loop as our dev process rolls along.

Website

Facebook Page

Any questions or comments can be sent to:

info@tripleslashstudios.com


The programming side of things has been moving along, and we are closing in on a basic functioning level editor so our designers can start designing!

XML Schema files and more!

Never thought I'd be excited about something so mundane as XML!  I've just wrapped up writing a custom serializer and deserializer for our Level class as part of our game, Attraction.  The coolest part about it was the schema file that basically defines objects within XML files.  It's a powerful tool that let's you create elements, extensions, and wrap elements within other elements.  I was able to tailor the schema to accept a level with any amount of entities, which included a set of components.  It's all matched up to our entity system, Artemis.

Now that the level portion is coming together, we'll be able to save and load levels.  Once the level editor is more or less complete, our designers will have the tools to create awesome levels!

XNA Intermediate XML format

I've been messing around with XNA's automagically parsed intermediate format, and finding good documentation has been horrible.  I finally found a good resource here.

I'm currently writing the Level class for our game and has the following structure so far:

public string name;                                     //level name

public List<List<Vector2>> playerClip;           //List of lists of coordinates for all player clip

public List<Vector2> magnets;                     //list of magnets throughout level

public Vector2 magnetHead;                       //initial magnet head spawn

public Vector2 playerSpawn;                       //initial player spawn

Serializing this object into XNA intermediate format looks something like this:

<?xml version="1.0" encoding="utf-8" ?>

<XnaContent>

  <Asset Type="DataTypes.Level">

    <name>TestLevel</name>

    <playerClip>

       <Item>x y x y....</Item>

       <Item>x y x y...</Item>

    </playerClip>

    <magnets>x y x y...</magnets>

    <magnetHead>x y</magnetHead>

    <playerSpawn>x y </playerSpawn>

  </Asset>

</XnaContent>

Yeah, Vector2's are space-seperated (who does that?) and a List within a List is stored in separate bins tagged with <Item>.  It also 'compiles' the xml files, just checking for any syntax errors at compile time.  Yeah, it's....odd.