Professional Context

The journey towards entering the gaming industry is a period of uncertainty and confusion for many people. I, like many others on the same journey, have often wondered what to do and where to start. Over the past few days, I’ve listened to several industry speakers in different roles talk about their own experiences, skills need, changes in mindset, and the real state of the industry.

This blog will show my key takeaways from these talks and how they have influenced the games I’m currently working on and my understanding of my future career direction. I’ll reflect on some of my current perceptions in the light of the speakers and collate the parts that I can take away from them and use in my future actions. The article will not be an academic analysis, but rather a reorganisation of ‘where I am now’ and ‘where I should be going’.

The Non-linear Path of Industrial Development

Before I decided to get into the games industry, I always thought that once I got my work to a good standard and had a relevant internship, the next step would be to submit a CV, have an interview and finally get into the industry. But after listening to these talks, I realised that most people’s experience in the industry is nothing like what I thought.

For example, Rhys Shepherd, who started out in QA after graduation, then moved on to programming, then to art, and then to Tech Art, spoke of this experience in a very normal tone, not at all like the ‘detours’ I had expected. He sees these job changes as part of the journey, not as a waste of time.

Bea Grove, on the other hand, has done a lot of things since graduation that aren’t so relevant to game designers: Freelance UI/UX, summer school, and even working in a shoe shop. But she said that she learnt how to communicate with different people and understand their different needs, which made it easier for her to adapt when she joined the game team afterwards.

When I look back on these stories, I feel less nervous. I always thought it was because I wasn’t clear enough in my direction or was slow compared to others. But they told me that the detours you take will end up being your accumulated wealth. Whereas before I would have wondered if my anxiety about my career was more about me not being fast enough, now I’m starting to wonder if I’m in too much of a hurry.

I realised that more than finding a role and direction right away, what I need is to let myself try in multiple directions, such as: UI, design, technology, production, visual, etc. Then slowly let them combine to become a role that belongs to me. Then slowly let them combine to become a direction that is mine.

Skill combinations

As for myself, on the one hand I’m interested in technology and gameplay flow; on the other hand, I occasionally work on UI; but at the same time, I like to think about gameplay, build levels, and do some light narrative work. All these interests point in different directions, and I’ve always wondered if I’m ‘too scattered’.

But after listening to the talk, I realized that multi-directionality is not chaos, but the norm in the game industry. Jamie said “Each project takes you in a different direction. The trick is learning how to stretch without breaking.” His day job is as a Unity developer, but his real work involves making games, web front ends, APIs, platform adaptations, and working with artists and producers to solve problems. It simply means that he needs to learn and do whatever the project needs.

On the other hand, there is no pure drawing in Olivia’s artwork showcase, almost half of her portfolio is process drawings: composition sketches, perspective tests, variations in light and shadow, material analysis and references. She treats art as a system of many small skills combined, rather than one fixed skill.

These are two completely different positions, yet both present a state where it is more crucial to have a combination of skills rather than one.

Now I am coming to understand that interests can collaborate with each other. As well as the competitiveness of many positions comes from combining skills: such as design + UI, prototype + technology, visual + interaction, and so on. It made me realise that I don’t need to be fixed by a certain position, I can let my skillset to create a position.

Communication

Technology and art are important, but what really got me thinking was the communication skills that several of the teachers emphasised.

Bea said something that really struck me: ‘The first duty of design is to communicate.’ She wasn’t talking about communication skills, but rather that the core of being a designer is to express your design clearly, so that other people can understand and realise it.

This was a good reminder to me that when I was making games, I often wrote my own logic, conceptualised my own gameplay and tested it myself. But if I’m asked to explain it to someone else, I tend to get stuck. Not because I don’t understand it, but because I haven’t practiced putting my thinking into a language that others also understand.

As well Rhys mentioned that a big part of his job on the team is not making or doing tools, but communicating with different departments, figuring out requirements, explaining problems, and finding solutions that work for everyone.

This made me realise that I used to think of ‘communication’ as an accessory, and that it wasn’t necessary in the design industry. But in fact, in a professional environment, it is the main thing and something that cannot be bypassed. More importantly, several speakers mentioned the ‘sense of imposture’. Often, communication is difficult not because of competence, but because of self-doubt. But perhaps expression itself is part of overcoming self-doubt, and the sooner you begin to express it, the sooner you begin to grow.

The balance between independence and teamwork

In the process of conceptualizing ROOM_9, I kept this kind of independent way of advancing for a long time: I adjusted whatever came to my mind immediately, the logic was all in my head, and I didn’t have any notes or basis for why I changed it. This way of doing things was fast, but as the project got more complex in the later stages, I realized that there were some designs that I couldn’t even tell you why I did them in the first place.

While no one directly said, “What’s the problem with independent creation.” But combining the experiences of several speakers made me realize that in game development, the work must be understood and used by others.

Jamie and Olivia both mentioned that a common difficulty in teams is not the technology itself, but rather the lack of understanding of the code or process behind it, and the lack of “readability”. This made me think about independence and collaboration together for the first time. I used to think of independence as something that only I could understand, but the speakers reminded me of something else: true independence is when you do something that others can easily accept. Just like ROOM_9 although it’s a one-man project, I should work in a way that is close to the direction that the team can read and understand it as well. For example, try some new habits: write down the iterations and break down the logic more clearly. It was also from this thread that I started reworking how to better build and document ROOM_9.

After that I’ll start thinking about how my projects, my rhythm, my portfolio and even my career direction should be reorganized if the industry’s logic is like this. These are exactly the questions I want to continue to answer in the content that follows.

Sketch and process

Of all the talks, the one that had the most direct impact on me came from Megan Matthews. Instead of speaking primarily about their industry experience like the other speakers, she was very specific about her design process: from the initial hand-drawn sketches to the structural analysis of the decrypted game, to the grey-box scenarios and some data collection. I clearly saw how a designer can turn an idea into a practical structure step by step.

When making ROOM9 I used to keep all the ideas in my head, like opening Unity directly and starting to work on them. I think of something and do it, rarely stopping to draw out the logic. But after seeing Megan’s sketches, I realized I was missing the ability to translate my ideas. So, I started to try a new method: draw or write down the draft in full before starting to do it, and I’m now in the habit of writing down some of my ideas on Figma first. For example, the three game ideas that I had previously constructed were shown in their entirety on Figma. Now I can find the problems earlier than before, and more importantly, the sketches are not for the sake of looking good, but for the sake of making my thoughts better understood.

Early game concept art for ROOM_9

Here is the original prototype of my game, documenting the basic gameplay and framework of the game.

Pacing in a professional environment

Of all the talks, Jade Carter’s sharing made me realize the huge difference between the way you learn in college and the way you work in industry.

Being a game producer, she emphasized not so much the technology but the importance of time and communication, while Jamie similarly illustrated team dependency from a developer’s perspective. Together, the two gave me an insight into what the pace is like in a professional environment.

While it’s common to work independently at university; ‘solo work’ is almost non-existent in the industry. You have to constantly share progress, ask questions, validate requirements, and identify risks because ‘time is money’ and any delays can be costly to the whole team. Although this statement sounds a bit serious, it made me realize once again that the independent way of moving forward, which I had been changing at will, was very impractical to use in real life, and would not hold up in a real project.

Pre-production

Of all the lectures, it was the discussion of pre-production that really made me start to understand the whole “making games” thing again.

It’s often misunderstood at the student level these days as a lightweight process: make a few sketches, write a concept, confirm direction. As I’ve mentioned before, it’s nice to be able to do this in a very detailed way. But in the speaker’s sharing, pre-production is not a preparation phase, but the core thinking of the project. It defines how the team understands the game and where all the complexities of the future will lead.

The purpose of pre-production is not to speed up production or to anticipate risks in advance, but to give the project a structure that can be discussed by the team, overturned, and rebuilt from the beginning. This structure is a consensus reached within the team.

During the production of ROOM9, I gradually realized the true meaning of pre-production. Early on, the project was very free: the corridors could be any length, the tempo was controlled by me, the triggers could be stacked, deleted or restarted as I wished, yet this approach did not constitute a direction. Now the good thing is that it’s still early in the project and there are many behaviors that can be optimized. When the design project starts, there will be a lot less unnecessary trouble.

For example, I’ve designed a lighting cadence that I want the player to feel nervous when passing a certain node. However, the cause of the tension is not clearly documented – whether it’s a change in lighting, a faster tempo or a sudden change in sound effects. When it goes into production, the original idea becomes blurred. It becomes possible for lighting changes to be interrupted by trigger chains, the tempo loses consistency, and I have a hard time recalling where the earliest ideas came from. Their repeated emphasis on pre-production is so that you don’t lose your sense of direction even in the face of complexity and it is a way to give the project the ability to have a clear expression.

Short- and long-term objectives

Short-term goals

After understanding these lectures, my short-term goals are no longer just a list of tasks, but a process of reprogramming the way I create. Over the next few months, I want to make sure that these methodologies I’ve learned are truly integrated into my daily work and learning, whether it’s making games or learning new tools and skills.

First and foremost, I’d like to create a clearer pre-construction for ROOM9. No more leaving ideas in my head but building a direction that really guides my production through sketches and multifaceted instructions. Several speakers emphasized the importance of “process visualization” and I want to actively practice this skill soon to improve my design thinking.

Secondly, I would like to improve my understanding of “testing”. Testing is not done when the system is finished, but when the system is being formed. For the games I’m going to make, I’m going to try to make lighter versions of certain pieces, rather than building huge structures all at once. I also hope to be more open to failures encountered in design, and to be able to analyze their causes more dispassionately.

Another part of the short-term goal is to improve the way I express my thoughts. Whether it is in a portfolio or an interview, explaining my logic shows more professionalism than showing results. Adding more comments to screenshots and taking more notes during the production process could help me build a more stable structure for thinking.

Lastly, I would like to reduce the habit of developing alone, and show my progress to whoever I can, and ask for feedback. The importance of network was mentioned many times in the lecture, not for the purpose of job hunting, but to keep the designer’s vision open and not only stay in personal space.

Long-term goals

In the long run, these lectures made me realize that career paths are not only determined by a certain skill or a certain project, but by the habits, mindset and way of working that one develops over time.

One of the long-term goals is to make the indie game I’m working on now into a piece of work that truly represents my design thinking. I want it to show not only the atmosphere, rhythm and spatial design, but also the logic, structure and process behind it. In other words, I want it to be a piece of work that expresses how I think, not just a demo to show off my skills.

The second goal is to develop together towards multiple aspects. Many speakers don’t have just one single competence but are constantly learning between different areas to develop a unique combination of individual competencies. I am not in a hurry to set a goal for myself, as many people discover their direction only after they find a job. I should continue to explore various aspects, such as design, rhythmic structure, interaction mechanism, technology and visual expression, etc. I also want to build a sense of responsibility for my own work.

I also want to build a sense of “resilience”. The game industry is full of changes, and the creation itself is also full of uncertainties. Keeping a clear head and maintaining balance is not only part of professional skills, but also the foundation for long-term creativity. In the future, I hope to maintain a way of working that doesn’t rely on explosiveness, but rather on a steady rhythm.

Conclusion

One thing I’ve thought about reflecting on these lectures is that the industry isn’t really defined by what position you’re in, but by the relationships between teams, between ideas, and between people. Each speaker, whether from design, technology or production, did not describe their work as a separate task, but rather as a process of constantly finding balance in all directions. The speakers’ stories varied, but at their core they were the same. Getting into the games industry is not a straight line, nor does it depend on mastering multiple tools as quickly as possible. It’s more like a formation of perspective – an understanding of how design works, how teams collaborate, the uncertainty of the creative process, and how to create overtime. There is no single path here, and no right speed. What really matters is learning, expression, adaptation and direction.

This has slowly changed the way I view my future direction. I no longer visualize my career as a fixed end point but prefer to place myself in a diverse space. This space can encompass design, technology, production, and communication to name a few. I hope that my position will not be limited by a certain position, and I prefer to know what kind of role I can play in the system rather than locking myself into a specific position.

Lastly, teamwork, as every speaker mentioned, is not just about how much content you accomplish alone, but whether your content and the way you think about it makes the whole team function more smoothly. Make the logic clearer, make the whole game more structured, and the team discussions more effective. This broader and more systematic perspective has influenced my understanding of my career and made me start to focus on what I can bring to the team, not just what I can produce. These are the directions I hope to continue to develop.