SWIFT*STITCH post-mortem

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.


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. 🙂


18 Comments on “SWIFT*STITCH post-mortem”

  1. Dan Silvers says:

    Sophie, great post mortem and a FANTASTIC GAME!

    I would like to give you one piece of feedback though: get the game up on Desura. As it is, it’s only available on your website, which will make it only visible to people who know your website, which in the grand scheme of the internet isn’t that many. If you need to make some rent money off of it, you need to expose it to a greater audience, and the indieDB/Desura audience is fantastic, helpful, full of feedback, and most importantly is always willing to help indies out. You could probably even talk Scott and Dave into letting you run the same kind of sale you’re having right now! They’re really cool guys. It’s a huge community that you NEED to tap and I guarantee they will welcome Swift*Stitch with open arms.

  2. Fin C says:

    This is really interesting to read, thanks Sophie. Would you consider collaboration for your next commercial game (and there will be one!) if the right project came up?

  3. Sophie says:

    @Dan Silvers: Desura is totally on my to-do list 🙂

    @Fin C: I’ll consider anything, and my email inbox is always open 🙂

  4. A very interesting read! Especially the framerate-independence/precision control stuff. That was really clever!

    I’m interested to know why you feel the game isn’t commercially promising though. It’s certainly original enough, has a unique look-and-feel, and is visually identifiable. I’m sure there’s a lot more promotion of it that you can do – you just need to find its USP and push that more. Make it clearly identifiable why people should be excited about your game. This is still early days, surely!

    I’m interested to know what you feel would have better commercial appeal tbh.

  5. Keeyai says:

    Great post Sophie. Don’t discount how incredible it is to have finished a game at all, let alone one that you can be proud of! Lessons learned, portfolio padded. I’m excited to see what comes next.

  6. ratking says:

    Now the real question is: What would have made money?

    … it’s something I couldn’t find out yet, even with two finished games on the AppStore. Trying to sell games really is disillusioning, especially with the mass of free games as your competition. 😕

  7. binary_girl says:

    argg i wrote quite abit bit it didnt submit ‘database error’ ;( anyhoot amongst other things in short i just wanted to say your an inspiration 🙂

  8. st33d says:

    Personally I thought it was good, but the demo was too long to encourage me to buy it and the progression spiked a bit awkwardly (pot calling kettle I know).

    I’m surprised it didn’t sell as well as expected though.

    Also: What happened to that game where you could run around walls? It was like a 3D version of a game called Headcase I did (where you could run around walls and leap off them). I quite liked that one.

  9. […] really enjoyed Sophie Houlden’s post-mortem of Switft*Stitch, and the things that really hit home for me was the following comments: “Swift*Stitch is my […]

  10. ErdTirdMans says:

    You may have spoken too soon, Sophie. Swift*Stitch is making the indie game blog rounds now. Maybe it was delayed by the holidays?

  11. Kevin Wells says:

    Very good read, quite inspirational! Thanks 🙂

  12. Ruber Eaglenest says:

    You should also pursue sell the game in the appstore and android market. It seems a perfect design for mobile devices and tablets.

    You could upload the demo at Kongregate too.

  13. First, thanks for posting this. Finishing a game is so very important, and I tell that to people who ask me about making games. It’s great to have someone else’s experiences posted to refer to (I’ve already used it as a link to someone for that purpose!)

    BTW, I was at Terry Cavanagh’s release party for At A Distance and heard afterward that you were there. Wish I had known, would have loved to said “hi” in person. Anyway, keep up the good work!

  14. st33d says:

    @Anthony that’s the one. Why isn’t it listed on the games page on this site? It’s a good game (maybe needs polish, but I’m not that fussed). I thought the level select was pretty clever too – actually being skilled enough to select level 10 is a good idea.

  15. Ilya says:

    Enjoying the game, feels precise & smooth & fair & fun.
    Thanks for the write-up.

  16. Dmitri says:

    I just wanted to say HUGE PROPS for doing that whole real-time input, independent from rendering thing. That’s awesome. I really hate it when developers bottleneck things at 60 Hz for no good reason (like not realizing/understanding the benefits of 60+ Hz, especially when it comes to twich-based skill games).

    One big offender off the top of my head is Super Meat Boy and it being locked to 60 Hz even on monitors that have higher refresh rates.

  17. […] “… 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” – [Author's Postmortem] […]

Leave a Reply

Your email address will not be published. Required fields are marked *