Grid Commander

Summary

The gameplay of Grid Commander consists of killing your enemies by carefully moving your units to strategic points on the map and using their different perks to your advantage.


Killing all enemies in the current level will send you to the next level until you finish the game. The player can obtain additional units by standing next to neutral units with one of his or her units.

Specifications

  • Turn-Based Strategy
  • Created in 8 weeks
  • Created by two level designers, four programmers and three artists

My Contributions

  • Level Design
  • Puzzle Design
  • Produced levels using the Tiled editor
  • Trum (Scrum) Master

The Team

Design Philosophy

Initially, we wanted to create a solid foundation for the game which we could later add to based on how much time we had, just like the previous projects I had worked in. We thought a good way to create that foundation would be to create a component system within the game engine which would serve as a hub where the level designers, programmers and artists could incorporate their work seamlessly using a graphical interface.


We knew creating such a complex system would be a challenge, but the programmers were up to the task and they started working on the system first thing. While they worked on the foundation, Olof Hedblom and I started to sketch up different ideas for the game and the features we would need to meet the requirements we had set up.


A UI mockup created in the early stages of development by Anton Sander

The prototype map which was used early on in the game

Playing With Dice

We started out by creating a top down of a level in Photoshop. Since we were making a turn-based strategy game, we were able to print out the levels on paper and test them using game tokens and dice as you would with a board game. We tried out different sets of rules and then we iterated those rules based on our playtests. This gave us a chance to lightly balance the game before we had a working prototype ready for testing.


We ended up with a rock, paper, scissors kind of balancing, where the different characters in the game had matching strengths and weaknesses. For instance, we had a melee character who could move long distances but didn’t deal much damage and a ranged character, who could only move short distances, but could deal massive damage to the enemies.

Revisiting Tiled

Once we were happy with the core of the game, we moved on to creating maps using the Tiled map editor. In my previous project, K.E.X., I had also used this editor, but this time we had to think differently.


The game was rendered using an ortographical view. This meant that we had to take things like the player's line of sight into consideration, since we wanted the player to be able to see his or her characters at all times.



What the component system looked like

An ortographic view of one of the levels

Time to Re-evaluate Tasks

Around the same time as we were finishing the basic blockouts of our levels, the base which would become the component system was finished. I was tasked with implementing the art from the graphical artists into the game using the component system.


Eventually, the art assets started to pile up and, as a consequence, I had to prioritize putting assets into the game over balancing my levels. Therefore I chose to delegate the workload to my colleague Olof, putting him in charge of balancing and testing, while I was in charge of implementing assets and features using the component system. We still shared thoughts and ideas regarding the levels and the game in general however, so we weren’t really restricted to our given tasks. We just had different responsibilities.

Functionality First

We ended up with a skirmish kind of approach to the gameplay, and the goal of every map was to eliminate the enemy. Additionally, the player could receive reinforcements if he or she chose to rescue neutral units on the map, providing the game with more versitility.


We also wanted to have different game modes such as defending an area using only a given amount of moves, or killing a large amount of enemies with the help of an AI, but we didn’t have time to implement those features. We prioritized creating a functional game over creating a ton of features and then cutting half of them.

Rescuing some neutral Units

Closing Thoughts

Implementing the assets into the game proved to be very time consuming and, up until the last few hours before our deadline, I was still implementing assets. While the component system I used eventually worked really well, too much time was spent fixing bugs related to it which in turn forced us to cut many gameplay features that we wanted.


Given more time I would have tweaked and balanced my levels further, and made sure the core we ended up with felt good for the player. For me, what matters in the end is what you do with what you have, not what you wanted to do with the ideas you had.

Screenshots

contact@erikleiram.com