Project Labrador - Data Persistence

Hi folks, since I’ve decided to take a break from developing Project Labrador (at times I already felt burnt out, so it’s better to relax for a bit and rethink stuff all over again - even if it takes months or years, I’ll rather work on it when I’m comfortable with it rather than forcing myself to do so), it’s a perfect opportunity to tell you a little bit about the project.

Like I mentioned in the Introduction, project was born on July 26th 2019. I was at work, waiting for a new project (which came just days after) and began to think: if Unity is scene-based, with no central data storage or manager, how do you keep track of entities and their data between scenes and also how to make it easy to save to a file and load it later? The answer came to me after a short research. Since I never did or had to implement such a system, I started to work on a prototype. I was excited. I finished it in 2 or 3 days.

Here’s how it works (please note that this is just my naive approach that seems to be working fine in my case. It has it’s quirks and pitfalls that you have to be aware of!):

  • Attach Entity component to the GameObject that you want to keep track of and make sure to set a proper id (generate a new one for new entities or copy id used before).
  • When the scene is loaded and the Entity Start method is executed, it syncs itself with the GameManager that stores all the entity data (inventory, stats, attributes etc.) that I wanted to be saveable. (NOTE: all the data that won’t change between scenes (like looks etc.) is not saved to the file. This way it’s possible to create NPCs that look differently based on some conditions in the game.)
    • If the data for said Entity are already stored in the GameManager, the Entity component’s internal data changes to the one in the GameManager.
    • If data does not exist in the GameManager, component’s data is copied there and stored for the future.
  • If data is stored in the serializable State object in the GameManager, it can be serialized and deserialized with one method.

And that’s it. Incremental entity data storage. This means that each entity component is filled in editor with its default values, allowing me to make a prefab of said entity to use in other scenes and ensures that even if we skip the scene where the entity was supposed to be first encountered, data will initialize properly and all the changes to his state will be persisted. Also, after some tweaking I was able to add something I called temporary entity - entity generated in runtime - at the moment it’s only used for items dropped from inventory, but in the future it will be possible to create some randomly generated enemies and so on.

Of course, this limits some options when it comes to creating scenes: entity instances live in a specific scene and cannot just leave it. They’re basically stuck, unless I simulate them going into other location and create an entity with their id in the other scene. For this purpose I had to create utility components that show/hide entities based on some conditions. Pretty hacky and limiting, but it should be okay for my purposes. I don’t expect to be doing that kind of stuff often anyway. Just keep it simple and it’ll work. I hope so at least.

Okay, that’s about it. This is just a tip of the iceberg that is my RPG framework. There’s a lot more to cover about it, I’ll make sure to write something more about the internals.

PS. Like a typical developer who is too ambitious to finish his projects, I’m contemplating starting a more achievable project that was in the back of my head for years now. I’ll only say this: it’ll be most likely created using Godot and will include a lot of conspiracy theories. Stay tuned!

Introduction

Hello, my name is Paweł and I’m a front-end developer in one of many big IT consulting corporations. But after hours I chase my dream of making games. Let me tell you about my pet projects a little bit more.

Way back in time I was a Computer Science student at Poznań University of Technology, where I met Sebastian Krzyszkowiak (also known as dos, check him out at dosowisko.net) who was also into gamedev and wanted to participate in Global Game Jam 2015. So we went there and in a period of 48 hours we created The Secret of Tremendous Corporation (check it out on Steam). Making an adventure game on a game jam seemed like a strange idea, but we did it anyway (the whole process of making it is a topic for another post). We downloaded an open-source adventure game engine called SLUDGE and just started working. I wrote most of the plot, dialogues and much of the code. And after stressful two days of work it was time to show it to the public. Even though we didn’t win any prizes (we landed at the second-to-last place), it felt good. We were fully fledged game developers. After the game jam, Sebastian took it upon himself to finish the game and try to make it to Steam. After a successful Steam Greenlight campaign it was time for final fixes and release. We had a game on Steam!

Fast forward a couple months (first commits in the git repo indicate May of 2015, but I’m pretty sure it was started some time before that), I’ve created a vaporwave-themed jumper-platformer called 私を買う: Trouble At Virtual Plaza that was fully functional and working, but lacked actual content due to my really poor GFX skills and lack of motivation. The game itself used Phaser and TypeScript and it introduced me to the wonderful world of HTML5 and modern Web.

After I graduated, I got a job as a front-end developer working mostly in React, Angular 2+ and Node.js, but that didn’t stop my attempts at game development. I participated in GGJ 2017 and 2018 with some other friends and while none of the games we’ve created made it to Steam, I’ve learned a lot about developing projects in Unity. That led to a project called Super Rumble that was a simple tech demo I made with my friend (more on that later).

On July 26th 2019 I started working on a next project - an isometric RPG (or rather an isometric RPG framework, more as an exercise than an achievable goal) inspired by first two Fallout games, but set in a post-apocalyptic sci-fi world codenamed Project Labrador. It’s all made in in Unity and C#.

Sometimes getting things done overwhelms me (mostly because of badly designed parts of the code that make me want to shoot myself while adding new features), but I try to keep going regularly - with shorter or longer breaks just to not go insane, as there’s no deadline for me after all. I contemplate stepping back from this project for a while, since I got a little bit worn out, but I’ll make sure to tell you a little bit about it’s internals.

And that’s my story. Somehow I became a game developer that works on his solo projects a lot. But I’ve talked enough - more details about the project and my thoughts on different technology-related topics will be coming soon. I hope you liked what I’ve written - be sure to check my blog regularly.

Bye for now!