Summit is a game I worked on during my 3rd year at ICAN.
As most of our group was made up of card game players, we decided to make a deckbuilder roguelike as we were most familiar with this genre.
I personally worked on programming, mostly alongside our level designer as I was in charge of creating tools for him to work with and to create algorithms to generate and spawn the maps he came up with.
This is the final project of my bachelor's degree and I really enjoyed working on it.
Here, I will talk about how I worked on the whole map system of the game.
Genre :
Roguelike - Deckbuilder
Roguelike - Deckbuilder
Software(s) :
Unity
Unity
My contributions :
Programming - Level Design
Programming - Level Design
.
At first, we wanted to make the game's maps using procedural Level Design.
Although we ended up not going with procedural Level Design, it is something we want to use going forward if we keep working on this project.
Although we ended up not going with procedural Level Design, it is something we want to use going forward if we keep working on this project.
In its place we focused on making more fleshed out and scripted maps. This led to me working more on how to make map generation and data storage more efficient.
Summit is a game where the player evolves on an hexagonal grid, for that reason I had to work on a new coordinates system as Unity's base coordinates system wouldn't allow me to easily determine the positions of the tiles where the player and enemies could move on.
In order to set that up, we used mathematics to determine the necessary X & Z axis offsets to position our tiles perfectly while placing them in Unity. Using that, we created a script that would calculate those positions for us when given specifically setup coordinates.
After having gotten this we used those coordinates as a Vector2 to position the tiles on our map and create the most comprehensive coordinate system we could, adding a 3rd horizontal axis since hexagons have 6 sides, this additional axis would use a -X/+Y format for its pattern (with X = +1/0 & Y = 0/+1).
The first thing i did once the coordinate system was done was to make a Editor Tool to help my Level Designer in his work.
This tool can manipulate the height and flags of the different tiles easily and allows the designer to quickly setup the map they've worked on.
I also setup some filters to make setting up flags easier by allowing the designer to focus on what he wants precisely by showing only what he is currently working on (see the bottom 2 images on the right).
Once the designer is satisfied, he can save the map using a button in the tool, this will save the tiles' data in a Scriptable Object which the designer can now reopen anytime if he wishes or that ca be input directly into the map spawning script to generate the map in game.
Before
After
Flags
Enemy Spawns
In order to spawn maps during a run, we use the data that was saved through the tool in order to determine how to spawn the tiles in any given map.
This not only allows us to store map data using as little storage as possible but also allows su to spawn map in a way that lets us modify how the tiles spawn or the flags they have if we need (for example in the case of a special area that requires certain tiles to be flagged differently to trigger certain events).
Thanks to this system we can also check for tiles that are next to empty spaces in order to properly spawn environment tiles.
We generate those randomly from a pool of environmental assets and spawn them on some empty spaces next to walkable tiles.
The overall map spawning is done using another Scriptable Object which the Level Designer fills out by hand, giving the position of the center of the maps as well their height and the different enemy spawn points.
This Scriptable Object is given to the MapManager that will then oversee how and where the maps are spawned and also use this information to spawn enemies properly, this allows us to easily customize maps and enemy spawning using a single object.
Using a Scriptable Object for this allows us to make iteration and variations to the overall map easier to implement and test.
In order to have enemies move on the map, I implemented a pathfinding system, due to time limitations I only used a simple Greedy Best First Search algorithm.
This decision was made because it is a simple and fast algorithm to implement and, while not the most optimal one, it is more than we need due to how small yet not labyrinthine nor cramped our maps are.
This decision was made because it is a simple and fast algorithm to implement and, while not the most optimal one, it is more than we need due to how small yet not labyrinthine nor cramped our maps are.
Using this algorithm, I can tell enemies what path to start taking every turn.
This algorithm also allows us to determine what tiles the character can interact with when using cards.
Working on this game was a really interesting and fulfilling experience, we have not finished working on it and we intend to keep doing so in order to be able to present it properly and truly be proud of the work we've done with it.
