Cartalotta: Strings of Fate

See you all on Thursday!

The submission deadline for GMD 2012 has been extended to Thursday January 19!  That’s more time to fix up your games so be sure to submit whatever you’ve got by the new submission deadline, even if you’re not terribly satisfied with it, for an excellent chance to win a prize (usually every videogame submitted will win something).

We were accepting GMD 2012 sign-up forms until the beginning of January, but you can still download these forms from our website if you need to for whatever reason.  As previously mentioned, the theme for GMD 2012 is “Murder Mildly Foul”

Feel free to email us at gmd@utgddc.com if you have any other questions about GMD 2012.

Good luck, game developers!

The CSSU is also still interested in those who would like to volunteer to help setup and lend gaming consoles and computers for the evening. So, if you’d like to help contribute to the fun, email the CSSU and have a chance to win a prize for your efforts. More information about this can be found on the CSSU’s webpage about Game Night.

So come on down and give yourself the fun you deserve at Game Night. Even the utGDDC Arcade cabinet that fellow member Tyler has finished will be making an appearance.

By the end of the last article, we had a physics system in which we could change the following aspects:

• The base acceleration, which, when increased, caused the enemy to move and accelerate faster,
• The angle at which the enemy is accelerating, and
• The coefficient of friction which determines how long it takes for the enemy to come to a stop, and also factors in to the enemy’s top speed.

In order to keep all the enemies moving with a similar “feel”, I kept the coefficient of friction identical for every enemy, as well as the player. If I wanted to, for example, have some enemies look like they’re gliding on ice, while others start and stop instantly, I could change this.

The base acceleration differs from enemy to enemy, but is kept constant for all enemies of that type, at all times. This also means the enemies never come to a stop.

Thus, the only thing that is changed dynamically by the AI is the angle at which the enemies accelerate. This is the parameter that all the AI logic goes into — it only changes where the enemy is supposed to go. This is decided using a couple of very simple rules, but the way this is decided is different from enemy to enemy, and results in very different behaviour.

Let’s take a look at the different types of enemies we have. Lucky Shot only has three types of enemies. They’re never given official names in-game, but I like to call them drifters, dodgers, and shooters.

• Drifters are the simplest and easiest enemy. All they do is chase you. That’s it.
• Dodgers chase you as well, but the moment you start shooting at them they scurry away from your bullets.
• Shooters are different in that they can shoot back. To take advantage of this, they keep their distance from you, circling you at a safe distance — not too far, not too close.

Let’s look at each of these in turn.

Drifter

Click above to play! Use the WASD or arrow keys to move, and click to fire.
Both you and the enemies are invincible.

The drifter is the simplest of the enemies. Their acceleration is always kept in the direction of the player. That’s the extent of their behaviour.

Well, almost. There’s a slight problem with that: if all of the enemies simply kept their acceleration pointed exactly towards the player at all times, as the player dodged and weaved around them, their paths would end up converging, and you’d get all the drifters overlapping in one big clump. To prevent this problem, I add a bit of noise to their motion — instead of accelerating directly at the player, they accelerate in the player’s direction, plus or minus up to 90°. That may seem like a lot, but remember that we’re dealing with acceleration rather than velocity. On average, they’re accelerating towards the player, and that means that their velocity is always going to be roughly towards the player as well. The overall effect of this is that the drifter takes a slightly wobbly path towards the player, and when you have several of them on screen, each of them heads in a slightly different path, keeping them from overlapping too much. This strategy is employed to varying degrees in all of the later enemies.

Dodger

Click above to play! Use the WASD or arrow keys to move, and click to fire.
Both you and the enemies are invincible.

If you’re not firing at it, the dodger acts identically to the drifter, with a few minor differences. It has a slightly higher base acceleration than the drifter, and a slightly smaller range of movement noise — it points itself in the player’s direction, plus or minus up to 65°. This means it’s both faster and travels in more of a straight line than the drifter.

The big difference, of course, comes when you fire at it — it flees from bullets, hence the name. This is probably the most complex of the AI behaviours, and it’s a bit rough around the edges — you may notice that they get confused if there’s a lot of bullets around them on all sides, and they sometimes travel into the stream of bullets rather than away from it. But for the purposes of the game, it works well enough.

First off, they’re not actually dodging the entire stream of bullets. They’re dodging only one bullet, the one that’s closest to them. Each frame, they look for the closest bullet to them, check the distance between themselves and the closest bullet, and depending on how close it is, they move themselves away. If the nearest bullet is all the way across the screen from them, they head towards the player as usual. As the bullet gets closer and closer, they turn further and further away from the player, until, if the bullet is right on them, they head 90° to the player, away from the bullet. By comparing the angle between them and the player, and the angle between them and the bullet, they can decide whether to dodge in a clockwise or counter-clockwise direction.

How the dodger decides which way to run from bullets

How far they turn away from the player is determined by the following formula:

Where is the angle the dodger will turn away from the player (ex. 0° is directly towards the player), is the distance from the dodger to the closest bullet, and is the width of the stage. If you plug in some values, you can see that when the dodger is a stage-width away from the player, it heads straight towards the player, and when the bullet is very close, the dodger will move at close to 90° away from the player.

This works out decently well in practise, even though there are some cases where the behaviour is a little wonky.

Shooter

Click above to play! Use the WASD or arrow keys to move, and click to fire.
Both you and the enemies are invincible.

These guys are the biggest threat in the game. With the ability to shoot at you, they can cause a lot more damage than any of the other enemies. In doing so, they like to keep their distance, making it harder for you to shoot back, especially if you have a short-range gun. They have a slightly higher base acceleration than the dodger, and only have a 60° range of noise added to their acceleration direction (±30° as compared to the dodgers’ ±65° and the drifters’ ±90°).

The key difference in their AI, of course, is that they keep their distance from the player at all times. To do this, I chose to use a simpler system than the dodgers’ AI, similar in nature but less complex. Depending on the distance between them and the player, they change the direction in which they’re accelerating. If they’re far from the player, they accelerate directly towards the player. A bit closer, and they accelerate at 45° to the player’s direction. At a neutral distance, they orbit the player, accelerating at 90° to the player’s direction. Any closer than that, and they move away, first at a 45° angle, and at a very close distance, directly away. Each of these is hard-coded into the shooters’ behaviour.

The shooters' behaviour is all hard-coded, based on the distance between itself and the player.

This works quite well, and has the advantage of being a lot simpler than the dodgers’ movement system. The simplicity also means that it’s easier to tweak — if I wanted them to orbit the player at a closer distance, or have a wider range of distances at which it would be happy to orbit, it’s as simple as changing a few constants. And because we only change the acceleration rather than velocity, you don’t see an abrupt change in direction when they hit the boundaries.

There’s one thing left in their movement AI, and that’s deciding which direction they’ll be orbiting the player. To do this, I had three options — have them orbit clockwise, have them orbit counterclockwise, or have them choose between the two randomly when they’re spawned. I chose all three options. I had those three options coded in, and chose between them based on what fit the level best. Even in the above flash demo, if you refresh a couple of times, you’ll notice that one of them is always orbiting clockwise, one always counterclockwise, and the last chooses one or the other randomly.

The very last thing handled by the AI is the direction in which they’ll be shooting. This is simple — their guns are pointed directly at the player, but have a spread of ±15°. Because enemies with perfect aim are cheap and boring.

The Final Word

What I wanted to show here is that you don’t have to have a fancy, strategizing, A* pathfinding, neural network creating AI to create fun behaviours for your game. Especially in a time-limited competition like GMD, simple AI is often best. But if you fake it well enough, your enemies can seem appropriately intelligent while still keeping that simplicity of implementation.

As always, I encourage you to email me or post a comment below if you have questions or comments. Happy coding!

Before I get started, though, I’d just like to say that this likely won’t be anything new to anyone who’s programmed a physics system in a game before — in fact, if you have, you will likely see this as overly basic. And it is. This is meant more as a beginner’s introduction and as a showcase on how some very simple ideas can lead to some very nice behaviour. It does, however, require some knowledge of high-school level math and physics.

The development of Lucky Shot started well before the competition even started — the fundamentals of its physics and movement had been developed earlier, while I was playing around with top-down-shooter-style movement and learning Actionscript 3. I came up with the movement system when I was playing around with creating a top-down shooter-style game based on the Doppler effect. The mechanic itself turned out not to be that fun, so I never continued with it, but the simple ideas behind its movement system has powered nearly every game I’ve made to date.

In order to best understand how it works, I’m going to lead you through the same thought and discovery process that I went through when coming up with this. In the beginning, I had just started playing around with Actionscript 3, so I started out by moving a circle around the screen in what is probably the most basic way possible: every frame, the game would check whether the arrow or WASD keys were held down, and if so, it would add or subtract a constant value from the circle’s x and y position as needed. (I called this constant value the circle’s base speed.) This gave me something like this:

Click above and use the WASD or arrow keys to move around!

This is a start, and for a simple game this might even be good enough. But there are some obvious problems with it:

1. You move at a constant speed.
2. You stop moving as soon as you let go of the key.
3. Moving diagonally is faster than moving purely horizontally or vertically.

Points 1 and 2 can be summarized in two words: no inertia. So let’s try a different approach: instead of adding a constant amount to the player’s position every frame, let’s try adding a constant amount to the player’s velocity, with a cap on the velocity to ensure the player doesn’t rocket off at ridiculous speeds. This means that the arrow keys would control the direction the player accelerated rather than the direction the player went. This strategy gave me this:

Click above and use the WASD or arrow keys to move around!

You’ll notice also that I added a bit of functionality to bounce the player off the walls. This is as simple as inverting the player’s x or y speed once the player is out of bounds.

This is much better already. Now when we press a direction, we’ll accelerate in that direction, and it feels much more smooth. But there are still some problems with this:

1. When you let go of the keys, you never slow down — you’ll keep moving and bouncing forever.
2. You accelerate faster diagonally than you do purely horizontally and vertically.

Let’s look at the first problem. Again this can be summarized in two words: no friction. Let’s add some simple friction.

The version of friction I implemented was inspired by the concept of terminal velocity. When an object is falling in air, that air applies a frictional force to it in the opposite direction of movement. This frictional force is proportional to the object’s velocity, so as the object falls, it gets faster, causing the friction to increase, which in turn causes it to accelerate at a slower rate. Eventually you reach a point where the air friction balances out the force of gravity, and the object’s speed stops increasing.

In my implementation of this, we don’t deal with forces, nor with gravity. Instead of dealing with forces, we can deal with accelerations instead. And instead of gravity, we have an acceleration imparted by keys that the player is pressing, or in the computer-controlled enemies, the AI’s logic.

The first thing we do is figure out the acceleration for the object, which is a constant value (which I call the base acceleration), but may be in a variety of different directions (more on that below). Then, we calculate deceleration due to friction , which is the object’s velocity multiplied by a friction coefficient , which is a number in the range of about 0.05 – 0.1, depending on how much friction you want to give the object.

The deceleration due to friction is then subtracted from the object’s acceleration, and that acceleration is added to the object’s speed. The second-last thing we do is compare the object’s speed to a very small value — about 0.01 — and set it to 0 if it’s below that. This is needed because with this implementation of friction, the object’s velocity never actually reaches 0, it just gets very very close to it. This causes a bit of “drift” when the object slows to a halt, where it keeps moving by a fraction of a pixel each frame.

The last thing we do, of course, is add that speed to the object’s position.

We can tweak the motion of the object by changing the constant base acceleration and the friction coefficient . The bigger we make , the faster the object will accelerate. The bigger we make , the slower the object will move, and the faster it will come to a halt. The object’s maximum or terminal velocity is the point at which these two balance out: . If you want the object to feel like it’s sliding on ice, you can decrease both and . If you want the object to stop and start instantly (similar to the movement in the first flash demo), you can increase both and . And as long as you keep the ratio between the two the same, the object will always move at the same speed.

So now we have friction. You no longer bounce infinitely off the walls, and turning is made a lot easier. There’s just one last issue to address, and that’s the increased acceleration when going on a diagonal. To fix this, we need a tiny bit of trigonometry.

Say you want your little dude to go at an arbitrary angle , but you want to keep his base acceleration as . That is, no matter which direction he’s going, his total acceleration should always be . To use this in the code, we need to break this down to its x and y components, which I’ll call and . This is as simple as doing this:

Plug in whatever angle you want for , use these as the acceleration values for your x and your y, and you have yourself some smooth movement whose speed and acceleration is independent of the direction you’re moving. In fact, if you’re just handling keyboard control — where you have at most 8 directions in which you can move — you can just handle the straight up/down case by just using the base acceleration , and the diagonals by adding to the x and y values with the sign dictated by the direction (this is the same as ).

Now that we have all this set up, let’s see it in action.

Click above and use the WASD or arrow keys to move around!

Wonderful. We now have a movement system that’s smooth, simple, flexible, and fun in and of itself. But here’s the dirty secret: this takes care of most of the natural-looking movement you see in this game’s AI. In part 2, I’ll show you how this system, along with some very simple rules of movement, created an AI system that was both fun and challenging to players.

During the last GMD, I created a retro-gambling-shooter game, Lucky Shot. It won the grand prize in the judged competition, ranked fourth in the public showcase, and was generally well-received. And of course, more than anything else, it was a great learning experience.

Last year was actually the first time the club ran the public showcase. We held it during the Computer Science Student Union‘s game night, and to take full advantage of it, we gave out feedback forms, asking people to rate each game and write a few words about it. I found that the reactions we observed and the feedback we got were even more valuable than the prizes given out. With that in mind, let’s take a look at how people enjoyed the game.

You can tell who the Starcraft players were.

But before we get started, if you haven’t played the game yet, go do that now! This article will make a lot more sense if you’ve played it.

Click here to play! (Opens in a new window)

Back? Ok, let’s get down to business.

What worked

Slim, bottom-up game design

This game was based on a very simple idea: a top-down shooter where you gamble for your guns. The gambling element came from the theme for the competition: Don’t be funky, let’s get lucky. But in development, instead of starting off with art, or music, or the gambling element, I started off with the very basics — movement, control, shooting, etc. Nothing extraneous was added until closer to the end. I built up a quick, simple, but very good and flexible framework for the game itself in the earlier stages of the competition, and later on I took as much time as I could to polish it, give it a good interface, and cram in as much content as possible (which in my case meant coding up a big variety of guns).

This can be risky for some people, as you can end up getting trapped in refining the framework and run out of time to build an actual game around it. But if you manage it right, and put priority on the actual game parts of your game, you end up with something playable very quickly. This is especially good for GMD, because of the need to balance the competition with school work. It’s likely that you’ll end up slammed with assignments or tests near the end of the competition, forcing you to hand in what you have done. If you have a playable game from the early stages, you at least have a chance at doing decently despite it being unfinished.

Arcade-style gameplay

This kept the game simple, accessible, and above all else, fun. It would have been nearly impossible to implement a game of calibre similar to an RPG, for example — it just requires far too much content to make it enjoyable. Arcade games can be enjoyable even if they’re only one level. And in the end, the environment in which they were shown lent itself far better to arcade-style pick-up-and-play gameplay than anything more complex.

Grabbing people's attention in between games of Counter-Strike.

Slick, simple AI system

This was one of the most complimented parts of the game, and it amazes me, because it was surprisingly simple to make. I won’t go into detail on this just yet, but keep your eye on this site, as I’ll be posting up some articles detailing the AI and physics systems soon.

Smooth difficulty curve with a high peak

The idea to make the later levels insanely difficult was inspired by the game Darkest Before the Dawn, made by my friends Francesco Ciarlandini and Sean Lacy for the previous year’s GMD. In their game, while it starts off relatively slowly, as it goes on it gets more and more difficult until all hell breaks loose near the end. Few people still have beaten that game. What I found, though, was that I kept coming back to it, playing it again and again, until eventually I managed to beat it. Its difficulty made it entertaining despite being relatively slim on content (as all GMD games are). Not only that, but the fact that the game treated me as if I wasn’t entitled to beat it made me even more determined to win. So I modelled Lucky Shot’s difficulty curve in a similar way. Most people should be able to get past the first few levels. Few will get past the last couple. And as of yet, I am the only one who has managed to beat the final level (and even I have only ever done it twice).

(As a side note, if you can provide evidence that you’ve beaten this game to me, I’ll personally acknowledge you on my blog as the first person to beat Lucky Shot other than its creator. Protip: save your Machine Guns for the last two levels.)

Doing it right.

What was interesting to me was comparing it against Francesco and Sean’s game from this year, Gamblon 777. This game was quite fun, managing to just barely beat me out for third place in the public showcase. But it didn’t have the smooth difficulty curve of the previous game. I noticed that many people would sit down at this game to play it, die within ten seconds, and simply get up and leave. It shows that you need that slow start in order to get people hooked in the first place.

Gradual introduction of concepts

Tying in somewhat to the above, it’s not just the difficulty curve that’s gradual — it’s the complexity as well. I had three types of enemies. Each behaved differently from the last, and they had a pretty obvious hierarchy in terms of difficulty. I had to make sure the player wasn’t confused by them at the beginning.

What I chose to do was introduce every enemy in turn, each in their own levels. Level 1 introduces you to the basic Drifter enemy that chases you. Level 2 is a slightly harder Drifter level. Level 3 introduces you to the Dodger. Level 4 is a slightly harder Dodger level, with a few Drifters thrown in at one point as a surprise. Level 5 introduces you to the Shooters. And so on. It’s not until the last few levels that they start mixing together in any significant way, and that’s when the game gets very difficult.

This is the same idea used by games like Portal. You have to deliberately train your players to understand and deal with your gameplay concepts before throwing them into situations where they have to manage several of them at once.

Minimalist art style

I’ll make no bones about it: I am not a good visual artist. This minimalist art style is my way of making something decently visually appealing, functional, and quick to make. And it allowed me more time to work on the game’s foundation.

Creative commons resources

Although I would have loved to have composed and created the music for the game myself, I spent nearly all of my time on the gameplay, making that impossible. I later found myself with an uncomfortably close deadline and no music. I knew I wanted an 8-bit style action-style song to compliment the retro visuals, so I popped open 8bitcollective (where all the songs are licensed under CC BY-NC-SA), found a song I liked, and threw it in there. And it immediately made the game much more fun. I’ve always been amazed at how much influence great music can have on a game.

Not to mention that it’s just so much better than anything I could have come up with myself. Exilefaker, you are a goddamn genius.

What could have been done better

Clearer instructions and between-level interface

This was one thing that surprised me. Several of the feedback forms mentioned a need for “more instructions”. Initially, I was confused. How hard is it to understand a game where you shoot red things? But then I realized that one of the most complex parts of the game — the between-level gun selection screen — had only minimal instructions on how to use it.

Whoops.

Not only that, but people seemed to completely miss things that I had included to make their lives easier. Things like the hints on the bottom-left as to which enemies are coming next, the lives indicator, or even the fact that you could hold down the mouse button to shoot.

To fix this, I could have added, on the first between-level screen, some helpful tips about the interface elements of the screen. A simple bit of text with some arrows pointing to the Gamble and Use buttons, describing each, would go a long way to helping people understand it. Highlighting the hint text and lives count in red would help to make them more apparent. And I guess the people took the words “Click to shoot” from the help screen a bit too literally, so it would have been nice to have made that clearer.

Originality, or lack thereof

I’ll be blunt here — this game was heavily inspired by games like Geometry Wars, even down to the enemy types and movements. As such, it doesn’t really stand out as something new or different, and this is a barrier to grabbing people’s interest. I expect it would be more interesting if I had had the time to add more gun types — after all, you’ve never seen Geometry Wars with mines, homing shots, or a nuke before, have you? Which brings me to my next point…

More content

Which in my case would mostly mean more gun types, though it could mean more enemies and levels as well. When I started conceptualizing this game, I had about a page and a half full of ideas for different gun types. The problem is that I ran out of time to implement them. I feel if I had managed my time better I could have done so.

Getting into a bit more detail, the limiting factor here was not actually the gun types themselves — it was the different types of bullets that I would have had to implement. By the end of the project I had exactly one type of bullet — the standard, round, travel-in-a-straight-line type. It was very easy to create new guns that would fire them in different directions, each with a different speed, range, and damage. It would not have been easy to create guns with bullets that curve, orbit, explode, split, penetrate, swarm, or home in on enemies. Some of those would require a new movement system. Some would require a different collision detection system. Some would even need AI. It just wasn’t feasible to add them given the time frame I found myself in near the end.

But it would have been so damn awesome.

The final word

Although there is definite room for improvement, I doubt I’ll revisit this game anytime soon, with the possible exception of some minor retrofitting to work with the upcoming UTGDDC arcade cabinet. The game is already good as it is now, and I’ve been spending my time recently on other projects. Still, this was a great experience. It was the first time since I got into game development in which I felt I had made something I could be proud of.

But in the end, it’s not my game anymore. It’s yours now. So play it, tell your friends, send me feedback, and most of all, have fun with it.