• Hermit

Milestone 1: Basic gameplay, Enemy system, first boss, and storyline

End of November, we hit our first milestone “Basic gameplay, Enemy system, first boss, and storyline”. Dwell with us into the state of the prototype and how we approached this new, exciting task of building a complex game.

Associated with winning the grant came a set of milestones to keep us structured throughout the development. The first milestone, which we hit end of November, was titled:

What this means, is that we needed to implement the base structure of the game, develop tools which allow us to rapidly implement new elements later on - i.e. add content easily -, define an artistic line for the game and arrive to the same state that we had with the game jam prototype, but in a robust implementation with a future oriented mindset, and obviously a polished art direction. I will here present the different tasks we have set for ourselves in these past few months and were we stand now. More detailed blog posts going more into the details of our choices of implementation, game-design and art direction might follow.

Hermit

The first point of order was to set up our little hermit in a way that feels smooth and amazing to play. Given the pre-set of the game - the hermit is squishy and vulnerable outside its shell - it felt important for us that mobility of the hermit and reactivity of the controls work really well and feel good for the player.

The base set of movements stay the same as in the prototype, i.e. the hermit can:

• move left or right
• jump

which are very basic functionalities. We then added two more abilities, both paramount for a smooth game experience:

• double - or multiple - jumps
• dash

These two features, although basic, definitely extend the player’s movement range, evade possibilities and overall control of space quite a bit.

It’s a bird, it’s a plane, it’s superHermit!#gamedev #indiedev #pixelart #IndieGameDev #indiegames #swissgames #madewithunity #aseprite @WithAseprite @aseprite @oropouche @JoGiezi pic.twitter.com/qH5fpP6msw

— Early Coffee Games (@EarlyCoffeeGame) November 2, 2020

The three other features were already part of the prototype:

• equipping and unequipping shells
• burrowing - hiding inside the shell
• activating a shell - using it as a weapon

The biggest difference between this implementation and the game jam version is that all components have been smoothly integrated into each other, transitions and interactions between components (jump, shell usage) and differentiating between mechanics and display, all with the idea to make the game more robust and bug free (hopefully 😅).

The animator as well had a complete overhaul, each previously mentioned state acting as a sub-state machine with more complex mechanics underneath. The different equipped shell each have their own animator overrider, so that the shell is an animation layer on top of the hermit, overridden with custom shell animations.

Shells

The shells being the main component of the game, this was our main point of focus over the past months. Given the little time we have to work on the game (we both do this in our free time), in order to be able to iterate different shells and to add them to the game easily, I developed a little tool which allows me to easily setup a new shell.

This tool allows to easily create a new shell, with all links between shell, hermit and enemies correctly setup.

It might seem odd, but a new shell is not just a sprite that you can add to the game and then works. There are different components coming into place, and these need to be well structured such that all shells work seamlessly.

Each shell needs to have a certain behaviour when equipped, the animation and integration with the hermit need to work, and it needs to be clear what happens when the hermit activates the shell or when the shell hits an enemy.

Fortunately, there are a lot of great concepts in c# to ensure such behaviour. One great example is the concept of inheritance, where one defines a base code for one particular behaviour of the shell, let’s say when the shell is equipped, and each subsequent shell will then inherit from this base code and have the same base attributes and behaviour. I can then add behaviours on top of this existing skeleton, for the specific needs of the shell, but ensuring the base stuff is actually happening.

For example, whenever a shell is equipped by the hermit, I want to make sure the shell disappears from the world and only exists on the hermit from now on. Or I want to alter the effects enemies have on the hermit when it gets hit: enemies now hit the shell instead of the hermit. This is all made possible with delegates and inherited behaviour.

In case of interest, it helped a lot to dwell into SOLID development to come up with a correct way to structure the interactions, and foremost, Jason Weimann’s SOLID tutorial series for Unity.

How do the new shells behave

The new shell implementation behaves a little bit differently than the old ones. As in the old system, they all have a given number of durability points which differs for each shell. The biggest change, is that this durability is now a shared commodity between offense and defense: hitting an enemy is going to cost you a certain amount of durability points, as well as defending against an enemy.

The other change is that getting hit by an enemy doesn’t automatically destroy the shell: whenever you get hit by an enemy, two scenarios unfold: you are either in burrowed state, and will thus simply take a durability hit but keep the shell equipped (as previously in the prototype), or, if not in burrow state, the shell gets hit and unequipped (as opposed to destroyed previously). This still means the shell loses in durability, but you can still re-equip it. If you don’t get hit by a monster in the meantime that is.

This change is mostly meant to increase the attractiveness of last-minute burrows as an escape manoeuvre. Hope it works!

Different types of shells

For now we have three shells implemented, with many more ideas in the pipeline: the two shells from the game jam prototype, i.e. the green one whish allows you to roll, and the rocket one which is thrown like a… rocket. We added a third one, a tea kettle, which throws you in the air and smashes to the ground, destroying the enemies in it’s path, but ending up destroyed (one use). Obviously lots more to come!

How do shells evolve?

We plan on having different types of upgrade paths for the shells: one which simply adds stats, like more durability, lower cost of attack, or higher attack points, and one path which improves on the shell’s ability, like e.g. the possibility to display the trajectory of the rocket shell.

Enemies

Enemies are at the core of the interaction in the game, and must thus feel diverse and challenging. Here as well I developed a little tool which permits to easily implement new enemies with all the required components.

One big element in the enemies’ implementation is the use of unity’s prefab variant, which heavily improves the workflow.

The idea for the enemies is that we will have different biomes, where the hermit has to struggle against different kind of enemies. Each biome will have a unique feel and environment (which we still have to implement, all surroundings you see in the clips are temporary). For this first milestone, we decided to focus on the “Crab” biome.

We have a couple of funny ideas which came from this process, hope you will enjoy them as much as we enjoyed implementing them.

Something’s coming…#gamedev #indiedev #pixelart #IndieGameDev #indiegames #swissgames #madewithunity @WithAseprite @aseprite @oropouche @JoGiezi pic.twitter.com/bpTxGUji8Z

— Early Coffee Games (@EarlyCoffeeGame) October 30, 2020

Conclusion

That’s it for now, hope you enjoyed this little update. We will try to post in a more regular fashion from now on, we had a lot of things going on apart from the game, and taking time to write blogs is not always easy. Let us know what you would like to hear about, I will probably post about the hermit’s movements next, something I really enjoyed implementing. I would also like to talk about our technical process of iterating with Tristan, how animations go from being images to landing in Unity, and talk about the tools we use, would this be of interest?

Don’t forget to head to the Contact page to find the different ways you can keep up with our updates.

Thanks a lot for reading!