RIP Method for Game Dev

By: Matthew Nixon

Repetitive Iterations for Proficiency

Become Proficient Through Repeated Effort


Why RIP?


    RIP stands for Repetitive Iterations for Proficiency, and this method is designed to get a game developer from being new or novice to becoming a great game developer. The idea is to drill everything in until it becomes second nature, so that the fun parts of conceptualising and designing are not held back by lack of experience and/or skills.


    What’s the problem?


    Many game devs are like me. I want to make games, I’ve always wanted to make games. My work ethic is actually pretty good I spend 15-30 hours a week on game dev, that’s because I have a full time job. I’m not the only game dev spending what spare time I have making games as my hobby. I’ve spent years making them and have almost nothing to show for it. When I was much younger I used to make games, but what I enjoyed more than that was designing games, thinking up fun game mechanics and getting inspired by the games I played.


There were a few that were “the game” that I would love to make but just didn’t have the skill or experience to tackle such a game. Hours turned into days, which turned into weeks, months and years. And I’ve only improved a little. Early this year I finished the game I had been working on for six years. And instead of rejoicing or feeling a sense of accomplishment, I felt despair. I mean I was happy that I finally finished it, but the point of making that game instead of my dream game, was to be a stepping stone towards my dream game. And in that, it was barely a success. In the six years I spent working on that game I’ve only developed a few different skills and gotten only a little better at others. And looking out at my next projects I can see most of them taking another three to five years a piece. All the while I’ll repeat the same learning experience by learning only a small set of skills and improving only a little more on the other skills.


Following the good advice to start small and improve before trying to take on my dream game, I can expect to get around to that game in 20-30 more years of game dev. If I tried to take on one of my dream games right now though, that would probably take 20-30 years to complete. So here I am, trying to decide between two equally bad options to keep pursuing my lifelong dream.


    Then What’s the Solution?


    What do I need to get to my goal? I need a lot of game dev skills. I need a lot of game dev experience to develop those skills. Like I said before, my two options are to start with a small game and work my way up building more and more complicated games until I’m good enough to take on my dream project… or I could try to take on my dream project and likely start and restart and spend most of my time rewriting everything because I didn’t have the knowledge or experience to things better the first five times. Neither option is very good and it makes me want to throw in the towel. But those are not the only two options.


    After completing my last, while I was feeling depressed about my game dev progress, I took an honest look at everything. If I couldn’t figure out a way to get to my goal before I died, I’d give up… well let’s be honest, I wouldn’t stop my hobby, I just wouldn’t be very happy about it. So back to the problem at hand. I need a lot of experience to develop a lot of skills. And that brought me to this idea of repetitive iterations to develop proficiencies. I didn’t call it that at first, the name is descriptive.


    The idea behind this, is to make a lot of games starting with tiny scopes, and focusing on certain skills, and then adding different skills in. To get rid of the brain storming the next big game idea just to develop experience making games, we start by taking games that have already been built that we like playing and copy them. Obviously, I don’t recommend selling these copies. And realistically, your first few games aren’t likely to actually sell anyway. This is for developing skills. As you progress through the course, the games you make start moving away from direct copies to inspired by to originals. Or at least as original as one can get.


So this is the reason for this method/course: I could spend 20-30 years developing really good game dev skills, or I could follow this and get a nearly equivalent amount of experience and skills in 1-3 years.


    This is not a program by numbers process, you’re still going to have to take on most of the decisions. If you don’t want to, or want inspiration, you can follow my progress through the course as I blog about it.


    Seems Daunting


    Yeah, this course looks like a huge list of things, and looks like a lot of work. And it is a huge list and is a lot of work. Game dev is a lot of work. There are 68 games to make in this course. That’s a lot of games by anyone’s standards. I’m trying, and probably failing right now to sell you on this and to make it seem not as bad as it looks. But I’m not going to lie to you, this is a lot of work. I’m not offering you a way out of the work, I’m offering you a path up the mountain that will make a mountaineer out of you without a huge risk of killing you. So take this one section at time, one level at a time, one project at a time, one task at a time.


    As you go through the course, you will get better and faster at all areas of game dev. If you make through to the end, then you’ll be a great game developer. You don’t have to complete the whole thing either. Follow it until you get the skills you need to make your dream game. I recommend after a few sections, that if you want to take on your own projects that you do so, but continue to work on this course.


    We also have a game dev group that was inspired by writing groups. You can present your work and get feedback, and we’re also here to help if you get stuck somewhere or have any questions. If you’re interested in joining the group, then send me an email at davin@devpirates.com. Eventually, the site will have a section that will contain game dev use cases with design patterns to show how to accomplish them. As we work through them, we’ll also be providing examples, starting with big engines like UE4 and Unity.