Play game
War of 1812's itch.io pageResults
| Criteria | Rank | Score* | Raw Score |
| Innovation | #1 | 4.000 | 4.000 |
| Scope | #6 | 3.500 | 3.500 |
| Aesthetics | #22 | 3.500 | 3.500 |
| Completeness | #23 | 3.500 | 3.500 |
| Overall | #26 | 3.333 | 3.333 |
| Fun | #40 | 3.000 | 3.000 |
| Roguelikeness | #113 | 2.500 | 2.500 |
Ranked from 2 ratings. Score is adjusted from raw score by the median number of ratings per game in the jam.
Judge feedback
Judge feedback is anonymous and shown in a random order.
- War of 1812 is a large-scale army combat simulator. The game is played on a massive battlefield, with UI and controls that sufficiently aid in viewing and maneuvering around the "world map" and battlefield. The player does not have direct control over the entire army, there are messengers that issue commands to other regiments, and information for distant regiments is not updated until you gather that intel by some means. The game feels complete and all of its base features and mechanics are quite refined, but it is short outside of the initial engagement, and probably does not present most players with much replay opportunity. Despite this, the scale of the armies, the independent simulation of each soldier, the climax of the central battle, are all a pleasure to witness, interact with, and watch unfold. The game falls just short of being a traditional roguelike for me, as you "control" thousands of soldiers, and the game is technically realtime (although it seems that the individual actions are carried out in a turnbased fashion, the player is spared from having to individually move 7000+ soldiers each turn). I did not encounter any real bugs, but the game does at times perform poorly during large battles; I noticed an option to remove the gunshot animations, but they were quite well done and nice to be able to see. In general, the use of ASCII for the map and battles was very well done, intuitive, and in particular I really enjoyed the smoke effect from the gunshots.
- Really captures that imperfect information feeling. Combined with the delay of commands via runners, the battle really has an interesting feel to it. Make this multiplayer and you've got something. Roguishness? Pretty low to my eyes. But bravo for ambition!
Successful or Incomplete?
Success
Did development of the game take place during the 7DRL Challenge week. (If not, please don't submit your game)
Yes
Is your game a roguelike or a roguelite? (If not, please don't submit your game)
Yep. But those who believe tactics define roguelikes will object to a strategy based approach.
Leave a comment
Log in with itch.io to leave a comment.
Comments
huge fan of your games, you really outdid yourself this time! fun, innovative and "simple" just like 7drl should be.
Thank you! Very glad you enjoyed it. I'm also pretty pleased with the result, even though in my imagination there were a lot of other scope that ended up not being accomplished :> It also very much is something that likely falls out of the definition of "roguelike" (which is fine for me, as finding these boundaries is what I do 7DRLs for :>)
Very cool concept, feels like a real scale warfare simulation, the same kind of game that I want to make. Epic combat, strategy, fun AI. The only thing that holds this back is the controls, the controls make it tedious to play. Still, to make something like this seems light years ahead any other entry in terms of implementation complexity. Have you made other similar games before? I'd wanna see them for sure.
Thank you! I did try to optimize the controls. Most importantly, pressing shift and directions lets you move 5 squares at a time, otherwise it gets very painful to move about. Ideally it would be a mouse-driven interface, but I didn't have time to build that on top. (Not to mention mice have always felt out-of-spirit for roguelikes to me :>)
What were the aspects of the controls that made it most tedious for you?
I've made lots of 7DRLs, none of which have been epic combat :> But they definitely laid the ground work to achieve this. Notably Smart Kobold had huge work for dealing with solving the problem of having densely packed groups of mobs move in a turn-by-turn fashion, but not get all broken up. Basically they are able to both delay their turn to see if others will move out of their requested spot, and have a priority scheme for shoving other mobs. And Jacob's Matrix is where I developed the whole non-cartesian coordinate system that lets me stitch 100x100 "rooms" each with 100x100 tiles together in a fashion seamless to the AI and map code.
Source is all there (and BSD) if you want to look at it for your own epic combat game!
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.
Having formations like you described is a pretty good idea.
Referring to what you said about non-cartesian coordinate system, why would you want to split your map in 100x100 rooms instead of having one single 1000x1000 and more gigantic room?
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 :>
Have you measured the time it takes to process those 10000+ soldiers? Like is it a big bottleneck or you could afford putting even more?
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.
I can't find the windows .exe file to launch the game...
I'm afraid I had to ship without it due to Windows defender being over-active. I have got a build that passes locally, so fingers crossed, I may get out a windows release soon!