Tuesday, October 8, 2024

Caravanserai, what is it?

Caravanserai is my attempt to build a video game, but fundamentally, I'm trying to share something with the world. The land depicted in this game (the World Basin) is a place that has been living and growing in my head for over four years now. It's a love letter to the cultures and countries that fascinate me, and a homage the media that I love, from The Elder Scrolls III: Morrowind to HBO's Raised by Wolves.



I don't want to promise a lot, because I know how most of these things go, but I intend for this game to be a little unlike most games of the genre. I'm honestly not even sure I'm going to include a main storyline (gasp!). So much of Caravanserai has been a process of discovering it's secrets through the strange and wonderful places that dot its landscape. And yes, the creation of this world has been very much a process of uncovering it as much as it has been designing it.

Have you heard of the Three Pillars of Play, the idea that a roleplaying game is held up by combat, exploration, and social interaction? Many people have their own ideas about what a fourth or even fifth pillar would be. My own is that it would be archaeology. The best game of D&D I ever played in was focused immensely on the history of the world, the dungeons we were delving into, and the treasures we were extracting from them. When the game started, there were some legendary figures in the distant past, but as the game wore on, we came into the possession of deeper knowledge about them, located their lost cities, their tombs, their temples. The world of Caravanserai inherits this sensibility.

Anyways, look at this spaghetti!


That's the inventory system (which I'm trying to model after Morrowind's as best I can).

There's more code elsewhere that handles opening up the window and pausing the game and such. This is mostly just the creation of the item slots (i.e., widgets).

It works like this:

  • The first thing it does is clear all of its children (get rid of any inventory slots currently attached to it). If you don't do this, then every time you open the widget, all of items that were in your inventory the last time you opened it will still be there. We don't want an item duplication glitch that is that easy to pull off.

  • Then it looks up every item in the inventory (this might get confusing). So, this is the inventory widget that displays what items we have, but we actually store the information about what items we have in a different blueprint (specifically, the Game Instance, since it persists across levels). That information is in the form of a map variable (which is basically just a dictionary, if you know any coding). It's a list of unique keys, each one of which is associated with some value. My inventory variable uses four-digit Name variables for the keys, and the values are Integers that tell us how many of each item we have. You can think of it as being structured like this:
  • I run each key through a For Each Loop. So for each item I put into this loop, it does something to it. This is where things get crazy.
  • We use the key to pull up a row in our Item Data Table. Each row is named after a key and holds the corresponding information about the item that has that key. Right now, key 0000 is assigned to my Test Item, which is just a dummy I'm using to make sure the system works. The row in the data table is where I get information about the item like whether it's stackable, what its stack size is, etc. I also take the Value and use it to set a variable called InventoryItemCount, because I need to count how many item widgets of a given item I've already created. I could decrement the Value itself 
  • Next, I take the Value associated with whatever Key I'm on and run some checks on it. First thing I do is determine whether the number of the item I have is greater than zero. After that, we check to see if it's stackable. If it is, I check to see whether we have a full stack or more.
  • Then I do all this. Depending on which category the item falls into (stackable and we have a full stack, stackable but no full stack, not stackable), we create the item widget and attach it to the inventory grid. If it's stackable but we don't have a full stack, I also include the number of the item in the corner of the widget. If it's not stackable, I just create the item and attach it. In all cases, I then decrement the number of item we have left by the appropriate amount, before adding 1 to the variable that keeps track of how many slots we have and finally looping it back to check whether the number of item we have left is still greater than zero. The stackable with a full stack branch is interesting (to me at least).

    What I did was decide that, since I know I have a full stack, I decrement the amount of item I just decrement it and label it using the stack size variable instead of the variable in the inventory map. Okay, not that interesting, but it took me a minute to figure out.
There you have it. That is the most complicated blueprint that I have figured out how to make on my own without following a tutorial.

No comments:

Post a Comment

An update

 Apologies about the absence and my lack of attention to this platform to those three or five of you who have actually read all of my posts....