Years ago as part of my Science Communication MSc I made a card game, and had the time of my life doing so. Several years into a normal job I realized that I really wanted to give game-making a go, so quit my job to spend more time doing it.
I made a couple of web games but being a PC gamer wanted to make one of those. S.O.R.S was that game, and now it’s done, I wanted to write about my experience in case it’s useful to anyone else out there.
A couple of points to note first though:
1. Everyone’s situation is different. What worked or didn’t work for me may be different for you.
2. A lot of these points are echoed across countless other game dev articles and retrospectives, some of which I even read whilst developing S.O.R.S! Alas, sometimes the best way to learn is to make the mistakes for yourself.
What went well
1. I made some sensible decisions at the start of the project
No-one ever made friends by saying things should be more complicated, but people love it when you try and make things simple.
Some of the most important decisions you make will be when you’re just starting out, because they will affect the shape of your game to come and lots of other factors. There were 2 that I made early on that I think were good ones:
- I made a 2D game rather than a 3D game
- I used Unity and coded in C#
In other words, I made things simpler for me, and my brain liked that, so he stuck around for the project.
The first decision meant I didn’t have to worry about things such as 3D modelling, 3D worlds or even the Z-axis (well, much). As a beginner programmer I needed to make things as simple as possible if I was ever going to finish the game, and this decision really helped.
Using Unity and C# helped because they are both widely used and have great online communities, meaning it was easier to get help, especially useful given I was coding this project solo with no tutors or guidance except the internet (and some books).
It almost goes without saying that the other benefit of using Unity is that it takes care of a lot of stuff for you – it’s a ready-made game engine. Now I know more about game development I’m truly thankful to have something like Unity that can deal with fundamentals and let you focus on scripting your specific game behaviours.
2. Building a game and learning to code worked well together
The great thing about building a game is you come up against very specific problems, and solving these is a great way to learn about coding. Just reading about coding without using it practically is like thinking about what you need from the grocery store without actually going there.
I gradually settled into a cycle during the game which roughly was learn -> code -> learn -> re-factor. Although I didn't re-visit my old code as much as I should have (see below), I did a bit and that helped broaden my C# skills.
Comparing my past attempts to learn programming, having a personal project I was passionate about really helped me learn.
3. Releasing early demos helped highlight some key issues
I could have done more to build a community and market the game earlier on (see below), but just having a few early demos released really helped identify some key issues.
For example, initially players had to type full condition and treatment names in order to select them. Imagine that! At the time I thought it added to the atmosphere and feeling of being a doctor in control of a new futuristic technology, but it quickly became apparent that this was just annoying. I implemented the shortcut of using numbers, and people stopped complaining!
No honestly, it’s really fun having to type that all out every time!
The place I used most for demo feedback was the Indie game reddit thread ‘Feedback Friday’. Check it out, there are some great games there and it’s a really good, positive space for getting feedback.
And in case you’re worried, no-one ever wrote ‘your game is shit’. So now you don’t have that fear as an excuse ;)
4. I accidentally did a soft launch which helped build the game's profile
So here's what happened - I finished the game, launched it, sold a few copies, did some PR, got some reviews and videos made, and then went on Steam greenlight and made it through.
I'd like to say this was all planned but it wasn't - my inexperience in game dev was really showcased in what turned out to be a nice blind (possibly drunk) walk down release alley.
This 'soft launch' helped build the game's profile for the Steam release, and whilst overall PR and marketing for the game were a bit of a failure (see below), this initial release helped get feedback and gather interest.
5. I listened to feedback
One of the greatest (and most unexpected) challenges in making the game was listening to feedback. Which bits do you listen to? Which bits do you ignore? I wish I could share with you an all-powerful formula for getting this right, but I lost the unicorn I wrote it on.
I looked at how many people mentioned the same bit of feedback, but I also used my gut – there were times when I read someone’s feedback, thought about it, and said to myself ‘you know what, they’re right’, and I knew the change had to be made.
Either way, listening to this feedback definitely helped make the game better and it’s a great, vital skill I will keep working on.
6. I got to mix games and science
I believe that games make the perfect vehicles for communicating science, especially to new audiences who perhaps don't engage with science much. It was my passion in this belief that sparked off this journey in the first place, so getting to mix science and game development was a real joy.
I really relished the challenge of looking through scientific papers and translating their findings into game mechanics, and I'm already looking forward to doing it again!!
This graph inspired the shape of the in-game breast cancer graph. From: Matousek & Stone, 2013, ‘Recent advances in the development of Raman spectroscopy for deep non-invasive medical diagnosis’
It’s always easy to take (positive) stuff for granted, so I wanted to mention this point explicitly because when all the smoke clears it’s important to remember why you were doing it all in the first place.
6. I outsourced
I'm no artist, so I didn't even try and do the art myself. I found an artist, James, via DeviantArt and was lucky that he was a great artist and a joy to work with.
I found a UI artist, Stan, via twitter and his online portfolio. Again, he was a joy to work with which helped ease the stress on me immensely.
When I started off working with these guys I made sure the initial work packages were small, which helped me make sure they were good to work with. It also showed them I would make payments on time and was good to work with too. This approach meant trust was built in both directions.
The downside of using contractors is that it costs more than doing it yourself. If you do work with them, I'd recommend starting off with small work packages so you both get used to working with each other and the stakes aren't so big if you face issues.
For music I used the site iLicenseMusic, which I found out about by reading about Braid, which used that site and had great music. It's a fantastic site and allows you to get high quality music for a very reasonable amount. There's a huge breadth of music on there too.
7. Going to science and game fairs let me see how players interacted with the game
There's nothing really like watching someone pick up and play your game without any prior knowledge. That advice is on the internet in plenty of places, and for a good reason - you learn so much by just watching people play.
Our typical game & science fair setup – although we tried to have 2 demo PCs for players where possible
I can sum these revelations up into 2 broad categories – ‘stuff you'd never thought of’ and ‘differences in interpretation’.
I'd never thought that having the scanner reticule in earlier levels where there was no scanning (just an earlier game mechanic involving reading patient history) would be confusing, but when I saw the player's faces it was so clear! Of course that would make things confusing – why is the scanner there if it’s not used for anything? Duh. I got lots of these revelations, and all of them made going to the fairs 100% worth it on their own.
Interpretation was important for S.O.R.S because its mechanics rely on text and diagrammatic instructions to the player, so these had to be clear. Watching people interpret these helped me refine the wording.
(NB: I wrote a mini-retrospective about our fair experience here)
7. I gone made a game, ma!
The big one….if I had to choose one point off this list, this is it. There is so much stuff to think about when releasing a game that you don’t realize until you go through it (and are getting people to pay for it).
Charging for the game made me go through everything and ask – is this going to be a bad experience for the customer? For example – have I chosen the right save game mechanism? Have I found all the bugs I can? How will I manage updates?
This was a huge project and challenge for me, but to develop a proper video game and release it on Steam feels great, and I guess as with any creative endeavor, finishing something you’ve spent so long on is truly satisfying.
What didn’t go well
1. PR didn't really work and was done too late
One thing I got really good at during development was reading advice online then ignoring it. In fact, I think it might be a special skill of mine. Hopefully if you're reading this you can be smarter than me and heed my words.... marketing your game is everything.
The week before Steam launch, I sent about 30 emails to online review sites and about 50 emails to youtubers/twitchers.
From the 30 press emails I sent (which contained steam keys), I got 4 who actually played the game, and zero (!) new reviews....so I had to rely on reviews from our earlier launch.
I think with the sheer amount of emails these journalists get / the number of games coming out these days, you need to have garnered interest in your game way before launch date. Relying on the press to pick up your game fresh from a review request feels like a game of russian roulette, and we all know the odds aren't good in that, right?
The youtube route was more successful, with at least 15 youtubers featuring the game (those are the ones I know about). My advice for this channel is (again, not new advice!)- focus on smaller channels: people with 20, 100, 200 followers are more likely to cover your game and any exposure is good publicity. Don't get greedy about which youtubers to spend most of your time marketing to.
Perseverance is also key – there’s a huge number of youtubers out there, so get your hands on a list and work through it, and maybe you’ll have to email them twice before you get a response; so get some music, some coffee and crack on!
2. By the end of the game I had spaghetti code
Spaghetti’s great to eat (if cooked well), but it’s really annoying in code-form; it’ll give you a bigger headache than babies on a plane.
Coding really is a balancing act between writing fast code, extensible code, and efficient code (known as the 'coding triangle').
I can safely say I stayed very much in the 'fast code' corner - ie: I wrote code to do something and never really thought about anything else, which probably isn't surprising given my inexperience.
I got lucky in that S.O.R.S isn't a graphically intensive game, so performance was never too much of an issue.
Dual graphics cards optional
However by the end of the project making changes to pretty much any area became a long process, and if I'd planned my code a more before writing it, I'm confident this would have been easier.
3. Game mechanics at the start were the worst kind - open to interpretation
Fun fact - I got the idea for the 'lifestyle advice' mechanic when thinking about 'insult sword fighting' from the Monkey Island games. During development I read an interview with one of the original devs of that series and he said they were bad mechanics, because there was lots of guesswork for the player. And I didn't change the lifestyle advice mechanics! What a noob.
I've since tweaked lifestyle advice so it's at least more obvious, but looking back it was one of my worst decisions to have the first core mechanic be based around guesswork, and I'm confident it's put lots of players off the game.
Kids, make sure your first game mechanic is a good one that hooks people into your game!
4. I got no tangible follow-throughs from game fairs or science fairs
The only thing of value I got from these fairs was the feedback from speaking to, and watching, people who played the game. What I didn’t get was any tangible ‘follow-ups’ or similar.
I didn’t make any new contacts (it’s a skill I need to work on) although I did collect quite a few business cards, and whilst I had people take an interest in the game, I never had a way to retain their interest (Eg: through signing up to an email list).
I definitely need to improve this for future games – I’m thinking competitions to help sign up, eg: a discount off existing games – anything is better than nothing!
5. I didn’t interact too much with the relevant communities
Taking a step into a brand new industry is daunting, especially when you’re working from home by yourself.
Added to that, my personality borders between extrovert and introvert. What this this means in reality is that whilst I’m ok when I’m at meetups or fairs, actually spurring myself to go to these events in the first place is hard.
All that taken together meant that during my first game I didn’t participate in the wider communities I should really be a part of – be it game dev or science communication.
I can’t really say quantitatively how this affected S.O.R.S, but really in any arena you get out what you put in, so being a proactive member of the community is important and something I want to work on.
Similarly, I didn’t work with any scientists at all. I didn’t work with any teachers until the game was out. In both cases, pretty bad for a game that is based on real science and which one target market was education (to be used in classrooms).
I reached out to one funding body and scientist, but the process was slow and it was clear they weren’t used to dealing with indie developers (which was hardly surprising, really).
Conclusion
Looking back, I think a lot of what didn’t go well can be chalked down to my inexperience. It hindered me in a really interesting way – because I didn’t know how things were going to turn out, I was reluctant to reach out to do anything beyond sit by myself and make a game. I even remember thinking stuff like: “I could ask them, but I don’t even know if I can finish this game..”.
So my overriding advice to other small indie teams is – trust yourselves. Believe that you have the ability to finish the game you’re working on, and work on a day-to-day basis assuming that at some point there will be a finished game. This should help your interactions with others and just help build your confidence. It’s easy to write those words though. It took me about 10 seconds to write that sentence, but working on your game could take 10 months (or 10 years), and that’s a lot of time alone when you’ll be fighting with yourself about how things are going to turn out.
And so here’s my second piece of advice – if believing in yourself gets hard, write down all the issues you’re facing, put them in a list, and tackle them one at a time. It’s amazing the power breaking things down into a list has – you can tackle problems systematically and get the satisfaction of crossing stuff off as you complete it.
The road is long, daunting, but you will come out of the journey a more confident, skilled person because of it.
As for my story, I’m back in a full-time job now but am working on my next game in my spare time. Everything I learnt during my time out has been immensely useful, and I’m planning on this next game to be bigger and better than my first one. Plus it’s about monkeys, so there’s that.
I hope this has been worthwhile to you – if you want to discuss any of these points in more detail or just ask more questions, feel free! It’d be great to talk – contact me on twitter or via email.
