Yeah, I meant to say the mouse would be better for this type of game. What would be tedious is giving move orders such as 1cShift>>>^^^>>^^Enter, and then repeat 9 times for the whole army. But I agree that mice doesn't belong in a roguelike.
What is Smart Kobold and Jacob's Matrix? I don't see them on your profile page.
Ah, true, moving multiple units is a pain. My original plan was for you to setup formations so you could join multiple regiments together as one unit for the purpose of commanding. This is pretty much how the AI general works.
My other roguelikes can be found on the http://www.zincland.com on the list of 7DRLs there with every increasing adjectives. I foolishly didn't provide any links on my itch.io profile :> I keep meaning some day to recompile them all so they can all be also hosted here.
Well, the gigantic room would be 10,000 x 10,000. Which means storing just a single byte tile value is 100MB! And storing a single byte flag value is another 100MB! To make things more interesting, the UI drawing is decoupled from the actual game engine. So I have to make a copy of the map every update so the UI drawing thread can read the map without fear of it changing while it is reading. (The alternative is to lock all reads of the map, which would defeat threading entirely and be atrociously slow) Copying 100MB is a substantial time. By breaking into 100x100 rooms, each of a more manageable 10KB size, I can use reference counting to only copy sections that changes. So stuff like FOV flags are only set on the live rooms - the rest of the rooms just have a flag stating that their FOV flag is constant. The same is for the smoke simulation - I have to store the amount of smoke per tile, but for the vast majority this is zero, so I can have that allocated only where necessary.
Separate rooms is also a very useful optimization for things like MOB look up. Until 1812 I stored monster and item lists per-room. Usually rooms were small, so to see if an item was on a square it would be faster to look through all monsters to see if a monster was there than track it per square. (This particularly relevant for stuff like Everything is Fodder which is technically an infinite map as it generates rooms on demand) For 1812, I had to build a separate VDB-style (https://github.com/AcademySoftwareFoundation/openvdb) acceleration structure to swiftly locate all creatures globally. I ended up with separate tables for both teams and for the officers, so I could do efficient searches for all enemy troops, or all friendly officers.
Separate rooms is a very useful roguelike construction technique as you can piece together "levels" that are usually connected by staircases smoothly. Vicious Orcs is a good example of this. The original motivation was Jacob's Matrix where it was just to confuse people through non-cartesian coordinates. And I assure you, it can be very confusing :>
I spent a significant amount of time in optimization for this 7DRL. I could afford more at this point. The biggest bottlenecks right now:
1) Copying the soldiers from frame to frame. This could be vastly accelerated if I switched to a SOA rather than the current pointer-chasing format for the MOB class.
2) Registering bullets on the display. I already restrict this to only the current FOV, but there is an ugly O(n^2) for my event class that wasn't a problem since normally only have a dozen events per frame at most :>
The big problem is I feel it already runs a bit slow even on high end machines... The simulation is currently completely uncapped (so if we ever get faster machines some day, it will be stupidly fast :>) I'd have much rather if I could have simulated way faster so given you a 1x, 10x, 60x realtime options rather than the current all or nothing.
