Orbit One Dev Diary #3: Bringing Sexy Back (and Obsessive Tweakery)
29 June 2010
I spent the following week working on the visual design for Orbit One. This was quite important to me, because visual design and usability are near and dear to my heart, so I really wanted to go all out.
[9:17pm] I've got some sketches done, now I'm just trying to put it together on Inkscape and into the game.
Listening to Thunder, Lightning, Strike / The Go! Team
When I got started on Orbit One I had a very clear view of how I wanted it to look:
very minimalist art style, a bit like wipeout zone mode theme'd colour schemes, random each game maybe transition colour over the time of the game BOLD typography players: cyan, magenta, yellow, white pickups round, enemies angular, powerups???
Not all of that made it in, but the basics (clean lines, smooth curves, bold typography and minimalism) are definitely evident in the final product. A variety of colour schemes and transitioning colours would have been cool, but there just wasn’t time.
Note how I created a visual language for the game. Apart from pickups being green and enemies red, I’ve added an extra visual indicator: pickups are round, smooth shapes and enemies are angular. Never had to figure out what to do with powerups. Also, I hope somebody appreciates the graphic nerdery of colouring the players CMYK.
Work continued as I experimented with design, agonized over typeface selections, and of course, added awesome special FX.
[12:57pm] Continuing to work visual design and extra polish. Spent yesterday getting a lot done, and pulling the Fireworks module in from DUOtrix to help out. Just bought a typeface, Tenby Four, to get the rest of the visual design done. Hopefully tonight or tomorrow?
Listening to
You’ve Come A Long Way Baby / Fatboy Slim on – get this – compact disc! I realize that I totally forgot to rip this onto my iPhone. For shame!
Even with a clear concept in mind, visual design takes time. Just like game design, graphics need to be designed, tested, tweaked, and redesigned. And just like game design, when it finally works, when the aesthetic clicks into place, it’s oh-so rewarding.
For Orbit One, it clicked after a week.
So I spent most of last week working exclusively on graphics. That was a lot of fun!Basically, I wanted something beautifully designed, a very modern look, and also very readable. I think I finally achieved that, and am really happy with the results.
With the game playing well and looking good, it was time to test it on friends. This is always a bit horrifying. It’s a bit like getting up on stage and showing your work to a large crowd. Except the crowd needs to interact with your work. And is more than happy to rip it to shreds. Thankfully, it went really well.
Last night I did focus testing on my game. (http://twitter.com/caffeinemonster/status/7589501477) Seriously, it was pretty win. People played singleplayer and multiplayer, and both seemed like enjoyable experiences ... they (and eventually, we) must have been playing for an hour or so. Yeah, so that went well.
With all the positive feedback came a tonne of negative feedback too. This is a good thing, it means they played the game long enough to spot some pretty subtle issues with the game.
As an aside, this is how insane balancing a game can drive you: I decided to change the distribution curve for orb/enemy spawning, wrote code to generate heatmaps to test my theories, and then played the game like crazy to see if my various hypothesis were true.
[2:51pm] Messing with the distribution of enemies/pickups over the map. Yes, I'm getting into obsessive compulsive territory here.
Comparing the old (left) and new (right) distribution algorithm. At a first glance they look pretty similar, but the new algorithm spreads things more evenly the further you go from the center of the arena. In particular, the inner ring is far less dense, and edge of the arena is filled a bit more.
A friend (who took part in the testing) started obsessing over balance with me. This is always a bit dangerous. Balancing is a tough job, and most people tend to take the “big sweeping changes” approach as opposed to my “slow methodical changes” approach. There’s also a tendancy to suggest knee-jerk reaction fixes. That is, a fix that would benefit themselves without thinking of the overall consequences to the game. Still, it’s important to listen, but it’s even more important to know when to listen.
Many suggestions were made, discussed, implemented, and ultimately discarded. But at the end of the day, we came up with a single, rather important, tweak.
[2:30am] Figured out some good stuff today. Playing the game with a friend/one of my testers, we started tweaking the code around while playing. A tonne of bad ideas that only experienced players would come up with, but a really nice one too: a slight boost coming out of a turn. Makes the turn smoother, which is great, because currently it's a bit draggy.
What I didn’t realize at the time is that the boost was also a great feedback indicator. Because the turn happens quicker there is less latency between “held the button down” and “see the ship turn.”
Things continued to move along at a brisk pace. This created long changelogs filled with seemingly minor tweaks:
[10:20pm] - added overdrive when changing direction - player trail is shorter - smaller blackhole radius - increased low time warning to 45s - tweaked spawn clip - tweaked spawn position distribution - tweaked spawn distribution - new players can join during the starting countdown - bigger, move obvious player shields - pickups blink for 3 seconds (not 2) - added a big try/catch error block around the whole program
That’s what great about the tweaking and balancing stage. You end up making a tonne of small changes here-and-there that add up to far more than the sum of their parts.
Almost there now.
leave a reply