KCMcG Studios

It’s been a long time since I posted, so here’s a related joke.

Q: How many people does it take to NOT develop a game?

A: Hundreds. One person to not develop it and hundreds to make all the 
   games and books that the one person plays with instead of working 
   on their game.

I’ve been slowly adding things to the game over the last 4 months, but I just couldn’t work up the motivation to make a post until now. I’ll try to post several updates in the near future talking about some of the difficult or fun bits of code I wrote in the last few months. This post is just to talk about the ups and downs of seriously working on a video game.

I have heard many people say that the most important thing for an indie developer to do is to release your games. They said that you will want to keep working on your game until it’s perfect. They said you will have trouble seeing past all the flaws in your game. That you’ll never think it’s good enough. I thought they were all full of shit.

I was wrong.

I went into working on this game saying that I had a reasonable set of features I wanted to include. I was so proud of the first few steps, that I didn’t think I’d ever feel ashamed of showing my game to the public. But as I got closer and closer to having an actual “Game” on my hands, I started to feel less and less confident. When you’re still thinking of your game as a prototype, everything that isn’t broken is a point of pride.

Pure Pride

As soon as you start thinking about releasing it, every single flaw sticks out like a sore thumb.

Complete Crap

At some point, you have to learn your limits. I can get the buttons and text to look a little better. I can add sound effects and find some music to play during the game. I can even animate the sprites that I currently have. But I can’t make sprites that look much better than they currently do. I can’t design a beautiful looking menu. I can’t write a stirring soundtrack that everyone will want to listen to.

So that’s what my game is going to be. Coherent looking menus, crappy but functional sprites, basic sound effects, basic music and a decent selection of levels. It’s a first game. It will work and I’ll be happy with it. And I will get it released.

I’ve been working on my own game instead of playing other people’s games the last week or two, and I’m very happy with the progress I’ve made in that time. The best advice I can give to anyone else that gets stuck on their first game is to keep pushing through it, because it gets better. My game isn’t ready yet, but I’ve accepted the limits of how good it’s going to be and I know what it’s going to take to get it finished.

I’ve got a working tower data importer for this game. Upgrades are also working and I managed to fix some bugs. Here’s what the game looks like right now.

My tower data is stored in a csv now. CSV stands for comma-separated values. It’s a simple spreadsheet format that gets stored as a text file, which makes it really easy to read. Writing the code to read the file wasn’t hard at all, though I did have some weird issues with Excel. For some reason, the first time I save a file as a csv, Excel saved it as tab-delimited instead of comma-delimited, so it didn’t work at first. Once I updated the csv manually, it worked perfectly. Here’s a sample of my data csv:

3,levels,bulletType
Standard,4,0
fireRate,damage,range,cost,image
1000,0,0,0,StdTowerSprite
15,10,50,100,StdTowerSprite
12,13,60,200,StdTowerSprite
10,20,70,400,StdTowerSprite

So, to explain how I set it up: The first value is the number of towers available. The second and third were just headers for the data below it so I could keep track. The second line is the name of the first tower, followed by the number of levels and the type of bullet it produces. The next row is just headers again so I could actually read the csv without confusing myself. The next 4 rows are the actual data for each level of tower. I include fire rate, which is actually the cooldown between shots, damage, range and cost. Last is the image to use for that level, so that I can change the tower’s appearance as the tower levels up.

And now the code to read the file:

var rawStatsString:String = new TowerStatsCsv;
var currentRow:int = 0;

var rawStatsArray:Array = rawStatsString.split("n");
var rawHeaderArray:Array = rawStatsArray[0].split(",");

for (i = 0; i < rawHeaderArray[0]; i++) {
    currentRow++;
    currentHeaderArray = rawStatsArray[currentRow].split(",");
    currentRow++;
    towerStats.push(new Array());
    towerStats[i]['bulletType'] = currentHeaderArray[2];
    towerStats[i]['name'] = currentHeaderArray[0];

    for (j = 0; j < currentHeaderArray[1]; j++) {
        currentRow++;
        currentRowArray = rawStatsArray[currentRow].split(",");

        towerStats[i][j] = new Array();
        towerStats[i][j]['damage'] = currentRowArray[damageCol];
        towerStats[i][j]['fireRate'] = currentRowArray[fireRateCol];
        towerStats[i][j]['range'] = currentRowArray[rangeCol];
        towerStats[i][j]['cost'] = currentRowArray[costCol];
        towerStats[i][j]['image'] = currentRowArray[imageCol];
    }
}

Most of this is pretty self-explanatory. First I read the contents of the csv into a string. .split(“n”) splits the string into an array of rows. .split(“,”) gives me an array containing each of the “cell” values of that row.

I’m struggling with what to work on next. I’m definitely thinking I want to get a functional main menu with level select and a save system to track level progress. Definitely thinking about adding some sound back in to the game, but not sure if I want placeholder stuff again, or something that could actually be used for the final game. I’m not sure if I want to add some abilities for the player to use during the game to give the player something else to do. Also considering adding a couple different enemy types and maybe one additional tower type. Any feedback on what I should add next?

I kept running into errors associated with objects not being deleted properly with my old tower defense engine. Part of it is because I wasn’t putting in proper destroy commands into my classes. Part of it is that I had no idea how to create a proper game framework. One that registers each object and deletes those objects when they’re no longer needed.

In comes Flixel, a flash-based game engine. Flixel breaks a game into “States” that can be created and destroyed without worrying about objects lingering. So a menu state can be opened to start the game, and when you load the game state, everything from the menu is cleared from memory. More importantly, when you exit to menu and then reopen the game, everything from the old game has been cleared out. No more invisible towers that start shooting at invisible enemies as soon as you load the game (this happened more times than I’m willing to admit).

This is your brain on Flixel

Flixel is an open source game-making library that is completely free for personal or commercial use. Written entirely in Actionscript 3, and designed to be used with free development tools, Flixel is easy to learn, extend and customize. -Flixel homepage

Flixel provides a large list of helper classes that takes care of some of the more basic programming needs. FlxGame is the base game class. FlxG controls global variables. FlxState can be extended to create new game states, though you only need one for your game to work. FlxSprite is the basic sprite, but with some animation automation, movement controls and automated cleanup. There’s lots of other classes that I haven’t yet dug in to.

Flixel sprites don’t have an addEventListener() function, which makes it harder to confuse yourself about which object is listening to which other object. From what I’ve read, the proper way to handle event checks is within the update function of each object. Flixel also has a class called FlxGroup which allows you to perform collision checks and tests against every object within the group. I’m currently using the FlxGroup as my enemy manager, tower manager and bullet manager.

I’ve started recoding my Weekend Tower Defense using the Flixel game engine. I’m not sure if recoding this Tower Defense game has just become a way to learn how to make games or if I’m actually planning on releasing this game eventually, but it certainly has been a learning experience. So far I’ve got a basic engine that loads up a map and spawns a series a waves to march across the map’s predefined paths.

“Progress”

Since finding Flixel, I’ve also found DAME a free tool for generating levels from tilemaps. You can create multiple layers in each level each using different tilemaps. It certainly makes creating new maps very easy and provides a nice visual tool for doing so. It supports several different export formats from a basic csv to an AS3 class that makes loading levels a breeze. It’s supposed to allow you to create paths, but I’ve haven’t yet been able to figure that tool out and have instead been defining paths manually.

Deadly Alien Map Editor in action

All in all, I think learning both these tools will help with future games. Flixel especially has been teaching me a better mindset for creating games. It also seems like it’s much easier to prototype a flash game using Flixel than the old way I was doing it, so maybe it will really pay off when I move on to the next game.

Here’s the current status on my Weekend Tower Defense game.

So the changes since the last video I posted are 2 new tower types, Wave and Laser. The Wave tower hits all enemy in range simultaneously and deals a lot of damage, but fires very slowly. The laser does very little damage per hit, but fires continuously, so it works well for lots of fast, weak enemies.

There’s also a wave counter showing all the upcoming waves so that the player can actually make plans instead of just reacting to what’s coming right now. I’ve finally balanced the amount of money the player has throughout the level with the strength of the enemies, so that you actually have to make a plan in order to finish the level without taking damage. It’s not too hard yet, but it’s a start.

I’ve been playing around this last week with Flixel. It’s an open source game-making library for flash that will hopefully make it a little bit easier to develop games in the future. I’m hoping it will also teach me the “proper” way to program a game, since it supports game states and automates a lot of collision detection, event detection and clean-up. This should at least eliminate my horrible AS3 event scripting in the future (events are a nightmare in AS3 because they can cause a lot of memory leaks).

The first set of changes I’ve made to the game were to add a tower design section. My current idea is that as you play levels, you will earn pieces of equipment for your towers. Then you’ll go into the tower design to equip each of your towers.

Players will only be able to use the top 4 towers at a time, but they will be able to design up to 8. Each tower will have a basic type, but the equipment will give customization, either to increase the tower’s abilities, or to decrease the cost of the towers. Currently, all you can do is reorder the towers. I think for a temporary fix I’ll implement the ability to manually adjust the tower stats so that I can test new builds.

Initial version completed last night

I’ve updated it slightly since uploading this video. Now the buttons slide into their new order over a 0.25 second animation, making it more clear which towers are moving and what the new order is.

The next things I’ll be working on are:
1. Actually allowing tower stats to be changed.

2. Saving the tower designs to the local machine.

3. Adding a couple different base tower types (such as an instant fire laser and an area of effect tower).

Well, we finished up around 5 and you can play the results for yourself here. Unfortunately, we didn’t get the chance to actually put a win condition in there for our one and only map. We also didn’t get around to making any additional towers, so you’re stuck with the standard tower. It’s currently getting a 1.85/5 rating on Kongregate.

Currently, our plan is for each of us to take the results and add on to it ourselves to see who can make a better game. Perhaps the updated versions will actually rate as games instead of just prototypes of games. We’ll see…

Overall, I’m very happy with the results of this weekend. This kind of tempts me to submit the current prototype of my TBS game, but I don’t think it’s quite ready. Hopefully some time soon.

Now that Ken is more familiar with coding a game in general and with AS3 specifically, I think we’ll try another one of these game jams in the future. It was incredibly productive and I felt like a learned a lot from the experience too.

Ok, so lot’s of coding done over the last 24 hours. The game now acts like an actual game, just without the help interface bits that make it possible to understand the rules. And without the restrictions of needing funds in game to purchase towers. And without any actual strategy because there’s only one tower type and one enemy type. But now it works.

Here’s a video of the results so far.

Next is making a more interesting map, more towers, more enemies and an actual game mechanic where you can win or lose.

My friend Ken and I started a game jam Friday night. I’ve been up working on this game for almost 9 hours now, and while what I have doesn’t look too impressive, there’s a lot of planning that’s already been completed as well as a few technological issues caused by Windows Vista (his computer, not mine). Also, it’s been mostly me on the programming because he’s both more sensitive to alcohol and less sensitive to caffeine.

I figured I’d post the results so far for all to see. It’s not much: a tiled map generator, a “Tower” that fires bullets at (0,0), sound effects, music and a mute button. But I think we’ve laid a good foundation and have a good plan of attack for the next 36-48 hours. Without further ado, here’s the game currently.

Hopefully we’ll have much more come tomorrow afternoon. Stay tuned!

A Game Jam is a programming session undertaken with the intention of creating a complete and working game prototype. Since I had so many issues when I went to integrate my level selection screen, I’ve decided that I’m going to start from scratch and see what I can do. If all goes well, I’ll post a picture of the new version of the game tomorrow.

I know I can stay up until at least 2 AM, so that’s at least 3 hours of work. Having already made the prototype of the game once that should be enough to get everything working as it does now. Since I already know what mistakes I made the first time, it might actually work better after I’m done with this. Wish me luck!

So I spent a good amount of time listening to the Infinite Ammo podcast today, specifically the one with Andy Moore. I think it helps a lot to listen to other game developers, especially when they have more experience than I do. Their discussion ranges all over the place, but here’s a few things I pulled from it.

Hook your players quickly

Like Murphy Lee said, “Wat da hook gon be?” For flash games specifically, it’s important to get players excited about the game as soon as possible. Players aren’t paying any money up front to play a flash game so if they aren’t enjoying it they have no reason to stick around. With more traditional, paid games, players have a sunk cost that they want to try and recoup before dropping a game. It’s a behavioral economics thing.

I’ve read before that with a flash game, you want to try and hook a player in the first minute, including load time. That’s also one of the reasons why keeping game file size down is important because people without a fast internet connection might give up on your game if it takes too long to load. Ideally, the player will feel like they’ve accomplished something within the first 4 clicks.

That might seem extreme, but why not? One click for “Play”, one click for “Okay” on the tutorial slide, one click to select your unit, one click to select an enemy. BOOM! You’ve defeated your first enemy! YAY!!!

I’m trying to keep this in mind as I design my user interface.

Metrics can make games better

While it’s important not to rely on metrics to design your game for you, they are a necessary tool for fixing and polishing your game. For example, let’s say you’re tracking what percentage of players are completing each level. Over all 20 levels, about 3% of players quit during every level, but you find that 20% of players quit on level 5.

Is it because level 5 contains an especially difficult challenge? Is there a glitch that causes some people to be unable to complete the level? Is there a mistake on any of the hints on that level that causes confusion? This merits further investigation, but without the metrics you’d have no way of knowing that there even was a problem.

Tips for new Indie developers

I realize I’m still in the target group on this one, but here are a few of the tips I gathered from the Infinite Ammo podcast.

1. Release your games
It’s very difficult after spending a lot of time on a creative work to think rationally about it’s quality. I know from just a couple months of working on this game that it’s all too easy to put an endless amount of work polishing, correcting, adding new features and generally improving the game. But if you do this forever, you’ll never release your game.

It’s also possible to get to a point where you’re sick of the game, having playtested it for the thousandth time and still not being satisfied with the way the characters move or with the level difficulty. At that point I think it’s time to fix any big glaring bugs and then publish it. It’s better to publish a game that has a few issues than to never publish a game at all.

2. Secure your code
This is a particular issue with flash games. Because of the way flash saves your game, it’s all too easy to decompile the source code, make whatever changes you want and then upload the game as your own. Fortunately there is software that encrypts code so that it’s more difficult/ near impossible to make changes to the swf file. Flash Game License provides a 25% code for Kindisoft’s secureSWF. It’s still $300 for the professional version, but it’s better than having your games ripped off.

3. Don’t be afraid to be inspired by other games
While this isn’t specifically mentioned during the podcast, it’s a lesson I drew from it. Around the 2:20:00 mark they discuss game clones. While copying a game action for action and level for level is definitely too far, there is a point at which you can borrow from other games. Innovation comes when people take what came before them and either reimagine it in a new way or combine it with other things to make a new combination.

It’s all too easy for critics to call any work derivative, but at the same time it’s impossible to construct a creative work in a vacuum. If you’re especially inspired by another game, don’t be afraid to say so. As long as you put your own touches on your game you have nothing to be afraid of.