11.27.2011

What I forgot about

Since I uninstalled Skyrim to not let my self get skills to their maximum level and other ridiculous things, I used the last minutes or today to again pick up my ressource loader system and think about what I originally planned. Heavily multithreaded systems are complex to say the least. One idea might be utterly useless the next time you think about it. In a game context, you also have to keep in mind what parts use what ressources how and how long they have to life and so on. My first concept included only a "might need it/need it/don't need it anymore" system still suitable as a base. But I'll also need to introduce something to note if a ressource is still used by another thread, what each thread should when it immediately wants to release stuff and so on. It's a complex cycle, sometimes looking a bit recursive in case you're trying to automate and specialize it for many possible, parallel accesses. Furthermore, the data map of my game can be changed anytime - persistently. I haven't thought about the problems arising from that and what makes up the wonderfully simple I-only-need-to-set-a-switch-to-let-this-castle-pop-up-here systems used almost in bigger games. Or asked in a better way: should quest set a value to let something slip into the renderer next time it's visible or should it alter the level data permanently? Questions every game programmer has to think about! Normally, everything is saved as a massive database with certain connection to the core quest/map/logic layout and will restore the desired game environment with possible restoration of running scripting events and so on. This saves up quite some amount of questions about how the game engine should start when loading a game and what to do when saving it. Zelda for example can entirely be made up of switches and integer because the level data is fixed and not much stuff is running besides the hero himself. In Oblivion or Skyrim there are most of the time as NPCs around you and need to get saved as well - NPCs having a schedule but aren't visible do not require savin but just calculating when they should pop up in the game. Thus it's mostly only a game engine specialization of sorts and it's good that I having to tackle such problems on my own at first. But all of this nice and clean trigger-based savegame management does not help me with the problem that I'll simply have to dynamically load and store map data as the player goes. I've thought a lot about how to realize such a system with my ressource loader concept and in the end I think it'd work quite automatically when building in some rules of what map data (both physics and graphics) have to stay in memory for what time and with what kind of limitations. However, this carries some problem with saving the map data etc and I'm not quite sure if it's a good idea to burden each thread with the task of also writing stuff to disk inbetween. Well, the actual writing would happen in a nother thread, but the thread would still suspend it's work until it's done. However, that makes enough ressources free to give the saving/loading thread more priority... Well, you see that's a lot of stuff to think about and it's time to focus on developing reallife game code rather trying to incorporate rather conceptual features. I have some extensions for the ressource system as well a plan to create for how the map streaming should work in detail. I'm hitting stone this time, better use a Notched Pickaxe now.

No comments: