Game Development: 10 Lessons I’ve Learned in 2 years as a Game Designer

Watching a GDC talk, reading a Game Writing article, and learning about WordPress | Flo

I’ve been gaining experience in game development as a designer working primarily in narrative content, with most of my efforts contributing towards an unannounced AAA game. I wanted to share some of the things I’ve picked up along the way, over the past (almost) 2 years. Though this is by no means an extensive, all-inclusive list and there’s a lot I’m not at liberty to go into detail about for now, some things are worth sharing!

1. Game Design is broad and specialised

When I was applying for games writing jobs, I didn’t know just how broad Game Design is, and how many sub-categories there are:

  • Game Designer
  • Level Designer
  • Content Designer
  • Narrative Designer / Game Writer
  • Systems Designer
  • Technical Designer
  • UI designer
  • UX Designer

The list goes on. A lot of these overlap. For example, I was hired as a “Game Designer”, which is very vague when you think about it — what exactly is it that I’ll be designing? It could be anything, several things, everything, or just one thing. Your focus might be revealed in the job description, and it might not. It’s possible that studios are looking for a whole pool of different types of designers, and in that case, you might find out at the interview.

In my case, I was hired as a “Game Designer” for the kick-off of a new project, where the need for designers in general outweighed the need for them to be specialised. After my team started specialising into different roles, I still kept the original title “Game Designer”, even though I mainly work on narrative content (quests, dialogue, stories) and content pieces (weapon descriptions, pop-ups, tooltips, loading screens).

Despite the content-based focus, I’ve also co-written many game design documents (GDDs) and participated in the creation of systems and whole features the way a Systems Designer would, and am more involved with the Art Department and UX/UI than I would ever have imagined I would be. In my still limited experience, this is typical of a lot of game development studios, and part of the challenge.

2. Designing is an “iterative” process

I hear it all the time: “this document is iterative, it’s a tentative approach, a first take, a WIP, a working doc, a live doc, a process, a draft.” Being a Game Designer has taught me that a design decision is rarely final, even if it’s been agreed on and received a stamp of approval by managers.

This can be frustrating at first if, like me, you come from creative writing or literature within academia. If you’re used to researching for a paper, polishing it, and then handing it in for a final grade, then the switch to game design is an interesting mental shift.

This doesn’t necessarily mean that “what was once right is now wrong”, and “throw out all your hard work.” Often, it just means that what was designed at the beginning of the project now no longer works within the project’s new scope (for example, if you decide to cut a feature, you might need to rewrite some content or re-design how a complementary system works).

This has been a very valuable learning experience because it forces you to re-think a lot of ideas, systems, writing, and overall plans that are dependent on each other.

3. Scripting is easier than it looks

As a deeply non-technical person who has never felt comfortable around numbers and symbols, I was borderline fearful of dipping my feet into anything that remotely looked like maths, logic, or coding, no matter how cool the #GirlsWhoCode circle is.

However, to my own credit (and that of those who taught me), I picked it up quickly. I also realised that scripting is a lot less technical than programming that requires compilation. Though they both fall under the umbrella term “coding” and technically also “programming”, scripting is code that lets you control an already built or compiled programme. That means that you’re not responsible for creating or modifying the tool that you’re going to use to write your own code, which to me was arguably easier to grasp, even if scripting can also be complex.

That’s all to say that if you’re a non-technical person, don’t shy away from the more technical side of design. If you’re being offered the chance to learn a skill, it’s a good opportunity to see what it’s all about, and gain your coder badge. Who knows, next you’ll be programming.

4. Solve problems, identify opportunities

Everyone on my team always says that “Game Designers solve problems”, no matter the sub-category. Rarely do you start designing without a vision or a Game Design Document, meaning that you already subscribe to a set of values and pillars. And in that sense, your task is to solve the problem of making a concept and its guidelines (the game vision) become a reality.

Uplift communities that aren’t often the focus of video games

But you’re also not just a problem-solver who only executes orders. You’re uniquely placed to tell a story in a sincere and well-researched way. This is a lot of responsibility, but it’s also a privilege. Consider that you could (and should), hopefully with the right tools and consultancy, uplift communities that aren’t often the focus of video games, such as women, LGBTQIA+, BIPOC, differently abled, to name just some examples. By doing so, Game Designers contribute towards solving another problem, which is lack of diversity and inclusion in their field. How do we do that in an authentic, non-tokenising, and profound way? It’s something a lot of us think about everyday.

5. Overtime affects estimations

If you’re a hard worker or a perfectionist, then you might think you’re doing your team, the project, and the game a favour by working overtime. What’s wrong with that anyway, if it’s your dream job? Asides from the very real medical condition that is burnout, and the proven need for work-life balance, working more than you need to is not always what’s best for the project, especially when it’s invisible. By that I mean, your project management team has no idea that you’re putting in the extra hours.

Overtime will contribute to numbers being more unreliable during estimation

This kind of work ethic can generate unrealistic expectations where your Lead or Production might start asking too much of you as they aren’t aware of how long it actually takes you to do something. That in turn can lead to your overtime contributing to unreliable estimations of effort and time. Production might then plan for a certain amount of content making it into the game, without being aware that a portion of that content will only make it if you keep working over-hours for the rest of the project’s duration.

You’re now stuck in a promise you didn’t make, and one you can’t keep if you fall ill or are unable to come to work. In fact, when you go on holiday, the whole team’s productivity might plummet, which sucks for everyone. So unless you’ve been explicitly asked to do compensated overtime, then I would strongly recommend against it. If you’re feeling gaslit or outrightly forced to do overtime, bring it up with your manager, production, and/or HR. If you’re part of a union or have a whistleblowing service, then that’s also an option — for any injustice you face.

As with all things, there are a few exceptions. Maybe it’s been your life-long dream to include a particular story, but it’s out-of-scope. Maybe if you write it anyway and it doesn’t cost any “project time”, it’ll make it in. Perhaps that’s worth it, but those decisions always come at a personal cost. Weigh it carefully and “visibilise” it.

6. Creative not chaotic

It’s worth mentioning that whilst writers are often stereotyped as chaotic, free, wild thinkers, I think the best writing and creative team management I have witnessed always relies to some degree on tools of organisation.

Sometimes these tools can also be used to manage the more “free and chaotic” work, like brainstorming sessions and writing workshops. It’s a common misconception that writers are lone wolves that pull wild ideas out of thin air all the time; the amount of careful co-work and planning involved in the process can sometimes get as micro as applying filters to quest ideas to make sure they can reliably function in the game as intended.

Tools like virtual whiteboards and product management systems are therefore essential in the design process, especially as some of the costliest mistakes and the worst designs can happen when lack of time meets disorganisation.

7. Visibility avoids overhead

Not only are good Game Designers owners of their features and experts in the games they are making, but they are deeply involved with each other and with other areas. This kind of involvement includes transmitting the work you do to colleagues, as well as the desire to know what they are working on; a bilateral and symbiotic type of relationship. This is important because it’ll contribute to a playable game that is coherent, consistent, holistic, and fun.

Not just that, but communicating early and often will help you avoid overhead, or, doing more work than you need to. If not, you might end up doing duplicate work, going about your task in a way that wasn’t intended, or being privy to missing out on a critical piece of information. This is especially likely if you work very closely, even more so if you’re committing and pushing in the same branch, writing in the same document, or coding in the same file.

8. Good QA will force you to re-think

I’ve never seen intention be subject to so many different interpretations and bugs as I have with the marriage that is Game Design and QA. It makes me think of that one video where a dad (QA) gets his kids (Game Design, hi that’s us) to write out instructions for making a peanut butter & jelly sandwich:

Or that other video with the woman who painfully comments and watches in horror as shapes that are part of a game pass through holes that weren’t intended for them:

This might cause frustration directed towards your own design or the game engine at first, but you have to commend the meticulous work people do in order to assure that the quality and playability of your design is sound, and most importantly, that it doesn’t break the build/game.

It also often leads to funny bugs or really weird edge cases (aka unusual situations that weren’t expected). I’ve seen things spawn in places they should never have been able to spawn in, or sizes and shapes of gameplay assets be altered to something so laughable that it warranted a 10-minute tea break.

9. Research precedes Content Design

I was really surprised at first at the amount of documentation that Game Design entails, especially in the early stages of a project. I spent many months researching and documenting intention, rarely content-designing or testing in the game engine. But when you think about it, how will you make a game without building its foundation first?

It’s, essentially, a compressed thesis carried out to set-up the theoretical part of something you intend to later prove through practice. That means a ton of benchmark research, researching various IPs, talking to people, having and hosting meetings, conceptualising, and system designing. In general, even after the game’s foundation has been set, a lot of your time will be spent doing things other than implementing gameplay content. Those who compile, know 🙂

10. Patience, Perseverance, and Resilience

Game Design and Game Development in general can be a rough experience if things like budget, amount of resources, or scope are poorly planned. It’s also not a very diverse industry (yet), and has garnered a lot of negative attention for, in essence, being no different than other industries dominated by an unforgiving majority. But, it can also be a rewarding experience when things go right and when hard work pays off. This line of work is a really special opportunity to be surrounded by people who are all creative problem-solvers, and all complementary parts of a super fun whole.

Regardless of whether things are going uphill or not, I’ve learned that it’s key to distinguish between when you need to be patient about a process, and when you need to be perseverant in your fight or feedback. Some change will never be achieved if underdogs don’t speak up, whether that’s to make a feature better or to push for something critical like diversity. It takes passion, nerve, and determination.

Regardless of the studio, or if you’re freelance or contracted, Game Developers are enduring. We sit through honest and sometimes hard-hitting critique. Some people will go through failed milestones or projects, others have their writing picked apart to be rebuilt, and many things you pour your heart and soul into might end up never seeing the light of day. But if you’re patient, perseverant, and resilient, and you work with people who are kind and want the best for the game, you’ll end up creating something both functional, beautiful, and quite literally game-changing.