I have one month to make an MMO: Day 17

Part of today was spent writing up the Sprint 5 blog post, so less time was spent on the code. Nevertheless, I completed what I planned to do in getting a basic inventory system up and running, and connected to the database.

Item library

I always build inventories in two halves: the “library”, which contains all of the static information about objects, like what sprite to use, and the human-readable name. And the “inventory” itself, which contains a list of inventory slots, and quantities.

The reason for this split is to avoid lugging around duplicate information inside the inventory. I can just say “inventory has 3 of this item”, and then the game looks up the appearance and name of said item in the “library”.

To start, I’m just hard-coding the library in Firebase. In the future, I may want to use a tool to help me manage this data, and then upload them into Firebase.

Currently I’ve only defined three items: Beetroot, Potato, and Seed. They only have three properties for now, the human-readable name, the sprite to use, and the position on the sprite sheet. The reason for this sprite/position is so that I can maintain a single large sprite sheet of items, rather than maintain several hundred loose sprites.

While loose sprites are probably more efficient since GameMaker can pack them tightly, a single sprite is easier to manage from a resource point of view.

Again, I’m using a sprite sheet from FinalBossBlues. The “sheet1” in the library refers to this sprite’s nam “spr_item_sheet1”

Just like all other content, the library is bootstrapped into the redis database in compressed form, and it gets loaded by the game client during startup. This allows me to update the library as needed without having to update the game client. This is important for balancing the game. (The sprites however are part of the game, though conceivably this too could be loaded dynamically).

Inventory Storage

With the library defined, player inventory can reference the item library. Since there’s no way for players to pick up items yet, I’ve hard-coded the items into the database for now for testing.

In the above example, I’ve given myself three potatoes in the first inventory slot; 7 beetroots in the second slot; and 2 seeds in the fourth slot; leaving slot 3 blank (just for testing).

The player node picks up this data from the database and sends it along to the client during login and any inventory changes.

Inventory Display

A simple inventory display has been added, it simply reads the first 10 slots of the inventory, and performs the relevant lookup to the now-loaded item library, and draws the relevant sprites.

As you can see, just as I’ve defined in the database, there are 3 potatoes in slot 1; 7 beetroot in slot 2; nothing in slot 3; and 2 seeds in slot 4. All working as expected.

Day 17 Task summary

The day went smoothly. As I worked on the inventory system I built a while ago, I began remembering what I did and how I built it, and it didn’t take long to put together the code for it again.

I previously estimated 2 points for Inventory Display and UI; but I’m going to reduce the scope a bit and not deal with an actual UI for displaying your full inventory just yet, and keep it to the 10-item hotbar for now. I’ll save more extensive UI work for later.

Tomorrow, I’ll add an ability for getting items from the environment (such as lying on the ground, or from a container. As well as allowing NPCs to give and take items from the player, forming a basis for a quest system.