All the way back in May I had the idea of making my own table-top wargame system. I revisited it a few times over the next couple months, but I never got around to, well, doing anything with it. It was never close to playable, just a rambling collection of ideas. And as my free time disappeared into university obligations, I let it fall off my todo list.
I've only got a couple weeks of free time before I'm back in the same situation, but I'm not going to let that stop me. I've got a lengthy list of things I want to be doing, and short of doing any of the things I originally wanted to do with my vacation, I'm returning to the Annihilation Ængine in the hopes of actually calling a project finished for once. The old thread was getting bloated and meandering, so I'm making a new one, where I can consolidate important information in the first and second posts (without Org's spam in the way). You may also notice that I dropped "Automatic" from the title. That is reserved for if/when I bodge together some programs to automate the building and gaming processes, which would be well in the future.
Anyway, without further ado, but much ado to come, I proudly relaunch...
The Annihilation ÆngineThis my attempt to make from scratch a table-top styled gaming system, specifically for wargames in the vein of
Chainmail,
Warhammer, and
BrikWars. As part of its mission statement, the game will have three major goals-
- The system must be simple enough to be played by hand without computer assistance, but malleable enough to reflect virtually any setting or concept.
- Players must be able to, with each other's understanding, design their own armies by whatever concept they choose, and be able to play against each other without requiring a referee (although one would always be useful).
- The system must function in such a way that no models, pieces, actual table, or physical elements of any kind be truly necessary. If for no other reason than being able to test it, any game should be completely playable via online methods, ideally purpose-made programs but ultimately anything the participants can agree to.
This doesn't begin to describe how the system will actually work. Everything else in this thread will do that. In the interests of not having to trip all over the thread to find interesting nuggets like before, I'll be posting links and concise descriptions back here in the first and second posts. This one will be a general list of stuff that still needs doing and problems encountered, the second will be "finalized" elements and eventually the working rules. It might make more sense to explain how the game is supposed to work before explaining why it's not working, but I like it better this way.
I am of course always open to suggestions and advice, which is exactly why this thread exists.
What's Stumping MeAny wargame or role-playing game worth its salt must at some point address what happens when two guys who want to kill each other get within punching range. And I want that to be a little more than just sidling mobs up close and rolling basic attacks. On the other hand, it's not that strange of a concept either, especially for large game-scales where "charges" are entire units closing ranks. Now that I'm revisiting the idea, I thinking it might be better to call activity beyond moving to engage and basic attacks a special effect rather than a given. However, it also raises the question of whether to use ranged attacks as part of the initial engagement, subsume shooting into the effect which doesn't make sense for widely different weapons, or require it to remain a separate, inadvertently penalizing, action.
There's also the messy business of reconciling who can swing at who in a hex-based arrangement. Can a sword only hit enemies in the same hex? What about two packed adjacent hexes? I can think of reason for several solutions, but none of them are particularly good.
Shooting is theoretically simpler than fisticuffs, because all that's really involved is declaring what you want to shoot at, then finding out if and how well you hit. Deciding how to do that is a little trickier. As you'll notice in the Stats section later, I've eliminated the Ranged Hitting stat (and Fighting stat), mostly because I want to differentiate my game from Warhammer more, but also because I think the logic of shooting can be better represented otherwise. Now, both making and dodging ranged attacks will be based on the Initiative stat, representing the "battlefield awareness" element of ranged combat. Mostly.
Allow me to explain. Using Agility to dodge melee attacks is sensible and natural, because that's basically what it means. But "dodging" bullets or even thrown rocks is nonsensical in itself. Rationalizing the "dodge" as using acrobatics to duck-and-weave and otherwise be hard to hit doesn't make much more sense, especially if the unit didn't move, implying the models are dancing in place to avoid being shot.
Initiative, encompassing a unit's general soldiering ability, describes both parts of shooting. When making attacks, it represents picking and lining up targets, coordinating fire, etc. Defending, it pertains to determining where the fire comes from, who and what is shooting, finding cover, etc. Conversely, when you're being beat to death with a hammer, to the extent that cover matters it's rolled into Agility anyway.
Obviously there are still many problems. Throwing axes would be better based on Agility or Strength. Maybe some creatures like animals and ghosts could have a special rule that lets them dodge with Agility instead. Not to mention how much weight it puts on the Initiative stat, or other logical conundrums like massed arrow fire.
I still don't know what I'm doing here. This is one of many areas where I can think of dozens of very particular situations that should be covered somehow, but I can't figure out how to reflect unit morale systematically. It'll certainly be subsumed under my general "check roll" rules, explained below. Exactly when that should happen is the question. I want to ape Warhammer as little as possible, but its morale rules (when you lose a fistfight or get shot up a lot) certainly make sense. I'll probably have to experiment with a lot of ideas use keep the ones that produce results I like.
Fairly simple idea, I just don't know what I want to do yet. I go into the detail problem more below, but put simply I need to find a line between terrain being important enough to think about without it being all important or tediously complex. I know want some basic rules for rough terrain, dangerous terrain, physical cover, sight cover, and elevation effects especially for weapon range. Shouldn't be too hard to slap together, but I haven't worried about it yet, and it can certainly wait for everything else to work right.
If a Unit contains models with different Initiative scores, when figuring out what order it acts in, do you use the highest, the lowest, or an average? Does a retreating Unit roll against the most of least Brave? Tricky. I do have a solution for the rather simple question of different Movement and Action rates, but otherwise I can think of good reasons for several solutions.
There's also the obvious question whether Units can be combined, split, and otherwise change their makeup mid-game, and if not why not (besides simplicity of course). Stumped.
As sparse as the system is right now, the only models it represents are self-contained homogeneous entities. Namely, individual dudes. With differences in scale, again a model can represent a vehicle or a regiment or whatever. But nothing with distinct parts aside from its entire self. This is all a complicated way of saying there's nothing like Warhammer's treatment of vehicles, where a model can have parts blow off and continue to function at a reduced capacity. I've got some ideas of how to handle this as well, but I'm going to leave it for well after the game is at least playable.
A more immediate problem is what to do with less "complex" models, like a horse and rider. Does the horse use the rider's Bravery? Can it panic without him, if the other way around? Can a rider get off his horse and keep fighting? If the horse loses it's rider does it disappear? There's a lot of different ways to tackle this, but first I'm going to settle for the simplest answer I can make work. This is one area where my Add-On Rule Options will help. If you want a large scale (or just easy) game where keeping track of horses and riders would be a hassle, just call mounted fighters one model and assume their statline represents both together. If you want a more detailed Cowboys and Indians game, you can add-on the Riderless Mounts and Dismounted Riders rule module to handle the necessary complications.
There's a lot that I could say about just complicated I could let the Ængine become that I'm not going to bother saying. I'm worried about, nay, already letting the scope run away from me, especially since I'm completely incapable of making lists. As if it need repeating, all I want to do first is make the engine payable.
I said many a time that I want the engine to be able to model interactions distinct from the flavor of what's being represented. As someone put it, a wizard casting magic bolts would be no different from a guy with a railgun and a pointy hat (loosely anyway). However, as you can see above, it's easier to conceive of what details need to be covered by imagining "naturalistic" scenarios and examples. I don't want the engine to be specifically tied to any one setting or description, but of course focusing on one description makes it a lot easier to describe.
Just to hammer it home one more time, I'm abandoning my original philosophy of top-down modeling everything all the time, for a bottom-up approach of thinking of one thing that I want to convey, making that work, and then branching out when able. So I'm not going to shoot down stuff as being too specific, and I'm probably going to be working from specific examples more.
And that my friends is how you spend 1300 words and two weeks saying exactly nothing. Coming Soon: actual rules, hopefully.