#software engineeering

It's primarily a feature handled by game design and engineering. The designers figure out how the camera needs to behave for the intended player experience and then the engineers figure out how to translate those behavior rules into code.

Let's say that we're working on the camera functionality for in-game cinematics for a narrative-heavy AAA game like the Witcher or Dragon Age. The cinematic designers need a solid toolbox to build cinematics with, a set of tools that they will use to create most of the cinematics of the game. That toolbox might include things like:

Look at X (cut)

Look at X (pan)

Zoom in/out

Move to point Y

Ease In/Out (acceleration control)

Camera Shake

As a designer, I would expect that I would be able to activate one or more of these tools at specific time stamps (e.g. at frame 32, pan to Desmal while moving to point A and zooming in) while I script my cinematic. As an engineer, it would be my responsibility to take the description of each of these tools and create them in code. I would then integrate them into the in-game cinematic editor so that the cinematic designers can use them to create the in-game cinematics.

Similar discussions and work take place for things like what the camera should do while the player is in combat, what the camera should do while the player is exploring, and so on.

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Code systems are code systems. Good code architecture tends to follow pretty universal principles, regardless of whether the system is governing loot tables or lighting systems. Constructing software systems is about seeing the general rules at work and using those to write code that adheres to those rules.

It really helps to take a larger view of what a game is from a software engineering perspective. A game (or any major piece of software) is a bunch of systems comprised of smaller subsystems, and how those individual systems interact with each other. All code systems all need to do three things:

Determine when the system needs to do its work

Return the processed results from that internal work to external systems that need those results to do their own work

Do their own internal work to process and handle requests correctly

When planning out what a system will do, it helps to divvy up the work into these three buckets. Once you know what the system needs to do, the engineer can break down the individual functions and data members she'll need in order to actually do that work.

Let's move forward with an example - say that I wanted to build a stealth takedown system in my action adventure game. The design document says that I want the player to be behind an unaware enemy, press a button, and then play a paired animation that kills the enemy. Using the three buckets mentioned previously, let's break it down.

When does the system need to do its work?

Player and enemy position

Player and enemy facing direction

Enemy awareness state

Game controller input state

What results do I need to provide?

I need to know when the player meets the conditions of being behind and facing an unaware enemy (call the UI system to show the button prompt)

I need to call the animation system to play the animations on the player and the enemy (call the animation system to play the animation)

I need to kill the enemy (call the damage system to kill the enemy)

What do I need to do the internal work to provide those results?

I need to calculate whether the player is behind the enemy

I need to calculate whether the player is facing the enemy

I need to determine whether the enemy is aware of the player

I need to know when the player presses the attack button

As each of these elements is built and works, we can use them to interact with each other. Logical checks like whether the player is behind the enemy will determine whether the action can be taken. Actions like performing the takedown animations are then attached to the conditions. These combine to form the rules from the designer and a system is born.

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

What you're seeing are the programming principles of optimization and scalability in effect. These two principles are more than the sum of their parts, they are multiplicative in their effectiveness (or lack thereof). Thus, if there's a situation where we need to optimize at scale, the results are very pronounced. When we talk about performance, it helps to think of it as costs to do things. We spend system resources (CPU time, GPU time, system memory, etc.) to perform tasks (load a dude, draw a dude, animate a dude). Optimization is being clever about not wasting our resources doing unnecessary things. This lowers the cost of performing these tasks. Scalability is the other factor - the number of things there are multiplies their overall costliness. This should make intuitive sense.

Let's have an example - imagine that you need cupcakes for a party. The cupcakes cost $5 each and there's a $20 flat delivery fee. We need five cupcakes for a party, so the cost is $20 (delivery) + $25 (5 cupcakes x $5) for a total of $45. Optimization is our way of reducing the individual costs. We can optimize either the cost of the cupcakes or the cost of the delivery fee. Maybe we can optimize the delivery fee down to $10 but can only optimize the cupcake cost down by $1 each. We only have time to choose one optimization. In this case, optimizing the delivery fee results in a better overall cost reduction - 5 cupcakes x $5 apiece + $10 delivery is $35, while 5 cupcakes x $4 apiece + $20 delivery is $40.

Now think about what happens if the numbers change. Instead of needing five cupcakes for the party, let's say we need a thousand cupcakes. 1,000 cupcakes x $5 apiece + $20 delivery = $5,020. If we optimize the delivery fee, the cost becomes 1,000 cupcakes x $5 + $10 delivery = $5,010. Here, optimizing the cupcake price is a much better deal than optimizing the delivery fee! If we reduce the price per cupcake by $1, we get 1,000 cupcakes x $4 apiece + $20 delivery fee = $4,020.

Bringing this back to games, it should make sense now. Ubisoft spent a lot of engineering time optimizing the cost of each NPC (cupcake) down as much as possible because they knew that they would have a huge number of them in their game world. Yandere Simulator did not spend as much time optimizing their NPCs, so their NPCs are more costly than the WatchDogs NPCs.

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Let's establish a baseline first - the purpose of a portfolio is a showcase of your best work to get you hired. Thus, anything that goes into your portfolio is put there with the goal of getting you a job. Does that make sense? I hope it does. With that in mind, here are some skills that teams tend to look for in a gameplay programmer, and some sample work a candidate could use to demonstrate that she knows how to do those things.

Data-Driven Gameplay Systems

Much of the time, gameplay programmers need to build a system that requires minimal further maintenance and updates for designers to create the content. If the designer can use the system to create more content without needing the programmer to rewrite large parts of it, that's the ideal. An example of this would be an equipment system for a normal RPG - imagine a weapon that adds stats and maybe has a proc on hit. A weapon-creation tool might allow a designer to set the weapon's data - name, damage, attack speed, stat bonuses, and procs (e.g. effects that fire on hit, on damage taken, etc.).

3D Math

A lot of gameplay happens in a 3D world, which means that 3D (vector and matrix) math is important to understand where things are and how to get them where we need them to be. An example of this might be a backstab feature in combat, where a player can deal bonus damage to an enemy if the player is behind the enemy. Detect when the player is attacking from behind the enemy, deal some extra damage, and provide some feedback to the player to notify them that they have successfully backstabbed a foe.

Optimization

Getting games to run at 60 fps is certainly not easy. Understanding how to improve performance is very helpful. An example of this would be to have a demo where you show a lot of something, but still keep it performant. A good example is a navigable field of grass that has non-uniform wind blowing across it. Making a field of grass is not that difficult, but getting said field of grass to perform at a high frame rate with a lot of grass in it is.

Remember, the purpose of the portfolio is to showcase the skills a candidate has to help her get a job. If a candidate has things to show (and, more importantly, talk about), it helps persuade the hiring managers that she can do the kind of gameplay engineering work that they need done. A candidate won't need all of these in a portfolio before applying - these kind of examples are helpful to have if she doesn't already have work experience in those areas. If she has work experience in those fields already, they should be on her resume and we hiring managers should be aware of them. If she does not have that kind of experience, then she should have something in her portfolio to demonstrate her skills.

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

It really depends on the project. For brand new games, the best we usually do is in-game comments and maybe some auto-documentation because we're writing a lot of new code as we go and time spent documenting is time not spent writing more code.

For established franchises and lifestyle games (e.g. Call of Duty, Destiny, FIFA, Elder Scrolls, etc.) that continue on using the same codebase, documentation of existing systems is more extensive and robust. This means that, as the last big game/expansion/deliverable ships and the next one begins development, there will be new devs hired on who will need to ramp up and older devs who hold a lot of tribal knowledge will leave the project (either finding new jobs, getting promoted to management, or transferred to a different project internally). This makes documentation of the existing codebase significantly more valuable over time.

My current employer is one of these kind of large franchise developers so we have multiple vectors of documentation of the various game systems. We have tools that auto-parse and auto-format comments in code in order to collate them into a searchable form, we have an extensive internal wiki to search for debugging and implementation information, and we've got tools engineers whose job it is to make sure as much of it is automated as possible so that there's little difficulty in generating good documentation for those who come after us.

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Some readers may not realize it, but you're actually asking a math question here. A bit is a value that can be one of 2^1 = two different values - 0, or 1. Thus two bits can represent up to 2^2 = four different values - 00, 01, 10, and 11. Three bits can represent up to 2^3 = eight different values - 000, 001, 010, 011, 100, 101, 110, 111. 10 bits can represent up to 1,024 different values, 16 bits can represent up to 65,536 different values, 32 bits can represent up to 4,294,967,296 different values, and 64 bits can represent up to 18,446,744,073,709,551,616 different values.

As you can see, 64 bits has a much larger range of potential than, say, 8 bits. However, just because it can store a lot of different values doesn't mean that you want to use 64 bit values everywhere. Imagine that I'm working on a game that has committed to four playable races - dark elf, hot elf, keebler elf, and santa elf. If I used a 64 bit value to store the player character's race, I'd wasting a large amount of that usable space - I really only need two bits to represent the four different possible races on a character so I would essentially wasting 62 bits of memory to store that one value. However, locking myself in to two bits for the player character race means that I'm also committing to never adding a fifth supported race (e.g. hers elf) for the lifespan of the game, because I would need additional bits to represent the fifth race. If I were forward-thinking, I might split the difference and give myself four bits (16 total races, room for up to 12 additional races) for the lifespan of the game.

Your question topic is known in programmer space as "bit packing" because the most efficient solution is to use the fewest number of bits possible to store the data. This way we don't waste computing resources that could be utilized elsewhere. A lot of clever engineering is about utilizing facts we know about the game's design (like the number of supported player races) and using that to shave down the needed bits to represent the data. This usually results in immediately improved performance and problems down the line if the game continues for years and the old assumptions get broken (which is often what happened when many old live service games needed to convert from [32 to 64 bits]).

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

It really depends on what your goal is. "Learning to program" is extremely broad, ranging from "barely enough to be a hobby" to "this is a useful tool in my toolbox" to "this is my decades-long career". If I were going to teach someone programming, I would start with the basics and then branch depending on what the student's goal is.

The basics - learn the building blocks of programming as a means of solving problems and how to translate the desired answer to a problem into a way that the computer can understand. This means understanding what a loop is, how conditions work, and how the computer understands instructions. One can learn this from most online tutorials or classes, and should be able to break down a human answer into a set of computer-understandable commands. The student should be able to have a functional (if basic) vocabulary of programming terms and should be able to form coherent and correct solutions to do the processing they wish the program to do for them.

After that, it depends on what the student wants to learn. If the student wants to make her own game, we can focus on lighter weight gameplay and the tools needed to build the game out. If she wants to focus on a specific field (e.g. gameplay, networking, tools, graphics, etc.) then we'd focus on that specific field. If the student wants to get a job in the field, then we'd focus on data structures, performance, and common test/interview questions.

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Optimization tends to be tailored to the specific tasks at hand. Programmers on large projects often build or use out-of-the-box tools called profilers that measure performance in specific areas of the code. Based on the profiler reports, the engineers can see where the majority of processing time is being spent and then consider looking into optimizing the heaviest offenders.

If we're optimizing the visuals specifically, then it's a question of what saves the most processing time. The best optimization is often not to render anything at all. If the hardware doesn't have to render and animate a thing, it saves a lot of processing time. We do this by not rendering models that the player can't see (e.g. stuff off-camera, stuff behind walls, stuff too far off in the distance, etc.), and also by not rendering the parts of the model that the player can't see (e.g. if you're looking at the front of a building, you can't see the back of the building at the same time without a mirror or something behind it).

That's only one example of optimizations we make. We load cheaper models and/or textures for things that are far away (LODs), we can reduce the frequency of animation updates for characters in the background or on the peripheral edges of the camera that players aren't focusing on, and so on. There are as many ways to save processing time as there are ways to spend it. If you have the time and interest, I suggest looking at the #game optimization tag on this blog, since I've written at length about various means of optimization in past posts.

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr