“Dominion” is a strategic top-down local multiplayer battle arena.

PROJECT INFORMATION

Date: 5th semester (2015/2016)
Duration: 5 months
Team Size: 3 people
Technology: Unreal Engine 4, Blueprint Visual Scripting
Constraints: Develop a fully playable prototype with the focus on AI.

Gameplay Video

Introduction

Our task was to create a game within a three month period, with each team member spending 600 working hours on this project and an estimated 1800 working hours in total. This project marks to be the last and greatest group project of our game design studies. Having this in mind; we were able to stretch our scope a little bit further than in previous projects. The topic for this group project is: “Agents”.

Concept

The focus of this project was to design a game with an emphasis on artificial intelligence. An agent represents an entity, which can operate by itself without constant player input. It can be a representation of an actual visible character, like for example in games like “Lemmings”. It can also be visual less apparent while managing the whole economic system of a game, like for example in games as “Sim City”. Agents are game entities which are operating as independent individuals or as a group, like for example as in the flocking behavior of ants.

One of the main advantages of agent-based systems is that the player can maneuver a high amount of units without the need of steering each unit individually all the time, like for example in Real Time Strategy games such as “StarCraft”. We decided on a system in which the player has to handle a small number of units. The units would have individual characteristics, behavior and a somewhat sophisticated artificial intelligence system. Each unit would have a unique personality.

Initial Idea

Our game was aimed to be a multiplayer local battle arena, in which each player is in charge of a little squad. Each squad member would have its unique statistics and therefore unique strengths and weaknesses. This again would ultimately influence their decision making, thus their behavior. The player would not be able to steer the characters directly. Instead, the player would be able to set the statistics, the class and assign tasks to each squad member, which will determine their behavior.

There would be two classes: workers and fighters. A worker could be given tasks like scavenging for resources or building expansions. Fighters, on the other hand, could be given assignments like looking out for enemies and to attack them or to defend a specific area. The player would be able to change the assigned tasks of a squad member whenever needed, but the squad member would be forced to return to the base or expansion whenever a change of class is required. Meaning, that changing tasks within a class would be free of expenses, but changing the class of a unit would be uneconomical due to the required time to return to the base.

There would be several ways to win the game. A player could win by being the first to collect 3 out of 5 targets, a player could outplay the other players by being the first to reach the target amount of resources, or a player could be the last surviving race by destroying all enemy bases while maintaining the own base intact. Setting our game up as a local multiplayer was essential to us because we wanted to add a diplomacy system to the game mechanics. We hope this diplomacy system would leverage the player's social interaction on the metagame layer.

Art Style

We decided to develop a game which could be played against other players locally on one shared screen. The advantages of a shared screen are the excellent overview of the whole map, the full usage of the entire screen for every player and the convenient and comfortable set up for gaming sessions and presentations. We were eager to develop a fun and also good looking game with beautiful assets and animations. One of the main challenges was to find an art style, which would not only look good at full HD resolution but would also provide all four players an excellent overview over the action on one single shared screen.

Background Story

The background story of the game is about four scientist, who went insane because of their dedication to science. These mad scientist, are now creating their little army of minions to conquer the world.

Dr. ‘Dolly’ Dolbert, who created unsatisfied clones of himself.

Dr. Vicki Frankensteiner, who tried to keep people alive for too long.

Dr. Robert Asimov, who did not see any harm in researching robotics.

Lady Bugoni, who studied bugs and experimented with cross-species.

My Task Area

After our team has agreed on the topic “Agents”, we decided that it would be most efficient, if everybody is developing multiple gameplay concepts by her/himself. We would then have a pool of thoughts and ideas, which we could share, combine or redefine.

After having defined a gameplay concept, my task as the only programmer was to start prototyping. I realized that I would need a consistent level, which I began to develop and to block out in the engine with brushes, in order to be able to test the AI. I was then programming the units and a cursor as an interface to select and interact with the units. To be able to spawn those units, I was creating an object which would represent the base. I created several items for the AI to interact with. Having all this set up, the next big task was to implement the units' behavior. Things like the implementation of GUI and animation had to be done as well.

Prototyping

A game concept which heavily relies on artificial intelligence was new to us, and it seemed very important to have a running prototype as soon as possible. We needed to figure out, if and what makes a game fun, in which the player’s main activity is watching, not interacting. Besides, I was very unfamiliar with AI systems and needed to understand its capabilities as fast as possible.

I started with a level generator, which would stack random rooms and corridors together. The idea was to confront and test the AI on many different level layouts. I realized that it was too complicated to observe and understand behavior in ever-changing environments. That is why I abandoned the level generator and started blocking out a new persistent level.

Making Changes to the Concept

If the behavior is following a simple ruleset, the player will not get disappointed as long as the behavior is consistent. The player is able to comprehend the condition, which led to specific actions in certain situations. If the patterns are too complicated, the player might not be able to follow how decisions are made. The behavior should always be readable and considered as reasonable in any situation.

Our game did not deliver on that. Behavior was wildly interconnected with the statistics of a unit and it became challenging to comprehend how decisions were made. Since the unit’s behavior was unpredictable, the actual behavior often did not match up with the expected behavior, and the player was getting unsatisfied. To minimize situations, in which the player can get unsatisfied, we implemented the feature, which allowed players to assign tasks to units directly so that the player could overwrite the units decision makings.

Level Design

I started to sketch out a level on paper and used this sketch to block out the level in the game engine. It gave me the opportunity to test the behavior in a consistent environment and helped Jeremia in developing the visual appearance of the environment. Blocked out areas got decorated with his Assets. The plan was to combine a consistent layout of the map with a little bit of randomness for the target placements etc., to raise the replayability.

Because we were aiming for a shared screen game, every bit of space had to be used wisely. Even the placement of thick solid walls would result in unused space. Using thin planes to divide space would not look right. A solution was to handle differences in heights to separate areas from each other.

Scaling Down

The level design part was a huge task to be tackled. To fit the whole map into one single screen, we had to scale everything down. We were not able to predict whether we would be able to fit everything into one single screen in a reasonable manner and whether this concept would work at all. Furthermore, it was quite difficult to predict, what kind of level design would work. It was necessary to try out a lot of features and to keep the good ones and to throw out the bad ones. The shared screen concept in combination with the 1K HD resolution was representing a though constraint, and I am glad, that we figured out a solution. We also experimented with different angles of projection. One idea was to develop this game as a table surface game. We dismissed this idea because it did not provide enough benefits compared to the rather complicated setup.

Artificial Intelligence

It is crucial to differentiate between: what is performing the action, what is controlling the performer and through which controlling device is the performer being controlled. The performer could be the representative game entity, the avatar for example. The controller could be a human being controlling this avatar through an input device, but also a non-human system, like for example an AI could be the controller.

This architecture comes handy, whenever the controller wants to change its performer. Racing games, where the player can choose from different car models, is a good example. Even more so, this allows AI to control the same type of performer in the same manner as humans would. Empty slots can be filled up with bots, as an example.

Behavior

After having set up the meshes for the units, I now needed to feed them with behavior. For that, I needed to set up an AI Controller and a Behavior Tree with all its Services, Decorators, and Tasks. According to my previous example, the representative body including the mesh would be the “performer”, while the behavior tree would be the “controller”, and the AI controller would be the “controlling device“.

The sensing component enables an AI to sense his environment through vision or hearing. Unlike with human players, the AI does not look at the screen but instead senses the surroundings out of the bodies perspective. Nonetheless, the sensing component is part of the AI controller. The AI Controller does not only possess the body and runs the behavior tree on it, but also contains the sensing component. With this sensing component, the AI can sense specific objects in its surroundings. In this case, the sensing component can detect all the intractable game objects. Every sensed object is being categorized and analyzed to figure out, whether it is relevant and should influence the behavior.

In this example a worker is sensing a fighter:
--> is this fighter one of ours?
--> is this fighter already occupied with something?
--> am I already threatened by another fighter and if so, is this other fighter closer to me than the sensed one?

If any of these checks are being answered with yes, then the sensed fighter will be ignored. If all of them are being answered with no, then the detected fighter is an enemy fighter, which has no other occupation right now and is closer than any other threatening opponent. This relevant fighter information will then be sent to the behavior tree and saved into a variable. Those variables, which are being set by the sensing component in combination with variables which are set by the player, when assigning tasks, are forming different combinations, which can result in different outcomes for the behavior.

In this example we have a fighter with different conditions set up for entering a specific behavior:
fighter sensed relevant enemy worker --> go to enemy worker
fighter sensed relevant enemy fighter --> go to enemy fighter
fighter is low on health --> hide

Having these conditions and behaviors ready, we can now set up the priorities for each branch. In this example, the last condition would have the highest priority, whereas the second last condition has the second highest priority. Having these priorities setup will let the behavior tree decide which behavior is more important. In our example: If the fighter senses an enemy worker and an enemy fighter at the same time, he will approach the enemy fighter, due to its higher priority. In any case, if he is low on health, he would flee, since it has top priority.

Animation

Another Task of mine was to implement the animation assets into our game. That involved setting up the Animation Blueprints and Animation Blendtrees. An animation is essential to give the player visual feedback about the state of the game. It is necessary to communicate and visualize the current activity of the units.

To guarantee a smooth transition from idling to running, I was setting up one-dimensional blend spaces with loopable animation assets of idling, walking and running. Depending on the velocity of the unit it would perform a scaleless blend from idle to walk and from walk to run. Because sudden changes in the velocity were causing little hiccups while blending, I was feeding the blend spaces with an interpolated value of the velocity.

A State Machine regulates the timing of the transition from one animation state to another. It observes whether predefined conditions for a change are matched and performs the transition from one state to another if necessary. To get the fighter units to play the walk and the attack animation at the same time, I had to setup Montage Blueprints. These Montages can be fired and stopped via Blueprint and stitched onto an active pose, beginning from a dedicated bone. This way, the fighters final pose can receive the locomotion pose of the state machine while performing the attack animation for the upper body.

Recap

Compared to previous projects, this turned out to be the most complicated one so far. I have tremendously underestimated the workload of complex AI systems. It took me a lot of time to get used to the AI components of Unreal Engine 4, and I needed numerous iteration steps. Nonetheless, I have the feeling, that I have learned a lot about game AI and that I have a much better understanding of it now. I think that this knowledge will come very handy for future projects.

The concept of the game has changed a lot during development. Features had to be replaced or removed. One of the significant changes was the introduction of the assignable tasks. I think that only through these several iteration processes it was possible to get into that final stage. I have to learn to set the scope right next time, to get my work/life balance right. The crunch time was getting very tense, and I want to avoid that for future projects.

In overall, I am satisfied with the outcome of this project. The game is fun and helped me a lot to understand the basics of game AI.

>>This is just a slice. For my full documentation: Click HERE!<<