Maestro

Maestro is a crappy tech prototype.

What it will be is a music game that is designed to let you dance with your mouse cursor. I should explain. Audiosurf is a game that takes your mp3s and creates a game level out of them that functions as a sort of action puzzle rhythm game. I like Audiosurf, but I'm upset the fact that I can't hit all the notes and succeed. The player has to strategize frantically on most game modes, and even with the simpler ones you can't just groove out in the game. Maestro is an attempt to create a game that also uses your mp3s to procedurally create levels, but simply asks you to move the mouse around in a way that matches the music.

Another source of inspiration for me was the strange phenomenon of dancing. I hate dancing as it's most often described, depicted, and seen. But I love drumming my fingers, bobbing my head, tapping my foot, and singing along to music. If I really really get into a song, I'll gesture with my hands, moving them around with the action of the song. So I figured that I could just have the player move the mouse in a similar fashion and get the feeling I was going for.

I've had this idea banging around in my head for a while. Now that I've finished Meridian, I figured it was time to see if I could pull together a fun prototype.

So far, I'm just working out the technical details. I can load up a WAV file and display the volume in synchronization with the song, and I can measure mouse movements and graph them in real time. I'm currently experimenting with different systems for smoothing out the different waveforms.

This is a picture of one of the earliest working prototypes. The top line is mouse speed data, the middle is a smoothed version of the top line, and the bottom is mean volume data for the WAV file. The song is Girl by Beck.


Here's a slightly more developed prototype, a few hours later, using the same song. Blue is smoothed audio data, light red is mouse speed data, light blue is adjusted audio volume data, and the last line blends the previous two.


As is mostly evident, I have a lot of work to do before this gets to a satisfying state. If I can make Maestro work well, then I'll redo it as a full production, with fancy particle effects and changing colors a la Audiosurf.

Meridian Retrospective

Today, after a four-month development span, Meridian was finally finished.

I wrote previously about its conception and evolution, but there's still room for the typical postmortem analysis.

It was my first project using XNA and C#, and I loved them both. Partially it's just that I'm a fan of Visual Studio C# Express, but really, everything was so easy. Once you spend an hour or two learning the basic setup, all there is to do is implement game logic, i.e. the fun part. I decided to add sound very late in the project, and XNA made it very easy. A++ would program again.

The art in Meridian was a huge step up from that in Asp. That's mostly because I didn't draw anything from scratch (except for the gates-- the worst sprite in the game by a long shot). For the backgrounds, I did what I usually do: find a cool image (thanks NASA!) and then play around with the filters in the GIMP until it looks cool. Those who know the program will note the use of the Waves and Starburst filters all over the place. For the fleet images, I found a free 3D model of a spaceship, loaded it up in Milkshape 3D, and took a screenshot of it. I also took a couple of perspective shots for use in the victory and defeat screens, which I think turned out very nicely.

I still had a single huge code file (over 3500 lines), but I used Visual Studio's #region tag to make it nice and collapsable throughout, so it never really hindered me. My commenting practices were as nice as they've ever been, and I never made any huge programming snafus that I know of.

But of course, it's design that really counts. The high-level design of Meridian changed very little. That is, I stuck to the original vision. But I had to make a lot of small rule changes in order to make that vision work.

One nice thing about Meridian is that the game states are very distinct in comparison to those in Asp. This meant that there were very few situations in which the game wasn't playing as I intended it to. One consequence of that, of course, is that the flaws in the gameplay are completely my fault. I can't blame this one on technical problems or anything like that.

The biggest problem that Meridian has is that the AI is forced to stay limited. I added boosts to break the inevitable stalemate of both sides avoiding each other. For that to work, the AI can't take boosts into account when considering which hexes are safe from attack, lest we run into the exact same problem as before. So they totally ignore defence from boosts, and suffer for it. The AI is also very vulnerable to the poisoned pawn strategy; it will take whatever it can get.

That's the primary reason I decided to include difficulty levels. I knew that once the player solved the AI puzzle, they'd have to start with a disadvantage to have an engaging experience. I know that Dice Wars is fun even after the player has solved it, and Meridian also uses randomness to provide basic variety, so I have hope that the game can stay fun.

Lastly, I'm very happy with the saving system I used. Because the game employs randomness, players might be tempted to revert back to an old save in order to get good outcomes on every chance they take. To ameliorate this problem, I only allowed one save, and the save updated after each turn and each time the player exited the game. This has the disadvantage of only allowing a single game to be active at any time, but I consider that acceptable in a game of this scope.

Commentary: Left 4 Dead

Raph Koster advises game designers to figure out what a game is about and then do nothing that would detract from that focus. I think that the developers of Left 4 Dead took that to heart. Every single aspect of the game system contributes to the creation of the best cooperative gameplay experience I've ever had. I'm a huge fan of pretty much any co-op experience, from side-by-side Gears of War battles to RTS comp stomps, but L4D easily takes the cake.

The general difficulty with co-op gaming is making everybody feel important. When there's a bunch of players fighting an AI, it's difficult to feel like your contribution was necessary. L4D gets past this by making it genuinely necessary that all four players work together (at least on the higher difficulties). If one player runs ahead, he will quickly get incapacitated or mobbed by zombies. If players don't stay conscious of each other's position, they'll end up losing due entirely to friendly fire. If players don't collaborate to use their resources effectively, they'll never make it past a end-of-campaign finale.

L4D does some cool things with the level design and art direction, but I think that the gameplay is its real strength, and the game stands as a testament to the idea that doing one thing and doing it well is a ticket to success.

Breaking the Sound Barrier

Meridian will be my first game to feature audio.

When I made my previous games, audio seemed like a wholly unnecessary feature. I originally chose to include it just to get some practice and to give Meridian a consistent level of production. Now, after hearing the game in action, I'm starting to realize what I was missing; I'm starting to get why Greg Costikyan wrote that Asp's nonexistent sounds "are sorely missed".

The most immediate and obvious benefit comes with interface design. By using sounds for multiple events, I can indicate the connections between them. When a fleet enters a transportation gate, when a solar system spits a fleet out through a gate, and when the rally point for transportation changes, I use the same sound cue to show that it's really the same event (interstellar travel). Battles are easier to follow when there's a sound during each attack and upon retreat. When players select fleets by different means, the sound lets them know what's going on.

Then there's the background music. I spent some time looking through a few albums of Creative Commons-licensed music and found some great tracks. I don't know how they'll hold up over the long term, but just during the short games I play for testing I'm finding myself more and more engrossed. The atmosphere conjured by the sound effects seems to be just as important as the graphics'.

I'm applying the same learning process to Audacity that I used with GIMP: play with all of the options until stuff looks/sounds good. Hopefully I'll be able to do some decent audio editing on future games. Certainly anything I build beyond a tech demo won't be silent.

Evolution of Meridian

Meridian is nearing completion. Just menus, game saves, and polishing left to do. Now is as good a time as any to share how the game idea came to be.

I'd like to think I was originally inspired by the idea of a game set along a single line of battlefields, with those further back supporting the troops at the front, but in fact I was inspired by the title Meridian. It's a really cool word. Sorta like "asp".

Originally, a major part of Meridian was going to be managing public opinion on your home planets. You'd have renewable and nonrenewable resources on each planet. Using up nonrenewable resources hurt public opinion, unless they were near the front of battle and desperate. Losing and winning battles both caused the people to clamor for war (either for further victory or for revenge). If your people thought too little of you, you'd be kicked out of office and lose the game. Perhaps opinion would also affect your industrial efficiency. I also toyed with the possibility of having the option of negotiating for peace with the enemy leader, but your people would always prefer that you scorn peace and fight for glory. Peace was difficult, but the only real winning option. It would offer a (simplistic) message through gameplay.

But as I thought about the actual battle system and simulated the ruleset in my head, I came to realize that the whole public opinion aspect belonged to a different game. Meridian was, at its core, a game of managing resources and pushing an enemy further and further into a corner. Perhaps later I'll make a diplomacy game, but this is not it.

Raph Koster advised designers to figure out what the game is about and then do nothing that does not support that core game. I decided that Meridian was about "pressure": you had to methodically push back the enemy forces while they tried to do the same to you. If you push them too fast, they'll summon reinforcements in order to ensure a fighting chance. I wanted the feeling of a slow but desperate arm-wrestling match. More and more pressure until one side broke.

The basic setup was easy to imagine. I love hex grids, and the organization of forces into fleets of arbitrary size was fairly simple. I originally thought that you'd set a certain "tactic" for each fleet that would affect when they would retreat from battle, but I quickly discarded that idea and handed retreating control to the player. During the first few weeks of development I would lie in bed and imagine the game being played. I discovered a whole slew of small refinements were necessary in order to get the game I was hoping for. One critical aspect of the gameplay was hit and run attacks. Smaller fleets needed to be able to chip away at larger fleets in safety. This required that fleets be able to retreat, have the capacity to move two spaces in one turn on occasion, and have an initial first strike before the retreat. The battle system had to be just right, and it took me a while to figure out the current system.

The game takes place on only one solar system at a time, trying to fight towards the more distant systems. Originally, moving from system to system was originally going to take several turns, and both sides would bide their time before invading a new system (which might have made for an excellent interest curve). With this setup, the newly built ships of the losing side could get to the active solar system faster (since it was closer to their home systems). In order to turn this into a true advantage, ships were given an accuracy rating to represent how effective they were at destroying enemy ships. Newer ships had better accuracy ratings than older ones, so the losing side would have the most modern ships in play.

Later in development, I decided that having interstellar travel take time was not very significant from a gameplay perspective. The accuracy difference barely made a difference at all, since there were so few new ships in comparison to the total number of older ones. Instead, I went with the system that was easiest to program: interstellar travel is instantaneous and only takes place when ships are built. If I needed to, I could justify this with in-game fiction, but Meridian is not much story-based, so I didn't bother.

It wasn't until a few hours ago that I realized that with this simpler system in place, there was no longer any reason to maintain the changing accuracy ratings. Their main influence on the game was to clog up the UI with hard-to-understand percentages. If I just keep accuracy ratings static, the only important information to show in the UI is fleet size. I should be able to really clean things up.

There were a lot of other design changes during development, of course, but these were the most drastic and/or instructive.

Meridian: Coming Soon!