Lunacy of War


Lunacy of War is a skirmish real time strategy game where the player controls an army of units conquering strategic points on different maps. The strategic points can be used to build structures and produce larger armies.

The enemy plays by the same rules as the player and mostly the gameplay consists of outsmarting the AI and multitasking.


  • Real Time Strategy Game
  • Created in 10 weeks half-time
  • Created by three level designers, five programmers and three artists

My Contributions

  • Level Design
  • Created one level
  • Created an RTS camera using Unity
  • Created various scripts for exporting scenes in Unity into a readable XML-document

The Team

Cherry Picking Features

After the success of the space shooter game we had just created, we felt confident that we would be able to make an awesome real time strategy game. First thing we did was to suggest ideas for reference games that we wanted to use as inspiration for our game. We ended up with a total of three reference games from which we cherry picked certain features that we wanted our game to have. The basic concept behind the game was a skirmish style game with control points where the player and the AI built structures.

Later on in the development process we learned the hard way that having multiple reference games was a terrible idea while creating games at The Game Assembly. At the time however it seemed like a solid concept and everybody had a say in what the game would end up becoming. so initially nobody felt like their ideas were excluded or ignored.

Some early concept art for the game created by Victor Petersson

Basic Symmetrical Balancing

Having made real time strategy maps for Warcraft 3 prior to this project I found it relatively easy to get started. Like any RTS map I started out with a basic symmetrical top down in Photoshop and then incorporated and took a look at it in Unity.

Using a symmetrical layout was an easy way for me to balance the conditions that the player and the AI would have so that playing against the AI would feel fair. Since we were pressed on time and didn't have a clear idea of how the game was going to be played once it was finished, I spent very little time with paper planning and stuck to the very basics for my top down map.

The general idea was to create a couple of different levels and see which concepts worked and which did not.

A screenshot of a part of the map during the blockout stage

A rough sketch of a symmetrical map made by me

Setting Up Goals

Since we knew early on that the AI part of our RTS game was going to take a long time to implement, I tried my best to imagine the different scenarios that might occur once it was implemented. I had an open dialogue with the programmers about different scenarios that might occur so that they might keep these situations in mind while creating the AI. The programmers were grateful for my input and I kept on providing feedback throughout the project.

Besides from that I also played around with the assets that were provided to me, striving to create a cool looking futuristic environment using those assets. In order to make things easier for us, I created a really basic script in Unity which enabled the level designers to fly around their maps in a third person perspective so that they could get a sense of what the player would and wouldn’t be able to see once the level was implemented into the game

Please Don't Make Me Export the Terrain

Once it was time to export our levels we had to do a number of things. First we needed to export the terrain that we had created in unity and then import it as a texture in photoshop where we would change the format of the texture file. We would also have to do the same thing and more in order for the splat map to work in game.

On top of that we had to export a navmesh from Unity and import in to MAYA where we cleaned it up and then we imported the clean mesh into another program that was called meshlab, where we finally exported the finished navmesh. After that, we also had to export the level into an XML file and then some of the time our levels worked and sometimes they didn’t work. Most of the time though, it was unclear why our levels didn’t work.

Since this process was very time consuming we tried to avoid updating the terrain of our levels. The result was that, in the end, more time was spent exporting our levels than actually playing them and this had a negative impact on the finished product.

The terrain exporting process wasn't really anybody's fault, there just wasn't enough time to develop a better solution for the problem. Every step of the process was thouroughly documented however, so that made it easier.

Part of the 22-page list of things we needed to do during export

What Do We Really Want?

Besides from the techical difficulties mentioned earlier, a lot of questions regarding game design and gameplay started to pop up during production. Questions like how our units were going to be balanced in battle against each other, how many seconds it would take to build a structure and what the end goal of each level was were just a few of the questions the team had.

Having three separate reference games, each member of the team (including me) referred to their favourite game out of the three as the one containing the best solutions to every problem, which led to a lot of subjective discussions with focus on right and wrong instead of discussions about logical and optimal solutions to the problems we faced. I myself often referred to my favourite RTS game Warcraft III as the game containing all of the best solutions, but I failed to recognize that other games had other features that might have served our game better in certain cases. Once we realised that having one reference game would have been so much better than having three, it was too late to do much about it.

Basically, every member of the team had a different idea of what the final product was going to be like which led to a lot of wierd choices in terms of prioritization as well as a lot of frustration for everyone involved.

A screenshot of one of the levels in the game

The final product

Coping With The Deadline

Once it was time to hand in our game we still had a ton of features that we knew were sub par, but we had no time to test those features. The game was full of bugs and we recieved a lot of negative feedback regarding many of the core features of our game. Before the release we had already created a long list of bugs and problems that we needed to fix after release. Not much feedback was giving concerning the level design of the game due to some game breaking bugs preventing the players from playing the levels.

While it was hard to read all of the negative feedback from the players we took the feedback to heart and we worked hard to fix the things that were broken after the release. We learned alot from fixing the game and in some ways it was nice to see that the players and the developers were both frustrated with the same core features.

Closing Thoughts

While this project was at many times frustrating to work on, it was also a project that taught me a lot about teamwork and the importance of having a unified vision for a game. Without clear goals to strive for, I found that team members will work on things that they themselves think is relevant to their own vision and that will eventually lead to misunderstandings and subjective discussions.

During our post mortem meeting the majority of the team agreed that having different reference games was the source of many problems that we faced and we decided to keep this in mind while making our next game, which was going to be a first person shooter.