SWIFT*STITCH post-mortem

Posted: January 10, 2012 | Author: Sophie | Filed under: Game stuffs, Post-mortem, Swift*Stitch | Tags: post-mortem | 18 Comments »

So then, I think it’s about time I wrote this. I was going to wait till after this week’s sale, but I got pretty upset about the game today and couldn’t hold myself back on twitter, so I have some explaining to do I guess 🙂

so then, let’s start with my tweets;

• “was not expecting anything to happen with Swift*Stitch at IGF, so I’m not fussed it wasn’t a finalist. I am upset however…”
• “…why the fuck did I spend that long working on a game I didn’t think could become a finalist? I must be an idiot.”

first, biggest disclaimer (since heated discussions involving IGF get controversial quick); I am very happy with Swift*Stitch not being a finalist, have you seen the games that did make it? Swift*Stitch does not deserve to be a finalist. The IGF is super cool and the finalists this year are super cool.

So, why was I an idiot to work on Swift*Stitch?

as many people pointed out to me on twitter, sales, awards etc aren’t what is most important, what is important is working on a game you love and having fun doing that. In this sense, the game is a success. I love the game, I love how it turned out, I had a brilliant time working on it (mostly, detail further down), I love the music Aeronic put together for the game and I like all the nice things people have said about it.

In this (most important) regard, Swift*Stitch was a success. but I knew, the entire time I was working on it, that the game probably wouldn’t sell well. For a game I was working on with the intention of paying rent from sales, this is where I’m a total, complete, idiot. I have no shortage of games I want to work on, I would enjoy working on them all, but I was broke and I needed to pick something I could have fun making AND could sell. Swift*Stitch was only ever a game I could have fun making, and maybe could sell maybe if something maybe maybe. not a good choice. I haven’t paid rent in over a year now. I needed to work on a game that had some commercial appeal, I have games that could have fit that bill and been fun to work on, but I didn’t make them, I made Swift*Stitch.

and that choice, even though it resulted in a cool game I’m happy with, was a mistake. because it puts my chances of making other complete games in jeopardy.

 

However, whilst Swift*Stitch was the wrong choice, I learnt a ton working on it, so lets get this post-mortem going properly shall we? 🙂

Swift*Stitch started out life as an entry to the GAMMAIV event called “ZAGIZIGI” (which you can play by clicking hyar!).  if you compare ZAGIZIGI and Swift*Stitch (link to Swift*Stitch demo in case you haven’t checked it out yet) you will see that the core of the game is pretty much the same. the control hasn’t changed, even the colour of the lines you cross to change directions is the same.

where the games differ though, is visually, in scope, and in polish. ZAGIZIGI has a story and 3D graphics when Swift*Stitch has no context for the events of the game, and minimalistic graphics built with just hard pixel lines. ZAGIZIGI has 5 levels (I think, been a while lol) and 1 game mode, where Swift*Stitch has 42 levels and 3 game modes, as well as achievements, and bonus options to change how the game plays. ZAGIZIGI was made in 2 weeks, Swift*Stitch took 5 and a half months.

Ultimately, the main point of deviation from zagizigi when I started work on Swift*Stitch, was precision. I wanted the game to look crisp; no ambiguity, no clutter, nothing distracting. and even more than appearance, I wanted the control of the game to be precise.

how precise did I want the game? well, a little way into development I noticed the input was a little laggy for the game at high speed. the reason? I was checking for input every time the game rendered a frame. and checking for input 60 times a second was TOO SLOW. so I tore apart the game and changed it so every input was recorded independantly of the frames, complete with the exact moment the input happened recorded too. this also made the game 100% framerate independent, something I’d managed to avoid having to do properly before. now, instead of the game ‘happening’ every time the frame was rendered, the game was constantly happening in realtime, each new frame was just a snapshot of what was going on.

Ultimately, this meant if your input was faster than the framerate, the game handled it perfectly. you press and release the control before the frame is rendered, and your ship still moves correctly, and precisely how you told it to.

With this, mostly I wanted to be able to make the game as cruel as I wanted. by removing things people can blame when they crash (laggy input, distracting visuals etc) a game feels more fair, and people are happy to own up to their losses. it’s “omfg this isn’t fair I pressed it at the right time!” versus “Aw Crap, I gotta press just a little later than that next time”. When making a skill game, you can’t punish the player for anything outside of their control. so I did everything I could to tie the game to the user’s input, and remove anything that could result in them failing through no fault of their own, or compensating for it.

Something else I wanted to do to distance the game from ZAGIZIGI was to add more types of line to cross, this resulted in the ‘arc’ lines and the teleporters. the addition of which provided a bunch of extra little nuggets of gameplay fun I hadn’t even considered when combined with the already existing rules of the game, and these make up no small part of the later levels.

Also added early on were particles when you grazed along a wall. this is just one of those things that felt good, so it stayed in the game. the shinies were also like this, though with the addition of survival mode and medals, they became tied more closely to the gameplay.

one of the last big decisions turned out to be, just what the game was. early on levels were scored by how quickly they were completed (which, due to the way the ship moved had no correlation with just how well the level was played) and some levels where the goal was to just keep doing laps until you collected all the shinies (which, was just plain boring).

I tried various ways of balancing the score, subtracting crashes, multiplying by shinies and various other math stuff, but it never felt like score had any relationship with performance until I kicked completion time out of the equation. and after doing that, it didn’t take long to see that I should just award completion, shiny collection and not crashing independently. it was more fun since you could focus on one thing and not be punished for disregarding the others. I liked this ability to choose how you wanted to play the game, so I kept it in, from the unlimited slowdown option, to being able to skip to any level, any game mode, any speed setting. I’m pretty happy that players can just play the game in whatever way they think is the most fun, something these crash-a-lot, arcade-y, reaction type games normally don’t do.

for the game’s music, I trawled through my collection of musicians who had emailed me samples before, and Aeronic jumped out at me, I had already been impressed with his work (especially some of his nujabes-sounding stuff, tasty!) so I shot him an email and we got to talking. In the end he is a total dude to work with and made an AMAZING soundtrack (which you can totally listen to and buy here). The game’s music is one of it’s best features, and when people do talk about the game, it’s rare for the music not to get some love.

but development wasn’t all accidental coolness, science-y game design and feature tweaks, there was some serious grind. Swift*Stitch is my first finished commercial game, and probably the only game I’ve spent more than a couple of months on that has actually been finished. Suffice to say, I didn’t have the skills to finish a game when I started it. I thought I did, but that was me being an idiot again. Whenever my someone would ask “what bit of the game are you working on today” they would often get the same response for weeks in row, each time with my face a little more tired. sometimes these would be things that just took a really long time (making menus, tutorial and achievement icon art) or bugs/glitches I couldn’t track down. There was one particular bug with the arcing I spent a lot of time trying to nail, and thought I had it fixed a few times, I’m pretty sure my housemates were sick of me talking about it lol.

ultimately though, after a lot of “naw, I got stuff done yesterday, I can have today off” and “there’s nothing to do until X is complete, but I’ll do X later” I finally managed to become the kind of person who can finish games. basically it comes down to making lists of what has to be done, and doing it no matter what. I’d only take a break if I’d been productive enough to not feel guilty for taking a break, and that got me through the bit that people who haven’t finished a game call the last 10%, and the people who have finished a game call the last 90%.

Finally, something I did with this game that I had never done before, was get serious about testing. I would normally just test a game myself, or give it to a few other people I know are good at finding things I’ve missed and that’s exactly how I did it with swift*Stitch for the majority of development. but I knew this was my first finished commercial release, better safe than sorry and all that. so I ‘finished’ the game, and then put it out for beta testing, just in case I’d missed something.

HOLY FEEDBACK BATMAN.

sooo much feedback, SO MUCH! I was swimming in it, there were a couple of bug reports as expected (yep, that arcing bug came back, much to the amusement of people who frequently asked what I was working on), but mostly the feedback.

at first, I hated it. for a good… five, maybe ten minutes, my thinking was “wtf, it’s not broken, I don’t care” but by the eleventh minute I came to my senses. most of the feedback was super useful, and I made tweaks to the game based on it that made the game so much better. one of the biggest complaints, even amongst early testers was that it was hard to know which direction you would go when you changed, the arrows were too small to see. but someone suggested maybe I have guide lines on all the time, not just when arcing. MY MIND WAS BLOWN. so simple, fixed the problem, looks cool, NEVER EVEN OCCURRED TO ME BEFORE.

and there were a bunch of other teeny tiny things that meant the finished game is so much more polished than back when it was pre-beta and I *thought* it was finished. testing worked wonders for Swift*Stitch.

 

…

 

and that’s pretty much all I have to say about that right now. the game may have been the wrong choice of project but I had fun, I learnt a lot (especially about finishing games, and self-control) and I’m really happy with the game too. 🙂

 

---