Ask a Game Dev

Gamedev is tough to do in general, but it's generally more difficult to do in a remote setting because humans are accustomed to being social in a certain way. Online communications is often bottlenecked in ways we aren't immediately cognizant of. After working remotely for a few years, I've adopted certain specific counter-intuitive techniques in order to try to facilitate better understanding on the team. The best advice I can give for remote work is Default to Talking in Public. Instead of using DMs to speak to someone about work privately, post to the appropriate channel and tag the person you want to speak to - even if you end up only speaking to the other person during the conversation.

One of the benefits of working within the same space is that it's much easier to pull someone into your work space to ask questions or have an impromptu meeting. One would think that DMs are an easy analog to this, but it's actually more troublesome than that. Normally, what happens is that the major stakeholders begin the discussion, and then others that are more tangentially involved are pulled in near the end to handle things like creating, prioritizing, and assigning tasks to cover the needed new work. Adding someone to DMs with history is a little better, but it puts the newly added person on the spot with needing to catch up immediately. The real problem with this, however, is following up the impromptu meeting makes it even more difficult for people who weren't involved to catch up. They weren't in the original DM chain, which means the entire discussion needs to be repeated again.

We can improve this by making such discussions/questions public by default and tagging the people involved. This leaves a publicly viewable history and discussion, which latecomers can view to catch up on. This also has the added benefit of allowing other tangential devs to see and possibly chime in with caveats and gotchas the primary discussers might not be aware of. It also makes other team members see that work in this area is being done and those who are interested can also follow along. There's some initial reluctance to doing so, since it feels more like speaking in the public square instead of being private, but many of those "private" discussions in the office are often overheard by other stakeholders anyway, who will insert themselves into the discussion by bringing up things that the initial speakers weren't necessarily aware of. In general, defaulting to asking questions and discussing elements in public channels solves a lot of remote working issues just by making sure anyone who wants to know about something can know about it.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

It sounds a lot like you're dealing with burnout. One of the quickest recipes for burnout is putting all of the value on the results of the work rather than finding the work itself inherently rewarding - valuing the explicit reward instead of an implicit one. These two aren't always causal, which can result in this disjointed feeling and lack of motivation. Since you're not seeing any results from your work, it feels like a lot of wasted time and energy.

The quickest way to provide that explicit reward is to see players enjoying the results of your work. This doesn't have to be through a shipped game, it can be through your own personal projects as well. One of our Discord members enjoys posting his own personal playable game projects to our indie channel, where people can try them. These are not massively scoped games, but they are fun and the play testers do appreciate them. The feeling that your work is not wasted is important to getting validation that your efforts are worthwhile.

A longer-term solution to switch to implicit enjoyment of your work is to embrace a sense of detachment from the results of your work and focus on doing tasks that you enjoy doing for their own sake. I don't focus on what the results of my work will get me when I go into my job at all. I focus on the part of the work I find inherently rewarding and interesting - I treat my tasks like puzzles and I solve them. The feeling of solving a puzzle is rewarding and interesting to me on its own, I would feel good solving problems and puzzles all day long. The other stuff - the rewards for doing well at work and the promotions and whatever - are obviously important and there is some long-term meta-game strategy, but the day-to-day job satisfaction is entirely based on doing the things I find inherently engaging to begin with.

You might not find that to be the case (or even possible) in your current place of employment, or even in general. What is job satisfaction worth to you? Perhaps you could find a new employer that matches your needs better? It's difficult to say for sure. I also suggest talking to a therapist about this. Therapists are there to advocate for and provide context to you in the field of mental health. Pursuing a career that is more engaging is certainly a reasonable goal that a mental health professional should be able to assist with. A good mental health professional should certainly help you identify and work through the feelings of burnout you've expressed.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

If keeping the beat is the most important thing in the game, then you build the game around keeping the beat. There are many different ways to approach the problem, but if I were building such a system myself, I would start with a system to handle a data-driven beat (e.g. this level/song sets the beat to X, that level/song sets the beat to Y) and then build all of my visuals and gameplay on top of that. The key component to making this work would likely be an animation system that could scale animations faster or slower in order to match the timing of the music.

On the data side, this would mean all animations would be built so they could be sped up by dropping frames, or slowed down by holding certain frames for additional length. All animations would also need to be the same length (or a multiple of a standard length), so that I can ensure the animations will fit into a standard musical measure. If I wanted to have a variety of attack animations and hit reactions, I would probably also establish a set of rules that each attacking and hit reaction animation must always be the same number of frames. I could further standardize each attack and hit reaction active frame happening on the same frame each time.

The code side would then play my animations to those musical measures along the beat. It would do so by scaling the animations longer or shorter based on the beat. The system could add or cut animation frames so that each animation can play in sync with the music. Once I've got the animation system integrated with the beat-keeping system, I can then ensure each animation should start playing on the appropriate frame to keep the beat. As long as the animations are scaled to the musical measure and the music keeps the same beat for its entire duration, the animations should always sync to the beat of the music.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

How do they find that many bugs? Consider - in AAA games, we bring on entire teams of QA to test every day during production. Imagine 50 testers each find only five bugs a day from a full eight hours of testing. That's logging a combined 250 bugs daily. In a week, you've got 1,250 bugs. After a month, that's 5,000 bugs. A year would be 60,000 bugs. Most testers can find more than five in a day, especially early in development.

To give you an idea of what things are like in the trenches, take my example. Two days ago, I personally fixed bug number 522,096 on my current project. I'm currently working on bug number 474,991. These are not randomly generated numbers. When I joined the team (roughly two years ago) I started working on bugs and tasks numbered in the mid 30,000s. QA finds and logs a lot of bugs.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

After being collectively yelled at on the forums for so long, I've developed a thick enough skin that none of the feedback really bothers me anymore. I don't get the emotional engagement with it much anymore. To me, there's really only two kinds of feedback - actionable and not.

If the feedback is actionable - if it's actually within the realm of possibility to do - then we'll consider it, figure out how much work it will take, prioritize it, and put it in the backlog to get worked on if/when we have time. Actionable feedback would be things like "Pastrylord doesn't feel very engaging to play", "The Buttery Doom ability feels overpowered", or "The Cappucino Plateau is a boring area". These are issues we can legitimately investigate and try to address.

If the feedback is not actionable, then we'll probably file it away somewhere. Some of this feedback is pretty obvious, but there's also some feedback that will never go anywhere. Trying to assign blame among the developers or our business partners for some shortcoming in the game, for example, is never actionable. Asking for a complete redesign of the game (or major game systems) is almost never actionable. Giving us unsolicited content ideas (e.g. posting a design a dungeon for the game you like) is not actionable for legal reasons. Realistically, little will actually come from this kind of feedback - we can't do it in the current game we're working on and we have plenty of our own ideas for things we want to do in other/future games. Never say never, but often say "probably not".

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

You're talking about downtime. Whenever I have downtime I try to be productive if I can, but the type of downtime determines what I can do. There's two main types of downtime - when my workstation is still usable and when it isn't.

If my workstation is still usable (e.g. the build is broken but I can still look at code/script/assets/etc.) then I notify my team that I've got some bandwidth and downtime to help out as a second set of eyes on any tasks my team might need help with. I can do code, design, or asset reviews for teammates and I can look over the various Slack discussions on other in-progress bug fixes and features to comment if I feel like I can contribute something helpful. I might not be able to run the game to test or validate anything, but I can still contribute my skill and knowledge to others who aren't having downtime.

If my workstation is unusable (e.g. all system resources are dedicated to building the game, building assets, compiling a level/lighting/etc., network or VPN down, etc.) then I really can't do much. I can't do reviews or join those conversations. In those situations I've traditionally done things to pass the time like listen to music or a podcast, scroll through social media, or think about what to write next on the blog. More recently, I've been focusing on leaning away from the social media scrolling and being more mindful so I have been taking the opportunity for mental and emotional "digestion" by not focusing on anything external and allowing my mind to process the normal emotional experiences in my life. It was difficult to start, but has definitely helped with my focus and my attention since I've started doing it.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

If you are one of those few people blessed with an eidetic/photographic memory, I just want you to know that I am incredibly jealous of you. For everybody else, I absolutely endorse the taking of notes and reviewing things later. It's extremely difficult to remember everything, especially if you're studying something for longer than around thirty minutes. This is just the way our brains work.

In order for things to transition from our short term memory to long, our brains need time for reflection and repetition. This is why we have players perform variations on the same kind of in-game tasks - it trains them to internalize what they're doing so that it becomes second nature to them. Writing (and later reviewing) notes helps with that reflection and repetition process because it forces you to reflect on what you heard and repeat it in your mind.

I often keep either a physical notebook or a text editor instance open regularly so that I can write things down that I know I will want to think about later. This might be a link to details about a new task, a particular asset or script I need to change, a location for a document to read, or the name of someone who might know something about what I'm investigating. Taking and reviewing notes is an incredibly helpful habit that will help a lot in just about any career that requires you to remember or learn stuff.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Animators typically count things in terms of frames. Some designers care about frames specifically too, but engineers and designers generally use milliseconds or decimal seconds (e.g. 0.6 seconds) to describe how long something should be. Using frames as a specific time measurement is less helpful because development builds typically aren't optimized and may run at different frame rates based on what's going on. Using a more specific measurement of real time is more helpful, since the game engine can calculate real time from its (variable) frame time in order to maintain accuracy. Our debug logging keeps tabs on everything in terms of milliseconds so we can see how temporally far apart events in the log fire.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

It's hard to say because the familiarizing depends a lot on how you learn best as an individual. Some folks do better with more formal training and documentation, others do better with jumping in and tracing code to see how things flow. Most will have a lot of questions as they learn more. I would say do the most that you can with what is available depending on the style of learning you favor (e.g. reading documents, tracing code, etc.) and then compile a list of questions you can't get answered through your own discovery and find a mentor on the team who you can ask.

When talking to a mentor, I find it better to ask for an overview of how things work rather than the exact specifics. I like to take notes while they go over things so I can review them later - I never expect to remember everything at once. This also includes copying down diagrams and such, they can be very helpful. Your mentor will also often be able to point you towards other resources and people you can ask. The important thing is that you need to do the legwork yourself - do the research yourself and see what you can figure out first, then go to the mentor to help fill in the gaps.

One thing I also suggest is to ask to be included on code reviews from other programmers working on similar tasks. This is a way for you to get exposed to other systems that you aren't super familiar with and see how the other programmers are working. During code reviews you don't just have to point out issues with the code - you can also ask questions about how something works and the more experienced programmers can explain it. Even senior programmers don't always 100% understand everything in another programmer's code review, so asking should be no big problem for anyone.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Not really, but I've always had trouble suspending my disbelief and immersing myself completely in games. My brain has never been able to turn off "analysis mode" when playing games. Every game I've played since I was a student has been an examination of what the devs did, how they did it, and whether it worked. That's how I've always enjoyed playing games so it's totally normal to me.

It’s not unlike a stage magician seeing other stage magicians perform their acts. I admire the artistry and performance of the entire experience and I can think about the way that I would perform a similar trick, but I would probably never believe that the magic is real. 

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

No one ever has life figured out and is that well-organized. What you're seeing is my ability to operationalize things in such a way that I no longer feel like I have no control. Operationalization is the skill of taking large difficult tasks that you can’t do yet (e.g. - doing your job, taking care of your finances, having a social life, etc.) and break them down into smaller, more reasonable tasks that you can do. The ability to operationalize big tasks is the real skill to being an adult. Once you've leveled up your operationalization in various aspects of your life, you'll feel a lot less imposter syndrome.

Operationalization is a learned skill that we apply to things as we understand them. We can see this demonstrated in small children - asking a five-year-old to "clean her room" is generally too difficult a process for her because she can't yet make the mental connection between the large goal (a clean room) with all of the smaller tasks that need to be accomplished in order to achieve that large goal. She doesn't yet understand that "clean your room" means "put the crayons back into the crayon box", "put all your toys into the bins", "stack the bins in the closet", "put the chairs away", "put the dirty clothes into the hamper", "put the trash and scraps into the trash", and so on. If we tell her to complete those tasks individually, she understands and can do them. It takes practice and experience for her to understand that "clean your room" comprises all of these various tasks. Once she has operationalized the process of "clean your room", she will be able to make those connections in the future and "clean your room" will no longer be too much for her.

This is also what experience teaches us - how to operationalize tasks and do them. Yesterday's post about gauging ideas by feasibility shows what operationalization is good for - I can take a big concept idea and break it down into component tasks that I can evaluate for feasibility, and I can apply and repeat this process as many times as necessary until I get to tasks I know I can do. Once I've operationalized a big task, not only can I break down how to accomplish that task, but I can also make confident predictions about the task, its subtasks, and those details around those subtasks. This principle applies to just about every big task that feels overwhelming, work and otherwise. The more we operationalize things, the better we become at it. Operationalization is a skill like any other - practice leads to improvements and familiarity.

As a corollary to this, Imposter Syndrome is your state when you've begun operationalizing something new, but haven't fully done so yet. You're able to do some of it but haven't fully internalized all of the connections yet, so it feels like you don't quite get it. Once you're familiar enough with the tasks that you feel confident in your ability to predict the results, imposter syndrome tends to vanish.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?