Elective Spawning: Programmer Edition!

In our last post, we began talking about our new spawning system in a general overview kind of way. Today, we're going to expand a bit into the technical side of the exciting improvements we're making to the system. This is the first blog post to be written by a member of the programming team, in our continued effort to give you perspectives from all around the studio. Stuart is going to be giving you a taste of how he and the other programmers actually created the new spawning system. We're going over some basic stuff first for those of you who may not already know, so for all you smarty pants out there - bear with us for a few paragraphs until we get into the specifics.

---

The Basics

APB – and every computer program ever created – is comprised of two essential ingredients:

• Code, which is the list of instructions telling the computer what to do and when to do it, what decisions to make and how often to do things.
• Data, which is the set of information about the game world and every last detail within that world.

We write code, which works with this data to create the game, but the code and data are organised in a very specific way.

Everything in APB is an object. Programmers see everything in terms of objects. An object is a small, self-contained clump of code and data which interacts with other objects to make the game work.

The complexity of APB is formidable, but because everything is enclosed in its own object, I can focus intently on one small piece of APB at a time without worrying about anything else. APB has many thousands of objects, all working together to make the game work, so this is the only possible way to tackle this complexity.

Objects generally correspond to “things” in the game. Each character is an object, every vehicle and pedestrian, each stop light and fire hydrant - they are all objects. There are other objects in the game world which you won’t be able to see. Spawn zones are a good example, as they exist in the world at a particular location but are ultimately just areas of empty space. Yet more objects work entirely behind the scenes, such as those which calculate collisions or run missions.

---

Everything in APB is an Object

All the objects in APB are organised into a hierarchy depending on how they are to interact. The way in which objects relate to one another tells us what this hierarchy should be. There are two key ways in which a pair of objects can relate to one another:

“One object has another object.”

A spawn wave is a set of characters which will spawn at the same time. Everything in APB is an object, so naturally we created a new spawn wave object to represent this. Characters in a spawn wave will always be on the same team and indeed there is already a team object.

We say that a team object has a spawn wave object. This means that the spawn wave object is owned by the team object, and as such the team object will be responsible for creating new spawn wave objects and putting team members into spawn waves when they die.

The other way in which objects can relate is subtly - but fundamentally - different:

“One object is a type of another object.”

One feature of the new spawning system is the ability to spawn directly into a vehicle. Previously it was possible to spawn only using the spawn zones dotted around the district.

We use the general term of “spawn point” to describe spawn zones and vehicles; a spawn point is just a something you can spawn into, whatever that might be. We say that a spawn zone object is a type of spawn point, and also that a vehicle object is a type of spawn point object.

An important point to note here is that the new spawning system is designed to work with these generalized spawn points. It deliberately doesn’t worry about the specific details of what a spawn point is; it lets the spawn zones and vehicles themselves worry about the particulars. This means we could potentially extend the new spawning system to allow spawning using something else in the game, as long as it can be made into a type of spawn point. In fact, we wouldn’t actually need to change the spawning system itself, as it would carry on working with what it sees as “spawn points”.

---

The New System

After we decided to move ahead with a new spawning system, the first order of business was to figure out exactly what we were trying to achieve. Our designer wrote a 'Requirements' document, which gave a high-level overview of all the features needed for the new system. There are three main features:

• Elective Spawning, where you choose where to spawn by clicking a spawn point on a map
• Spawn Waves, where you are able to coordinate spawning with team mates
• Vehicle Spawning, where you may spawn directly into a vehicle

Most of this information was given in the form of a timeline, which describes the series of events from the instant a character dies to their subsequent re-spawn, as seen below:

1. The character dies and joins a spawn wave with other dead teammates.
2. The death camera views the character’s rag doll.
3. The elective spawning map is shown with a countdown. It is a map of the district which shows the set of spawn zones and vehicles chosen for the spawn wave. The best spawn point is already selected for the player.
4. The player may click different spawn points. They will see which spawn points other members of the spawn wave are clicking, so they may conspire to spawn at the same location.
5. A spawn point will be disabled if an enemy approaches. This can invalidate the player’s selection and they will need to choose a different spawn point.
6. When the countdown reaches zero, the character will spawn at their chosen location. If their selection was invalidated and they did not choose another spawn point then a red countdown begins.
7. If the player clicks a spawn point during the red countdown then they will spawn immediately.
8. If the player still hasn’t choose a spawn point when the red countdown goes to zero, the character will spawn at a point chosen for them.

The document went into more detail about each stage, and included a mock-up of what the elective spawning map should look like:

An example of the spawn selection UI. As you can see, you are given 

information on where your team died and where they plan to re-spawn.

The Legend for the Elective Spawning Menu. 

NOTE: The enemy location visibility works in the same way as the 

radar - if they are driving or firing a weapon, they are always shown.

There were a series of meetings where the finer points of the requirements were discussed, and after these meetings a 'Design' document was written. This outlined the key strategies and decisions that needed to be made by a programmer when creating the new spawning system. The actual process of that creation is called the implementation.

---

Server vs Game Client

There are two sides to every coin, and APB is no exception. There is the game client itself (which you will be very familiar with), but there is also the server, which hosts the game world and allows you to play with and against other people.

A key question we had to ask ourselves was: which parts of the new spawning system will be added to the server, and which parts will be added to the game client? In other words, who is in charge of what?

The server acts as the ultimate authority of all things. It has complete knowledge of every aspect of the game world. As such, it would:

• Remove characters from the world when they die and add them again when they spawn.
• Create spawn waves and put characters into waves depending on when they died.
• Choose the best set of spawn zones from those scattered across the world.
• Add any vehicles which have the appropriate modifier.
• Validate the spawn point selections a player makes.

The game client doesn’t have any authority to make decisions which would affect other players. It only has a limited knowledge of the game world, knowing only about that which is directly relevant to the player. As such, it does much less than the server, which:

• Shows the elective spawning map.
• Handles the mouse input as the player selects spawn points.

This division of responsibility also showed us the sort of information which would need to be communicated back and forth between the server and game client. The server will need to send the set of spawn points it has chosen to each game client involved in the spawn wave, to allow the elective spawning map to display them. The client will need to send the player’s selection to the server, when they click on a spawn point.

---

Exceptions to Every Rule

The new spawning system must be able to handle edge cases. An edge case is a situation which is exceptional or out of the ordinary. We needed to take some time to imagine all these possible scenarios and think of the best way to deal with them. Here are some of the edge cases we came up with first:

• What happens if a vehicle is destroyed after you’ve selected it on the elective spawning map? Wrecked vehicles can’t be used for spawning.
• What happens if a mission ends when you are in the middle of elective spawning?
• What happens if you are kicked from a team while in the middle of elective spawning?

These won’t happen very often, but they still must be proactively accounted for and handled appropriately.

Edge cases can be time consuming and sometimes difficult to deal with, especially in testing. But we actually cheated a little to make testing of these edge cases easier - we altered the configuration of the new system so that it spent a full 60 seconds on the elective spawning map! This is nothing like the actual amount of time you will see the map for, but this gave us sufficient time to run through all the combinations we were interested in.

---

So, perhaps that’s given you a little bit of an insight into the life of a programmer at Reloaded.

Next time…