Black Bart Charley said:
soggie said:
I'm assuming it's just a bunch of logical entities with tile location and world coordinates. Put in some basic pathing AI into each entity, randomize a little, and you'd get thousands of entities marching across the wasteland minding their own business. Pain in the ass to optimize and keep track though...
Yeah. But how does he transfer them into the "tactical map" coordinates? (too lazy to think about it)
Btw, what is an efficient way memory/cpu/ease of access wise to store a map? Array? Linked list?
shihonage, how do you do it?
I am writing a small roguelike and having basically zero theory doesnt help. Gotta look up every small thing...
Well, I came up with a number of tricks to make it work, and ironically, now I will be eliminating half of them in order to make the game better, because this "ambitious design" didn't offer any benefits!
Nonetheless, this is how everything worked:
* there's a reason I didn't use Flash and shit like that... using Visual C for speed didn't hurt
* I do everything through static 2D arrays
* it handled fine something like 1400 entities moving in realtime on 3000x3000 map - with combat (fighting each other) and Lode Runner-or-worse pathfinding, because the only potential obstacles for them on BIG MAP were borders of towns, and the NPCs themselves
* only one town was stored in memory at a time - the town YOU are in.
* EVERY town's COORDINATES were stored in memory though. This means, left corner X, Y on BIGMAP, and their overall length/height.
* so there's 2 structures - local (detailed) map and BIG MAP. Local map contains EVERYTHING, BIG MAP's each cell is only a reference to an NPC that's standing on it
* NPCs that are stuck on BIG MAP (wilderness/emptiness), were not permitted to cross town borders unless YOU are in this town, therefore the town is loaded, therefore we can track the obstacles and prevent them from getting to places they shouldn't be getting to. Player-centric design - if the player doesn't notice it, it doesn't matter.
* they WERE permitted to cross from the BIG MAP into the local town YOU ARE IN, so the Giant Rats could chase you to the gates from a previous encounter, and the guards would kill them.
* There are routines for translating BIG MAP x,y into LOCAL MAP x,y, and vice versa - I use them very often
* NPCs have behavioral modes AI_GUARDPERSON, AI_GUARDAREA (half-assed patrol), and something I forget
* The only per-tick processing performed for NPCs was animaction (animation linked to action, such as firing or "magic fiddling"), and movement. This is the spinal column, primitive, fastest response, it had to ensure real-timeness, or appearance of it.
* Higher-level AI functions (combat decision-making, for instance) were spread out to save CPU time. Each NPC was given a random tick number at which they would execute their next decision.
* Above was done for NPCs that are farther away from you on the big map - because you don't see them, the balance isn't broken, because their lagged reactions are equally retarded against each other.
* For area hostile scan, I determined that iterating through 1400 NPCs was more time-consuming than scanning a 20x20 (or even 30x30) area around each, making from 400 to 900 iterations. The CPU time for this was spread using above technique of making NPCs do it on average every 25th cycle, instead of EVERY cycle.
* Running into hostiles on big map near edges of a town (or several) forced cutting up of the encounter map's edges. In this case exiting it in some directions would immediately transition you to the nearby town
...
It was kinda fun to watch little red combat markers on the 3000x3000 map light up and watch the messages about Raiders being knocked down by Giant Rats, and then stumble upon corpses, but it got old after a while, and didn't really offer ANY benefits to gameplay - only problems.
I mean, what are the chances of you stumbling upon that Fallout2 family slaughtering encounter just at the RIGHT moment in this scheme? None.
If you're making a rogueline I'd suggest going the classical route and NOT trying to make the big map (should it exist) into a "REAL SPACE". If the player doesn't see the difference, it doesn't matter.
P.S. there are problems with having people ONLY LOCALLY, because then you can't check quest status for someone who is NOT IN LOCAL TOWN.
However, having GLOBAL people list creates the following problems:
* inability to elegantly implement "dungeon levels" that you "rope into" from an existing map, as their 2D coordinates cross...
* having to iterate through the WHOLE LIST while on the local map is undesireable. What should be done, ideally, is upon entering the local map you create list of people that are on it, and process only THEM actively. Passively you can still check stats of "outsiders" as needed by quests.