Hacker News Reader

Comment by brcmthrowaway | Hacker News Reader

So there is no compression?

No. This might seem useless to non game coders but it's a very common pattern in videogames. The state of the world is frequently 1000s of yes/no data points.

It's not rocket science but this seems like a decent enough implementation of it. The number of data points rarely goes beyond thousands so compression doesn't have much value.

(From a non-game coder) How do teams keep track of which events need to be tracked in state, what their names are, etc.? (Not how as in how is this possible, but rather, what kinds of processes have evolved for this.) Like are state events typically planned out ahead of time, or do devs realize which ones they need as they go? What if I want to add a new event to state, how can I check if someone else has added it -- do I just scan all the names in the code and hope that it was named something that I will recognize?

If you look at the code linked to for the OoT decomplication, it's centralized in a single file everyone would be committing to

https://github.com/zeldaret/oot/blob/4d2bc68bacdff06261f7a89...

That is not at all representative of how the original code would have looked like. At all.

I am tired of people assigning pseudo-magical properties to "decompilations" while at the same doublethinking them as a way to launder copyrighted works.

Yeah looking at that is what prompted this question. Are the events in order? If so: the index for an event in the bitmap is constant, so if you realize you need to save an event that wasn't previously being saved, how do you insert it to keep order? Do you break all previously saved data by changing all the following indexes? Or are the events not in order, which could make it harder to find if an event is already in it (and just generally be confusing)? Managing a long list of events like this given that it is used for persistent state seems like an interesting process challenge.

There are usually two types of flags. Whole-game and level specific.

For most games I've worked on the most senior game designer will control the game specific flags and then levels will be "owned" by individual designers and they will control the level flags.

Someone, usually the most senior game designer, decides how many flags the game gets and thus the max number of flags each level can have.

If this seems a bit uncontrolled to you.. then yeah it is and yes that's why a lot of games are full of bugs :)

This has become less of an issue as runtime memory has expanded and save games can be HUGE. In the N64 days the constraints were more real and a bloated save game could double the cost cartridge manufacturing and destroy any profit the game made (Nintendo charged a lot more for cartridges with larger battery backed memory).

Interesting! Thanks for the glimpse into the workings of the game dev world.

No compression. In the olden days, storage was scarce. While you could compres the bitset, the worst case compression of that bitset would be larger than the uncompressed size. You likely have no way to guarantee the worst case is impossible, so you'd have to reserve extra space. In the end you'd store more data, in a slower to use format.

These days storage bandwidth is the main limiter, so now compression makes sense. When storage size is the main limiter, compression is ironically not very helpful.

Reply on news.ycombinator.com