Jumps Background Race Background Turret Background


We've had a lot of good progress on our space tower defense game recently: lots of good coding, art, and music. But in a departure from our regularly scheduled program, we're doing a special feature: one developer (that'd be me) making a Facebook game from scratch to release in just one business week. Five days to do everything. And I'm going to be blogging about it the whole time.

Today is the first day of that endeavor. I'll be doing daily summaries at the end of each day. For now, there are a few assumptions I've already made about where I'm at with starting this thing:

  • I've already decided on a programming language, framework, and hosting service: Python, with Google App Engine.
  • Based on that, I already know the Facebook SDK I'll be using: my fork of the official Python SDK. (I used a fork of the third-party PyFacebook in the past, so this will be new to me.)
  • Facebook Credits are still in beta, so I'll have to use a third-party to monetize virtual goods. I've used TrialPay in the past, and I loathe their interface, so I'll be trying something new this time around. Social Gold appears to be the most promising.
  • I already have the Facebook account I'll be using setup (the Zen Otter one), but not the application itself.

Finally, the concept of the game is already fleshed out most of the way: it's working title is tentatively "Friend Fight." The idea is that you challenge friends to fights where your health and stats are based on your profile stats - number of friends, pictures, etc. There will be some basic attacks and spells you can cast to begin with, but to do more damage you'll have to buy the more advanced versions. Leaderboards will be a pivotal component. That's pretty much the entire game. Simple, but easily extensible: I can always add more and more powerful (and expensive) moves to the game.

Now I'm off to get this thing started. Full speed ahead!


Here is the entire complete series:

There's also the conclusion post and the live game, which you can play right now.

See All Comments (0)

Moving from a scripting language like Lua and an engine that's meant for rapid prototyping like LÖVE over to Microsoft's C# and XNA is a challenging process. Here are the biggest differences (other than syntax) that I've found:

  • In LÖVE, sprites are referenced by their center, whereas in XNA it's their top left. (XNA seems to be doing the more standard approach here, and I think more recent versions of LÖVE have actually switched as well.)
  • Colors in LÖVE are represented in RGB by three integers ranging from 0 to 255. For XNA, they're three floats ranging from 0.0 to 1.0, but using an integer like 255 doesn't throw an error - it just evaluates as 1.0! This led to a lot of confusion and wrong colors on the screen before I figured it out.
  • LÖVE lacks a lot of the convenient math functions that XNA has. You have to keep track of X and Y components yourself, and make your own distance formula. XNA has these awesome pre-defined objects called Vectors, which already have an X and a Y component, as well as some nice convenience functions like Vector.Zero and Vector.Distance.
  • While XNA may be better for quick math, it's much worse at 2D drawing. For instance, there are no functions for drawing 2D primitives like lines or rectangles! You have to come up with those all on your own! And there's no built in way to animate! While there are some tutorials to walk you through through the basic stuff, I found that I had to write most of this code myself. These are things that I feel have to be included in any game engine, but Microsoft totally skimped on them. If you're having trouble while reinventing the wheel, I found that this post and the included code on drawing lines gave me the tools to figure things out.

Well, I hope that helps somebody in the future avoid the same trouble areas that I had with starting on XNA. Sound is one topic in particular I didn't cover here, because XNA handles it so differently from other game engines I've worked with that it deserves its own post. I guess that comes from having to work with a content pipeline instead of just files.

See All Comments (0)

Just to show off the power of LÖVE, here's what I managed to do starting from scratch during a single day of coding by myself:

Day 1

There are enemies already moving across the screen and getting blasted by lasers! Of course, this is nothing like what the final version will look like, but it's cool to know that with modern development tools you can get off to such a fast start.

And by the way, all of those sprites - including the planet - were made by me in Inkscape, a great free SVG drawing tool.

See All Comments (0)

When we first started on our new game idea this past fall, we knew that a lot of things would be changing rapidly. Rather than dive straight into programming for the Xbox, we wanted to prototype the basic ideas on a platform that would let us make tweaks without having to recompile.

At first, the obvious choice seemed to be Python and PyGame. I was already very familiar with both, and they probably would have suited us fine. But then while looking around for a tool like this, I found LÖVE.

According to the website, "LÖVE is an unquestionably awesome 2D game engine, which allows rapid game development and prototyping in Lua." And that quote is pretty much right. LÖVE takes care of all the boilerplate, code-repetition, and nastiness to let you get down to making awesome games. We chose to go with it immediately, as it was clear that with LÖVE we'd be able to worry about algorithms and balance, rather than code.

The biggest hurdle that we ran into was largely the fault of Lua, and not LÖVE. By default, Lua is a meticulously pure scripting language, and therefore has no native support for object-oriented programming. This is highly annoying. After some searching though, we found a workaround involving tricking Lua's tables (like a Python dictionary) into behaving like classes.

Beyond that, the only issue LÖVE has is that it is just a prototyping tool. You'll probably have to port your code to something else in order to actually distribute it. But for projects that are purely academic in nature, or where you want to figure things out in a quick, interpreted language before moving over to the behemoth, it's an excellent choice.

See All Comments (0)

Easily the most common question we've had is why we made the decision to switch from Android to the Xbox. It's not totally cut-and-dry, and it doesn't mean that there's no Android for us in the future. And it wasn't the only big change. I'll try to walk you through what happened.


First, we came to the realization that an RPG was just too big of a commitment for a small team. In order to have a successful, memorable RPG we figured we would need a lot of art, sound, and writing. When we started mapping out the requirements for the game, we realized that the shear amount of content was beyond us at this point. So at least in regards to the genre, we needed to downscale.

That led us to the idea of doing a game where the genre wasn't quite as demanding for content creation. Where we could re-use a lot of the same assets without feeling bad about it, and where the story would be simple enough so that we wouldn't have to do extra work to accommodate it. We also wanted to make sure we could still do it in 2D. All of those considerations pointed us straight at making a tower defense game.


We made some preliminary art ourselves, but we knew that we wanted it to have a more professional, stylized look to it. So we decided to outsource it, and started working on finding an artist. This also made us realize that if we were going to all this trouble about the art, we might as well make the game in full 1080p first, and then downscale to a final display resolution.


Re-examining our requirements, we came up with a list for an ideal target platform that looked something like this:

  • supports HD
  • easily accessible by a lot of people
  • something we ourselves would be willing (and able) to play on - that is, devices we already own
  • easy to spend money on

Both the Xbox 360 and Android fit the last two, but the Xbox easily had the upper hand on the first two: a much higher maximum resolution (1080p vs. HVGA) and a much larger install base (30 million vs. 3 million).

In the end, we view this more as a vote for the Xbox than a vote against Android. With the huge added bonus we haven't mentioned before being that when you develop a game for the Xbox, porting it to Windows (a platform with an even larger install base) is supposed to be super easy.

See All Comments (0)

We made our first public declaration about making a game thirteen months ago. Now, we're in the middle of doing just that, but a lot of things have changed. Here's the comprehensive list:

  • John and I are no longer thousands of miles and two timezones away: it's a lot more like 650 miles and a single timezone.
  • The platform has changed: we've moved from Android to the Xbox Live Arcade.
  • We've got this totally new website, on a new host, with a new domain.
  • The whole concept (and genre) for the game itself has changed. We'll have a lot more on that later.
  • We have a team of artists working with us!

Here's to round two of getting a real game under our belts! Be sure to check back often (or just subscribe to the RSS feed) as we'll have a lot more to say as things get built.

See All Comments (0)

The idea to create a video game from scratch is not a novel one, by any means. I've begun that quest several times in the past myself, but they were ill-defined personal projects only. Certainly nothing with the potential for distribution. Now, with the advent of things like the Xbox Live Arcade and the iPhone App Store there's a way to get independent games straight from development and into the hands of players. And with the success of games like Braid, there might even be money exchanged for doing so.

One night in January, John and I decided that we simply had to make a game together. Thousands of miles and two timezones weren't going to stop us. We decided to create something for the newest of those aforementioned platforms: Android, with the ultimate goal to publish the game in the Android Market. This blog is where we'll be describing our experiences developing the game. There'll be laughter, and crying, and code - lots of code. Hopefully we'll be able to point out some pitfalls about programming and design in general, and the Android platform in particular so that others don't get stuck in the same places.

This is the blog. Red Sands is the game. And the race has just begun.

See All Comments (0)

Newer Posts >


Stay Connected