The importance of NOT optimising

I talked briefly already about the importance of not trying to optimise when prototyping, but as it turns out, ‘not prototyping’ is generally something I would recommend you do almost all of the time.

This seems like a very odd thing to be recommending, but here are some reasons why.

• You may not need to. If your game is running at 60fps, there is simply no need to waste time optimising. Remember that your time is a precious resource, you only have so much time to make a game. Wait until you actually need to optimise before you spend time doing it.
• Always profile first. When your game does begin to run slower, don’t second guess your code and spend weeks or months trying to make everything faster. it will amaze you what ends up being the problem. Use a profiler to actually show you what is taking the most time each frame, and focus in on that.
• You probably aren’t helping anyway. Optimisation is a very in-depth subject, something that you might think needs optimising may actually be optimised by the compiler anyway, and your efforts could even make it worse.

If in doubt, ALWAYS write readable code over optimised code. Even in AAA, code that someone else can come and jump into is almost always preferred over fast code (unless we’re talking about very low-level systems), because when people leave, someone else will have to try and understand it.

Tips for rapid prototyping

Rapid prototyping is an important part of development any game, and is an especially necessary skill when working on big titles. The ability to get something out that plays well and demonstrates your idea fast at the beginning of a project can mean the difference between the game adopting something new and unique, or just falling back to using a standard design that has been lingering in the industry for decades.

The key is that in that brief prototyping phase, you have to be able to produce something that makes an impression, and you have to be able to do it fast.

So, here is a quick collection of tips to really focus on.

• Your prototype should be throwaway. This means you don’t waste time optimising or writing good code you plan to use later. Also scrapping something and writing the system again is a really great way of working out the best way to implement something. Just like walking away from a tough problem, your brain has an amazing way of solving problems for you when you’re not thinking about them.
• Use third party tools. Sometimes you have to convince the studio to let you use a third party tool such as UE4 or Unity, but it’s almost always worth it as most custom game engines take far longer to get content into them. Again, push on the fact that these things are throwaway, so it’s ok if a quick mock-up is created in some other tool.
• Don’t be afraid of messy code. The point is to make this fast, not well. A nice tip is to encapsulate things (if you happen to be coding) in blocks of empty scope instead of using up time creating new classes.
{
     //a simple block like this can encapsulate variables
     without the overhead of writing a new class
}
• Don’t use anything other than basic container types. In fact don’t attempt to optimise in general/ This applies to all kinds of scripting. Your time is the most precious resource here, so use it as sparingly as you can.
• Look and feel is important. This is a little counter intuitive, but despite the above you have to remember that you can’t rely on people filling in the blanks when they play it like you do. It has to communicate what you are trying to achieve, so this often means - camera shake, hit-reactions, some basic effects, sounds and so on. these are linked with the basics of what makes something feel good so you can’t afford to miss them out.
• Sometimes polish will save your idea. If you’re lucky enough to work with leads that can see past cubes and debug text, then great, but recognize if this is not the case at first and get a modeller and animator to throw together a quick model and some basic animations before you show anyone. Showing a prototype too early can means its death before you’ve had a chance to complete it.

Djikstra and A* search algorithms

Since we covered navmeshes briefly, I also thought it would be good to provide a quick overview of the pathfinding algorithms that underpin them.

This knowledge will serve as a good jumping off point if you want to delve deeper, but can also be very useful in recognising what might be happening with an AI when they are not behaving as expected.

Djikstra’s Algorithm

This is the most basic search algorithm that we would reasonably use in a 3D video game, and it is very closely related to A* search which is the industry standard algorithm, so it’s a good place to start.

The concept is very simple.

1. From your starting point you search every adjacent space and place them into a list representing the frontier of the search.
2. After all of the adjacents have been explored, you search the adjacents of the frontier nodes
3. You repeat this on and on and on, until you find the goal node
4. You then recurse back though the adjacencies until you have a path back to the start

A* Algorithm

This is simply an optimisation of Djikstra. It uses a concept called a Heuristic - this is simply an estimation of how close each node is to the goal node. For this example we will use linear distance to the goal node (the most common heursitic).

1. From the starting point you look for the adjacent with the smallest heuristic value and place them into a list representing the frontier of the search
2. You then move onto the next node with the lowest heuristic cost
3. You continue to do this until you reach the goal node
4. You then recurse back though the nodes until you have a path back to the start

The difference here is that instead of searching all adjacencies before you expand the frontier, you are trying to guess which direction the search should go in to be successful faster.

Of course this isn’t always optimal, as shown in this example. however it’s an edge case and it still slightly more optimal that Djikstra seaching the same space.

Navigation meshes explained

As a gameplay scripter we work a lot with AI, and so it’s important to understand the basics of how these systems are put together so we have a better understanding of how to work with them.

A little history

Historically AI navigation was handled with waypoint grids. They use a search algorithm to query the location of an AI and work out what order they need to travel between nodes to get to the desired location, resulting in a path they can follow.

This was fine for a long time, until someone came up with the concept of a navigation mesh. These have an enormous amount of advantages we'll cover briefly.

For pathfinding they actually work the same way as waypoint grids, only each point is associated with a convex polygon. An initial path is still calculated using the central points of each polygon.

The difference is that the paths then go through two phases of optimisation.

The first is a culling phase, in which the grid works out if there are any unnecessary links.

The path then runs a smoothing algorithm using the bounds of the polygons and a radius for the agent to set how extremely or subtly this path is smoothed.

This gets rid of the strange zigzagging we used to see in games - the result of sticking to the links on a waypoint grid.

Further notes

Just on their own this would be enough to use them over grids, but there are some added benefits that come with this implementation.

Path correction
AI can use the knowledge of polygon bounds to correct their paths around obstacles, as long as they can remain within the bound of the mesh.

Smarter actions
The AI can make sure that they have enough space to complete an action, such as a dodge-roll, so that they avoid doing stupid looking things like rolling into a wall, or worse - rolling off an edge.

Extensibility
Navmeshes allow for multiple agents with different navigation requirements, such as larger or smaller AI's, or AI's that have restrictions based on turning circles (things like planes, boats or vehicles), therefore allowing all of them to use one set of navigation data.

How to explore a new game engine

Whether you are working with well documented, widely used engines like Unreal, or using a custom set up on a big project, the ability to quickly find your way around a new toolset or codebase is an important skill. Often you need to get up and running fast, and get over that hump where you start to be fluent with what you’re using.

This is often a daunting or seemingly impossible process for people with less experience. Many people have recently asked me what to do in these situations, and the answer is almost too obvious, and too un-technical to even occur to most.

The key is to actually use basic search functionality to find something relevant and then to expand from that point. From there you then dig down into anything relevant, and also explore any functions that you don’t immediately understand.

When all else fails sometimes you have to fall back on these most basic techniques. It sounds like strange advice, but when there is no documentation, and no obvious place to start, this is how you begin to piece together your knowledge of a toolset.

And be aware that this can take years. I have worked on projects where large teams are still not 100% familiar with all of an engine’s facets after using them for multiple years.

So...

Think of synonyms to search for. If you’re trying to find out how the AI works, search for character names, commonly used keywords. Drill into base classes then search for them and see where they’re used. You’re essentially trying to find an anchor point to then build up your knowledge base from.

With commercial engines like UE4 you have the benefit of being able to search their huge list of nodes, and documentation. Pull them out and see what they do. See what they link to and be aware that this knowledge will start to gel together the more you absorb.

With something like Unity for example, searching in-engine is less easy. Here documentation is your friend. If you don’t know how to do something, don't agonise for hours, just google it and get used to looking up their documentation pages and how to read them. It is a skill you will need time and time again on new projects so get used to the idea of jumping in at the deep end.

And as one final piece of advice, if you’re lucky enough to be using a commercially available engine, the associated answerhub or stackexchange websites are a brilliant resource.

Delta time

The following is part of an ongoing series of basic tutorials for gameplay scripters.

Delta time is a simple but fundamental aspect of how we program in games.

Simply - delta time is the measure of how much time has passed between each frame. Updates aren't fixed (they can take different times to complete), because of this, if you are moving an object a fixed amount each frame, it will actually move at a variable speed.

What you really want is to be able to move something at a constant speed.

The solution is simple: We measure the amount of time passed in milliseconds since the last frame and we multiply it by our delta time.

This means that if a frame takes more time to complete, your object will move further to compensate.

SudoCode
object's position + increment * delta time

Unity C#
myObject.transform.position += myVectorOffset * Time.deltaTime;

UE4 Blueprints

Strongly vs Weakly typed languages

The following is one of a series of bite-sized lessons on useful programming terminology. Understanding these things can eventually help you learn new languages very quickly by making educated assumptions about how they work.

You may have heard of the concept of strongly or weakly typed programming languages. Although these concepts are not rigidly defined, the following is a mostly agreed upon definition of the differences between them.

Strongly typed

• must define the type (integer, string, float, etc.)
• For example, in C++ you declare a type inline or before you use a variable int myInteger = 1;
• may produce errors if the data passed is not exactly, or close to the expected type
  int myInteger = “string”; //ERROR

Weakly typed
(also called ‘dynamically typed’, 'loosely-typed' or 'type-fluid')

• don’t need to define type
• For example, in Javascript
• may perform implicit type conversions
• more likely to produce undefined behavior than errors, but variables are not limited to a single data-type in their lifecycle

  
  var myVariable = 5;
myVariable = “string”;

Scripting languages vs programming languages

The following is part of an ongoing series of basic tutorials for gameplay scripters.

Many have asked me what the difference between scripting and programming languages are, so I thought I’d write a short post about it.

The truth is that the line is often blurred between these two things, and people often refer to scripting as the act of creating content with something that resembles code.

In general though, there are some aspects that can be broadly applied to most (but not all) scripting or programming languages that offer some distinction

Scripting Languages

• Often uncompiled meaning that what you write it what actually gets read by your program. This is known as being ‘interpreted’ (rather than ‘compiled’)

  The above means they are slower to execute than programming languages

  It also means they can often be live edited if your set-up allows it, which is brilliant for iterating on a feature quickly and is relatively easy to set up.

• They are often designed to be a middle ground between the more technical engine code and the game, mostly being designed to be designer friendly with complex sequences of actions being wrapped up in easy to use functions.

  To give an arbitrary example, a function like ‘GoAndOpenGate(Sully)’ could take a string name (Sully), search for the nearest gate, calculate a path there, run the relevant locomotion and animation scripts, position the character in the right place and send messages to open the gate.

Some Examples of Scripting Languages

• Lua
• Lisp
• AppleScript

Programming Languages

• Are compiled before the game is run into an optimised, more computer-friendly format

  This means faster execution

  It also means they cannot be altered at run-time, unless your set-up allows you to recompile and reload modules on the fly, but this is harder to pull off.

Some Examples of Programming Languages

• C++
• C
• C#
• Java

Understanding and working with radians

The following is part of an ongoing series of basic tutorials for gameplay scripters. Note also that this symbol - Π is Pi, but the font this site is using makes it look a little odd in my opinion.

Radians are a subject that confuses some when the first start programming, and because of this they are often avoided. However, they are a very simple concept that can be extremely useful when understood. Not to mention that many libraries provide functions that return radian values, so it’s important to know how to work with them.

Ultimately they are most useful to us when using trigonometric functions which make up our mathematical bread and butter as gameplay scripters.

The basics

Radians are the standard units for measuring angles. There are 2 Π radians in one circle. In other words there are just over 6 radians in the angle of a circle. If you trace along the edge of a circle the length of its radius and mark the start and end points - the angle between those points is one radian.

Conversion

We know that 2 Π radians = 360 degrees. So we know that Π radians = 180 degrees. We can then of course see that 1 radian is equal to 180 degrees / Π and this is what we use to convert the values between degrees and radians.

Radians to Degrees

Sudocode
ourRadianValue * (180 / Π)

Unity C#
ourRadianValue * Mathf.Rad2Deg

UE4 Blueprints

Degrees to Radians

Sudocode
ourDegreeValue / (180 / Π)
But because multiplication is less expensive and safer when programming we instead use:
ourDegreeValue * (Π / 180)

Unity C#
ourRadianValue * Mathf.Deg2Rad

UE4 Blueprints

Event driven systems vs Polling

The following is part of an ongoing series of basic tutorials for gameplay scripters.

Event driven systems vs polling

Simply this is the difference between code that checks or ‘polls’ every frame to see if a condition has been met, and code that is called only once, when a condition triggers a function to be executed.

Let’s look at an example of a damage system.

Polling

We run a check, every single frame to see if any bullet’s position overlaps with the player, and if it does we subtract some health.

Event Driven

The function used to subtract health is only ever called when the bullet has hit the player. When the bullet hits them, a check is run to see if the target has health (so for example, is not a wall) and if it does, we call the relevant damage function.

Where possible event driven systems are far better because they reduce function calls drastically, and are far neater. If you find your script has to be called every frame, consider instead how you can change your code to be triggered on an event.

One thing to remember is that even things that seem like they should be checked every frame can often be event driven.

Take the example of a trigger box. You would think as it needs to check for the player consistently, it should be polling the world for them constantly. However, if you think about it, triggers only really need to query for collision on everything that’s moved significantly. If the player is still, it may be that it is unnecessary to check them. A player only trigger can therefore be tied to the players

Message sending vs function calling

The following is part of an ongoing series of basic tutorials for gameplay scripters.

Programming languages and scripting systems alike, use one, or sometimes both of two paradigms. These are

1. method or function calling based systems.
2. message sending based systems.

So what do the two mean? It's actually very simple, but important to know nonetheless.

In a method or function calling system, you have to have to know that an object contains a function in order to use it.

Say you've programmed a dog and that dog has a method that causes it to bark when called. In a calling system you would access the dog, and then call its bark method.

In a message based system you send a message to an object that asks if it knows how to bark, and if it does, then it would execute that code.

The benefit of a message based system is that it allows you to to treat many different objects the same. If two different classes both contain the bark function, even if they're completely different they will respond to that same message.

This is of course possible with function calling through inheritance. If both objects inherit from a base class that defines the bark function, then you can again call the same method on both, you just have to be sure the method exists or you will have an error on your hands.

This is called polymorphism.

There is another advantage to message sending, which is that in many systems you don't actually have to even have a reference to an object you’re trying to send a message to. You can often issue a message globally, and any objects listening for it will pick it up and execute code if they have a corresponding message handler.

So to summarise: Message sending is often more flexible from the offset, but function calling can be slightly more efficient. Realistically these differences are negligible, it's just important to understand the concepts as you might come up against systems that use either one of these in any games you work on.

UE4 for example, implements both in its Blueprints system.

Scripting Handbook: Vectors

The following is part of an ongoing series of basic tutorials for gameplay scripters.

In maths a vector represents a line that has a direction and magnitude (length).

Programmatically a vector is a list of numbers, for our purposes we mostly use vectors that hold 2 or 3 numbers, with a so-called 2D vector holding two numbers, representing X and Y, while a 3D vector holds 3: X, Y and Z.

What this means practically, is that we often use vectors to hold a position in X, Y and Z. This however, is not traditionally what we mean when we’re talking about a mathematical vector.

A true vector, the line with direction and magnitude, often represents a displacement - a set of instructions that describes how far and in what direction we should move.

How the data is stored does not change, whether we are storing a displacement or a position. If you look at the above image, you can see two quite different things. A point at 3, 2 and a 3, 2 vector. We would actually store these things in exactly the same way, it is our use of it that changes what that vector actually does.

It is also worth noting that a vector in programming languages simply refers to a one-dimensional array, (single list) or numbers. A vector as the concept we are talking about here, again just refers to how you use it.

You can see from this image a number of differences. A point does not store any kind of information about heading and has no length. A vector on the other hand, has no knowledge of where it is in the world, it simply represents a set of instructions on how to move from any point.

Vector Terminology Magnitude / Length - refers to the length of the vector from start point to end point.

2D Calculations

SudoCode
√ (x * x + y * y)

Unity C#
by accessing the magnitude variable in your vector -
myVector.magnitude;

UE4 Blueprints

3D Calculations

SudoCode

lengthOfAdjacentSide = √ ( (x * x + y * y) )

√ ( lengthOfAdjacentSide * lengthOfAdjacentSide + z * z)

The picture above should help explain this sudocode. You are trying to work out the length of a 2D triangle described by the dashed lines. You know one size because it’s simply the Z value. The other side, the one marked adjacent, is actually the length of a 2D vector laid flat.

Unity C#

by accessing the magnitude variable in your vector
myVector.magnitude;

by calling a static function in the vector library
Vector3.Magnitude( myVector );

UE4 Blueprints

Preventing mechanic burnout: A cutthroat rule of game design.

Next in a series of articles on practical game design now on Gamasutra.

"What, not How" - A goal centered approach to player motivation

Article now up on Gamasutra.

Featured on Gamasutra

You can now view the previous blog post as a featured article on Gamasutra! If you so choose...

Four-Step Puzzle Design

Good puzzle design gives a player that moment of epiphany, where suddenly all is clear, and the following satisfaction when your put your solution in place, and it works!

During my time working on Disney Infinity, I began to see that a lot of game puzzles, including many of our own, missed this mark. Even puzzles in some of my favourite games often left me feeling unsatisfied. The reason was simple - I kept finding myself solving puzzles through experimentation or trial and error without fully understanding either the objective or the true nature of the puzzle itself.

Consider this extremely simple and often seen game puzzle:

You walk into a room and see a heavy box and a weighted switch. You move the box onto the switch. A cutscene plays showing a door opening you haven't really registered before. You solved the puzzle before you even knew there was one. You feel cheated because if you had realised, you would have been capable of solving it. Even in a situation as simple as this, there is a better way.

Because of this I developed four steps to deal with this problem, they may seem obvious at first but it’s amazing how many puzzles, simple and complicated, fail this simple test.

Step one - the player understands the objective clearly.
You’d think this would be an obvious one, but time and time again we encounter design that skips this basic step, leaving players unsure why they’ve been presented with the elements of a puzzle in the first place. As gamers, we know when we encounter a puzzle we are meant to solve it, and so as a designer it's easy to lean on that fact and overlook this fundamental step. Clearly communicate the problem FIRST. Example: There is a locked door you need to get through.

Step two - the player discovers the pieces of the puzzle needed to solve it.
Basic things like switches and levers. Note though that it is OK if these objects need to be experimented with in order to discover their true function. Note too the emphasis on this ordering. You discover a problem that needs a solution AND THEN you notice the puzzle that needs solving.

Step three - the player notices the association between the components and works out a solution in their head.
This is an important one, though there are a few caveats I’ll discuss later. The player must be able to think of a solution before implementing it. What this essentially means is that they are not forced to solve the puzzle with simple trial and error. It may be POSSIBLE to solve with experimentation, but the key point is that it is not necessary. The puzzle is readable.

Step four - the player implements the solution and solves the puzzle
Again, obvious, but it exists as a reminder that working out a solution and implementing it are two separate stages.

Now consider this reworking of the same simple puzzle:

You drop into a room and observe a locked door which seems to be the only way out (step 1). After exploring more you then find a heavy box and a weighted switch that weren't immediately visible from where you entered the room (Step 2). You see a line from the switch to the door and deduce their association. After standing on the switch and observing no movement you guess the heavy crate might do the trick (Step 3). You move the box onto the switch and the door opens (Step 4). You feel a small amount of satisfaction that you were presented with a challenge, solved the problem and are now able to progress.

Now we can see that the original room had us noticing the puzzle elements first (Step 2), solving it (Step 4) and only then realising what our objective was all along (Step 1) and finally gaining a true understanding of what the puzzle had been and why your solution worked (Step 3).

There are a couple more things it's important to keep in mind.

First of all it's important to remember that experimentation can be a fun mechanic. These steps do not mean that everything has to be immediately obvious. It's fine to create a room in which each puzzle component, each switch and lever has to be experimented with to see what it does. The important part is that once the true functionality is discovered, the player can work out a solution.

Now that's not to say that confusing situations, games of chance or trial and error as a game mechanic don't have their place, but they are not puzzles. There is a difference between a maze and a labyrinth. Simply be aware of what experience you are trying to give the player and mould the gameplay to that goal.

The other caveat to this system are complex puzzles that are too large for the solution to be calculated and held in the player’s mind at once. There are many examples of these we've all come across before - a Rubik's cube or a Sudoku puzzle for example.

But here we can see that each stage in the greater puzzle is in itself a small 4 step loop. Every number written on the page in a Sudoku solution is a tiny calculation and solution that can be put in place and saves the progress of the puzzle and brings the overall solution closer.

This concept of incremental progress in more complex puzzles is an import at one, otherwise the player can feel lost and frustrated in the face of seemingly endless combinations. Most of us will have at some point fallen back to brute-force trial-and-error in a point-and-click adventure when the puzzles true goal has eluded us, and this is always very tiresome.

Playtesting

Finally, a note on testing. Just because someone can get through a puzzle does not mean it's a successful one. The joy of a puzzle is in solving a problem, if the problem is only understood in retrospect the puzzle is not successful. Time and time again I have seen confusing game design make it into a final product simply because the player is, after some time, able to solve the puzzle by mistake.

There are thankfully many solutions, asking the player to explain what they did after they've finished the puzzle and why they did it can be incredibly valuable. Also having them do this while watching a replay of themselves will often prompt their memory.

Another good technique is to sit with a player and ask them to think aloud while they attempt the puzzle.

So those steps again:

1. The player understands the objective.
2. The player discovers the puzzle.
3. Step three - the player works out a solution in their head.
4. The player implements the solution and solves the puzzle.

Attempting a puzzle is essentially an attempt to find a solution for a problem, so make sure the problem is clear. No one would attempt to solve a Rubik’s cube if it wasn’t for the coloured stickers on each piece.

Redesigning the ATAT

Click the image above to see some of Game Informers first thoughts on our work on one of Star Wars's most iconic enemies - the ATAT.

More concepts

More experimentation courtesy of Damian Buzugbe

Version 1.0

The first version of the cover-system project is up! Check it out HERE. Not bad for two months worth of evenings and weekends!

Almost done!

All behaviours are now implemented including a combat group based tactical retreat. It all just needs a little tuning now. The main blocker at this point is just a slew of editor bugs, specifically with behaviour trees. Hopefully they'll be fixed soon.