RPG Data (Skills, Monsters, Items, Equippables)

Question

I'm creating a simple RPG type game. I've dabbled with the idea of just loading all the skills, monsters, items and so on at once. However, to do that seems horrible wasteful since I would have potentially hundreds of things in memory that may not necessarily be used just for the battle system.

I'm pretty close to finishing the battle system, I just need to figure out how to handle the data prior.

So would it be best just to just access the disk to load this information in when I need it? I was considering porting this to another device after I get it working on a PC.

I was looking at the decompilation of Pokemon Red and I'm not exactly sure how they managed to do it either. Given that the RAM for the Gameboy was 8 kilobytes (32 if expanded).

Any pointers (no pun intended) or ideas?

Answer 1

Hundreds of items is really not much for today's hardware. The mechanics-relevant information about items, enemies etc. is likely not going to be more than a few hundred bytes per entity. So keeping it all in memory is likely not that much of an issue.

What could become an issue is sprites and sounds. A decompressed spritesheet or sound file can easily eat up a few megabyte which can be problematic on low-end mobile devices. A simple solution for this is to request any such resources through a resource cache. Whenever the resource is needed, request it from the cache. The cache checks if that resource is in memory, and if not loads it from disk. It also checks in regular intervals which resources were not requested for x seconds and discards them. The only thing you need to keep in mind is that you always request resources through the cache and don't maintain any other references to it. This is required to make sure the cache is aware of any use of the resource.

A more precise but harder to maintain option is to explicitly load sprites and sounds when they are needed and explicitly unload them when they are not. For example, when you enter a battle, you check who participates in the battle and load all their sprites. When the battle is over, you explicitly release those sprites from memory. This would be the best strategy to minimize memory footprint, but also the one where you are most likely to end up with missingno-like bugs due to accidentally using sprites which aren't loaded or after they are released.

Answer 2

Disk access, I mean I/O time, is another resource to worry about.

It's OK to worry about unneeded memory usage, having cellphones with 1 to 3 GB or RAM or computers with 4 - 8+ GB or RAM is no excuse to not do things in the most optimal possible way. But use a bit more RAM to avoid slow I/O, or to concentrate most of the I/O in specific parts of the game like at the start of the level, is a perfectly valid excuse and one used by games since the first day.

I don't know how your structures look but hundreds of items cannot be so RAM filling. I would bet that 999 of your items take less RAM that all the graphics assets and sounds needed at any given time to draw a scene frame.

My posture on this: worry about RAM when the times comes and not before. If you manage to fit your entire game, or at least a whole level and then move all the heavy I/O to the loading screens that connect levels, you save yourself of having to deal with things like different hard disk speeds, something else than your game doing I/O operations at the same time, etc.

About having each item graphics loading when the player access the item description page (if this is what you are planning): It doesn't sound so terrible to me, maybe we can have a loading wheel that only the players with slower hardware will see, yet no game I have played do this leading me to believe that the items description text or graphics assets aren't a worry for the developers of those games.

RPGs with battles that moves the player away from the exploration map: maybe there is an opportunity to place disk access here. We can make the transition animation a loading screen.

Just consider the following: if data is small enough, then no matters which path you follow in respect to avoid freezing the game enough for the player to notice, probably either load from disk or already having everything in RAM will just work when you test it, but if we add to the formula that now you have to write the code to make the loading possible, that probably involves to process the format used to represent your items in disk, we have increased the complexity of the project, potentially without needed it.

You always can work in an incremental way. Design how your items will be represented in memory is something you have to do with or without the on demand loading system, so, start by designing them. Start adding items by filling an array of instances of your items, if you observe the memory go beyond what you are willing to tolerate then it's time to start your on demand loading system. The advantage is that you didn't lose any time, as the structures designed will probably remain the same, just that now instances of them won't exists on memory all time.

Same goes for everything else like monsters stats and so on.