Big Game Project – Post 5 – Final Post

In the final days before GGC I made/worked on the following:

• Pause Menu
• Results Screen
• Loading Screen
• Assisted Driving (derived from AI)
• Scene Transitions

Pause Menu

The pause menu is accessed by any player pressing the start button on their controller (if four controllers are connected but only two of them are racing, only the two active controllers can be used to pause).
Pausing the game triggers a global bool that stops every script from running. It originally set the TimeScale of Unity to 0, but then it stopped taking input for the pause menu so I had to solve it using the global bool.

The pause menu itself is a canvas that (de)activates and overlays the game screen, with buttons copied from the main menu that another programmer created earlier in the production.
The code for input I wrote to take every active controller into account with an internal cooldown for each controllers input so it doesn’t spam through the buttons.

Every button has properties like if they should have a confirmation window before triggering along with choosing the text displayed in it.

Fixes:

There is a cooldown for the A button that triggers when the confirmation window opens since it autotriggered when it wasn’t there (Confirm is done by pressing A, and entering the confirmation window uses the same button).

When switching scenes in Unity the global bools didn’t reset, so the return to main menu autotriggered when re-entering the Game state, fixed by having every static variable resetting in the OnEnable method of Unity.

 

Results Screen

Basically the same solution as the pause screen, only this was made on the final day so it was rushed together.
The Canvas activates when the game is done, it goes through every child the canvas has in order, with every object having a script containing a bool done that triggers the canvas to deactivate and activate the next object until it has gone through all of them and the game goes back to the main menu.

Some objects are triggered by themselves (like a fade to black that starts the results part of the game) and some by pressing A on any controller active (same procedure as pause menu, only the controllers currently in the race can press).

I made an input system for the high scores, every player chooses three letters by using the D-pad (up & down for switching through letters and left & right to switch between which of the three letters to be changed).
The letters was made using a generated image of a font using a program that our programming teacher Tommi Lipponen provided during an earlier course. The image was divided into individual letters by  Unitys built in sprite editor.
If I remember correctly I made an array of letters in a script, adding every individual image of a letter manually.
Then it was just switching the image by switching the the next/previous image in the array and the letter was retrieved by the same way, which position in the array they are (A is 0, B is 1 etc.).

We never designed the rest of the visual area of the highscore inputting, leading to that part of the results being only a black screen with each players’ three letters shown. We decided to not use the highscore input for the GGC build and only have the results shown (The data, things like best lap time and total time was saved by a trigger in the waypointhandler and timers created by the other programmers).

 

Loading Screen/Screen transitions

The loading screen in our game is fake, it doesn’t take more than 0.5 seconds to load the game but we used it to show our control scheme before the race, and we didn’t want the game to freeze for 0.5 seconds when pressing start so we added screen transitions that fades the screen to black (and back again in the next scene).
The only things in the loading screen is an image of the control schemes and starting circles that indicate the start/goal of the racetracks as a “now loading” indication.

 

Assisted Driving

The playtesters said that the game was too hard, so I added some assistance to the drivers that helps them turn.

What it does is cast a ray down to each side and if it doesn’t hit the track it adds a predetermined value to the steering of the vehicle.
The same idea is used for the AI so I just copied my code from there to the players.
This assistance some said was annoying since it leads them into the center when close to the edge so I added a way to shut it down by pressing the space bar on a keyboard.

 

That is basically every major artifact I made/worked on during this project, thank you for reading through my journey in the making of our game and I’ll start posting again next year when school starts again

 

Big Game Project – Post 4

Fourth week was when we finished most of the smaller things like HUD, main menu and loading screen with screenfading etc.

From last week: Waypoints were used for:

• AI Navigation points
• Player placement
• Lap count
• Wrong-way indicator
• Respawn position/rotation

I explained AI Navigation and will be going more indepth into the AI in the next post.
This post will be about the other things and the systems surrounding those features along with the other things done this week.

Player placement & Lap count

Basic functionality: A Waypointhandler triggers every players waypoints depending on their distance to it, if they are close enough to the next waypoint it triggers and the waypoint after this takes its place.
It also increases a counter for how many waypoints have been passed and how many laps have been completed (when waypoints passed count exceeds the total amount of waypoints a lap has been completed and the next waypoint becomes the first).

Player placement was done by giving each player “points” depending on the number of waypoints passed in total (lapcount * waypoints in total + waypoints passed in current lap) and then sorting their placements based on their points. If two players have the same count then the distance to the next waypoint determines their position. As this uses just basic position – position math it can be weird if the waypoints are not divided properly.

For example: imagine a U turn, place waypoints in both end points of the U and then the distance to the next waypoint for players in the U will not result in the player “leading the race” being closest (1st).

Wrong way indicator

Wrong way indicator was done by checking the rotation between the vehicles forward and the next waypoint and if it was larger than 110 degrees (number got from experimentation) we display the “wrong way” indicator.
that indicator is shown until the degrees drops under 70 degrees (again, experimented).
Playtesters then said that the wrongway-indicator telling them that they were going the wrong way when they fell off the track was annoying, solution to this was using the already existing “grounded-check” from the gravity script that checks if the vehicle should “snap” to the track or not.

Respawn position/rotation

This was done using the waypointhandler mentioned before, every time a player passed a waypoint (when the current waypointtarget changed) I updated the starting position and rotation to the waypoint that was just passed. (I manually rotated every waypoint so they were aligned with the road and facing the right way. This could have been automated with raycasts and such, but I didn’t have the time to create more tools for this when it was as easy as just adjusting the waypoints manually).

 

Another thing I finalized this week was the Swap mechanic.
I don’t know if I have mentioned it but our game features two parallell tracks that the players can swap between at will.

What it does is raycast straight up from the player and if the ray hits the track above we can swap and that triggers the following:

Rotate the vehicle 180 degrees
Invert the ray for the gravity/rotation systems
Allow for long range snapping

The last one explained:
The gravity snapping you to the track felt unnatural when it happened from extreme ranges (you could fall off the track and move the vehicle in line with the track and you would snap back up no matter how far you fell)
so I nerfed the range of the ray for everything except swaps and respawns in which the ray has a longer range for a set amount of time (About 4 frames if if recall correctly).
That is what was done on week four (I might have made the pause menu this week, I don’t remember exactly when it was done but I will be covering it in the next post anyway)

Big Game Project – Post 3

The course is over and this blog was ignored in favor of production so I will be writing three blog posts summarizing the third, fourth and then the final weeks or the project.

First is the third week.

This week I finished our gravitational system with the simplest solution: using the previously mentioned raycast that finds the normal of the mesh below the ship and then move the ship to a predetermined distance away from the mesh along the normal, pseudocode:

newPosition = RayCastHit.point + RayCastHit.normal * distance

This worked surprisingly well and is the solution used in the final game.

Another thing I added this week was splitting the screen based on the number of controllers connected.
How it worked was creating a player prefab for every controller connected and then changing each players camera viewport based on which controller it was (checked using XInput GetState with valued 0-3 for players 1-4).

Finally I created the basic waypoints that made the following things functional:

• AI Navigation points
• Player placement
• Lap count
• Wrong-way indicator
• Respawn position/rotation

I will only be adressing the first point in this post about the third week as that was the only thing they were used for at that point.

The AI racers are not very good at anything here, they have a LookAt (basic method in Transform for Unity) and then a move forward to go towards the waypoint.
The waypoints themselves were manually placed in the world but with assistant scripts that spawn them using Unity editor magic.
This is what I used:  https://unity3d.com/learn/tutorials/modules/intermediate/editor/adding-buttons-to-inspector
First thing I made was a button that created another waypoint, makes it a child of the parentobject designated in the script, names it depending on the current childcount of the parentobject and then places it at 0,0,0 in the world.
That wasn’t good enough for a tool that should simplify the placement of the waypoints, so I added an object called Starting Area that was used for spawning the players on the track where it begins. Next I added a button that did the same as the last one but positioned it on the starting area object.
To accompany this I made a button that creates a new waypoint on the position of the last waypoint in the hierarchy.

With these buttons the process of placing waypoints around the track was done in much less time than placing them out in the world manually would have. (Since this was done when the final version of the track was not yet done and waypoints could not even be placed yet)

 

That was, from what our SCRUM document along with what my memory says, the major things that were added on the third week of production, up next is week four.

Big Game Project – Post 2

Another week has passed, and here comes a summary of what I’ve been up to this past week.

The tasks I took in our weekly SCRUM sprint was:
Vehicle rotation & Gravity towards the track.
Simple AI racers if the level generation finishes.
Multiplayer Interactions.

The first one you can read more about in last weeks post. (here)
I only altered the gravity to now apply forces to the rigidbody of the object instead of forcing it to move using its transform.position which causes bugs and glitches in the collisions/physics (vehicle moving right through the track for example), and the rotation was hardly touched at all.

The simple AI was not worked on since the level generation is not yet complete, I did however set up a waypoint system that will both be used by the AI and as a way to track each racers position in the race. Position is done through calculating which racer is closest to the next waypoint using Vector3.Distance.
The waypoints is basically a script on a dummy object that adds three buttons to the ui: Add waypoint to (0,0,0), Add waypoint to Last and Add waypoint to Starting area Object.
The three buttons are somewhat self explanatory, the add to last finds the last waypoint added and adds another waypoint in the same position. These three are used to make it simpler to position waypoints in the world since just moving them from the last waypoints location is easier than manouvering them from the 0,0,0 of the world every time you want to add a waypoint.

Multiplayer interactions was touched upon somewhat, I made the game split the screen depending on the amount of controllers are connected at the start of the game.
It then created playerobjects from a prefab and changes their viewport to fit half/a quarter of the screen.
The prefabs then execute a script that changes layer on an indicator that every other player can see, so that the players view is as clear as possible.
The indicator is there to show the other players where they are, a green animated arrow above their vehicles.

 

This is an image of the track with the waypoints placed randomly, they will be generated through splines when the level generation is finished but for now this is fine

 

Big Game Project – Post 1

The second year project that is set to be displayed at the Gotland Game Conference (GGC) has started production, and with that progress blogs every week until the big day, this being the first.

The project is done in teams and my team, called Team GG (The GG stands for Gravity Grind which was the name of the concept) consists of:

Jonas Lundgren as the Producer and Lead Programmer (https://enfisk1994.wordpress.com/)
Laban Melander as the Lead Designer (https://labanmelander.wordpress.com/)
Valdemar Ribbing as the Lead Artist http://valdemarribbing.blogspot.se/
Ludwig Lindstål as Artist and Soundguy (http://luiart.net/)
Simon Brundin as a Level Designer(https://harttago.wordpress.com/)

The game we are making is much like Wipeout and F-Zero with high-speed competitive racing. Our game, however, differentiates from these with having two tracks running mostly parallell that the players can swap between in the race.
It takes place on a scrapyard planet in the future, with broken buildings and debris everywhere, the cars built from whatever the racers could scavenge.
We are doing this using the Unity Engine 5 and coding in C#.

So now to what these blogs are for: weekly updates of my progress in this project.
My main task for this week was to make the vehicles move along the splines as the track twists, flips and turns which is one of the biggest parts of making this game work. The vehicle needs to feel the same to control no matter which way the track is currently running (The tracks and vehicles work with some form of magnetism lorewise which allows this).
Luckily one of the teachers had heard of these problems before and had some very useful links for this exact problem:
http://www.gamasutra.com/view/feature/131997/games_demystified_super_mario_.php
and
http://futuregrind.tumblr.com/post/101354098523/the-math-behind-the-futuregrind-track-editor

After reading these I started working on the task.
The basic solution was always: Raycast from the objects relative down vector and align after the normal of whatever the ray hits first.
That was not as easy as it may sound though, since Unity uses the black magic known as Quaternions that are very hard to control when you for example want to rotate something along a vector.
After searching the web and the Unity reference page I came across a solution, the Quaternion method FromToRotation apparently does this very well.
The method does exactly what we want: rotate a quaternion to a vector, the only thing now was that it didn’t work at all.
I blame the Quaternions.
After digging around some more I found that I also had to multiply this with the current rotation, so now it all looks like this:

Quaternion.FromToRotation(transform.up, hit.normal) * transform.rotation;

transform.up is the local up, which takes into account the transform of the object, it is always the up from the objects perspective.
hit.normal is the normal of the object hit with the raycast, curr is a RayCastHit-object.

Of course this method returns a Quaternion that I have to handle, the resulting quaternion is the final rotation where the vehicle is rotated as it should be along the normal of the mesh below it.
I should also mention that Unity handles the Raycasting brilliantly and if you hit a large mesh the returned collider will only be the triangle below you and not the entire object that you hit, which is exactly what I wanted.
Now I used a Slerp-method to make the rotation smooth and not just snap to the new rotation when a new collider was hit.

Ray ray = new Ray(transform.position, -transform.up);
   if (Physics.Raycast(ray, out hit, 100f))
   {
       m_targetrotation = Quaternion.FromToRotation(transform.up, curr.normal) * transform.rotation;
   }
   transform.rotation = Quaternion.Slerp(transform.rotation, m_targetrotation, Time.deltaTime * m_RotationSmoothing);

I later added another thing to this, making it only update the target rotation when the collider hit is a new one, done using a simple current hit != previous hit statement.

Those simple lines took me several hours to get working as they should, with adjustments being made to everything, and it still does not work the way i want it to, so it is by no means a finished work but it does give a pretty good idea of what the end result is going to look like.

After this I started working on a custom gravity for the same reason, the tracks shifting rotation needs an equally shifting gravitation. I made a temporary solution to this using the same way, the gravity is set to the negative normal of the mesh being hit by the downward raycast. It also checks the distance to the mesh and stops pulling down when close enough to the “ground”, which results in a somewhat functional but not even almost acceptable solution for the final game.

Other than working on design documents and trying out multiple controllers functionality and insanely simple ai just moving towards waypoints that was all I did this week. Thank you for reading and I’ll see you next week!

Programming

I haven’t updated this blog for a couple of weeks so I will be summarizing each week up until now below.

Week 48

This was the week where I made the Webserver for the second assignment of the course Game Programming III at Uppsala University.

The code for this small project can be found here.

Basically the assignment was to host a webserver that could be accessed through the ip of the host, when accessed the server would first answer the connection-call and then send back a header containing the same information as every other webpage header should. The data that the server recieves from a client includes a GET-request that tells the server which page it wants to access. I handled this request very simplistically at first, sending the index.html-page every time, no matter what the request was. At the same time I had a webpage written in the code and not an actual index.html-file that was read and sent.
Seeing as both of those were required to pass the assignment I had to remake alot of things, the first thing I did was to create the method LoadPage that took a std::string page as a parameter to attempt to open and load a webpage instead of having it written in the code itself. This made the first issue easier as I could simply retrieve the requested page from the header sent to me from the client and attempt to open and load that page, and if it failed I redirected them to a 404-page of my creation.

All in all I made just about as simple a webserver as possible seeing as the only grade for this assignment is G (Pass), I would rather spend my energy on the third assignment that we can actually get a VG (Pass /w Distiction) on.

Week 49

Another server was made this week, this time for assignment 3 of Game Programming III.

This assignment is to choose one of three preset concepts (racing, space shooter, marble game) and then make a 3D-game using DirectX and C++. The concept that my team (Myself and Laban Melander) chose was space shooter but instead of the twodimensional standard space shooter we asked and was permitted to make a first person shooter instead.

The concept document for this concept can be found here: https://docs.google.com/document/d/1IKorgIe-K1CIddaYZSanQPoJmU9qiwgo3DCjwJVN8hg/edit?usp=sharing

A link to the repository will be posted when we have progressed enough to feel comfortable sharing our code with the world.

Back to the server.
I used the same principle as the webserver from the week before, only this time it has to use UDP instead of TCP because of the slow nature of TCP and the fact that a FPS has to be near instantaneous for it to be playable at all.

This meant that I had to change alot of things, mostly though it was the three-way handshake of TCP that took up most of the time. The way that TCP handles packetsending is that it checks an address if it is trying to send data and if it does it accepts this request and then recieves the data. UDP however just stays openended and tried to recieve data from anyone and if a client wants to send something to the server it arrives with minimal delay. The problem with this method is that no side of the connection verifies that the sent packet actually arrived and just keeps going no matter what happens.

The way I chose to do this (and this is still untested in practise and will most likely be changed) is to send every movement from every player to the server that then cycles through every known connection (stored when the first packet from a source is processed) and sends it back out to everyone.
One of the problems I see with this is the unreliability of the messages being sent, if for example a player fails to recieve another players messages for more than a second in a 1v1 fight then that player will percieve his opponent as continously moving the same direction of the last recieved message (it sends position and direction in every message) and no bullet has been fired during this time.
This means that if the player that is not lagging shoots the other player the message will not be delivered and that player will take no damage, thus having the upper hand just from lagging.

Some ways of solving this would be to store every players data on the server and tell this lagging player that he did infact take damage even though he never saw the other player shooting. This could, however, lead to the players feeling that the game is unfair since he does not know what killed him but seeing as it is just a programmingassignment and not gamedesign it’s fine.

The message interpreter looks for “codewords” to know what has been sent in the message, for example SENDER: Bullda ENDSND will read from the : to the E of ENDSND and store that as the identifier of that ip address.

Week 50

During week 50 I made the states of our FPS. The hardest part of doing this was understanding how the project that our teacher had given us as a template for our projects even worked.
Most of the project was selfexplanatory but other things seemed almost too abstract to comprehend. Again, I will share this code when it is ready.

The statemanager provided uses a state factory-class to create and attach states to the manager using a stringhash for an identifier and an abstract state-class as a base. I made the menustate and the gamestate using this, and then started working on a way to implement the server/client that I made last week into this project.

Week 51

This week I made modifications to the menu as well as managed to build and include the library AssetImporter or assimp for short.

By far the most timeconsuming part was getting assimp to work as it simply would not build in CMake.
After troubleshooting both online and asking our teacher, and after trying many different versions of assimp I finally found the answer: you have to have the DirectX SDK installed on your computer or it wont build. What had confused me first was that I had DirectX installed already, and every file was in the folder it was supposed to be, and yet CMake insisted that the files did not exist at all.
When I finally managed to build the library I was presented with a bunch of solution-files and no lib-folder in sight. Luckily in my previously mentioned troubleshooting I had read that you had to open the files and build them in Visual Studio to finally get the so so elusive lib-files.

After building I was tired and just entered the folder and searched for every file with the extension .lib and copied them into a folder that I included into the project, paying no heed to the names of the files. After changing the compiler to build the 64-bits version it finally, after so many hours of errors, worked. Assimp was implemented.

All that remains now is to read and handle the data that assimp reads from the modelfiles and then convert that into actual models in the game.

The other thing I made this week was the menubuttons, using a GUITexture that the other member of my team had created before to render two-dimensional textures on a fixed position on the screen no matter where the camera moves or is pointed at.
The button compared the position of the object (building a rectangle using the width and height of the object) to the mouses position and if they overlap the button is triggered.
This worked fine until I tried getting more than one button rendered at the same time, this proved difficult since apparently the only thing that is drawn is the last read texture, so only the last button created would be rendered.
This problem has yet to be solved but I will be updating next week with how it was solved.

EDIT: Solved it, one of the variables in the GUITexture-class was static and was updating every object with the latest ones position, rendering everything in the same place and the last one being drawn as the one on the “top”.

Thank you for reading and I’ll see you next week!

Programming Blog – Week 2

This week I created my linked list for the first assignment of this course.

A linked list is essentialy a number of nodes containing its data as well as having a pointer to the next node in the list.

The first idea I had for this was a struct Node shown below.

struct Node {

int data;

Node *next;

}

Then I had to tackle the problem of having several Nodes and where to store them, and while thinking of using actual std::lists or vectors a friend told me that I only needed to define the root-node and the rest would just be layered through the Node *next without needing a way of storing them. so, I created the rootnode as a member-variable of the class LinkedList that I created for this assignment.

Any additions to this “linked list” would just add a node to this base, or switching the head to a new node (push_front() does this) while moving the previous head one step into the hierarchy.

Removing additions through pop_back/front just reversed this process by removing either the last node (found by looping through until the node no longer had a defined next-node) or the first one (removed by making head = head->next then deleting the old head).

The search method takes an argument for T data (everything had to be done using general coding, templates) and returning a bool found. This was done by looping through the nodes and comparing each nodes data by the argument.

Size loops through and counts every node, everything so far has used the same looping-method, this is the code for the loop in the size-method.

Node<T> *current = m_root;
++size; //The root exists, count it
while (current->next != nullptr) {
++size;
current = current->next;
}

Basically it loops until the final node is found (the one who has no defined next-node) and then returns the number of times it looped.

Erase was trickier, this method takes an argument int index for what position in the linked list it wants removed, meaning that to remove a node in the middle of the list I would have to make the previous nodes’ next pointing to the targeted nodes next, which in turn meant that I had to keep track of both the current node and the previous one while looping through the list.

I am now working on a Binary Search Tree which is the second part of the first assignment, and I will also be looking into unit testing which is required for this assignment as well. Thank you for your time and I’ll see you next week,

Programming Blog – Week 1

A new course has started, game programming III. This course contains three assignments, and I will be updating this blog on my progress on them once per week.

This week started off with a small contest to see who could compress an image the most, smallest filesize won. The hard part was that we got no lecture or any general information about how to compress images or even how to read the data of an image, so we had to figure out on our own how to do this, and then compress it in an efficient way while still being able to rebuild the image from the compressed data. This was done in teams of no more than four people.

Our teams plan for compression was first to figure out how to read data from a .bmp image (which was the image provided). Then, when we somehow managed to read and store all this data somewhere we could access we needed a way to compress the data. The data was stored in an array of bitmaps, 24 binary values per pixel. Our first idea for compressing was to look for pixelpatterns, for instance: if more than two of the same pixel repeated we switch out the data from 72 binary digits (3 pixels) to 24 digits and then a number for how many times it repeats, in this case, 3.

We didn’t have the time to even attempt a way of decompression as we only had that day to finish the contest, when the groups presented their work it turned out that noone had had the time to make decompression work.

 

After this we got the first of the three assignments explained, we are to create a linked list and a binary search tree from scratch, which I will be writing about when I finish the assignment.

Analysing a Boardgame #2

This week we chose to play and analyze the game Small World Underground, a strategy game that reminded us somewhat of last weeks game, Dust. The game is played with 2-5 players on a specific board for specific amounts of players, meaning that two players get one map and four will be playing on another map.

The goal of the game is to collect as many victory coins as possible through conquests and dominating important tiles on the map.

The gameboard consists of various different regions that have unique properties, some of them give bonus points for owning with a power (the Mining special power gives one more coin per Mine owned) and some give inherent bonuses, like the Black Mountains that give 1 additional defence along with a bonus coin.
The game starts with the players deciding who starts based on which one of them last was physically in a cave or basement and then clockwise after that. The players then choose a race and special power combo to begin with.
After this the players recieve so called race tokens that count as this players’ units that he can start conquering the world with, starting from an edge-tile. The number of units the players recieve is dictated by the numbers on the race/special power cards, as seen in the picture above, the Mining Mummies give 4 and 10 respectively, for a total of 14 units.

Conquests are done by having as many units invade as needed, based on what is currently in the attacked region. The base for an empty region is 2 units and one more is needed for every hostile unit and every black mountain.
After a conquest is done the units that were mandatory (2 units in an empty etc.) has to stay in that region until the end of the turn and cannot be used for further conquests. At the end of a players turn he can choose to move any units he wishes to any owned regions on the map, this is to prepare for the next round of conquests or to place defences around regions you do not want to lose.

If a player decides that he has done everything he could with the limited units at his disposal he can choose to, at the start of his turn, go In Decline. This meant that he loses all but one of his units per region and the remaining units become inactive in that they can’t be moved and sometimes “unpower” the region he is in. After going In Decline the player waits one turn and then chooses a new race and special power-combination along with recieving more units to place on the map in the same way as before, on an edge-tile of the map.

If a players wants to he can attempt to conguer a region with less than the needed amount. If this happens the player rolls a die that have half the sides blank and the other sides have one, two and three dots in them, indicating how much “bonus power” his conquest has. This means that if a player were to attack a region with 5 defence with only 3 units he wouls need to roll at least a 2 on the die to succeed in taking over the region.

If a player loses a battle, be it from being conquered or failing a conquest, one of the attacking units are permanently discarded and the rest are redistributed to his other regions at the end of the turn.

Some regions have monsters in them, indicated by an icon on the map, when a player clears these he recieves a Popular Place or Righteous Relic at random and places it in this region. These are various bonuses that can affect the power of this players’ attacks, let him move his units in unconventional ways and even release a balrog that destroys any region he is in.

The game continues for the number of round indicated by the map, using a turn-token that moves every turn, when the last turn is over the player that has the highest amount of coins is the winner, if two players are even then the one with the most regions owned is declared the winner.

At the end of every players turn he is given victory coins based on the following:

• 1 coin per region owned
• 1 coin per special power-region owned
• 1 coin per Black Mountain-region owned.
• Some special powers and races give more coins based on the number of region-clusters owned and if a region is adjacent to any enemy regions.
• Some Popular Places and Righetous Relics award bonus-coins, for example the Keep on the Motherland gives one bonus-coin per turn.

Core game system:

The core game system of Small World Underground I would say is the victory coin system, in that everything you do is in an attempt to either get coins for yourself or stop someone else from getting coins.
Taking over regions on the map awards one coin at the end of your turn per region, owning special tiles based on what power you have (ex. Muddy gets one more coin per mudpool owned) does the same.
Various other powers award coins, and almost all of them help in either acquiring more land (= more coins) or more units to use in later conquests, an example of this would be the mudmen that gets one more unit per mudpool owned.

The victory points are used to determine the winner of the game after the final round has been played, the player with the most coins wins the game.

So everything the player does feeds into the victory coin system which makes it the core of the game and everything that the player does is influenced by how many coins you will be getting from it.

Most interesting system:

the race and power-system is the system I find the most interesting. Every race in this game is paired with a random power to almost always give the players unique game sessions in that there are so many combinations of races and powers. The powers themselves are also very interesting, they give the player unique properties.

This also influences how you will be playing the game as you will want to cater to your race/special power when making your conquesting decisions. One example of this would be the second round we played when I started as the race Will-o´-wisps that can use the reinforcement-die before attacking a magic crystals-region or when attacking any adjacent region from a magic crystal region. So instead of having to decide to attack and risk losing my valuable units I could try rolling the die and if i didn’t get the result I wanted I did not have to attack, instead of rolling the die mid-attack and not being able to withdraw on a loss as the other races had to do. This led to me mainly focusing on the magic crystal-regions of the map as I was honestly insanely op in these regions.

In the same game I went In Decline and switched to the Flames class that have an inherent Volcano-object that they can choose to place on any abysmal chasm-region on the map (the black regions with a one-way sign and a volcano-symbol in the picture). The volcano made every adjacent tile be conquerable as if it was empty, requiring only two units no matter what was in the regions. This changed my strategy to trying to take over these regions as they would be very easily defendable with this passive effect from the volcano.

So, the races and powers in this game affect the gameplay in such a way that I don’t think that any two sessions will be the same as the players all seek different goals to get as many coins as they possibly can through utilizing their racial and special powers.

Best parts of the game:

One of the best parts of this game is the fact that there are different boards for different amounts of players, this gives new scenarios and strategies based on the number of players playing, with a strategy that might work well in the map for four players that doesn’t work at all in the five player map because the layout is so different. It also shows that the developer was dedicated in making balanced maps no matter how many players would be playing.

The extremely limited unitcounts of every player that limited the domination to strategical choices of which few land areas you really needed. This was strengthened by the going In Decline-system that allowed you to switch races and lose all but one unit per region of your old race while recieving all the units of your new race to start conquering more areas with, but with the limited turns of every game session and going in decline costing a full turn this wasn’t always a viable choice. That along with the fact that some regions get powered down and no longer give benefits acts to sway the players from going in decline.
Also, the fact that you can only ever have two “active” races on the board at the same time and that you lose all the units of your first race if you decide to go In Decline more than once makes it a very interesting mechanic that can both act as a way to get back into an active state after having spent all your units on spreading out and now have no more than one unit per region and as a way to replenish your stores while also giving you the opportunity to abandon your old regions and begin conquering on the other side of the map.
Another strategical point about the units is the fact that you have to discard one of your units permanently if you lose a fight, which makes the players wary about trying to conquer without having enough units. This is used as a way of making the players want to go In Decline, to get their much needed reinforcements.

Worst parts of the game:

The game ends too soon, there are only as many rounds as the map dictates, and after that the game is over. This led to a feeling of not being able to execute any major strategical plans and more of a rush to get every single coin possible. The competitive side also only started after a couple of rounds as the players first had to settle into their own parts of the map before even thinking about trying to take down the other players as well as not having enough troops to mount an assault on anything more than a single region. meaning that the players would have to go In Decline before attacking each other which costs an entire turn.
This also turned the game into more of a “who can farm more gold the fastest”-style of play instead of the strategy domination-game that we expected.

Target Audience

The age written on the box states “Ages 8 and up”. For this kind of game that requires the players to make strategical choices of which regions to claim and what is and isn’t worth going for as well as deciding when to go In Decline and get more troops I would say requires more attention and thinking that an average 8 year old should be able to muster. There is also the choice of which race/power combo to pick and then which regions to aim for when doing the conquests that all require some strategical thinking.

Summary

This game is well balanced and the mechanics with the races/powers make it a unique experience both as a board game and on a game sessions by game session basis in that the combinations that are available are always different which leads to different types of strategy for every new game played. The rules are pretty straight forward but with having alot of pieces and mechanics comes a hefty rulebook, so the game takes some time to get into and you have to consult the rulebook several times during the course of the game which makes for a slower game.

Analysing a Boardgame #1

The second year of game design has started, and with it a new task to analyze board games.
The task consists of first playing the game and then deciding the objectively worst and best sides of the game. After that we are to decide the core game system, meaning the system that the entire game revolves around, and then defining the objects, functions and the properties, behavior and relationships that is this game.
And then we choose the subjectively most interesting system and describe its objects and functions, giving a rough idea of how these work with the other systems and mechanics to create this interesting system.
Then we do a target audience interpretation, basically we check the box for what it says the age limit is and then try to derive from this a target audience, using the games systems and intricacies to give an idea of what their possible target audiences are.
Finally we are to do a summary of how all this correlates to create this board game.

My group chose the game Dust, a strategy game where the goal is world domination. The game is played by two to six players in rounds with five different phases, with a setup-phase at the start of every game. The game is won by controlling capitals, power sources and by controlling the majority of land/sea areas or production centers which all give one victory point. When a player reaches the set amount of victory points needed (50 points if there are two players, 40 if 3-4 and 30 if there are 5-6) that player wins and the game is over.

The setup

When the game starts every player is given six cards. These cards can be played during the various phases of the game depending on which type of card it is, but in the setup as well as the start of every round one card is chosen and placed face down on the table. When all the players have chosen their cards they are simultaneously flipped over and the order of play is determined based on the values of the card chosen. The player with the card that has the highest valued card goes first and places a tank unit on their desired capital. Then the player with the second highest card does the same until every player has claimed a capital.
Then, using the same order, the players place tanks on and claim any unclaimed land areas until every land area has been claimed. If a player claims a power source he can then use this to power one of his production centers, which gives more production points which I will explain further down.
After this they place production centers on their own land areas in the same order.
The final part of the setup is placing reinforcement units on friendly land areas that have production centers on them.
At the end of the setup or any other round the cards placed during it are discarded.

Before I go into the game round I should explain how the cards work.

Every card has the three values combat, movement and production along with a number of stars at the bottom.
The order of every turn is decided by the highest combat value. If players combat values are even, the movement value decides the order and in case of the values still being even the tie-breaker stars at the bottom of the card decides who goes first.
The cards also have a special usage based on the image on the card, but they can only be used from your hand and not from the table, meaning that the card you play at the start of the round cannot use its special move.

A Game Round

When the players have determined the playing order the same way as the setup, using the numerical values of the cards placed the round begins with the production phase.

In the production phase the player calculate how many production points he gets, these points are used as currency to purchase units and cards. How many points the player gets is calculated by the number of capitals, power sources and production centers that he owns as well as the number on the card he placed on the table. The player then purchases the units he wants and places them on any of his own land areas that has a production center on it. The player can also use the points to purchase more cards, this is the only way to replenish your hand. After the player is done with the production phase he moves on to the movement phase

The movement phase lets the player move his units around the board, the number of moves the player can do during this round is based on the number of movement points the card he placed has.
The player can choose to move any units from any area to any connected friendly area, connected meaning that no enemy or neutral area can be passed through in the movement. If the player moves through water then the shore-to-shore movement is considered one movement. When the movement phase is complete the player moves on to the attack phase.

While in the attack phase the player can choose to mount an attack to any adjacent land areas that are not controlled by him, the number of attacks a player may do in one round is determined by the combat value of the card he played. If a player attacks the two parts will first calculate who has a tactical supremacy which would allow him to attack first.
Tactical supremacy is given by certain advanced units that cost more than regular units.
Combat is done by first calculating the power of your tile, counting any units combat power as well as capitals giving 5 and production centers giving 3 “combat points”.
Then the player rolls as many dice as he has combat value, these dice are unique to this game and have 2 sides that are hits and the rest are blank. Every dice that rolls a hit is a killed unit for the opponent, meaning that the player that didn’t have tactical supremacy risks losing many of his forces before he even gets a chance to attack.
If two players are even in their tactical supremacy the defending tile has supremacy, and capitals always have supremacy.
When the player is done attacking the turn goes to the next player, when they are all done the round moves on to the victory point phase.

The final phase of every round is the victory point phase, here the players recieve victory points in the following ways:

• One point per capital owned.
• One point per power source owned.
• One point if you are the player with the most land areas owned.
• One point if you are the player with the most sea areas owned.
• One point if you are the player with the most production centers owned.

When a player reaches the amount of victory points needed to win as well as owning at least one capital the game is over. If more than one player reaches the goal at the same time then the one with the most points win. If this is tied then the player with the most capitals win. If this too is tied then the player with the most total land areas owned wins, and finally if that is tied then they share the victory.

 

And now for the objectively worst and best sides of this game.

The worst

The rules take a lot of time to learn, our first playthrough took almost six hours because we had to refer to the rulebook every time we did anything, not knowing how many units you can place where, not knowing how the power sources work and thus not having the correct number of production points.
The many different edge cases that this game creates, there are so many different small details that are not included or very unclear in the rulebook. For example if one player uses a card that forces another player to empty a tile of units on the capital and then attacks it, will it defend itself? Or will it now require a movement which cannot be done in the attack phase to claim? Another example of this is when creating submarines, do they spawn on the land tile with the production center or the adjacent sea tile? And what if the tile is already occupied, do they automatically engage in combat and skip the movementphase for this?

 

The best

The game is not over until it’s over, with the cards that every player has that are incredibly useful, some of them prohibit a player from attacking, some forces a player to retreat or drops every single mech that you own into enemy territory, wreaking havoc. Every round that we played were even with one straggler at least one obvious victor, but it was only an obvious victor in the final round when we all realized that he owned half the worlds power sources and will be getting enough points to win no matter what.
The strategical side of this game with the actual players makes it even more openended, for example some players teaming up on an apparent victor, taking him down before he wins as well as forming alliances to be able to focus on other sides of the map without having to worry about a two-front war.

 

The Core System

I would argue that the cards are the core system of this game, they are what decides the order of play, how many units you can build, how much you can move and how many times you are allowed to attack each round.
The cards also have a unique move that they can use during the various parts of the game, some cards grant free units during production, some are special moves that you can use during your combat phase to relocate or surprise attack someone. The most valued card would be the one that has the ability to clear out any adjacent tile of units, including capitals. This means that if you have a tile next to an enemy capital then you can basically get a free extra capital.

The objects of this system are 11 different cards and 45 cards in total, their properties are:

• An attack value, telling the player how many attacks he can make if he plays this as well as determining the order of play in every round.
• A movement value which tells the players how many movements they can make every round, this also works as a tie-breaker if two players are even  in attack when determining the order of play.
• A production value that gives the player more production points when producing units.
• Tie-breaker stars that are used when determining the order of play and attack/movement-values are the same.
• An image telling which special move this unit can perform, only cards in the hand can be played as a special move and only during their specified times (i.e. a card that takes over another players’ turn can only be played at the start of a turn.)

Their behaviour and function changes the flow of the game, in that it can completely turn a situation around. One of the cards adds +1 attack to every plane in a skirmish, which could easily turn the tide in a rough situation. Another example is the diplomat-card that forces an alliance between one player of choice and yourself which means that during this round neither of you may attack each other, meaning that you can completely ignore this player and focus on other parts of the board and maybe get an advantage later on by getting majorites. The cards can be used in their specified times, meaning that they have relationships with their respective parts of the game.

All in all the cards provide an interesting twist to the average strategy game that changes the whole dynamic of the game from just having the largest army to having the right cards at the right times as well as cautioning the players from attacking and trying to brute force  world domination.

 

The Most Interesting System

What I think is the most interesting system is the victory points, in that it changes the game from domination to grabbing as many points as you possibly can, and seeing as you only get one point for owning the most land while taking over a single power source tile gives one as well the priorites shift to a more strategic war over the victory points. The players also get a clear view of the standing of the game, and they can easily check if one player is on the verge of winning and thus can take action and stop this from happening. It also adds an inevitability to the game with every turn drawing the players closer to victory, there are no drawn out games and most of the times we played in never went more than seven rounds before it was over.

The objects of the victory point system is the points themselves, counting up to the victory and the objects that give victory points, see the list above for reference.

 

The Target Audience

The box says 12 plus to play this game, and that age suggestion is understandable as it is a very complicated game that you have to understand to stand a chance at winning at. The image on the box works in this 12-plus suggestion in that it has some soldier-babes standing in the front and more soliders and a tank in the bottom/background which could entice potential players to check the game out and potentially purchase it.

 

Summary

To summarize this game and its systems, it is a very complicated game that takes a long time to learn but when you do and you get into it then it becomes a very fun game to play with friends, scheming and backstabbing as you go towards victory. The cards add an interesting dynamic to the standard war game, with cards that allow you to retreat unharmed or reroll your dice. If the rules had been more clearly stated and every scenario covered by the 25 page rulebook then it would have been even better, the only things that drag this game down is just that, the rules are a bit iffy in some of the most important parts (my example above about the capital being cleared).