Retrobooster Retrospective Video

May 27, 2014 by Terry

To illustrate the creation of a game, I made this video of Retrobooster’s development process. Enjoy.

There are a couple versions of the game that have been lost along the way, and I wish I could have included them. In particular, version 0.0.1 was even more bare-bones than version 0.0.5. It was before I had programmed a level editor, so it consisted simply of a ship flying around a big pink temporary planetoid.

The information in the video moves quickly. In case you had trouble reading all the text, here is the full script.

version 0.0.5 – December 30, 2007
Basic physics, navigation, particles
Sort of looks like a game
Passable level editor

version 0.1 – May 29, 2009
Surface shader
Particle shader
Light sources
Sound effects

version 0.2.5 – November 24, 2009
Level design experimentation
Advanced particle animation
Gobs of math

version 0.3 – December 8, 2010
Soundtrack from subatomicglue.com
Game controller support
Better textures and shaders
Glow effect
Gross levels
Splatter
Starfield backgrounds

version 0.4 – February 26, 2012
Content creation
Level prototyping
More math

version 0.5.3 – December 3, 2012
Much testing
Health bar
10 weapons
Continuous shooting
Smoke trails
Better backgrounds
Quit day job
Targeting laser
Lightning weapon
Splash damage
Defender drone
First trailer
Playable demo
Fried egg

version 0.7 – July 12, 2013
Conveyor beams
More enemies
More puzzles
Death Ray
A little calculus

version 0.8 – November 11, 2013
Humans are more interactive
New HUD
New player ship model
Multiple render targets for better multiplayer performance

version 0.9 – January 10, 2014
Save game feature
Refined collisions, physics
Tweaked visuals, packaging, difficulty, bonuses, powerups, weapons

version 1.0 – February 21, 2014
Unique starfields and lighting per level
Dolly-zoom for score multipliers
Optimizations
Launch trailer
Full game released
Fried egg looks more galactic

version 1.1 – April 23, 2014
Widescreen support
Level and game timers

Retrobooster Updated to Version 1.1

April 25, 2014 by Terry

Upon releasing Retrobooster, the most popular request was for better support for multiple-monitor configurations. Fixing the field-of-view issues was easy. Fixing the glow effect so it didn’t look really stretched was a bit harder. And updating the levels so you can’t see their edges with a wide field of view took a decent amount of work. Here’s what it will look like now if you spread it across three monitors.

Buy Retrobooster.
Download the free demo.
Vote for it on Steam Greenlight.

New in version 1.1:

  • Added widescreen support for multi-monitor configurations.
    • Horizontal and vertical field of view will not go below 30 degrees, so the game will be playable with extreme aspect ratios.
    • Updated levels so the edges cannot be seen and updated glow effect so it does not appear stretched when using extreme aspect ratios.
    • Better distribution of player viewports when using extreme aspect ratios during multiplayer games.
    • Added slider bar for positioning HUD elements so they can be moved onto the center monitor.
  • Added statistics at end of each level: score per level, time per level, total game time, and frags (in deathmatch games). Speedrunners, these timers are for you.
  • Rescuing a human now boosts whichever is lower, health or shields. Previously, one would be boosted at random.
  • Fixed small user interface quirks and bugs.
  • Added libasound2-plugins to the .deb package dependencies. Audio will not work without it.

Retrobooster at CogsCon

April 20, 2014 by Terry

Retrobooster will be available to try at CogsCon on Saturday, April 26 from 10am to 6pm. This is a nerd/art festival put on by students of CogsWell College in Sunnyvale, California. Registration is $20 at the door (free for children 5 and under). There will be local artists, video/card/board game competitions, and a cosplay contest, among other things. If you’re anywhere near Silicon Valley, come check it out.

First Big Sale

March 27, 2014 by Terry

Retrobooster is having its first sale at 50% off starting today. Tell your friends! You can get it any of these places through Wednesday, April 2.

And don’t forget. Retrobooster is still looking for votes on Steam Greenlight.

Demo speed run

March 26, 2014 by Terry

People have been asking me about speed runs lately, so I decided to speed run the demo version of Retrobooster. I did it in 2:24.965. See if you can beat that.

To get an accurate time, I added a timer to the game that only counts up while you’re actually playing. This lets you rest your fingers a little between levels if you want. The timer will be included in the next Retrobooster update.

I had a little trouble on Level 2 and Level 4. You can probably see where. Perhaps I could shave another five seconds off this time if those parts went more smoothly. You might also notice that I slaughter some innocent humans at the beginning of the run. This gives me a negative score because you are supposed to save them, but saving them takes too long for a speed run.

On the last level, I ram some of the enemies to destroy them. Ramming will deplete your health and shields quickly, but it’s the most efficient way to destroy the weaker enemies.

Simulating Spiders

March 5, 2014 by Terry

Spoilers ahead. If you do not want to learn about some of the more revolting monsters in Retrobooster, stop reading now.

Cave-flyers commonly have stationary and flying enemies but not enemies that crawl along surfaces. These are probably left out because they are a lot of extra work, but they allow for fun new enemy types that give Retrobooster much of its flavor. Before starting on this game I had a recurring dream about a level where you could blast enormous alien spiders with your tiny thrust ship. The game has evolved a lot since then, but this initial inspiration remains. The most important part of the dream was that these spiders would be, unlike common video game spiders, actually creepy. This article describes how I simulated spiders for maximum creepiness.

Spiders need two main components to move about in a convincing manner: a way to navigate terrain and quality leg animation. You can see both in effect in this video. Note that all of this works in 3D despite the gameplay existing in a 2D plane.

Method

Studying some videos of spiders and insects walking, the first thing I noticed is their efficient motion. Their bodies rarely bob up and down like carefully animated cartoon characters–they glide smoothly over surfaces leaving all the intricate motion to the legs. This would be even more true of a spider the size of a spaceship because its body would have too much weight to throw around unnecessarily. Bobbing around like a cartoon character also diminishes creepiness. What this all means is that the body can be animated on its own without involving the physics of the legs. This is fortunate because it breaks apart and simplifies the whole problem.

Following terrain

Moving the spider body along the terrain actually became one of the most difficult programming problems in Retrobooster. I wanted to generalize the physics of the game as much as possible because the realistic physics is an important part of the interactivity and game feel. For spiders, generalized physics requires not simply repositioning the body each frame but applying forces to it based on the distance to and speed of surrounding terrain. (I mention speed of terrain because sometimes spiders encounter moving obstacles, and they need to walk on these surfaces as naturally as they would stationary terrain.) All this work allows spiders to realistically bump into other entities and crawl all over one other. You can even get underneath small ones with the player ship and push them into the air.

It took a great deal of iteration to make an acceptable algorithm for walking on terrain. The final solution is generalized so that it can be used for multiple types of walking entities by setting a few parameters. The first step is to search for nearby terrain using segments extending from the center of the spider body. The segments are changed each frame in a pseudorandom pattern to slightly randomize the final forces on the spider body, which does a lot to prevent it from getting stuck in concavities and help it find its way around convexities.

The segment intersection points and their accompanying surface normals are used to determine the average position of the nearest terrain and its slope. A force is applied to accelerate the body toward a desired distance from the terrain, and another force is applied to accelerate the body toward a desired speed across the terrain. Depending on the type of creature and its mass, a desired speed and force multipliers can be chosen as input to the walking algorithm. For small spiders, the forces are strong enough that they effortlessly climb up walls against the pull of gravity. Larger spiders and some other creatures are made to look like this is a struggle.

The final algorithm does a reasonable job of following terrain. Spiders and other creatures still make mistakes sometimes and fall off when trying to climb around sharp points on the terrain. This happened much too often with early versions of the terrain following algorithm. Once I reduced this problem to a minimum it stopped bothering me because it adds some variety and realism to what appears to be a difficult climbing task.

Animating the legs

A long-standing problem with video game animation lies in the disconnection between animal legs and the terrain beneath them. This is caused when animation is done entirely with art software and the actual game terrain is ignored. In the worst cases, animals plant their feet firmly in the air or underground. And when these animals turn, their legs slide along the ground as if they were wearing Teflon shoes. This type of lazy animation absolutely kills creepiness. The spider legs in Retrobooster are animated algorithmically to accurately connect them with the terrain.

I made two assumptions at the start which both worked out well. First, nobody would notice if the spider legs passed through one another sometimes, allowing me to ignore leg-leg collisions. Second, my spider legs would only have one knee joint and one hip joint. Actual spiders that I observed have three knees, but keeping it to one simplifies the math and cuts the number of leg transforms in half. I modeled each leg half as two leg quarters with a slightly bent static joint, which successfully gives the illusion that there are three joints in each leg. I was initially concerned that a hefty swarm of spiders would put so many transforms on the screen that only the most powerful graphics cards would be able to cope. This may have been true ten years ago, but it is not now. Even modest PC graphics cards handle all these transforms with ease, so I was not forced to explore other options such as animating the legs with vertex shaders.

In my opinion, the creepiest spiders pick up their feet quickly and set them down gently. (I’m throwing out words like “knee” and “feet” as if spiders actually have these. An arachnologist would probably hate reading this.) To simulate this motion, you can solve for the coefficients of a simple polynomial where t is the interpolater in the range {0.0, 1.0} and x is the resulting position.

x = at3 + bt2 + ct + d

The derivative of this polynomial where dx is the velocity:

dx = 3at2 +2bt + c

You have a position and velocity at the start of the step (t=0) and at the end of the step (t=1). If you plug them into this polynomial and its derivative you get four equations and you can solve for the polynomial’s four coefficients. The final function is one-dimensional, and it is used in triples to account for the feet moving in three dimensions.


// p = s at t = 0
// dp = ds at t = 0
// q = s at t = 1
// dq = ds at t = 1
float interpolate(float p, float dp, float q, float dq, float t){
   float a = 2.0f * (p - q) + dp + dq;
   float b = (dq - 3.0f * a - dp) * 0.5f;
   float t2 = t * t;
   float t3 = t2 * t;
   return (a * t3) + (b * t2) + (dp * t) + p;
}

A new foot position is calculated each frame during a step, and inverse kinematics is used to compute the leg transforms. The step speeds vary slightly from one spider to the next and are slower for larger spiders. This gives each creature a little character.

When at rest, a spider foot matches the velocity of the surface on which it is resting. This part of the animation could be better because the velocity is only given to the foot at the moment it is planted, but the surface might be accelerating. If the velocity were updated more often there would be less chance of anyone noticing a spider leg floating above or sinking into a surface. In practice, most surfaces are stationary and most spiders are small enough on the screen that a player will probably not notice this.

Each leg operates almost independently. When a foot is moved a specified distance away from its hip, the leg automatically takes a step. With each step the foot reaches for a point ahead of the spider body. This effect really shines when a spider turns to move a different direction. Each leg takes the appropriate number of steps, bringing the creature to life.

The legs cannot be left to move completely independent of one another or they might end up all taking steps at the same time. To prevent this there is a little code that biases the speed of each step, keeping all of the legs out of sync. The legs are purely cosmetic and do not affect the movement of the spider body, but they appear to give it good support as long as a few of them are on the ground at all times.

There are also many small details that add life to the simulation. When navigating rough or highly convex terrain, sometimes a leg can struggle to find a place to step. When this happens, the leg does not pause. It keeps moving as if it is trying to find a place to land a step. Similarly, when a spider falls through space its legs flail about as if it were trying to find its footing.

Stomping softly

It took too long to find the right sound effect for spider steps. I tried many different stepping and stomping sounds made from things like elephants and sand bags. In the end I decided the creepiest sound was very little at all. I just used a decent stomping sound and turned the volume way down. These creatures are supposed to appear efficient in the way they move, so they should sound efficient as well.

Making models

As for modeling, the most important compromise was already mentioned: the legs contain some fake joints that never move. If you don’t know to look for it, you would probably guess there are more animated joints than there actually are. If I had more time I would have also liked to put a joint or two in the body so that it could flex to follow terrain contours and absorb impacts with some visible squashing and bending.

The spider texture was designed to be colorful and full of contrast so that all the animation would stand out. I tried some different patterns on the legs and decided that stripes emphasized the leg movement the best. The gloss is turned all the way up to make the spiders look slimy and wet.

P1120718

I ran into a lot of these guys on Mount Tai in China. It was amazing how much they look like Retrobooster’s spiders.

Conclusion

Spiders in video games rock! The more the better, and they should be as disgusting as possible. After about a week of programming these spiders I started having nightmares about them, and I hope they give you nightmares too. My only regret is not having time to make more spider varieties, but that is not to say Retrobooster does not contain other gross creatures with legs. Bon app├ętit!