This is going to be the first of many articles we put out on the development of Lamina Island. The goal of these dev logs is to explain in broad strokes how we accomplished what we did. It won’t cover everything that was done, but it will cover anything major. There will be various smaller articles to cover more finite details. We also have a progress log for those of you less interested in the technical side of things, and just looking for the key notes.
Nothing is set in stone, and during game development a lot of features will be re-designed or completely scraped over time due to many reasons. These dev logs provide a snapshot into what the game looks like at the time of writing them, and hold no promise of what will make it into the final product.
The focus of this month for our development in Lamina Island has been our Alchemy Minigame.
Development started with the Ingredient Spawner. This is the code that decides when and how to drop the ingredients from the sky into the mini game. This code base started out working by just defining a box of space that can pick a location for it, but We ended up writing a Camera extension method for unity to pick a random point in screen space.
Once we got the ingredient spawner working, we had to work out how to get the ingredient itself to work. Using spawn pools, the ingredient would pulse out radicals. When the radicals hit the player, both the player & the radicals need to die.
We can’t have the radicals going around forever, so we added borders around the visible level just outside the scope of the camera that kill the radicals on contact.
Once we had this worked out, we started work on the recipes. We used scriptable objects to hold a lot of our information. The recipes were a bit complex since we wanted each recipe to be able to have their own unique instructions. So the recipe is basically a list of instruction scriptable objects that decide if an ingredient matches the instruction & a sprite of what the potion bottle will look like.
From here we had to get the player to be able to pick up the ingredient, and then when they step on the recipe it checks to see if it matches any of the recipes instructions, and mark the instruction as complete if that’s the case. When the recipe is ‘finished’, is a simple matter of checking if all the instructions are complete.
Of course from here, we realized a design issue of the possibility of spawning recipes that you don’t have ingredients for, or ingredients that don’t correlate to the recipes on the ground. So we had to add a lot more intelligence.
Reading the player’s loot hoard, we would determine what recipes could be made and spawn random recipes from that list. Then it was changed so that the recipe causes the ingredients to spawn instead of the ingredients to spawn on their own independent timers.
This had the benefit of more recipes naturally causing more ingredients on the ground, and the ingredients to always go to at least one of the recipes already out. This was awesome…but it also immediately hiked up the difficulty beyond what was reasonable to test with.
We ended up just adding a hard limit on how many ingredients & how many recipes can be on the ground at the same time, and marked them pretty low for testing purposes. Managing difficulty was not something we wanted to dedicate time to until at least at least all the basic features in the game.
The next thing we added was the elements. These were fun, because just the simple act of going from standard unity white balls to fancy fireballs makes the game feel a lot more alive.
Now that we had elements into the mini game, we needed to add potion residue to spawn when you finished brewing a potion. We found some jelly assets on the unity store to represent them.
We had to make sure elements maintained throughout the entire process. The ingredients used in the recipe dictate what element residue can be created, which will decide which elemental barrier you get when you pick it up.
The barrier was easy to get working, as we would just parent the barrier to the player & add a collider to kill any radicals it ran into.
After some play testing, we found that using previous ingredient elements to determine the barriers that is given to you resulted in getting unfavorable barriers too frequently, so it was adjusted to pick it’s element based on what elements are currently on the field rather than what was used to make that particular potion.
More playtesting revealed that there was a lot of ‘pause and wait’ gameplay in which you were just waiting for the environment to change to be able to move again. And sometimes the movement required was too precise to pull off with the current controls. In general all of this led to a lack of feeling of agency.
To remedy this we added a shield. Which unlike the barrier can block any element. Knowing this could easily be exploited we started with a three projectile limit for it to block and a five second delay between each block and the block limit being regenerated.
The last thing we got up and running completely, though throughout the entire process we were using it somewhat, was our difficulty manager. A lot of co-op games try to balance their stuff by having one value of things for single player & then just trying to add a multiplier for co-op. And while you can sometimes get this correct with a lot of testing…usually it’s a mess.
Usually using a single difficulty curve for both single & co-op game play end up causing either single player to be too easy/hard or co-op to be too easy/hard. And the reason for this, is that a change in one system can unbalance the other. So for our mini game we wanted to make two separate difficulty managers. Single player & Co-op. This way we can fine tune one until we are comfortable with it, and then fine tune the other one without needing to worry about breaking the first one.
Once the mini game was fully established, we brought our focus on connecting the mini game to the main game. We added a confirmation window, required a minimum of 20 ingredients, and finally fixed our loot magnet.
