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.

Practice Pitch

Today was our practice pitch, and it went well.  You can see the trailer for our game below.  We received lots of good feedback, and got a little bit of a wake-up call on the quality of the competition.  Everyone has done an extremely good job at creating a prototype and presenting it.  We are going to need to step up our game if we want our game to be picked.  And do I want this game to be picked SO BAD!!1!

Attraction Trailer

Tuesday is the actual pitch to a panel of game industry peoples and faculty.  I'm excitedly nervous for the outcome.

Magnets and Muzak!

Our prototype has changed so much!  That's probably a good sign, because it was pretty rubbish a week ago.

We now have different types of magnets; positive, negative and a mix type.  You can only pull yourself towards a positively charged magnet, and repel from a negatively charged magnet.  Also we have a revised targeting system.  To unlock from a magnet, one must only aim at a new magnet in the area with the targeting thumbstick.  This makes the controls more fluid and less intrusive.  Also the way that the targeting arrow changes position has been smoothed.  Overall the game is still fun to play, and adding more puzzles and challenges only make it more so!

I have also been busy on prototype music.  A sample of my first work can be heard here: http://soundcloud.com/sideshowdave/whatwhat

Thanks for tuning in!

First Prototype

Our first week of prototyping is complete, and we've made fair progress.  Below is a screenshot of what we have so far.  We've decided to use the Farseer Physics engine, based on Box2d.  This allows a lot of flexibility, and eases our rapid prototyping.  Below you can see a magnet that the robot is "locked" onto.  There is a graphic overlayed to show which magnet the robot is focused on.  The 360's controller has two triggers which control the amount of push or pull towards the magnet.  This is already turning into a lot of fun!

More updates to come soon!

MagnetBot!

The picks are in....and my idea wasn't selected!  I'm a bit bummed, but I happy with the game I've been put on.  We are working on a game called MagnetBot, about two robots having relationship issues.  The main game mechanic is control magnetism to solve puzzles in a 2D platformer type world.  Here are some similar games that I've researched to learn how we can make our game better:

Magnetic Rush

This is a simple flash game with 2 magnets that must be positioned correctly to pass each puzzle. It's a fun game, but the puzzles are mostly thought-based, and not skilled based.  Our game will try to require thought and precision/skill.







 Give Up, Robot

This simple to learn, yet challenging to complete puzzle game has one mechanic that makes it addictive.  The player uses a hook to navigate many types of puzzles and is very skill-based.  You can control the length of your hook and your left to right swing.




 MagnetiZR

This is a more static game revolving around placing magnets in the right place.  Once you think you have the right setup, hit the shoot button and hopefully the metal projectile makes it to the goal.  Different  types of magnets, and different obstacles aren't enough to make this game exciting.




The Light Temple

This fire and ice boyfriend and girlfriend duo are in a Light temple and must solve puzzles to get through each level.  If you position yourself wrong just once, you will lose the level.  This makes the game very thought-based, and you must think before doing anything.  



Robot Platformer

All I can say about this game is it doesn't make sense to me.  Why Clouds? Why is everything that's gray catch me on fire? What are these robots that want to kill me?  I honestly don't know.