Dev Blog 6 - Skirmish layer
Hey everyone!
Starting this week, I’ll be talking a bunch about the combat layer of the game.
Most world encounters will be of a social nature, designed as a story driven by your choices, with branching narratives and different outcomes. However, some encounters are just a means to an end - to get you into combat. Once you get such an encounter, after a short introduction and setting the scene, you’ll be transitioned into one of our skirmish maps.
The combat works similar to XCOM, so it should be mostly familiar if you’ve ever played it: it uses a square tile grid, the player and enemy each have their own party of units, and take full turns to do all of their actions. Each unit has 2 action points to spend on movement and/or using abilities. There will be dedicated blog posts about units and abilities later. In this post, I wanted to talk specifically about the maps themselves.
A lot of roguelite games try having randomized levels to increase replayability and variety. We discussed doing random level generation, but ultimately decided against it. The reason is mostly that with a team of this size (only 2 programmers), it would take too much time and resources to implement a correct level generation that takes into account all aspects of what a level requires. Levels should be visually interesting, have unique elements and layouts that make them distinct from each other, have decently placed spawn points for both player and enemies, have enough obstacles and cover objects placed to make the gameplay satisfying for any combination of abilities that the players units can have. So, we hand craft each and every level.
This work is mostly done by 2 of our most recent additions to the team, Mateja and Lucija. They joined the team when they were still students of the Academy of Fine Arts in Zagreb around a year ago, and in the meanwhile, Mateja finished her studies and got hired full time, while Lucija is about to finish her degree. They joined to help our 3 poor struggling artists spread out the work, from modeling and texturing objects, animating environment objects and units, and creating levels and concept art. Most of their time, however, has been put into making the levels (and any required props to make them). A single level, from it’s concept stages to the finished visual design, takes around 2 days, if they have enough general props that can be just positioned in the world. If not, a single prop takes anywhere from 2 hours to a day, depending on complexity. Also, since each level is used by only one encounter, there is no fear that levels would be seen too often, as getting the same encounter in two successive runs has a low enough chance.
All maps feature certain obstacles in them. Some obstacles are based on terrain features, and define mostly where you can stand, and whether you get any sort of cover benefits. The other kind of obstacles are our destructible objects. They grant cover the same way as terrain features, however, they are fully destructible by abilities that have the “destroy cover” functionality. We’re in the process of giving them all a proper destruction effect, and the current idea is to have most of the small obstacles (around the size of a unit) reuse a pool of similar destruction effects, categorized by material (wood, stone, dirt/grass, etc), but for the larger ones we’d do a full destruction into pieces, like in the gif below.
Next week I’ll be showing off some player controllable units available in the first region of the game, and the party with which the player will most likely start first. Thank you for reading, and feel free to
Starting this week, I’ll be talking a bunch about the combat layer of the game.
Most world encounters will be of a social nature, designed as a story driven by your choices, with branching narratives and different outcomes. However, some encounters are just a means to an end - to get you into combat. Once you get such an encounter, after a short introduction and setting the scene, you’ll be transitioned into one of our skirmish maps.
The combat works similar to XCOM, so it should be mostly familiar if you’ve ever played it: it uses a square tile grid, the player and enemy each have their own party of units, and take full turns to do all of their actions. Each unit has 2 action points to spend on movement and/or using abilities. There will be dedicated blog posts about units and abilities later. In this post, I wanted to talk specifically about the maps themselves.
A lot of roguelite games try having randomized levels to increase replayability and variety. We discussed doing random level generation, but ultimately decided against it. The reason is mostly that with a team of this size (only 2 programmers), it would take too much time and resources to implement a correct level generation that takes into account all aspects of what a level requires. Levels should be visually interesting, have unique elements and layouts that make them distinct from each other, have decently placed spawn points for both player and enemies, have enough obstacles and cover objects placed to make the gameplay satisfying for any combination of abilities that the players units can have. So, we hand craft each and every level.
This work is mostly done by 2 of our most recent additions to the team, Mateja and Lucija. They joined the team when they were still students of the Academy of Fine Arts in Zagreb around a year ago, and in the meanwhile, Mateja finished her studies and got hired full time, while Lucija is about to finish her degree. They joined to help our 3 poor struggling artists spread out the work, from modeling and texturing objects, animating environment objects and units, and creating levels and concept art. Most of their time, however, has been put into making the levels (and any required props to make them). A single level, from it’s concept stages to the finished visual design, takes around 2 days, if they have enough general props that can be just positioned in the world. If not, a single prop takes anywhere from 2 hours to a day, depending on complexity. Also, since each level is used by only one encounter, there is no fear that levels would be seen too often, as getting the same encounter in two successive runs has a low enough chance.
All maps feature certain obstacles in them. Some obstacles are based on terrain features, and define mostly where you can stand, and whether you get any sort of cover benefits. The other kind of obstacles are our destructible objects. They grant cover the same way as terrain features, however, they are fully destructible by abilities that have the “destroy cover” functionality. We’re in the process of giving them all a proper destruction effect, and the current idea is to have most of the small obstacles (around the size of a unit) reuse a pool of similar destruction effects, categorized by material (wood, stone, dirt/grass, etc), but for the larger ones we’d do a full destruction into pieces, like in the gif below.
Next week I’ll be showing off some player controllable units available in the first region of the game, and the party with which the player will most likely start first. Thank you for reading, and feel free to