I'm not sure you meant by "an environment too large to handle in its entirety" - if you mean the number of tiles on the map exceeds the memory of the JVM, that can be compensated for by saving out-of-range areas to disk. Except for AI pathfinding (which should be used sparingly on large maps), map size shouldn't have any effect on the time it takes to process a turn. I assume that the actors and map tiles are double-referenced, so that the occupant of a tile and the position of an actor can both be found in constant time.
Either way, the answer to your hypothetical question is there are, but theoretically they shouldn't be much better than the method you described. However, all of those systems should be able to give better performance than what you described.
What time periods were you measuring in your timing system? Did you actually create a scene with hundreds of actors and measure the time it took to process a turn, or did you measure the time it took to process a single event? What was the precision of the clock system you used? If the smallest unit of time it can measure is a millisecond, then you may have a very fast system that's being diagnosed with a nonexistent problem.
- Yes, actors and map tiles are double referenced.
- Like I said in a previous comment, I had quite an increase in performance since yesterday.
- I measured both the entire turn and the single events, both in milliseconds and nanoseconds. What I posted here wasn't really all that accurate because I wasn't expecting you guys to actually focus on that, it was more of an fyi.
Lastly, I have to mention this game won't really be following standard roguelike format. I suppose you could consider it more of a blend using roguelike and RPG elements. The major focus of the game's programming will be on rather complex AI routines. Basically, instead of having a great deal of randomly generated monsters, the overworld will be more static in its layout, populated with NPCs that each can have a small to large impact on the story; the player will actually be spending a lot of his time exploring the narrative of the game instead of trying to improve his character.
I suppose I can sum it up nicely comparing it to 'Dwarf Fortress in a predefined world'. In any case, yes, there will be quite a bit of pathfinding in play. Not necessarily over huge distances, but quite a few of them at the same time.
I think the OP does have a problem that needs to be fixed, if they're reaching for a new, probably more complicated solution to a performance issue that shouldn't exist in this case (as far as I know).
@Thales, can you post a working example of your code so people here can run it?
No, buddy, I can't. I'm planning on posting an example once I finished the demo chapter but not sooner. Please, I appreciate you all telling me what I had was inherently too slow, but don't worry about that. I can manage that part.
Here's another, maybe better way of putting this whole thing: Don't worry about the amount of time it takes for a single actor event to execute. Let me worry about that. What I'm interested in is ways of optimizing the total amount of time it takes per actor in the level. As it is now, the total amount of time increases linearly with the amount of actors; since I check up on all of them in the same way. A good example was the person telling me to predict the actor's movements ahead of time while the loop's idle, waiting for player input.
