The week before Gotland Game Conference

The following is a list of what I did the week before Gotland Game Conference (GGC), and for a bit during GGC.

  • I made it so every character in the game starts facing a random direction. It would be better if the characters instead faced a direction that made best sense, but it’s a fast and easy solution, and it’s better than that every character starts facing the same direction.
  • I finished the system for saving network messages that are not ready to be received yet, which I had started making the week before as I had mentioned in the previous post.
  • I changed so the lightning effect is shown even it doesn’t hit anything so that the players can see that it was used.
  • I implemented the feature that a damage multiplier is determinerad by the the initiative card. Lower initiative means higher damage, and higher initiative means lower damage. I also later implemented the icons for this that is shown on the cards.
  • I fixed a bug that made the last joining client think that the player of that client was dead, which was caused by not having gotten the data about their player yet.
  • I fixed so that the attack animations faced the right direction.
  • I implemented the Protector objective. The Protector gains score every turn a player doesn’t take damage, and loses score every turn a player takes damage. The Protector didn’t work well and had a hard time preventing the other players from taking damage. We didn’t have time to try to fix this so the Protector wasn’t included for GGC.
  • I made the attacked avatar bar on the server shake when they get hit, and I also made the avatar bar get pulled to the left to show that they are executing their turn.
  • I changed so that the turned was executed faster and required less waiting.
  • I made an animation so that the objective screen shrinks into the objective button when the objective screen is closed, and the objective screen is enlarged from the objective button when the button is pressed.
  • The title and description of the objectives are sent to the clients from the server, but for some unknown reason the title and description was null on the client for the Protector, so as a quick fix, the title and description was set on the clients to be that of the Protector if a null title is received from the server. There was no time for a more proper fix if the protector was to be included for GGC, which it wasn’t anyhow.
  • I made destructible entites that gives score to player that destroys it. This wasn’t included for GGC as there wasn’t enough time to play-test it.
  • The Sadist gains score from attacking, and loses score for killing. I fixed so that the Sadist didn’t also get score for attacking when killing.
  • The fire previously only dealt damage when it was first cast, but that is wrong. I made the fire to also deal damage when a character walks through it and on each new turn that a character stands in it.
  • I made the AI see ~10 tiles far, and able to walk ~5 tiles. The AI can make up to two actions in sequence. The actions could be  to move towards the nearest player, attack the nearest player, or move in a random direction. If attack was chosen as the first action, then the second action is canceled. The AI previously used an action point system, and always made one action per turn. This was changed as the AI couldn’t attack on the same turn as it moved, which didn’t seem intuitive for the players, it was also changed because the players wasn’t using an action point system anymore, so the AI was changed to behave more like the players.
  • I made the blood that appears when taking damage not appear if the attacked character is blocking.
  • I made a music always play on the server.
  • A change on the server was that I zoomed out the camera, and offset it a bit to the left, so that the characters wouldn’t be covered by the avatar bars.
  • I made a sound play on the server when a new turn happened.
  • The flame effect didn’t appear immediately when cast and instead appeared when the turn was over, so that was fixed to show immediately.
  • I implemented so that walk icons are shown where the player can go on the client, and Adrian implemented the other such icons.
  • I implemented the image for the button that is pressed to show the initiative on the client.
  • I implemented the animation, textures, and 3D models for the Dyrkaren, Pyrofeten, and Kappelmeister player character classes; and the Dyrkare troll animations, textures, and 3D models were updated.
  • I made a ring that could be seen on the ground under the player characters on the server. The rings had the color for each specific player character, though the colors turned out to be hard to see at GGC.
  • The tiles on the client was updated. The tiles was only one sprite and a “frame”, so to have it look better I made the sprite have a random direction and not have a frame when the tile is a wall.
  • I adjusted the player character colors so they looked the same everywhere.
  • I adjusted the post processing effects and removed the eye adaption, so the scene wouldn’t be too dark.
  • I changed the message the players get when they die.
  • I made all the texts in the game use the font “Times New Yorker”.
  • I made everything be dark except the “waiting for other players” text when waiting for other players.
  • I decreased the penalty the Sadist gets for killing other players.
  • I made the server automatically start the server, and the clients automatically connect to the server, without having to navigating through the main menu.
  • A number of bug fixes not previously mentioned here.


On Monday, two weeks ago, the week before the Gotland Game Conference, we started the day by having a meeting about the design of the game, the UI design, and the graphics. The talk about graphics was about scaling down the scope and prioritizing, and I didn’t partake in that discussion as I’m not one of the graphical artists. The game design didn’t feel good enough and fun enough, and the UI didn’t feel intuitive and easy to use. A few of the changes we talked about for the game had already been in the works since before the meeting, but there were also some very important design decisions made then, and we had already at the end of the game made some changes that made the game much more enjoyable to play than at the start of that day.

We at first had so the player could choose any action until the player is out of action points, which had to be confirmed each time an action was chosen, we changed that so the player each turn instead could choose between doing a move, an attack, move + attack, or move + move. We had since before been thinking about how to improve that system before we did that change, as how we had it then was cumbersome to use and wasn’t intuitive how it was used. This change was implemented in the game relatively quickly as it was similar to how we had it at a point previously.

We also decided to add score, which players gain either by killing enemies, or by fulfilling their personal objective. I implemented this, while Adrian made the new system of choosing actions. The score acts as a way to incentivize and give feedback to the players, and so they can continuously be aware of how they are progressing. The score system at first only gave score for killing, but I during the following days added so it also gave score for progress towards the player’s objective, instead of simply showing at the end of the game whether the objective was completed or not. The Sadist and Masochist objectives was also implemented then, which replaced the “defeat all the enemies and reach the end” objective, and which from the beginning was an objective we intended to probably not keep. The Sadist gains score for dealing damage to either other players or enemies and loses score for killing, while the Masochist gains score for taking damage, from either other players or enemies.

What I else did this week, except for very small fixes, was to fix so the animations works, at that time at least. I implemented animation when getting hit. I began making the code for destructible items, which was fully implemented in time for Gotland Game Conference, but wasn’t properly play-tested, and was as such not included in the game. I fixed a bug that made the input not work when zooming out on the client. I offset the rooms relative to on another, the code for that had been previously implemented, but the room switch didn’t work now so that was fixed. I began making so that network messages are saved if the receiving end isn’t ready for it, which I finished making the following week. This turned out to be something which might not have been needed at that point as the bug I was trying to fix turned out to be caused by another thing, but it was something that could possibly be useful in the future.

Dynamic Camera, Joining the Game, and Reset

The work week that was 1-5 May mostly consisted of work tasks of not very big size, so I’ll detail a few, but not all, of the things I did instead of just one task per post as I did previously. One of the things i made then was a dynamic camera. It zooms in on the character that is currently doing their action. The camera zooms out to show everyone while the players plan their turns. The camera is positioned right in the middle of the two characters that are furthest away, and the distance how far away from the room is determined by how far away those two characters are. The transitioning of the camera smooths in when switching what the camera focuses on. The camera only moves to entities that have their “doFocus” variable boolean set to true.

Another thing I made that week was to have the game start start when all three players have connected to the server and have chosen character, and also disallowing more players from joining the game. I made it so the game could be started regardless of the number of players by pressing the ‘s’ key, so it would be easier for us to test the game. I also made the game server to disallow multiple players from choosing the same character.

I made it so the game can be reset by holding the ‘r’ key for three seconds on the server. The clients are also made to do a proper reset if they get disconnected from the server. Game objects that are set to not to be destroyed on scene change by using DontDestroyOnLoad are changed to use my DontDestroy wrapper, which adds the game object to a pool. All the game objects in the pool is destroyed when the game is reset. During the reset the entities are destroyed and the NetworkServer is reset, and finally the main menu is loaded.

Commands, attacking and blocking

I have this week, four or five weeks since the start of the course, among other things been making the players attacks and blocks. I also made the player attacks and blocks we had in the prototype. We had all of them sort of working in the prototype except the fire attack. We have now just hade Alpha and have pretty much everything at least almost implemented. The attacks and blocks are:

  • A horizontal slash in front of the player character. This causes damage on the three tiles horizontally in front of the player character.
  • A forward stab in front of the player character. This causes damage on two tiles forward in front of the player character.
  • The bug zapper / chain lightning causes damage on a tile of the player’s choice. This choice will be restricted to a radius around the player, but can as of now be placed anywhere on the map. Any character near it will also be damaged, and will also damage anyone near those character, and will continue to do so until there are no longer any characters nearby.
  • The fire attack causes sustained damage on a tile of player’s choice. This attack can just as the bug zapper / chain lighting be placed anywhere, but will be restricted in the future. Fire will appear on the tile, and will at least as of now, stay there indefinitely.
  • The stun block nullifies any incoming attack until next turn and stuns any attacking enemy.
  • The directional block nullifies any incoming attack from a direction of player’s choice.

For the final game, each character class has their own specific attacks and blocks, but we as of now only have one player character, and all attack and blocks are always available to be able to always test them. Making the different character classes is up next to do.

We had in the prototype made the attacks, blocks, and moving both for the player characters and for the enemy characters be ‘action’ behavior tree nodes so they could both be used in the planning stage for the AI, and be used when executing them. We have in the post-prototype version divided it up in behavior tree nodes and  ‘commands’. The behavior tree nodes are used by the AI for planning, and the commands are used by all characters to do actions such as walking, attacking, and blocking. The commands are put in a list on the server specifying what they are to do that turn. The clients make the player’s commands and sends them to the server. The commands can be created and sent as command classes without any conversion, in difference to the prototype where we had instructions be sent to the server, and the server made ‘action’ nodes out of the instructions. I had begun making the command code last week, but hadn’t made almost all of the attacks and blocks.

Something else I made this week is the status effects, which strongly relates to the attacks and blocks. Each character has a ‘StatusEffector’ which keeps a list of the different ‘StatusEffects’ that character currently has. The status effects we currently have in the game are ‘Stunned’, ‘StunBlocking’, and ‘DirBlocking’. The reason ‘StunBlocking’ and ‘DirBlocking’ are status effects even though their not usually thought of as status effects is because they remain and stay on the character unlike actions such as e.g. walking or horizontal slash which are used up immediately. We also had status effects in the prototype, and was then implemented directly in the ‘Entity’ class , and was implemented as an enum. We now have a ‘Character’ class inheriting from an ‘Entity’ class, unlike in the prototype where we didn’t have the character class.

Spawning and entities

One of the things I’ve made this week, week 3 or 4, is to have the data about characters and entities be loaded from files, and to able to be placed in the tilemap editor. It’s otherwise been mostly small fixes and et cetera. These are some of the things which wasn’t implemented in the prototype, except for the tilemap editor. The placing where the entities appear are called spawns, which they usually are called in games. The spawn data about what entitets are spawned and where they are spawned, are included in the tilemap file, while the data about the entity types are saved as separate files for each entity type. The data is stored as JSON files. Adrian had implemented loading of the tilemap from a JSON file before I began with this, so I loaded and saved the JSON files using the same way.

The type of entity is selected from a drop down menu in the tilemap editor, except for the first item in the drop down menu, which is for editing the tilemap, and edits what is solid and what is not solid. The entities are placed by clicking on the tiles on the tilemap in the tilemap editor.

One of the entity types loaded from the files is player spawn points, the places for the players to spawn are chosen at random between these positions. It is worth noting that we have two ways of  having entity types. We for example have ‘Character’ which is a class inherited from Entity, and we also have the specific enemies and player classes which are of the ‘Character’ class type, and are saved as JSON files. These data are structs of ‘EntityData’ which exists on the ‘Entity’ class.

Prototype and Networking


In the current course we are to make a ‘vertical slice’ of a game. We are 7 people in my group; 4 are graphical artists, and 3 are programmers. 1 of the artists are is the lead designer, and 1 of the programmers is the producer. The producer has so far not made any of the code, so I and the other programmer have made the code we have produced so far.

The Game

 The game is called “A Rat Betwixt”. It is a turn based multiplayer game, where players either cooperate or betray each other based on their objectives and current situation. The game is controlled with input from a smartphone, while the game itself is displayed on a TV (or something similar). Each player can choose a different character, with each character having different skills. Most of the attacks use area of effect (AOE), meaning they damage or effect the surrounding of the target, we have this as a means for the betrayer being able to attack the other players without being recognized as the betrayer. Besides fighting enemies there are also ‘events’, situations for the players to handle.


We made a prototype of the game for the first two weeks. We made the prototype using my code from the previous course where I had made a behavior tree, path finding, it was turn-based, and made in Unity, which are features that fits well with the game we’re making now. Before we began making the prototype I made a smaller prototype in a few hours displaying the use of networking.

Our prototype was turn based, where every player and AI controlled character has a predefined initiative that decides their turn order. AI and A* path finding were brought in from code I had made in the previous course, with in large part, especially the path finding, was used in the prototype with very little changes. The prototype had multiple attacks and moves. It had networking between server and client working, with the server on a computer and the client on a mobile phone. The client had a minimap where the player can see what is solid and what is other players and enemies. The player clicks on the map to choose where to go. On the client screen were also the selection of attacks/moves. The prototype also had a tilemap editor, which is used in editor mode of Unity, and is used to create a tilemap of what is solid/collidable in the game. We are reusing most of the tilemap editor code for the post-prototype version. I made the initial version, and the other programmer has converted the code for the post-prototype.

Post Prototype Programming

 This is about the week we began with programming the post-prototype version. We planned how we would restructure the code and began making it. We have by the end of the week, implemented most systems which were present in the prototype, although somewhat different in how they’re structured.


 I’ve been in charge of making the networking work as I had experience with networking in Unity, and it has been fine with me to do so. We shared in making most other things.

Networking – Prototype

We had in the prototype a class called ‘Master’ that had an instance created for each client on every client. The server is a hosting server, it in other words is also a client, so it also has a master for itself. A ‘Master’ creates an instance of either ‘ClientMain’ or ‘ServerMain’, of their respective ‘Master’ on their game instance. The ‘Master’ class also dealt with communication between the server and clients.

Networking – Reasoning

I chose to do it this way partly because I was unsure about what networking features we would benefit from using, and partly because I didn’t want to complicate the code more than needed for the prototype. Unity provides certain ways of doing networking that requires a ‘NetworkBehaviour’ and ‘NetworkIdentity’ to be used. They need to be on a GameObject instanced on each client and server for each game instance. The script inheriting from ‘NetworkBehaviour’ is ‘Master’ in this case. I believe Unity does it this way as each of those are supposed to be a player, and they’re created as an instance on each machine because each player are meant to be seen on each machine, and can that way more easily sync their properties. This didn’t work well for us because #1 the players are only meant to be seen on the clients on the minimap UI, while they appear as 3d models on the server. #2 The other programmer felt he preferably wanted our code to be seperated from the code dealing directly with Unity. #3 I though of a though reason but forgot it. I chose to do it using this way though because I wanted to see if there was anything we could benefit from using it, as I stated earlier.

Networking – Post Prototype

For the post-prototype, I decided that it was going to control how connecting and disconnecting clients are dealt with by inheriting from Unity’s ‘NetworkManager’ class. This time the server is not a hosting server, as far as Unity regards it. ‘NetworkBehaviour’ and ‘NetworkIdentity’ is now not used at all. When the server starts the scene is changed to the ‘Server’ scene, and when the client starts the scene is changed to the ‘client’ scene. When a server connects, the server creates an id representing that client and puts it plus connection details to a list which is kept on the server. ‘ServerMain’ and ‘ClientMain’ are now called ‘Server’ and ‘Client’ and are attatched to an empty GameObject on the ‘Server’ and ‘Client’ scenes. I was going to make a ‘MessageManager’ class, but instead decided to inherit from Unity’s ‘MessageBase’, calling the class ‘MsgBase’. The MsgBase class contains public ‘SendToServer’, ‘SendToClient’, ‘SendToAllClients’, ‘Recieve’, and ‘Register’ functions. Register must be called statically with the respective ‘MsgBase’ derivative class type as argument to be able to recieve messages of that respective type. Recieve is called when a message is recieved of the respective type.

Cogwheel Main Menu

CogwheelHello and welcome to the last of the blog posts of our Planet Suburbia game. The game is nearing its finish, and tomorrow it has to be done. There has been a lot that have had to be done, but I feel like it’ll turn out pretty good.

One of the things I’ve done this week is to implement our new main menu screen. I’ve spent a number of hours on it today and yesterday, as there are a number of things that needed to go into it. I’ve also implemented the new appearances of the other menus, but what I am going to talk about in this blog post is the main menu. Our new main menu screen looks like a cogwheel. The cogwheel is rotated when you change which one of the menu items is selected.

Behind the cogwheel are scrap parts that are floating around in space. They represent the destroyed planet shields and destroyed alien ships. They get a random position and rotation when they’re created. They also get a random direction with random speed and rotation to continuously move and rotate in. They also get a random sprite out of 9 different images.

When you select a new menu item in the main menu, the text of the selected menu item becomes green. There’s a slight fade-in on it when the white of the unselected text goes to the green of the selected text. The menu is navigated using the ‘a’ and ‘d’ keys. We were thinking of making it possible to also navigate the main menu using the mouse, but we scrapped that as we don’t have much time left until the game needs to be done.

The way of how to rotate the cogwheel helped me with the rotation problem I had with the planet in-game, the one in-game is a bit more complex though. The problem was that if the rotation of the cogwheel was 0 and you wanted to selected to the one to the left, it would then go to the right, the long way around, to rotation 270. It does the same way when going from 270 to 0. My solution was to set the rotation to -90 if the rotation is 270 and it should go towards 0, and set the rotation to 360 if the rotation is 0 and it should go towards 270. I think it didn’t take so much time for me to figure out how to do that.

I hope you’ve enjoyed reading my blog posts about Planet Suburbia, and hope you’ll continue reading and enjoying my blog posts in the future that I might possibly make.