The past week involved creating the new module for my exploration world and getting sarted with it.

What have I been up to?

Creating the Lost module

The Lost module is the new gameplay module that I have created and would be working on for the next two months. I’m still working on writing some logs but the general idea for the lore is complete. In short the story is centered around an intergalactic explorer who while exploring the vast world of Terasology, gets stranded. The wormhole creator that allows him to travel through space becomes dysfunctional. Fornlorn with no way to return to his home planet, he starts exploring the planet, trying to survive on what may become the last planet he would ever set his foot on.

Integrating Journal

A key part of the new explorationn world would be a journal that links several things. The main purpose of the Journal would be to serve as a secondary memory for the player. I plan to use the Journal in several ways-

1. Exploration logs that would be generated as time passes or when an event occurs. Like when the player first spots a deer or finds a treasure.
2. New recipes would show up when the player pick a new item. Like picking up a stone would create an entry with the recipe for hammer.
3. The journal would be integrated with books. Whenever you open an important book, the key parts of the book would be stored in the journal.
4. Integrations with content modules like WoodCrafting, StoneCrafting (earlier WoodAndStone), CopperAndBronze, Alchemy, EquipmentSmithing, Equipment, Cooking and SimpleFarming. These would essentially be tutorials to help the player. Essentially recipes that show up, guides about more involved process like different quality of ingredients resulting in different final products.

As of now the Journal has only been integrated with item pick up events and an initial on-spawn event that sends the first journal entry.

Improvements in Journal

The Journal module was left pretty much untouched since MarcinSc had created. The Journal module looks like so-

It has a left panel for different chapters and each chapter has its own entries. This handles categorisation pretty well, making it easier for the user to access specific entries and saving a long scroll.

I’ve added another enhancement which now makes the Journal more interactive. Earlier there was just a notification that would pop up when a new Journal Entry was added. However, it wouldn’t be highlighted in any way in the Journal. With the latest PR merged, now the unread Journal entries appear highlightedin yellow, until the chapter they belong to gets opened once.

In the image above, Exploration Log #111 is a “read” entry while Exploration Log #112 is a new/”unread” entry.

Roadblock: There was a problem with the Journal module though, the first journal entry that was required to be sent only once when the player was spawned was resent every time the player respawned. This happened because the onPlayerSpawnedEvent was sent to the Player entity even on respawn.
A bigger problem was that whatever entries that the player had in his journal would all disappear when the player respawned. This happened because the player entity in the game was completely destroyed when the player died. In the process all components attached to the player were stripped and destroyed too.

This was what I dealt with for the larger part of last week.

Saving the player entity from destruction

All existing systems relied on the player entity to be totally destroyed (and stripped of all components) when the player dies in game. This however wasn’t a nice approach, as the player entity carried a lot of data that potentially could be preserved or dealt with a better way even on death.

I felt this problem for the first time when I realised that my player would lose all it’s journal entries on death. However there are many other cases which require the player entity and it’s components to not be totally destroyed.

The need

1. A player’s inventory is always lost on death. It just disappears. With the player entity now being preserved, the player simply gets to keep its inventory after respawn. However, if needed a system can easily be added to allow items from inventory to drop when a player dies (even probabilistically).
2. Many other components would be better off having persisted than being destroyed at death. For eg. the EventualSkills module makes learning and gaining skills possible. All the skills a player has just would disappear if the player entity is completely destroyed, which might be undesirable.
3. There was no separate event that would be sent upon respawning. Now there is an additional onPlayerRespawnedEvent that can be used for this purpose. The onPlayerSpawnedEvent is simply an event that only gets fired once when the player enters a world for the first time.

This PR makes the said change. It adds the OnPlayerRespawnedEvent, PlayerDeathEvent, AliveCharacterComponent, PlayerCharacterComponent.

What happens now

A character lives. It has the AliveComponent. It dies. A BeforeDestroyEvent handler receives all entities having AliveCharacterComponent

• If the entity also has a PlayerCharacterComponent, the event is consumed to prevent destruction. The AliveCharacterComponent is stripped off adn a PlayerDeathEvent sent along with DeathEvent
• Else just a DeathEvent sent and the AliveCharacterComponent stripped off. DeathScreen launches on PlayerDeathEvent and sends the RespawnRequestEvent. RespawnRequestEvent is received by the PlayerSystem. PlayerSystem then respawns player, sets the location for clientEntity to spawn location. Sends OnPlayerRespawnedEvent.

Components that need to be removed on death are removed by receiving the PlayerDeathEvent. Components that need to be reset are done by receiving the OnPlayerRespawnedEvent.

Next week would see more work on the exploration module. I need to experiment with Structural Templates and see what’s the best way to spawn structures in different places.