Lamina Island Dev Logs

Welcome back to the Lamina Island dev log series. Where I’m showing off our game from start to finish. We are still a long way to go before we reach the finish line but we are now at a point we can put up a page on Steam so you can begin to wishlist!

https://www.youtube.com/watch?v=OrH_YQwDoLQ&feature=share

The goal of these dev logs is to mark out the biggest features that have been added, changed, or removed. It won’t cover everything that was done, but it will cover anything major.

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.

We missed last months dev log. The focus of these last couple months our development in Lamina Island has been adding in our dialogue system & quest system. We also spent some time shifting from the unity Stand render pipeline to their Universal Pipeline. Which…was a project.

We eventually got everything, you know…not pink. Then we spent some time implementing the grass made by Brute Force, which came out looking pretty cool.

For the dialogue system, we ended up using unity’s ‘localization’ package so that we will be able to shift the project’s language with ease in the future. That of course, required us to go through the entire game & replace any text with

For the quest system, we had to make sure that the quest state was kept track of at all times. So when you first enter Evolym’s area, each actor will go to the quest manager and see if they have any finished quests for you to turn in, quests that your currently on going, or quests that are available to give you. And then they pick their dialogue options based off this information.

We then had to add some events to refresh the status of the quests,as they change in real time. This allows you to take on a quest, do it, and then turn it in without needing to reload the level. While all of this is pretty basic quest stuff..it still had to all get implemented & wrapped into our save system.

The goal of these dev logs is to mark out the biggest features that have been added, changed, or removed. It won’t cover everything that was done, but it will cover anything major.

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 creating our game’s taming system. In Lamina Island you can tame animals and change the character you are controlling. This is all done through our taming system.

So, our taming system started out with our beam. This ghost beam attaches to a target and alters the player’s movement to face the target while walking.

The beam lowers their confidence bar. And when it gets low enough, the confidence bar changes color to indicate that the target is docile.

While the target is docile, you can use ghost commands, which are available in the confidence bar. The two ghost commands we got up & running were “Possession” which allows you to take control of the target. And of course the ghost command that gives the system it’s name “Tame” which turns the animal into an ally.

And those are the major features in this update. A few bugs were fixed such as the issue with our co op UI that caused player two to always end up taking control of player one’s pause menu.

The goal of these progress logs is to mark out the biggest features that have been added, changed, or removed. It won’t cover everything that was done, but it will cover anything major.

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 breaking apart the Island into level chunks, and creating the first pass for the are players are going to be spending the most time in, the Underground.

The way we are loading our levels got upgraded. We are basing it off of how unity did their open project level loading using unity’s addressable system. It is a pretty cool way of loading levels that is not dependent on build indexes, and since we are in the process of breaking 1 big generic level into many smaller but more personalized levels, our build indexes were changing too often to continue to be a basis for our level loading. It also gave us a chance to expand upon it & load a scene in the proper context, so if you entered the room from a specific side, it’d bring you to that side of the level you entered. Standard video game stuff that we did not have in our game until now.

The underground level was white boxed, and then fleshed out into our first pass implementation.

We added a placeholder for our shop keeper. At the moment, he’s just a pretty figure head, but eventually he will be the shopping point to spend all your gems to upgrade your underground.

And of course, a shop would be completely useless without gems to collect. So we added Gembot.

The idea behind Gembot, is that he will spawn in a random area each day, and if you find him, he will spray gems all over the place. He is shy however, and if you get too close to him, he will turtle up until you give him some space.

We also added the first implementation of our shadow cloud. The shadow cloud, chases players down and summon monsters in it’s wake.

And that wraps up our 10th month of development on Lamina Island

During the beginning of development for Lamina Island, one of the ideas that was kicked around was the idea of having a ‘desire system’ to give the player something they’d have to pay attention to. The desire system was also supposed to give the AI something entertaining to be doing while you were just sitting around, as this was before combat was

In this desire system the goal was that the animal would eat when they are hungry & look for entertainment when they were satisfied with their desires. The idea was to have something similar to the Sims’s need system.

You can read up on their system here, which is way more advanced that what we were going for with the desire system.

To test that the AI would actually go around and ‘do things’ a test environment was set up with cubes to represent something that gives entertainment and something else that gives food.

Once it was proven that the basics of the AI worked, we had to figure out if it would be entertaining. So our test scene got a little bit of an upgrade, and what we ended up with was spiders who kicked soccer balls.

While the end result did end up being entertaining, we did not keep the desire system in the game because it didn’t end up fitting with the rest of the game’s features, and gave the game the wrong feeling. But it was an interesting system to develop, and it might end up being implemented in a future game project.

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 game’s AI.

Since we ended up scrapping Emerald AI to be able to have more control over it, that meant we had to implement our own combat into our AI system. The core of our AI system is based off the three state AI logic of FEAR. Our states are a little bit different then theirs, but the essence is the same. And just like their system, it probably could have been cut down to two states.

Our three states we settled on were “Plan”,”Move”, & “Do”. And this worked great for a long time. We had a general desire system & that would drive the planning, and everything else would work accordingly. Our game however has a few complexities that have pushed this system to it’s limit.

For one while most games have a player entity & an AI entity. One of the core mechanics we are shooting for in this game is the ability to shift between one entity to another. That means all entities are AI & any that we allow the player to control is also player. To accomplish this, when the switch occurs, we have to kill whatever action plan we have on the entity the player is about to control and kick on the AI for the entity the player is no longer controlling.

And the most important limitation? This is our first full scale AI system. The FEAR system was written by somebody with a lot more time and experience to dedicate to their AI than we have to dedicate to ours.

So we ended up having to make a few modifications to the FEAR model. We reduced the world state information significantly. Rather than knowing a blackboard of information & updating it as needed, the only ‘world’ information it has access to is whether or not the action in question is being advertised and what goals said action contribute to.

There was also a lot of processing being taken into consideration by each entity in the planning state. Each entity was running it’s own planning logic, and that planning logic included scanning their local area, global values, and checking all of the pre-conditions as well as attempting to plan 3 steps ahead, so it would evaluate every action to see how it changed the world state before discarding it. And this was before we even added combat into the mix. If there were 100 apples on the ground and the AI was looking for something to eat, it would go through all 100 options, and then see, if eating the apple changed the world state in any meaningful way by estimating the outcome of the action against the remaining 99 options. This would get out of hand very quickly, and was not ideal.

Since we cut the pre-conditions out as well as the ability to plan more than a single step at a time, all of the delays were removed. We also pushed the AI planning out of the entity’s realm of control and instead into a shared ‘master mind’. Now the entities simply hand the master mind it’s desires & what entity it is attached to, the master mind evaluates all the possible actions for the entity, and then returns an action plan for the AI to follow.

This immediately cut down planning time by several degrees. Of course the obvious ‘only look at one step at a time’ caused the biggest change here. Another effect of a centralized planning system however was the ability cache some of it’s evaluations & thus reduce the number of repeated calculations.

I think our biggest issue with getting the preconditions and world state correct, was an inability to clearly define a useful way to represent the world state. We will explore this further in side projects before implementing it in future games, however the AI system as it stands allows for a lot of different behaviors without a high degree of effort in slotting them in, so while it’s not perfect and does not allow for complex series of actions, it will work for what we need it to do.

We also added a mood system which is a bit on the crass side at the moment, but it acts closer to a standard state machine in which it holds a list of desires and triggers can put it into a different mood that would hold it’s own desires. The logic goes like this. The AI’s mood starts out as ‘calm’. Each mood holds a list of desires. A player attacks the AI, now it’s mood has changed from ‘calm’ to ‘aggressive’ and it has a new list of desires. The planning system, when reading the desires will thus give you a different set of actions.

It kinda means we have a little bit of both systems but that’s OK because it allows us to get classic AI logic in for our animals & monsters, but still be able to inject some observatory AI into our Lamina & Heroes. By observatory AI, I’m referring to the kind that kind that is less combat driven and more entertainment driven. While the lamina is in our home base for example, just giving them the ‘desire to eat’, we can slot in a dozen different food and it will go to any number of them and eat them. By slotting in the ‘desire to play’ we can add a number of toys for them to play with and thus give rise to looking like they have a sense of agency worth observing.

There are a million little decisions that went into the framework of our AI system. Too much to cover in a single article while giving it justice. There will probably be a few articles covering different parts of the AI in greater detail. Being an iterative process, I doubt it’s anywhere near complete yet.Now we have a strong framework that we can build upon that is capable of all our goals, and that marks a pivotal point in the project’s development.

The work put into our spawn systems was minor in comparison to the AI, but just as important. That will get it’s own post down the road. The combination of these two however, make the game feel much more alive, and that is the most important part.

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.