It’s with a combination of sadness and relief that I decided to shelve System Raid. After quitting my job, I worked on it for eight strong months, which was not nearly enough time to complete the project, but I decided to return to regular work after the trajectory of my life took an unpredicted turn and rather than stubbornly march forward. It was time to stop, regroup, and start over from a more solid and grounded position.
I’m not sad about it, I’m actually really proud of what I did. “I failed” is better than “what if” whichever way you look at it and I’m not going to stop making games. Although I am going to change my strategy to one that better fits with my current lifestyle of full-time employment, exercise and social life. A strategy built upon starting small and sustainably building up momentum over time.
But before any of that, it’s quite important to reflect on System Raid and what lessons I can take forward to my next project. I’ll share a few of them here.
Everything everyone ever said about project scope is true
Don’t get me wrong, I’m all for working on a passion project. Loving the idea and wanting to bring it to life for my friends to play is one of the things that kept me going on those early mornings and late coffee fuelled nights. I thought that having the time that quitting my job would allow me to have would compensate for this. But what would have been better would be to slowly build up my skills and experience with the process of game development. My game was larger and more complicated than I thought it was going to be and I was not ready for that. No other way of putting it.
Regular play-testing from friends is insanely useful and also very rewarding
I set up a WhatsApp group with some friends who I would send regular builds to. This regular feedback was invaluable to helping me prioritise features and identify holes in my design. One of the most rewarding aspects of developing the game was getting feedback from my friends and watching videos they had made of themselves playing it.
It is quite special, watching people play a thing that you designed and programmed from scratch. They also found loads of bugs for me so this is something I will definitely do on future projects.
Structure and build your project management around maintaining a minimum viable product
Something that was important to me was to maintain the project in a playable state so it could be tested early, easily and constantly. I split my work up into two-week sprints, developing with an Agile methodology. This worked nicely for me because my goal was always to add a feature that added to / built upon the minimum viable product. I broke the project up into releases which was how I managed my work in Trello where I would take two weeks’ worth of work, plan it out, build it and release it to my friends.
It was always quite easy to see the current state of a sprint, keep track of bugs, and plan / refine what I needed to work on next.
Source control is life
Source control? Who needs it!? I’m working alone I don’t need to share my work with anyone, so I shouldn’t bother right?
I should have used some form of source control such as Git. That would have really helped manage the quality of my code and releases. Especially if I wanted to go back on something I had built previously. It would have given me a backup of my project at all times and perhaps would have been a much better way to handle my build, test and release process.
It would have also helped keep my work in manageable chunks and not get distracted by making changes not relevant to what I my current task was.
Know your design. Playtest it before writing any code if you can!
I had a very good idea of what the game was going to look like, sound like and feel like to play. But I had not spent time designing and playtesting the game in pen and paper format. Which I could have done easily. Since the game played out like a board / card game I could have spent a month up-front making a pen and paper prototype with real cards and tokens to determine exactly what worked and what didn’t work. What was fun and what wasn’t fun. I could of and should of nailed down a lot more of the details before writing a single line of code.
Being a great C# developer does not make you a great Unity developer.
Granted, you’re never going to know it all from the start, but I could have done with having more experience with Unity. I’m a strong C# coder which helped a lot but this would sometimes be a curse as much as a blessing. I would often be able to come up with complex code-based solutions to problems that had already been solved and that the engine supported. I re-invented the wheel a couple of times when I just didn’t need to.
Having nearly 10 years' experience in software engineering, I expected this to easily compensate for my lack of experience with Unity. It didn’t.
These are the kinds of lessons I could have learned on smaller projects had I made more small games before this one.
Work on something you really believe in, but you have to have fun doing it.
System Raid is a game I want to play and that I want to exist. I did do some market research in the beginning to help determine if it was commercially viable, but what was more important was that it was a game I wanted to play myself and I was passionate enough to believe that others would love it to. Passionate enough to quit my job and work my butt off trying to realise that dream. But ...
Don’t quit your job just yet! Fortunately for me, I am highly employable so it was not difficult for me to land back on my feet in an enjoyable job.
That said, don’t quit your job to build something by yourself with no real plan, no real experience and no real clue. But if you really have to, make sure that:
- You have proper funding in place - You don’t go it alone - You have a well fleshed out plan - You know how to scope a project
Moving forward Those are just some of the lessons I learned from my time building System Raid. But that’s in the past, so what now? Well it’s taken some time really establish some regular patterns in my life and it’s time to get back on the saddle with my new sustainable strategy.
I actually stole this plan from a YouTube video from Code Monkey It’s pretty simple and it’s all based around building games and small projects.
- Spend 2 months making very small weekly games
- Spend 1 month building one game and complete it
- Spend 3 months building one game. Complete it and release it to Steam!
- Spend 6 months building one game. Complete it and release it to Steam!
Doing this, all while studying C# and coding fundamentals which I already have in the bag.
I’ve already decided that my first game is going to be a platformer of some kind. Probably a simple endless runner type game, so look out for that in about a week or so!
I have a very positive outlook to the future of Double One Studios. Built around having fun and enjoying the process of creating and being patient with progress as opposed to striving for an impossibly high-quality target in a very short amount of time.
Thanks for reading. Here’s to the next step.
Bình luận