Devlog #8 We can rebuild him. We have the technology

Hello there,

It’s been 2 weeks since the last devlog, there was good reason for this. There wasn’t much to talk about lol

So the week before last was to be the plan for moving the inventory over to the database and make it multiplayer. Well that plan turned into an evolution because when getting with Tango and looking over the code that was designed, it was basically limited in numerous ways. If not for the fact that it was originally designed as a single player tutorial, migrating that tutorial to not only the database, but to be relevant to multiplayer and have server authority provided basically meant rewriting most of the code.

So after we discussed it and Tango put his thinking cap on, we agreed to rebuild the inventory from scratch. Well, this lead to much research on Tango’s end and experimentation in the evenings when I got home.  The result of this was that most of that week was spent think tanking an appropriate design for the new inventory system from the ground up.  It wasn’t just a “This is what it will be” scenario either. It has to be built from the ground piece by piece for the specific purpose of this game, so in turn it is still an ongoing growth.

With that said, I did get some side work in during all of this theory-crafting during that week. Amongst those things was changing interactions from a system where the player’s collider enters another object’s collider’s area into a system of direct interaction through raycasts. Similar to area into area, but generally it’s a laser that shoots from the player constantly to a limited distance. When that laser touches an interact-able collider, it “unlocks” the ability for the player to press E to interact only when the player’s raycast laser is touching it.  The raycast is attached to the camera rather than the player.  This means that the controlling player must be facing the camera directly at the object to use it.

In addition to this, I added a text display, very similar to FoM’s old interaction system, for when the raycast touches an in object with an interact-able collider.  So when the player camera looks at the storage within the required distance, the player sees the cursor disappear and text saying “Storage Unit” appears in place of it.

While this system is technically now in place, I did not grab screenshots to show it and I’m already in a new branch working on the new inventory system so it would be rather annoying to go back and get those shots, I will try to remember to grab these next time. I do apologize for not thinking about this.

I also grabbed a placeholder set of art that I’m hoping to start working with soon to improve the playground into something worth playing around in for the time being until I find an environment artist to work with.  I spent time getting those assets imported and cleaned up, ready for use in actual world building a bit. It’s a fairly simple Sci Fi interior environment, but should work for the time being.

https://kappa.lol/edlAed

I took some time to reorganize the project structure, it was getting a bit chaotic. It’s not perfect, but better than it was. I also added some simple code to allow the player to jump, no animations, just using it for testing purposes.

https://kappa.lol/fPSLQa

But side work aside. We reached the end of the first week with a simple input and output section of code we plan to use for the database, server and client interaction of items which allows the UID to be acquired from a specific item as needed in-game, stored into the database and retrieved back from the database and used in code to regenerate it in-game and we had a design for the items themselves in the database.  The items will be stored in a table specifically set up for items. It looks like this

https://kappa.lol/lUrUj0

Basically the database stores an item by checking which character in the game it belongs to, which world that item is on(map index is 0 for player body inventory, then 1-however many worlds exist for world storage unit inventory), the slot in the inventory that it exists in, the unique ID of the item(For the purpose of getting details about the item to the player for reference) and lastly the quantity of the item in that slot in the inventory.  We do not use a generic incremental id in the database for items because the character id, map index and slot combined make for a unique requirement every time so there will never be an overlap.

Tango also discovered an authorization system built into Godot’s high level multiplayer system which allows data to be sent back and forth between the server, database and client before the client is actually inserted into the world. This allowed us to grab the player’s character id as they “log in” and send a request for the player’s inventory to the server, which checks the database, returns that data to the server and will eventually send the final results to the client all before the client actually “connects” to the game world. Happens lightning fast as well, at least so far as we have tested it.

After all of this, we set up an additional node on the server that maintains a script which simply holds an array of all player inventories. Technically it’s a dictionary of dictionaries that contain arrays for each item(It will be, not currently set up this way), but ultimately, it’s the server storage for player inventories. This allows the server to do all the necessary math on the fly as well as handle the authority for player inventories without constant data input and output with the database.

The current result is as described above minus the client side result as we haven’t gotten that far yet:

https://kappa.lol/UUamdi

You can see that we have the inventory of each player in the server inventories node set to print on creation. So in the clip you can see the list of items in the first player’s inventory generated and stored into the server, then when the second player joins, you can see their character’s items added to this array separated by their player reference.

All in all, while it may not LOOK like huge progress, this actually was. Between myself being a complete noob in this and Tango researching all of this stuff and then teaching it to me while we worked to think of the proper solutions for each step of the data manipulation, it’s a bit of a slog in the design process. But I think the result will be something efficient and appropriate for every item manipulation use case we can think of for it.

This next week will be the continuation of this process, slowly getting the back-end in place for all of this followed by the front end design and use of it all. I plan to have the first iteration of the inventory handling mimic that of FoM’s where slots 1-3 are weapon specific, then there’s armor/implant specific slots and additional hotkeys set up to use items from the inventory.

All in all, the process is slow but productive and I’m happy to report I’m enjoying the iteration just about as much as when I started this all and I don’t see the locomotive slowing down any time soon.

Until next time.