Recently, I took my first trip to Game Developers Conference (GDC). It was an all-around educational experience. Retrobooster hasn’t supplied me with a budget yet, so I bought a relatively inexpensive expo-only pass and went there just to meet people and do some networking. It was good to get a feel for the video game industry and see what people are doing. I even got to show my game to a few people and received some feedback. Following are my observations on GDC and random topics in gaming. They are completely unscientific, so don’t bet your budding indie game studio on any of them without more research.

It’s a good time to be indie

If you follow the game scene you’ve probably heard how wonderful it is to be indie due to the rise of digital distribution portals, such as Steam, Desura, and all those app stores. I didn’t meet anyone who disagrees with this theory, and GDC was overflowing with indie developers. Additionally, there are new consoles on the way that sound more indie friendly than past consoles: Ouya, Game Stick, Steam Box, and MiiPC. (MiiPC is billed as a low-power PC, but I’m guessing it will be used for simple games a whole lot.) And now Sony is courting indie developers for PS4.

Talk to engineers

As at all most shows, I had a great time talking to engineers who actually worked on the products on display. They tend to enjoy nuts-and-bolts conversations about how you can use their tools for your projects. Conversely, there is a breed of sales- and businesspeople that choose words too carefully. They have a hard time giving you straight answers, and when they decide you’re not going to buy something they want to end the conversation as soon as possible. GDC had plenty of those too. If you want to have educational conversations, people who actually make stuff are a safe bet, but watch out for smooth-talkers.

GDC Play was just as good as IGF

GDC Play and IGF both had some excellent games, some with clever new mechanics and some that were just beautiful. GDC Play was sold to the exhibitors as a great way to reach the press, but I talked to plenty of developers there who got little or no attention from the press. It’s too bad, since there were some real gems to be seen. Here are some of my favorites from GDC Play:

* Monochroma – Simply gorgeous.
* Laika Believes – Cool premise, like a dog version of V’Ger.
* Ring Run Circus – Flip-flop mechanic with fun possibilities for skill and puzzle gameplay.
* Concerned Joe – Don’t stop moving. Very clever.
* Super Motherload – Looks like a great multiplayer experience.
* Windforge – Build destructible airships and battle dragons with them.
* Dungeon Dashers – Excellent possibilities for puzzles using characters with different abilities.
* Beyond the Depth – If I ever made an underwater screensaver, I’d want it to look a lot like this.

Use an engine or roll your own?

After meeting a lot of people in the gaming industry, I notice many of them are shocked that I’m writing Retrobooster in C++. This was a reasonable choice when I started the game in 2007, but there are probably much better game engine options today. A good game engine lets you develop a professional looking game relatively fast. However, this often costs you performance, and you can end up with a game that looks like it was made with a particular engine. If you build your own engine (or at least targeted pieces of it) you can have a big performance boost and customize your visuals more. For example, people notice the particles in Retrobooster right from the start because they stand out from the particles in most other games. That’s because they are made specifically for Retrobooster and coded from scratch with C++ and OpenGL.

To be accurate, I’m building Retrobooster with OpenSceneGraph, SDL, and SDL_mixer, which takes me about halfway to using an “engine.” These tools provide a safe, community-vetted base but not as complete a solution as a an actual game engine. As a developer, the gray area you need to navigate is how much of your game to build from scratch. I’m still happy with my choice because I have always viewed my game as a big art project, and C++ allows me to do things I have not seen in other games and pay great attention to detail. After much playtesting, I can see these things are not lost on players. But will they translate into better sales?

It’s amazing how fast technology progresses. Building a game in C++ would not have seemed strange to anyone five years ago, much like optimizing using assembly would not have seemed strange to anyone ten years ago.

A side effect of all these engines is that there is an unlimited amount of shovelware available and more every day. This can make it much too difficult to get your game noticed, especially if it’s on mobile devices, which brings me to . . .

“You have GOT to be on mobile”

I hear this from almost everyone in gaming. People will often look at your game for thirty seconds or not at all and say you need to convert to freemium and put it on phones and tablets, giving no consideration to your game’s playability with a touch screen. The more I hear this, the less I believe it. It is reminiscent of any economic bubble. And once everyone you talk to is raving about a particular bubble, it’s already too late to join the frenzy.

Part of the mobile argument usually contains disparaging remarks about PC and console gaming. Despite what you may have heard from your favorite mobile zealot, PC gaming is not dead. It’s actually growing. And not to be without a fun anecdote, there are also developers like Jake Birkett who just can’t find value in the mobile market.

I also heard broad agreement at GDC that it’s nearly impossible to get your game noticed on mobile without a lot of marketing dollars behind it. This could be a show stopper for an indie developer who can’t find a publisher. As I understand it, most mobile gamers fall into the “casual gamer” category and put little effort into searching for games. If your game isn’t on a “top ten” or “featured games” list, it will get very little attention. On the other hand, not-so-casual indie games on PC have a huge community of fans talking about them. If you make a game they like and do a huge amount of PR work, they help you get the word out.

Some people are starting to talk about this bubble is bursting, but I haven’t observed any signs of that yet. It is inevitable, though. Any new platform will eventually reach a plateau or die out completely. Before either of these happens, there is often a period of great excitement like we are now seeing in mobile gaming.

Parties

GDC parties are touted as fully half of the GDC experience and the best place for networking. Most of the parties that I saw were too crowded and loud to do much of anything. By far the best party I attended was the Indie Art Jam. The epitome of a casual gathering, a bunch of artists and programmers raided Denny’s Restaurant for a few hours. We talked, drew some pictures, played the accordion, and showed each other our games.

There is an idea floating around for the ultimate GDC party. It would basically be a coffee shop filled with white boards and projection screens. Sketch some ideas, show off your latest game prototype on the screens, have a hot chocolate, and speak without needing to yell. I don’t know whose idea this was originally, but I have heard it suggested by a couple people and would love to see it actually happen.

It has been a while since I posted anything about the tech in Retrobooster. Lately, I have been refining the conveyor beams, which figure prominently near the end of the game. They are basically tubes of energy that pull game entities around the levels. Think of them as rivers of space. I imagine them as the main mode of transportation used by Retrobooster’s evil aliens in and around their giant spacecraft.

The motivation for the conveyor beams is to have a fun game mechanic that ties together the final set of levels and builds upon mechanics encountered earlier in the game. The beams allow for new scenarios, such as accelerating faster that you can with your ship’s thrusters, using force fields to bounce in and out of beams, and requiring you to fly at high speeds to penetrate against the flow of a beam.

Inner workings

Making the conveyor beams function properly was a difficult exercise in math. The beams are defined by a series of points. Each point has an associated velocity. From the velocity you know the direction the beam should move and how fast it should push entities inside of it. The curve between two points is defined entirely by the position of the points and the direction vector (normalized velocity vector) at each point.

First I tried to shape the curves with third-order polynomials. Unfortunately, these cannot define perfectly circular arcs. There are a lot of radial levels in Retrobooster with circular walls, so it was necessary to have beams that could follow along those walls. I was actually able to approximate 90- and 180-degree arcs fairly well with polynomials, but s-curves were misshapen. After this failed experiment, I switched to interpolating between real circular arcs. These require more computation to work with, but they are exactly circular when you need them to be and they produce smooth s-curves as well. To define a curve with circular arcs between two points I first create two arcs, one defined by both points and the first point’s direction vector, and the other defined by both points and the other point’s direction vector. Then I interpolate between both arcs depending on the proximity to each point. (Not coincidentally, this method of defining curves is also used to shape the terrain in all the levels.) (Here is a more detailed treatment of splines vs. circular arcs.)

On top of defining the shape of the conveyor beams, there was plenty of work required to make the beams properly influence game entities’ movements. I wanted to allow freedom of movement sideways through beams, make it impossible to push against beams of a certain speed without a running start, allow players to fly faster than beams if they want, and have entities’ velocities rotate as they move along curved beams. This all comes down to a whole lot of tricky linear algebra. The most difficult part was finding a good way to rotate an entity’s velocity as it moves along a beam when the entity is not in the center of the beam. Doing it at the center is easy–off to the side is strange.

Another thing that would have been fun to try is to program the beams as actual inertial coordinate systems. In this scenario, an entity could be moving along with a conveyor beam but its internal velocity vector would be set to zero. In other words, the entity would think it was stationary but they space around it (the beam) would be moving through the game space. The reason I did not program the beams this way is because I predict two problems. One, there would be a discontinuity in an entity’s velocity as it moved in or out of a beam, and two, an unreasonably fast beam would be required to prevent a player from thrusting upstream through it.

Looking good

For the conveyor beams’ appearance, I wanted some attractive sci-fi graphics that defined the shape of the beam for the player and didn’t distract too much from the rest of the game action. This took a few iterations. Eventually, I settled on what you see in the video. Before that I tried drawing different tubes and amorphous blobs moving through the beams with various shaders and different amounts of glow. These other ideas all looked too polygonal or failed to show the shape of the beam as well as the final solution.

To polish off the visuals, I added some light sources and sound effects to add more pizazz to the energy bolts zipping along the beams.

Game on

The conveyor beams function quite well now and look kinda sexy. It’s time to put them into more levels. So far I have a few sketches and prototypes and two nearly complete levels that use the beams. Those levels both have the player manipulating force fields and teleporters while traveling at unsafe velocities. I’ll be refining some of my other ideas in the coming weeks.

Version 0.6 of Retrobooster’s playable demo is now available from the downloads page. There are some bug fixes and improvements to many systems in the game, but there are no major gameplay changes. Retrobooster is still very much in beta and progressing smoothly. Here is the complete list of changes:

• Bug fixed: Fixed crash caused by missiles colliding in deathmatch games. Thanks for the report, Nick.
• Bug fixed: Data directory was not created properly in some Linux desktop environments.
• Bug fixed: In Co-op game, pressing fire to launch a ship would exit level if another ship had already exited.
• Bug fixed: First level was not always being unlocked.
• Bug fixed: Fixed rare premature level exit.
• Improved terrain following algorithm for all walking enemies, such as Thumpers. They now creep around sharp corners more reliably without falling off terrain as much.
• In deathmatch, other players’ missiles now target you after you spawn a ship instead of before.
• Removed end-of-level bonuses from Deathmatch games. The current set of bonuses don’t make sense in the context of Deathmatch competitions.
• Refined art pipeline, improving some art assets and boosting performance about 10%.
  Refined terrain tiles and many other models.
• Added more depth to levels; the added parallax helps distinguish the foreground from background.
• Added fullscreen switch to Settings menu.
• Animated shootable buttons.
• Now high scores are recorded for any player that earns one in Co-op games instead of only Player 1.
• Added multiple high score charts to differentiate between solo, cooperative, and various difficulty levels.
• Improved GUI navigation with arrow keys.
• Removed “ramp” sliders for joysticks, as they have not felt useful on any sticks tested so far.
• Added workaround for bizarre fullscreen window clipping behavior when using DPI scaling in Windows Vista, 7, and 8. Nice discovery, Joe.

Since the release of the first version of the demo, most of my time has been spent on the full game rather than this demo update. In addition to the changes you see above, I have worked on designing and prototyping levels, creating new enemies and other game entities that appear in later levels, finalizing the art pipeline, improving many art assets, and creating a new art style for levels at the end of the game. I’ll post more about that stuff later on.

Oh yeah, and I got a Twitter account finally. It will probably get more frequent (and much smaller) updates than this blog, plus random weird stuff. Follow me at @TerryMWelsh.

The Indie Games Channel picked my brain about Retrobooster a while back. Now they have posted this article that talks a bit about my vision for the game and how I go about making levels. Thanks for the cool write-up, IGC.

Retrobooster just showed up on Penguspy. And with the Pengu Choice award! It’s great to see the Linux gaming community keeping an eye on this game. Thanks, Penguspy.

Stefan LeBlanc contacted me a couple days ago asking about Retrobooster, saying he wanted to write an article for Examiner.com. Well, he is very fast, and here is the article.