Learning on the Job

Monkey with a Typewriter

Like many indie game developers, I grew up playing video games. I didn’t always think I wanted to make video games. Though I knew that it was a discipline one could pursue, it just seemed like it would be pretty difficult to pursue. In hindsight, I was right. I started playing games on consoles, but at some point moved over to computers, and that’s when I learned that you could change the game you were playing from outside the game. There were ways to play different maps and modes for Warcraft 3, and they could be found on the internet. You could change the look of Minecraft with texture packs, or even the gameplay, with mods. I wasn’t doing anything advanced or making my own mods, but the feeling of messing around with computers was instilled at this point, and so I figured that I wanted to work in IT or software engineering one day. Fast forward to high school, I was learning to code for the first time, and I started making games in Unity. I didn’t actually learn in a very structured way, and I definitely didn’t take advantage of having so many other talented coders around me at the time, so my solutions were often terrible hacked-together pieces of game logic that barely worked. It would take me hours to figure out how to do something more advanced than I already knew, because I wasn’t taking the time to learn coding practices or features of the language, but going at it with what sparse knowledge I already had.

This was a journey of frustration that made me feel like I didn’t know what I was doing when sat in front of the keyboard. I guess this is the reason that I chose to study software engineering at university, to have a chance to learn in a structured way and internalise all of the fundamentals, and become a good game programmer. It’s too bad I hated the process and couldn’t stand to look at the trajectory I was going towards.

I dropped out, went travelling for a bit, and came back to university to study game design. Thank goodness I did, because otherwise I wouldn’t have met the fine folks I make games with now. I would undoubtedly have been a better coder by now, though, which I still think about on the occasions where I’m struggling to figure out how to implement particularly difficult systems in our game. I don’t think it needs to be said that this isn’t a very healthy line of thought to go down, so I’ll take the chance to highlight Alex’ post from a couple of weeks ago: An Imposing Syndrome. These days, I’m a much better coder than I ever was, and not only that, I’m loving the process (on most days), and I’m continuously learning new coding principles and getting better at building architecture, while building something that excites me. If you have to be learning on the job, especially when it’s a core discipline, I think this is important. Either be excited about it, because if learning while doing doesn’t energise you, it’ll drain you ‘till you burn out. Alternatively, minimise the discipline to the point where it couldn’t ever drain you fully.

When to Learn

Learning on the job isn’t really optional when making an indie video game, for most studios. I covered this in part when talking about the hats you wear in a studio, but in essence, operating a business and a game studio with a small team means that you’re almost certainly going to do things you’ve never done before, and so you have to learn while doing. However, learning is a time commitment, and while it’s great to have the opportunity, if your studio has any sort of urgency to release a game in a manageable time horizon, you can’t take the time you’re spending on learning for granted. In general, if you have someone on your team who knows how to do something you need done, then let them do it. If your team is lacking a skill or knowledge of how to do something, it’s worth considering what the relative cost of time to learn a skill is vs. cost of resources to get someone external to help is. For a new indie studio, time is likely what you have more of, so learning will often be the default course of action, in which case, being smart about what you need to learn will be essential.

The thing is, while learning may not sound like the most optimal or time-efficient way to fill in a skill lack in a team, it’s often an absolute necessity. This is especially true for small indie teams that suddenly have to deal with every facet of game development, where they previously may have been very specialised. The detractor for learning while doing is that the time spent on learning a necessary skill is unpredictable, and so we prefer not to have to learn at all. However, as I found out from my early days of coding, if you must do something you haven’t done before, taking the time needed to learn new concepts in proper depth is likely to save you time later. Back in high school, I would often think of a feature I needed, search online for “how to make X in Unity”, and follow a tutorial or copy some scripts online, and while that might have worked in some way, I didn’t learn much from it. This caused problems when it didn’t work as expected, or when I needed to modify it. Had I instead spent the time thinking about everything I need to do to complete a task, figuring out what I don’t know, and then focusing on properly understanding what I didn’t, I would have saved time and headaches in the long run. These days, I know better, and I take the time I need to learn.

There’s two ways you might approach learning a discipline while needing to work on your game. If you come to this discipline with some knowledge or experience already, you’re then looking at figuring out how much you need to top-up with to be able to finish tasks on your project. If you need a discipline but have no experience on the team, you need to learn enough about the discipline to estimate your time spend on learning enough to finish tasks. In either case, you can design your project to make your learning time more predictable, and happen when you need it the most. Consider these two approaches:

Develop your skills based on project needs

When you’re designing your project in overall terms, and you get an idea of the different parts of the game that need to be developed, and make rough priority order, you can at the same time think about which skills are needed that you don’t have yet. If you know when those skills are needed, you’ll then have an overview of when you need to learn particular skills. With any luck, you can plan the order of game development to suit your learning goals, so that you’re only learning a small portion of the skills you need each month. Now, in many projects, this might not work out, because certain features just need to be made first, because they are core to the game. Likewise, some skills have a high minimum barrier to pass before you can apply them to project tasks.

Let’s imagine a project where the team has no graphics skills, but they want to learn enough to the point where they can make their own game art. The project can maybe get planned such that placeholder art assets are used for the first part of development, and the prospective artist can structure their learning around what gives the quickest in-game results. In a 3D game, they might start learning how to create a block-out over a few sprints, then move on to environment props for another few sprints, and gradually build towards the most complicated skills they think they need to learn.

Design project requirements to fit minimal skill requirements

The other side of lacking a skill is trying to make your project fit your existing skills as well as it can. If you know that your project is going to be in 3D, but you don’t have a 3D artist, you can lighten the learning load a lot by deciding on an art style that is easy to learn and achieve. Likewise, you can try to figure out ways to have your other disciplines make up for the skills that you lack. If your prospective 3D artist can learn to create a minimum fidelity of 3D assets in a predictable way, then maybe you can have your programmer create shaders that make those models pop, without adding more learning load onto your prospective artist. Similarly, if you have a 3D project, and a 2D artist, maybe there’s an art style that can be developed that relies on 2D art being projected to a 3D world, thus lightening the 3D learning load required by the artist.

These approaches can of course be combined, and the best case scenario is that you design your project requirements to need only minimal learning, and plan the project so that the learning is very gradual. Each project and team will be different, but planning a little ahead, and being creative in design solutions, can go a long way.

Becoming a Programmer

These days, there are very few problems that I don’t know how to solve as soon as they are designed, and it’s more a question of how much time it might take for me to implement a system. If I come across a task where I need to learn something new, like a Unity feature that I haven’t used before, I try to factor in the time to learn the task, and work on the minimal viable version of the feature. After closing out the task, the team and I can evaluate whether the implementation is good enough, or if we should spend more time on it, in which case I can make a new task with a more accurate time estimate. This isn’t much different than how I was learning on the job in the early days of MVGIE, there are just fewer instances now where it is necessary. Back then, I tried to plan each sprint with only a certain number of tasks that required a lot of learning, which worked well enough. I’m also lucky enough to have some good friends who are much better programmers than me, and are willing to lend me bits of their time to give feedback on my approaches to certain problems. The thing is, even though I am a much better programmer than I was when I started working on games, I still feel like I don’t know everything that I should. However, years of successfully developing features and seeing gradual changes to the amount of learning I need to do has given me more confidence, and that might be what I find most important in helping me accept my role as the sole programmer at MVGIE.

With all of that said, there is always more to learn, and keeping your skills up to date is useful, if not to your immediate project, then to your future projects, and thereby, the sorts of games your studio can build in the future. I’ve taken to using an hour each day to focus on the learning aspect of my job. It gives me a specified period where I don’t have to estimate how much time I need to learn something, nor have the pressure of completing a task on time, and being just an hour, it doesn’t take much time away from the project. In my case, I’ve been taking systems from our games and putting them into a blank Unity project, and then refactoring them to be generic and project-independent. I get to learn while working on something relevant, and the studio gains tools that can speed up development time for future games. It’s a win-win.

Whatever your skill level, it’s likely that you are sometimes learning on the job, and even if it isn’t frequent, taking time to learn is an investment into the future of your projects, studio, and yourself. So if it is unavoidable, and has benefits, then you might as well embrace it and work it into your schedule.

That’s all from me this week. Thank you very much for reading along. Should you have any questions about learning, or anything else we’ve covered on our blog, you can always reach out to us.

phillip@mvgiestudios.com