From June 9th through the 17th I was heads down working on my entry for the 7 day First Person Shooter game development challenge 7DFPS (website: http://7dfps.org/). Like many others I would be working with the Unity 3D engine (website: http://unity3d.com/). Unity is an absolutely wonderful tool for quickly putting together games, and they turned out to be supporters of the competition — offering an extension of the Pro version of their software for the competition. One of the core features of the Pro version of Unity is access to the Asset Server — a separate server application you need to maintain to collaborate on your projects. Without the Asset Server, Unity has earned a reputation for absolutely destroying itself when shared via source control.

Given that I was planning on participating in the SA Game Dev Challenge VII (theme: ‘Balls’) with a team of three other people, and that I wasn’t planning on spending $1500 for a Pro license just to participate in a few competitions, I decided to use the 7DFPS challenge as an excuse to learn how to collaborate with Unity using git.

I was in for a treat.

Unity Hates Source Control

Unity clearly does not enjoy working with source control outside of the Asset Server. (This is actually my number one complaint about working with Unity — I basically can’t collaborate with people who are not wizards. Thankfully the person I worked with for Duck Hunted is Swedish, which is functionally equivalent to being a wizard.)

What is it about Unity that drives source control crazy? For starters, a heavy reliance on binary file formats. Scenes and prefabs, for instance, are stored as binary files which prevents two people from working on a scene at the same time. Unity also has a number of local cache directories that should not be synced between clients. Syncing them causes weird corruption issues and can potentially destroy all your hard work. Finally, there isn’t a lot of information online about using external source control with Unity. It’s mostly tribal knowledge, and Unity’s own page on the issue contains incomplete information. In the release of Unity 3.5, they changed the way Unity worked with external tools, which means a lot of the information on the net is simply no longer current. I’m hoping this post sheds some light on how Svampson, my co-developer during 7DFPS, and I managed to use Github to work on a Unity project and not totally hate ourselves the whole time.

Continue reading »

The Something Awful forums run an annual game development competition. Participants are given one month to design and develop a video game based around a rotating theme. Everything, from planning mechanics and developing ideas to the actual creation of assets and code needs to take place between 12:01AM July 1st and 11:59PM July 31st. It’s a mad whirlwind of activity as developers, artists, and musicians come together to attempt to complete something worthwhile and still meet commitments to their jobs, friends, and families.

Like many of the other participants, I am a hobbyist game developer with big dreams of breaking into the industry at some point. This contest provided the perfect excuse to sequester myself from the world and really knuckle down to produce a portfolio worthy. Feel free to give it a play.

The Finished Product: Psychopomps (Click to Enlarge)

What went well

Flixel (or, ‘Learning to Let Go’)

The single largest contributor to our success was to use an awesome Actionscript library called Flixel (available at http://flixel.org/). Flixel did an enormous amount of the heavy lifting and asset management, and allowed the team to focus on gameplay concepts from day one. In fact, we had a playable demo on the first day that was loading a level, allowing the player to move around, jump into water, and aim at the mouse.

Continue reading »

It’s been a while since I’ve added any content to this blog. Thought I’d get back into it. I’ve got a few new projects to highlight, and I owe a decent exposition of the Douglas Peucker algorithm. Those things are on their way, but in the meanwhile I thought I’d pad this blog out with a post or two on what I’m currently playing, and why I’m enjoying it (or not, as the case may be.)

The game that has captivated me most recently? None other than Doukutsu Monogatari, or Cave Story.

This image sold me on Cave Story. Yes, that's a dog riding on his head. Artist: Risachantag. Click for link to DeviantArt Page

Continue reading »

First, a disclaimer: I in no way undermined the security or broke into any accounts. I got access to 0 privileged information, merely recorded information that was already presented by the website.

Recently, I’ve become re-enamored with an old school board game: Diplomacy. This board game, set in Europe around the turn of the century (19th-20th century, that is), features gameplay similar to Risk or Axis and Allies. The key difference in Diplomacy is that the gameplay is entirely free of luck. There are no dice rolls, no random chance, your strength comes entirely from the other nations you can con into helping you. It is a game of wicked social engineering, where every player is trying to get good intelligence on every other player. It is not uncommon for players to ‘release’ a tidbit of information to one player, and see how long it takes to find it’s way back to them from a different player. The math nerd in my head visualizes the connections between these nations as a directed graph — but that’s another post.

I’ve been playing the game online with a friend from the computer science department here, and he made an interesting suggestion — the game may be vulnerable to something called a ‘side channel attack‘. The basic concept behind a side channel attack is that there are trends and data that exist alongside the actual data you want access to. In Diplomacy, what I’d really like to have access to is the messages between other players, but that data is not available (and that would be cheating!) Web diplomacy, however, makes a certain amount of other data available. The player’s name, readiness, and online status are all displayed on every page load. With a little help from Python, it’s trivial to capture this data and use it to craft a side channel attack.

Example Status in Diplomacy

Continue reading »

I’ve been doing a lot of reading the past few days trying to figure out the relationship between shaders and the vertex definitions in XNA code. XNA provides a number of vertex definitions for you, including VertexPositionColor, VertexPositionColorTexture, VertexPositionTexture, and VertexPositionNormalTexture. It’s pretty clear what they each hold — a position, and some extra information about vertex colors, textures, or normals. But what if you wanted to pass additional information to your shader? How would you tell XNA to do that? You could pass the information to your shader by calling the SetValue() method of a parameter, but that only lets you pass one value (or texture, etc.) What if you need that information on a per vertex level?
Continue reading »

There are a number of useful algorithms that every game programmer should be aware of and know how to code. One of my goals is to explain how these algorithms work and provide code samples. If the algorithms have a cool visualization, than I’ll try to provide one of those as well.

Without further ado, let’s start with our first Better Know An Algorithm (BKAA) with The Marching Squares Algorithm — THE FIGHTIN’ SQUARES!

What does it do?

You’ve seen the output of this algorithm all over the place. When you use the magic wand tool in Adobe Photoshop, it produces the ‘ants marching’ perimeter of a colored area. Marching Squares gets its name from the way it works — it takes a square area of an image and marches around the perimeter of an object.

For example, if you wanted to select the first big sprite from this Tyrian sprite sheet from Lost Garden:

Example Tyrian Sprite Sheet

And produce an outline (with the sprite sheet on the top, and without on the bottom):

Marching Squares Outline

Points Produced by the Marching Squares Algorithm

Just found this interesting video about the evolution of Halo: Combat Evolved. Originally, the game was going to be similar to one of Bungie’s previous titles – Myth. As time and technology progressed, they changed the overall design of the game, from RTS to third person shooter, and eventually into the game we have today. This video, narrated by various members of the Halo team, showcases some of the many iterations along the way.

Truly a fascinating look at how games change over time — particularly when they have no time constraints. A few times throughout the movie they bemoan having to complete the project on Microsoft’s schedule, yet they also see it as the reason the game actually was released.

This week I discovered an incredibly cool framework for XNA. Head to Synapse Gaming right now to check out what they can do for your game. Here’s a few screenshots (taken from their blog):

Ambient and Directional Lighting

Complex Texturing

Reflection and Refraction

Now, if you were to try and write all the code to accomplish that yourself you’d spend more time working on your engine than you would working on your game. If you are a hobbyist like me, it’s the game that drives you forward, not always the mechanics behind it. I’ve lost a number of projects because I got bogged down in dealing with the minutia of engine development.

Don’t get me wrong, I love understanding how all this stuff works, and it’s very cool to build your own shader and lighting prototypes. In fact, I’m somewhat notorious around these parts for adding interesting shader effects to our club project before we had our gameplay solid. We discovered the ‘Magpie Paradigm’ during that project – also known as, “Oooh shiny!” Developers like to build cool things that have interesting visual results before they do the hard work.

Well, thankfully, Synapse Gaming has taken care of both for you with their Sunburn Rendering Engine. Sunburn is a rendering engine that produces the gorgeous results you see above without a whole lot of work on our end. They have several different price points for their product – depending on what you want to accomplish (and where you intend on selling your game). The one I’m most interested in is the Sunburn Framework (registration required for download), the version of the rendering engine they are giving away for free to hobbyists, students, and anyone else interested in evaluating the full product.

I’ve already combined a basic scene graph with Sunburn to provide a quick and easy way to handle rendering your game while working with a higher level of abstraction. It’s as easy as inserting models, lights, and terrain into the scene graph and watching as Sunburn handles all the lighting and texturing for you. Soon I’ll share the code I wrote for the scene graph, as well as those three basic node types and give you an idea of how to build your own.

Like many of you, I started writing computer games with pong, or some variant thereof. My pong featured multiple balls, powerups, paddles of varying size, and a crippling misunderstanding of how to manage all my many objects. Pong, in its more traditional form, requires the developer to keep track of the state of three objects: two players and the ball. If you were like me, you probably did something like (and excuse the egregious abuse of pseudocode):

int main()
{
  // Initialize game states
  // Load Assets
  // (Skipped for brevity)
 
  while (!gameOver)
  {
 
    // Check for bouncing the ball off the walls
    // which is skipped for brevity
    // and for player input, updating velocities as needed
 
    // Update the position of everything in the game
    ballPosition += ballVelocity;
    player1Position += player1Velocity;
    player2Position += player2Velocity;
 
    // Clear screen to black
    renderWindow.ClearScreen(0.0f, 0.0f, 0.0f);
 
    // Draw our sprites
    renderWindow.Draw(ballSprite, ballPosition);
    renderWindow.Draw(playerSprite, player1Position);
    renderWindow.Draw(playerSprite, player2Position);
 
    // Present what we drew this frame
    renderWindow.PresentFrameBuffer();
  }
}

In this example, and indeed my first crack at pong, I tried to keep track of all my objects state (their positions, velocities, and sprites) in my main method. This works just fine when you only have to keep track of three simple things every frame. It does not scale well, however. I thought I was pretty hot stuff when I added a second ball to pong (appropriately named ball2) followed by a third and fourth ball. (My pong was well endowed.) It occurred to me around ball10 that keeping track of all this stuff was a nuisance, and there had to be a better way of doing things.

You can mitigate the problem somewhat through clever use of arrays and lists, but you are still ultimately tracking the state of everything inside your main. Plus, complex dependencies are difficult to control. Suppose your game environment had a flashlight, and you wanted to attach a dynamic light to the front of the flashlight, so when the flashlight pointed, the environment lit up. Sure, that’s not too tricky to manage. But then let’s allow that flashlight to be picked up by characters in the game and carried in their hands. And let’s say those characters get into a tram that carries them throughout the underbelly of a ship on the rolling seas.

Suddenly, keeping track of the position of your light object relies on one or more of the positions of the ship, the tram, the character, the character’s hand, and the flashlight. I don’t even want to think about managing the state of all that, especially when you have a complex environment.

Example Scene Graph

Enter the Scene Graph, a way to easily create complex relationships between objects. Every node in the graph is an object you want to position in your world (it could be drawables like a model or sprite, a light, even a sound.) Every node’s position is relative to its parent’s position, so in the simplified example below, the smokestack stays attached to its parent – the ship. In fact, every object on the ship is a descendent of the ship, so whenever you move your ship object everything on board moves with the ship automatically.

As you can imagine, this cuts down on your work tremendously and enables some cool effects. Ever wonder how they change out all the different weapon models on your World of Warcraft character? They use a scene graph (although theirs is probably more specialized than the one I’m going to show you.)

There is already a fantastic scene graph tutorial over at Sgt. Conker’s amazing XNA website http://www.sgtconker.com/2009/10/article-creating-a-scene-graph-in-xna/1/ . His model is an excellent start, and there are a number of improvements that can be made upon it that I’ll be going over in the coming weeks.

Scene Graph Class Diagram

As you can see, the class diagram for the scene graph is pretty simple, and polymorphism allows us to be very flexible regarding the objects we insert into the graph. Sgt. Conker provides an example of a scene node to draw a model, but by subclassing from SceneNode you can display whatever you want — lighting, terrain,particle systems, or effects. Anything you can position in the world you can, hypothetically, put in your scene graph. This example was built for 3D, but you could absolutely use this to display sprites. In fact, you can simplify things quite a bit (no more need for quaternions to represent rotation, for example).

I just found out about a nice little set of tutorials over at The Indie Stone forums. Topics covered include:

• Using design patterns – the singleton, factory, and abstract factory
• Building and managing a state machine
• Interface Design
• Generics
• Timers

It’s a great start, although it looks like it hasn’t been updated since last July.