#1 - 20/08/2024

Welcome to the first Dev Log of my untitled game project. We’re making a 1-4 player, PvE, survival-focused game, with an emphasis on sandbox elements with rpg combat. Building/Camp mechanics will be a key progression loop, along with world bosses. My visual designs are vague, and will be refined as I go, when they need to be. In fact, I have been ‘working’ on this game for the past couple of years on and off - exploring solutions and finding what works, what doesn’t. As the project reached a point where all critical gameplay and core features were present and working, it was time to remake it from the ground-up (without all the bloat, broken ideas and unused assets) knowing the skeleton of what’s needed to complete the project. As for right now this log covers the first week of progress on this new remake, so we should see the project go from initial building blocks to a complete game. Here we go.

Week #1 - Core Framework

Using unreal engine, starting from the blank TPS template project, enabling and setting up the Gameplay Ability System within Unreal Engine 5. I’m going to be using the Gameplay Ability System, (aka GAS) extensively within this project, as Epic has built a great and flexible tags-based system to handle game logic, which has some good replication support. In addition, rpg style equipment, attributes and items with varying loadouts and gameplay abilities is a perfect use case for a system like this. I’ll be talking about GAS more in future posts as I learn more of it’s intricacies.

Attributes

We have base Stats ‘health’, ‘stamina’, ‘mana’, (names to change in future) assigned to our player, with regen rates also defined. I won’t be dabbling in C++ if I can help it during this project as my skills in that area are limited to say the least, so a valuable plugin being used is ‘GAS Companion’ - a simple plugin that allows Blueprint-only projects to work better with GAS framework and attribute setup (which would normally need to be defined in c++). Absolutely worth it’s value for any project using GAS.

GAS and tags.

Gas is being used to declare current states on the player pawn, e.g. State.InAir, and State.Crouched. When these gameplay tags are attached to the pawn, the rest of the systems react to the presence of that tag. This means animation graphs, gameplay actions and effects can all be controlled by altering the tags, making the whole system very scalable and manageable.

Interaction

Interaction Component has been built to be a modular component; firstly for organisation, but also allows this behaviour to be used on other player-possessable pawns at runtime if later design decisions may need it. It’s a basic system, using a line trace as opposed to area traces/triggers for precise interaction feedback, and utilising an inventory interface between the component and any hit object that implements the interface. All interaction requests and resultant logic are handled on the server, with RepNotify core variables driving actual client-side feedback.

Inventory

I have a lot of love for simplicity when it comes to game UIs and Inventories, minecraft still is one of my favourite inventory systems ever purely on it’s transparency and intuitiveness. For this project I will be aiming for it to be playable equally through mouse/keyboard and controllers, so a grid-based system would allow both quick feedback to players on their entire inventory, allows for faster selection of items on both controllers and mouse, without the need to scroll long lists and also serves as an intuitive limit on inventory size that can be expected and managed, rather than an arbitrary weight limit which usually catches you off guard mid dungeon. Importantly though, this grid system will not be supporting or utilising drag and drop features; instead the inventory will simply fill in with the order at which the items are added to it, with an option to sort the visual inventory into item type groups. There’s a few reasons for doing this, 1) easier to immediately find an item you’ve just acquired. 2) it will stop players micro-managing their inventory, simply click ‘sort’ which will re-arrange the visual order by item type and name.

All critical inventory and equipment functions are server-authoritative functions. with clients simply receiving updates to their core inventory lists rather than directly affecting them, and delegate UI and other reactive functions when receiving these inventory updates.

Items

All items are defined on a Data Table of S_ItemInfo structs. They include basic item data, with a few soft references to texture assets, and a soft reference UActor class that represents the physically spawned actor for this item (mainly weapons and armors) - soft references allow the datatable to load and be used without loading all textures/actor classes and let’s me control asynchronous loading when the asset is finally needed. Items have game world representations, can be picked up, have stacking limits, and can be dropped by one or multiple. Items also have a ‘health’ variable, which is a standard 0-100 float which can be used to represent durability, or any other item-specific stat.

Equipment

Equipment is a sub-set of items that have an equipment gameplay tag associated with them. E.g. a Helmet item will have EquipSlot.Head in it’s S_ItemInfo struct. When trying to equip an item, the item gets ‘linked’ to a slot if the UActor Player Pawn has these Slots available, and will replace any equipment already linked to that slot. The linking is done via an ID Key that is uniquely generated for each inventory item. Equipping items is a server function, and is currently not manifesting in any actual ‘equipping’, nothing is being spawned or added to our player pawn right now.

And that’s about it, without diving into too much detail about things, an ugly, but functional item, inventory, attributes and the core of an equipment system - all replicated and ready to build upon. Next log aims to include weapons/tools and armors, async animation and logic loading for item- specific actions (load sword actions and animations when equipping sword).