We’re going to try something new! Interest has been expressed in devblogs, even when there are no pretty pictures or lovely Kyna narration. So here’s trying! I’ll explain what I’m doing as I complete a project I’ve been putting off for a while: converting relics to a cache instead of real items.
This Devblog is about breaking down the code so the wider community can understand the intricate details that go into even the most simple IDEA from the idea list.
- Provide a look behind the curtain to what programming Rapture looks like
- Provide amusement, Rapture has quirks!
- Help the community to understand why even simple things can be an undertaking
- Gauge interest in this content when it’s not teasing something amazing
- Reduce one of the largest uses of player inventory
Why Make the Thing
Why? Databases. Most everything in Aetolia is either a replica, room, or persona/player. Each of those entries comes with all the flags, variables, bytes, datas, etc that could be possible on that object… so they can get pretty large! The space is reserved, even if the numbers are all 0. While you might be annoyed at how many things named “piece#####” you hold in your inventory, the upstairs are annoyed because every single one of those little things is holding 170+ flags, 40+ bytes, etc. It’s not that big of a deal in a modern computer but it does cause bloat. And when we need to iterate through every replica in the game looking for certain things? Huge waste of time to iterate over multiple tens of thousand piece######’s. This used to be a huge problem with herbs in pocketbelts!
Also, I’ve been a player and having a backpack with 200+ relic pieces annoyed me too.
So our goal is to delete all the pieces, freeing up a ton of replica numbers, and reducing a large number of unnecessary memory usage. How? We’ll make another database! (Tiur’s answer to every problem is to make another database, you’ll see that if these continue.) This one will store the relevant information about a relic piece, and a quantity. Much easier to store a list of “Bob has 47 pieces of relic XYZ” than 47 instances of extra nonsense. This could be just as bloated if we save too much information… but our relic system was actually made by a Good Coder (yay Razmael!) and has some clever tricks.
Every single relic piece is the same thing, just with a different name and a number pointing at what piece it represents. Each piece is a database that includes a few things; what it should look like and which relic it’s meant for. Then the relics store what they build into, and how many of each piece# they require!
The summary of all that nonsense? The relic cache database only needs to say this:
Persona => variable,
Rpiece => variable,
Quantity => variable,
Thanks to Raz thinking ahead that’s super easy! Who owns the thing, what piece it represents, and how many! The variable bit there is me telling Rapture that the number could be anything inside a signed 16bit integer. It’s reserving 3*16bit, which is totally no big deal… or more, I’m kinda terrible at real architecture and there’s more to it than that… but w/e. Also, to those of you who think that’s not fancy, when Rapture was made it was impressive to be able to label things like that!
After that it’s just like any other programming language. We need a validator, an accessor, and a mutator. At least one of each.
So, this is getting long and we’ll do a part 2 if there’s interest. But first, the most important and the only thing I could teach effectively: the thought process. I make a list of everything we need today’s code to do, then a sublist of how that’s done.
- A way to put thing into our cache
- add # to cache
- delete old replcia
- A way to look at the cache
- a subroutine to output the cache
- A way to get things out of the cache
- reduce # from cache
- create replica(s)
- check if we should delete the cache entry, no one needs 0s
- A way to force every piece in the game into the cache
- protected verb
- look over inventory and use above add method
- send a message to the player so they won’t freak out
From there a real programmer would make pseudocode… but for me, that might as well be pseudocode. I do this often enough that I already know how many of each thing I’d make for a command and database. The above is important because it is TERRIBLE to get to the end of a project and realize you skipped an entire thing the project needs. You could have to code it twice! Or three times! Not that I would ever make those sorts of mistakes all the time.
You know what we didn’t list up there? Loyalty! That’s an important part of the pieces we’ll need to preserve. Tune in for Part II to see how I add that without having to redo everything I’ve made already. Also, I’ll explain verbs.