I hoped that I'll make new levels before June, but I have some health issues and will go into hospital in a few days and have been spending the last few weeks doing medical tests... It's nothing serious, but is frustrating and time/nerve consuming.

When I get back I'll continue working on the levels.

In the meantime I did many changes to the project and most of those are new, never before seen features!

Project development direction

Some people have a tendency to hide most of the elements from the Unity scene, to make things less visible or cluttered and maybe that's a good idea for complicated projects but for this project I don't think that kind of optimization would have a big impact. Based on my experience as a game developer I'm more keen to make things clearly visible, understandable and easily changeable by a level designer.

I'm going in that direction while working on this project and I believe this approach will prove adding and creating art and levels less time consuming and more fun.

Project changes

Multiple characters control

I've implemented an option for the player to control multiple characters. This will be done by switching between currently controlling characters while on the same level.

Handles playable characters information

After some testing I've decided to make the switching option available only during the Idle state of the currently activated character. Depending on the feedback this could be changed, but I've noticed that in other cases there are too many glitches and issues. It also often feels very strange during gameplay.

Implementing character switching meant I needed to make changes on many things - like checkpoint control system, interaction with the world, objects and enemies, camera control, UI control and player input control.

Our beautiful Princess is jumping around like our main character does. Little does she know that she cannot attack the enemy underneath her!

Character switching system I've implemented can theoretically hold infinite number of playable characters, but in this game four will be the maximum.

I've made everything modular so on UI there could be shown character icons (or not) and information like health and attack bars. Attack bar is not visible if character doesn’t have attack ability.

For example Princess will not be able to attack, but will be able to interact with some special objects.

Checkpoint control system

Checkpoint control is now handled modularly. I've changed its logic so there are additional classes for each different activated/deactivated state when a checkpoint is reached or loaded upon game continuation. This makes the whole process of assembling gameplay logic for a level quicker, easier and much clearer.

New elements of the Checkpoint system

Before checkpoint system was level relative, now all important information are stored in Checkpoint Reached Controller class

Teleportation system

I've implanted this system so it can be used as forced or player desired action. This means that the same teleportation class/object is used to transfer controllable character to another position but also can be part of a teleportation object that can activate animation and sounds when character is teleported. Teleportation objects can be activated by any or by a specific playable character and can be disabled after activation.

Some elements are used just for easier following of states or for testing - like Disabled color

I think I have covered all options for teleportation gameplay logic I'll need on this project, but it can be easily upgraded if needed.

Interactable objects system

The simple example for this object type is a door, but the system can be used on other objects too. This system is similar to teleportation in a way that it can be activated by any or specific controllable character. Activation controls animation and sound on the interacted object. This also changes the state of the controlled object.

In this case it changes state of the JailDoor to 1 (open) if Player activates it and Collectable_key object is in state "collected". If the option Disable trigger after Enter wouldn’t be checked, the door would close on exiting this trigger (JailDoor state would go to state 0).

Changing state can be forced (without sound or animation) and this will mostly be used when the game is resumed after the player reached a certain checkpoint.

Door example for Interactable object. I’ve placed various offsets here because for example sometimes the sound of rattling the keys should be heard before animation starts and the bounding box should be removed only when animation gets started or is in a certain position.

Activation can be connected with an object that can be collected by certain or all controllable characters.

Example: Princess collects a key and when accessing trigger object, interactable object "door" is being activated - open.

Note that I've deliberately separated activation and activated objects. For example there can be a keyhole in one part of the room and by activating it the door in the other part of the room gets open.

Interactable collectable objects

Those objects are similar to other interactable objects and can be collected by any or specific playable character.

They usually need to be connected with the interactable object that "uses" them. There are three states for these objects - disabled, enabled and collected.

Collectable objects class

Collectable objects can be enabled during gameplay using the Interactable controller system or be dropped by an enemy.

Enemy dropped items

Some enemies when killed will drop items. Items dropped are Interactable collectable objects and they are set to disabled state until being dropped. Then they get enabled.

Small delay is added after the kill so the playable character can't collect this item instantly. This is done so players can notice items being dropped.

I plan to add Icon above an enemy carrying an important item.

Conclusion

All of the mentioned mechanics implemented were tested and worked, but there will be few tweaks. Hopefully these tweaks will mostly be of an esthetical nature.

But I’m aware that while working on new levels there will be a need for improvements and additions.

The biggest part of the job related to Chapter 1 mechanics I wanted to implement is now done so I believe I will soon be able to work more on pixel art and game levels for Chapter 1.

Stay tuned!