October 25, 2020

Project 2: Dev Blog #2

Last time around I focused on how I built the world builder and the Procedural Generation around it, this time I'll be discussing the structure of the code and how it fits in with the rest of the project.

Project 2: Dev Blog #2

Welcome!

It's the second dev blog for Project 2! If you missed the first one you can read it here.

Code Structure

Last time around I focused on how I built the world builder and the Procedural Generation around it, this time I'll be discussing the structure of the code and how it fits in with the rest of the project.

When I first started this project I didn't have a set structure on how I'd do things. I went with having Services and their respective interfaces to make things more modular, allow for Unit Testing and to enable the ease of different implementations.

It was once I'd started getting these services into the actual game-play scene that I came into an issue. I didn't have a way to expose them in Unity itself, such as I have the PrefabService and MaterialService which hold the respective repository of information and are used to get the data based on provided keys. But I didn't have a way for them to be used.

That's where I have the concept of Systems. These are the layer that sits between Unity itself and the Services, where they handle some overall specifics of the game. An example of this is the DataSystem it exposes the various data-related services, such as the Prefab and Material ones mentioned above and allows them to be of use in other systems, like the LevelSystem.

The current structure design of Project 2.

The LevelSystem itself handles, as you may have guessed, anything related to the overall level. In this case, it would be things like moving the player, updating the visible tiles in the game, loading/saving the world and displaying the level as a whole.

I'm finding that I like the way this setup works and it seems like it'll be a fair bit less messy than how I've implemented things in the past.

I mentioned in my previous blog post that in previous projects I would just do a selection of management systems for a specific domain. This is still the case, but any logic that isn't related to things that interact with Unity itself is abstracted away and separated. These are things like file loading, holding things in memory and most of the game logic in the case of this project.

In previous projects, the systems would generally be named as managers but I find defining them as systems work out as a better naming convention for me.

Other News

Outside of this, I've been working on getting another mechanic sorted for the project which has been partially completed.

The first part of the Cards mechanic has been sorted, but I'll go into more detail into the specifics of that mechanic in a future post.

Anyway, that's it from me for this week you can find the ways to support me over on the Support Me page!

Have a fantastic week!