Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
The anatomy of missions in The Man From U.N.C.L.E.
In this post I will explain how we created a system that our designers could use to quickly create a wide variety of missions for The Man From U.N.C.L.E. game.
Originally posted on the Sticky Studios Blog.
When we started working on The Man From U.N.C.L.E., our main task was to create a large, open seamless world offering a high degree of freedom. The environment, resembling Berlin in 1963, allows players to explore, find new weapons and outfits, complete several missions, run, sneak, drive and interact with other players in real-time.
With the main platforms being IOS and Android, we obviously had to be smart about how we would construct the city. The environment needed to be big enough to stay interesting for exploration, but we also didn’t want to player to aimlessly wander around for longer periods of time. What also fed design choices were time and team size constraints. The entire game was developed in just 5 months with the Unity3D Game Engine.
One of the challenges we had to tackle were the missions. Throughout the city you can find various missions that are different each time you play it. So how were we able to create such a large amount of missions?
THE ANATOMY
A mission is set up using the following 2 major components:
A mission blueprint.
A mission area.
All systems rely on these 2 components and the information they provide to define what a mission is.
Blueprints
At the very base of our mission system, we have 4 different types of missions:
Delivery. Pick up a specified object and deliver it to the designated location.
Elimination. Eliminate the designated target.
Last man standing. Eliminate your opposing agent.
Prevention. Prevent your target from reaching their designated location.
These base mission types we constructed through what we called Blueprints. These blueprints are made with ScriptableObjects, which are classes that allows storing large quantities of data that can be referenced independently by other scripts while only allocating memory once. Considering that we are storing plenty of data in these blueprints that define our missions, ScriptableObjects are the perfect solution for storing that data.
These blueprints contain various bits of information:
In the screenshot above you can see the blueprint structure for the Elimination mission. I’ll go over the most important components in there.
Every mission can be made up of 1 or more stages. Once you meet the winning condition of the first stage, you can continue to the next and so on. So the first components we need to set up are the winning and losing conditions. These are all generic conditions that rely on the players interaction with the world.
There are no specifically made winning or losing conditions. The underlying systems only need to know if a condition is met or not and know what your main target is.
The designers can mix and match any of these conditions to make any mission they want. We support variations relying on “Complete this condition AND that condition”, but also “Complete this condition OR that condition” and any combinations between these OR/AND operators.
Optionally, we’re able to add a certain amount of time to the missions. This amount ties in with the “OutOfTimeCondition