Forum adverts like this one are shown to any user who is not logged in. Join us by filling out a tiny 3 field form and you will get your own, free, dakka user account which gives a good range of benefits to you: No adverts like this in the forums anymore. Times and dates in your local timezone. Full tracking of what you have read so you can skip to your first unread post, easily see what has changed since you last logged in, and easily see what is new at a glance. Email notifications for threads you want to watch closely. Being a part of the oldest wargaming community on the net. If you are already a member then feel free to login now.

I'm trying to conceive of a system, but I'm really not sure what I'd consider the ESSENTIALS-what does a wargame NEED?

Beyond that, I could use general advice on creating a wargaming system.

First thing is to have a really good idea of what you want the game to do, and then stick to it. Good example is a death race game I tried to make; after a good start, I got bogged down with boarding, and people falling off, now there's people on the ground to account for, and it devolved into a very messy skirmish game with a whole host of mechanics which didn't work together.
As such, if you have any more ideas which don't really fit, write them down and put them in something else.
Fluff and mechanics have a few linking features, but for the most part, fluff can be applied alongside the game. for example, if the fluff says that these guys were created by a god and are thousands of years old and can walk through walls, the only relevant part to the game mechanics is walking through walls. As such you could split your fluff into "What they can do" and "Why they can do it". "why" is just stories, "What" needs be have game mechanics for it.

most of the time special abilities will be reflected by overriding the basic rules, so you don't have to worry about them as much. But if you have tricky ones, like stopping or reversing time, then you may have to get creative in how you will ultimately make it work.

What the mechanics of the game need are:

Actions: what the units do, and how they do it
interactions: how the units interact - can they move past or through friendly units, do units have more morale if close to others?
combat: how do units resolve combat? will you go nitty-gritty and have it break into smaller fights, or will you keep it as one unit vs another? can they just walk away, or are they stuck, or can they make a roll to escape?

Morale is an important function in the game - if your dudes will keep doing what you want no matter what, it'll make for a boring game. if they react to having their mates head explode next to them, then that makes it a bit more interesting! Also include pinning, people won't just walk out of cover if the enemy Is unloading a HMG at them.

I tend to think of a theme, then muck around with how to do combat, then work out the fine details and special rules.

First of all, the purpose. Do you want a game that feels like simulation, with "tabletop perspective" playing bigger role than "omnipotent general" player agency or the other way around. In the first case minute details will be reflected in the rules but for the most time players will be more of an CPU doing calculations, with rarely sprinkled decision making. I the second case you will have to decide how much abstraction vs how much detail is really required to catch a wargame feel. One of my favourite wargames of all time is Neuroshima Hex - it has all traits of a wargame (down to unique factions, resource management, placement, movement, terrain, shooting, CC, buffs etc...) in a highly abstracted package - I strongly recommend having a look at it from game design perspective, it has a nice and cheap mobile version. I once started designing a game based on desire to play on ever shifting diorama, with full 3d and unrestricted movement and ended up with a card game, because all interactions that were trully necessary could as well be represented with much simplified representations. Stubbornly sticking to initial outlines when everything you come up with points in totally different direction usually results in an out of place feel of the game. One could argue that this is exactly the case of 8th ed or Warmahordes feeling more like CCGs than historicals. This may be the only way for GW as they exist to produce miniatures, but when making a game from scratch that is a thing to consider.

Secondly, the scope - but not really in a form of a question of "small skirmish with <10 models or an army with... <10 units in it" because they are, in general principle, nearly the same if those two levels are not intermixed. With 10 models you have ten movement decisions, ten target decisions and ten interaction resolutions, same with 10 units per side. You can play WFB with just labelled movement trays and dice counters and still get more meaningfull decision making than with coherency based individual model placements in AOS. Exact terrain interaction rules are mechanics wise the same if they only consider single models or single units. That changes if you want an army level game that still feels like simulation, where those 10 squads consist of 10 independent models with their own layer of interactions. This is where 2nd ed 40K collapsed - resolving squad vs squad combat using model vs model detailed mechanics was completely out of proportions of time vs effects on the global battle landscape.

Next up is development scope - is it "one and done" system or an ongoing development. Because depending on answer to this question comes another one: how much of flavor should come from flexible core rules and how much from exceptions to those rules. You can write a "future proof" system using d100 for everything, with majority of units in the game with stats in 40-60 range just to accomodate those few future outliers with stats around 10 or 90, or you can use d6 and introduce rare occurences of rerolls, d10 or d24. Personally I prefer to have just the very core interactions codified in basic rules and then add uniquness directly, as this allows for greater flavour, but there are a lot of people who would strongly disagree, because they want to be able for every interaction to be the result of common rules, so they don't have to memorize large number of exceptions and some are ok with "this unit is different from that unit over there just because it is slightly better at doing the exact same thing in exactly same way". Thing to remember here is that it is impossible to futureproof for unknown unknowns, so in case of perpetual development every developer has to start introducing new mechanics at one point because discreet set of rules has it's maximum resolution and capacity and you will inevitably get to a place when new idea for unit will either be a copypaste of something already existing or ruleset won't support it at all.

Only after those questions does setting come in - is it ground game, a dogfighting game or a naval game, is it low tech or high tech, rank and file or covert ops etc... - this will define what interactions have to be codified for a full representation of the setting. Next up is should it require heavy terrain investment for rules to produce engaging gameplay or should it be perfectly playable on planet bowling ball or with minimal/symbolic terrain. Physical scale comes last, you can design the whole thing in abstract units and specify if those units are centimeters, inches, hexes or squares only after you know how big of a table would be necessary for resulting gameplay and if it is practical. (and before anybody objects that grid based games are fundamentally different - mathematically they aren't, it's always about some metrics and whether you use "taxi driver metrics" or euclidean one it really does not fundamentally matter for developing intended interactions).

With miniature games come another question - how detailed the models should be and what manufacturing processes wil be used. People constantly complain about 40K scale creep but do not account for plastic having a lot less physical resolution than resin or white metal, or lead requiring beefy rods for polearms to not bend into pretzels. For naval or armoured combat 6-8mm can be enough, for plastic heroes 54mm will be much more appropriate (that is why Guilliman or Abbaddon are so large, plastic just cannot support so much detail in 28-32mm scale). You can compare 4th ed Shadow Seer with it newer plastic incarnation - those are nearly identical sculpts and you can clearly see limitations of plastic process and necessity for enlarging it.

Simplify regularly.

Its easy when designing anything to have the mechanics run away from you. Every once in awhile go through each step in any given process and ask, what is this adding? Is it more fun? Is it slowing it down? Is it killing the pacing of the game? Does everyone playing care whats happening and are invested in the game?

It might emulate something you think is beat but if its not making the experience better then cut it and simplify.

I think it helps to think of your motivation: Why are you creating this game? What do you want to accomplish?

some bloke wrote:First thing is to have a really good idea of what you want the game to do, and then stick to it. Good example is a death race game I tried to make; after a good start, I got bogged down with boarding, and people falling off, now there's people on the ground to account for, and it devolved into a very messy skirmish game with a whole host of mechanics which didn't work together.
As such, if you have any more ideas which don't really fit, write them down and put them in something else.
Fluff and mechanics have a few linking features, but for the most part, fluff can be applied alongside the game. for example, if the fluff says that these guys were created by a god and are thousands of years old and can walk through walls, the only relevant part to the game mechanics is walking through walls. As such you could split your fluff into "What they can do" and "Why they can do it". "why" is just stories, "What" needs be have game mechanics for it.

most of the time special abilities will be reflected by overriding the basic rules, so you don't have to worry about them as much. But if you have tricky ones, like stopping or reversing time, then you may have to get creative in how you will ultimately make it work.

What the mechanics of the game need are:

Actions: what the units do, and how they do it
interactions: how the units interact - can they move past or through friendly units, do units have more morale if close to others?
combat: how do units resolve combat? will you go nitty-gritty and have it break into smaller fights, or will you keep it as one unit vs another? can they just walk away, or are they stuck, or can they make a roll to escape?

Morale is an important function in the game - if your dudes will keep doing what you want no matter what, it'll make for a boring game. if they react to having their mates head explode next to them, then that makes it a bit more interesting! Also include pinning, people won't just walk out of cover if the enemy Is unloading a HMG at them.

I tend to think of a theme, then muck around with how to do combat, then work out the fine details and special rules.

This is some solid advice.

nou wrote:First of all, the purpose. Do you want a game that feels like simulation, with "tabletop perspective" playing bigger role than "omnipotent general" player agency or the other way around. In the first case minute details will be reflected in the rules but for the most time players will be more of an CPU doing calculations, with rarely sprinkled decision making. I the second case you will have to decide how much abstraction vs how much detail is really required to catch a wargame feel. One of my favourite wargames of all time is Neuroshima Hex - it has all traits of a wargame (down to unique factions, resource management, placement, movement, terrain, shooting, CC, buffs etc...) in a highly abstracted package - I strongly recommend having a look at it from game design perspective, it has a nice and cheap mobile version. I once started designing a game based on desire to play on ever shifting diorama, with full 3d and unrestricted movement and ended up with a card game, because all interactions that were trully necessary could as well be represented with much simplified representations. Stubbornly sticking to initial outlines when everything you come up with points in totally different direction usually results in an out of place feel of the game. One could argue that this is exactly the case of 8th ed or Warmahordes feeling more like CCGs than historicals. This may be the only way for GW as they exist to produce miniatures, but when making a game from scratch that is a thing to consider.

Secondly, the scope - but not really in a form of a question of "small skirmish with <10 models or an army with... <10 units in it" because they are, in general principle, nearly the same if those two levels are not intermixed. With 10 models you have ten movement decisions, ten target decisions and ten interaction resolutions, same with 10 units per side. You can play WFB with just labelled movement trays and dice counters and still get more meaningfull decision making than with coherency based individual model placements in AOS. Exact terrain interaction rules are mechanics wise the same if they only consider single models or single units. That changes if you want an army level game that still feels like simulation, where those 10 squads consist of 10 independent models with their own layer of interactions. This is where 2nd ed 40K collapsed - resolving squad vs squad combat using model vs model detailed mechanics was completely out of proportions of time vs effects on the global battle landscape.

Next up is development scope - is it "one and done" system or an ongoing development. Because depending on answer to this question comes another one: how much of flavor should come from flexible core rules and how much from exceptions to those rules. You can write a "future proof" system using d100 for everything, with majority of units in the game with stats in 40-60 range just to accomodate those few future outliers with stats around 10 or 90, or you can use d6 and introduce rare occurences of rerolls, d10 or d24. Personally I prefer to have just the very core interactions codified in basic rules and then add uniquness directly, as this allows for greater flavour, but there are a lot of people who would strongly disagree, because they want to be able for every interaction to be the result of common rules, so they don't have to memorize large number of exceptions and some are ok with "this unit is different from that unit over there just because it is slightly better at doing the exact same thing in exactly same way". Thing to remember here is that it is impossible to futureproof for unknown unknowns, so in case of perpetual development every developer has to start introducing new mechanics at one point because discreet set of rules has it's maximum resolution and capacity and you will inevitably get to a place when new idea for unit will either be a copypaste of something already existing or ruleset won't support it at all.

Only after those questions does setting come in - is it ground game, a dogfighting game or a naval game, is it low tech or high tech, rank and file or covert ops etc... - this will define what interactions have to be codified for a full representation of the setting. Next up is should it require heavy terrain investment for rules to produce engaging gameplay or should it be perfectly playable on planet bowling ball or with minimal/symbolic terrain. Physical scale comes last, you can design the whole thing in abstract units and specify if those units are centimeters, inches, hexes or squares only after you know how big of a table would be necessary for resulting gameplay and if it is practical. (and before anybody objects that grid based games are fundamentally different - mathematically they aren't, it's always about some metrics and whether you use "taxi driver metrics" or euclidean one it really does not fundamentally matter for developing intended interactions).

With miniature games come another question - how detailed the models should be and what manufacturing processes wil be used. People constantly complain about 40K scale creep but do not account for plastic having a lot less physical resolution than resin or white metal, or lead requiring beefy rods for polearms to not bend into pretzels. For naval or armoured combat 6-8mm can be enough, for plastic heroes 54mm will be much more appropriate (that is why Guilliman or Abbaddon are so large, plastic just cannot support so much detail in 28-32mm scale). You can compare 4th ed Shadow Seer with it newer plastic incarnation - those are nearly identical sculpts and you can clearly see limitations of plastic process and necessity for enlarging it.

Also good advice.

Lance845 wrote:Simplify regularly.

Its easy when designing anything to have the mechanics run away from you. Every once in awhile go through each step in any given process and ask, what is this adding? Is it more fun? Is it slowing it down? Is it killing the pacing of the game? Does everyone playing care whats happening and are invested in the game?

It might emulate something you think is beat but if its not making the experience better then cut it and simplify.

This is something I will definitely need to keep in mind. Excellent advice.
____________________________________________________________________________________________________________________________

Thank you everyone for your advice! I really appreciate it.

If I may offer some humble advice:

Rule #1- Design a wargame because YOU want to make a wargame. Don't think you are going to make any money, get a following, etc. All you will get is a long line of people telling you that you did it wrong.

Now, onto the basics:

Getting Started with your Concept
https://bloodandspectacles.blogspot.com/2018/09/wargame-design-getting-started-on.html

The 4Ms
https://bloodandspectacles.blogspot.com/2017/01/wargame-design-basics-4ms.html

I have a whole series of articles about the process on my blog, if you are interested in such things. You may also want to check out the Game Design posts on the Delta Vector blog. They were always inspirational to me.

1) Create a problem statement, as this will give you a rough concept and overall goal.

Examples

"How can I design a game that recreates the feel of modern small unit tactics?"

"How can I design a game that scales well with multiple players, in other words, it should take about as much time for 2 to play as it does 6?"

Notice that the first example is specifically thematic while the second is specifically mechanical. Both types of problem statements work just fine, as the goal is simply put into words what it is your design is trying to achieve, all good product design starts with a problem that needs solving. Be careful with vagueness here though, you want the problem you're trying to solve to be somewhat specific.

2) Create a GDD, a GDD is a game design document. Not enough people in tabletop bother to make one of these but they are powerful tools. A game design document is basically your outline for designing your game, it is also a living document that can change over time as you hit eureka moments and playtest the game. While GDDs can include a lot of things but at a minimum should include the following.

Gameplay Description: This should be a very general description of the gameplay starting with the core, if I were to use 40k, for example, I might say something like this for core gameplay "Uses d6s for task resolution, all distances are measured in inches, terrain should be both area and obstacle type terrain, rolls can be affected by modifiers etc, etc" and as I got to more specific gameplay (think twist on the norm) I may say something like "each side has a finite resource pool with which to use game-breaking abilities (talking about command points and strategems here). Now that's just a quickly written example by me, you will likely want to be a little more in-depth than that BUT let me be clear this is not where you write the rules of the game.

Systematic Breakdown of Components: note I'm not talking physical components here but this should be a list of systems in the game, breaking a game down by systems will make your rules design so much easier. You'll also want to include things that while they may not have their entire own system still need to be noted. Example once again using 40k

-Movement
-Unit Stat lines
-Shooting
-Psychic powers
-Melee
-Morale
-Command & Control
-Stratagems
-Asymmetric factions (note not a system in the game but it should still be here)

Asset Breakdown: This is the physical breakdown of what is needed for your game, 40k used again as an example

-D6s
-Play area
-Models
-Terrain
-Rules to include specific unit entries and faction specific rules
-A measuring device that has inches
-Objective markers

Notice I didn't put the cards on the list, those aren't needed to play, they are just nice, but you can worry about nice accessories when the game design is finished.

Suggested Game Flow Diagram: This can as simple as listing the phases of the game in order or using a flow chart. I prefer flow charts even for simple games myself as even most simple games don't have straight linear flow due to having a check for victory state. Example:

Setup -> 1st player movement phase -> 1st player psychic phase -> 1st player shooting phase -> 1st player Assault phase -> combat phase -> battle shock phase -> 2nd player repeats all steps -> check for victory, if victory game ends, if not to start again at step 2

Those are what you want to have at a minimum in your GDD, if you are going to be making a lot of fluff to go along with it you'll also want to include an Art Style section (what's the art style you are going for, this is important for fluff as the style says a lot about the world, just think about GWs iconic style), Story section (a brief overview not a novel), and possibly a Character section (who are the characters, what are their personalities etc).

3) Create a rules document, make yourself a rules document and write it like you would a rule book. This will make playtesting so much easier on you. May I recommend having a glossary of terms in the document as well, not enough people do this but man I love glossaries.

4)Create a prototype, this is fairly straight forward, you just need some stuff to playtest your design with. This can be as simple as paper disc representing the models or fully 3d printed models if you got one and know your way around CAD.

5)Playtest, playtest, playtest! Not just guided playtest either, but blind playtests as well. When you playtest you should also have a notepad and some paper and take notes of peoples comments and reactions as they play. Then have some specific questions ready that are geared towards whatever your playtest is focus is for that session. Example, you want to really hammer melee with your next playtest, so have questions like "what was your favorite part of melee? what was your least favorite part?" You'll also want to have some generic questions prepped as well. The main takeaway here though is that a playtest is a fun session for you, it's an opportunity for you to really pay attention and see how well your game is achieving its goals (designers are the absolute worst judges of their own games), so TAKE NOTES.

General advice:

Don't be married to your darlings, if everyone in your target audience is telling you that X sucks in the game during playtesting but it is your favorite thing about the game you still need to ax it. Unless for whatever reason you are simply designing it for your own amusement and the rest of the world can be damned.

Learn about Agile! Agile is simply a method of organizing product development (yes a game is a product even if you never intend for the public to see it, so good practices should still be followed), it will help you focus and will keep you on schedule (well hopefully).

Hope that helps.

I wouldn't say that morale is a must-have. I know some games where morale isn't really a thing and that doesn't make them boring. I think of Dark Age by CMoN for example.
And when it isn't done in the right way, it can be a huge bummer... I think of WH40k before 8th... I can remember rolling for so many minis that will do nothing for the rest of the game, I speak about you the last remaining boyz of an orc mob running from a lost melee aaaaall the way back to my table edge. I couldn't see any benefit in a morale mechanic at that point.
I'd rather like to put into the special rules for effects that can break the opponents' morale to let them do a forced movement.

In my opinion morale is a spice that should be used with caution.

Or in general:

1) Try to make the mechanics not fight against each other. If there is a rule that slows down the game kill it with fire!

2) Watch for downtimes: Is there a time in the game, where rarely happens anything else than movement? That's a downtime. It's bad.

3) Built in balancing tolerances: Give the player more than one way to win the game. It makes the game fairer in mean matchups. Maybe have a no kill option. Again, Dark Age is a good example for that.

4) Less is more: Keep your base rules simple. You can still give your special units special abilities. But to force the potential player to read through 100s of pages before even thinking about having a game is a horrifying thing of the past... or at least it should be. You still can have a bazillion special rules, that are tied to your unique special legendary character or a subfaction etc., but the rules of how the game works should fit in a few pages and should be idiot proof. Which leads to the next advice...

5) Rather Strangers than friends: Give your rules to strangers and let them tell you how they think how to play your game. Don't tell them everything and have game with them. Only answer questions but don't help them too much. Why not with friends? Friends know you and they can understand your wording better than other people and proparbly they know the game anyway because you told them a lot about it. That's why: Strangers!

6) Test your game as early in development as possible. It'll help a lot to figure out what's fun and what's not. Agile is indeed a great method to manage that as early as possible.

7) Play many different games. Have a look around how other designers solved (or not solved) different problems. Don't stick to GW only. They have some great games, but most of them have similar flaws... they're getting better.
Maybe have a look outside the well known systems (GW, Infinity, Mantic etc.) to let you be inspired by them.

8) Theme Mechanic: Focus on your theme and let it be reflected by the rules. If you have a postapo game, maybe you should think about a mechanic for lack of ammo and gasoline or a possibility to loot killed enemies. If you have a steampunk game, your machines are motored by steam and should have a rule to raise the pressure to perform special actions that consume pressure. Your game can have multiple themes that are represented by different factions but it definetely helps your game to stand out if you have an overall theme mechanic.

Besides that... all what DrNo wrote...

What scale of battles are you wanting it to run? Massive conflicts where entire worlds or star clusters are on the line, or small scale battles where every shot counts? I think that's the first thing you need to decide. As a rule, I think the "keep it simple stupid" method is best. The core rules should be cut and dry - let the various factions complicate, but make sure additional rules are easily enforced. If something in the core rules says you can't, but special rule X from faction A allows you to - you obviously can. Layout the skeleton first, then you can flesh it out easily.

I too recently started creating my own wargame system - if you want to assist or just pick my brain, feel free to message or email me.

Maybe an offensive question, but:

Are dice an irrefutable neccessity?

I mean isn't it possible to replace calculating modifiers and rolling (possibly several times) with a more fluently mechanic?
And without special dice because money.

Lord Royal wrote:
Maybe an offensive question, but:

Are dice an irrefutable neccessity?

I mean isn't it possible to replace calculating modifiers and rolling (possibly several times) with a more fluently mechanic?
And without special dice because money.

Malifuax uses cards, some versions of Kriegspiel used a game master to determine outcomes, I'm sure there are many more that don't use dice either. So I would not say they are a necessity.


Automatically Appended Next Post:
Though I suppose the advantage of dice, especially the D6 is it's rather easy to work out probabilities.

What about digital RNG? With a software that actually shows you the exact chance in percent before you "roll" and can distinguish between several different weapons in one click. WH40k would be a much shorter game^^

Lord Royal wrote:
Maybe an offensive question, but:

Are dice an irrefutable neccessity?

I mean isn't it possible to replace calculating modifiers and rolling (possibly several times) with a more fluently mechanic?
And without special dice because money.

Very good point, actually. But if you already play 40k, it's not that big of a deal, is it?

You could use something like the deck not dice variant from Settlers of Catan, I guess. Heck, could even have different decks for different types of weapons or units. Three general classifications would do it - hard attacks - for mechanical units, soft attacks - for the average dough boy and a specialty deck - for things like airstrikes or other specialty wargear like grenades or flamethrowers. Whatever you're attacking could even have a defense deck too, so there'd be some degree of chance on both sides. For example - a network of bunkers connected by trenches and defended with entrenched machine guns. Hard attacks from a vehicle could do it but damage the installation, which you were ordered not to do. Snipers and other small arms are valid but not your best option, either - because battlefields ain't the place for waiting games. That leaves either airstrikes, grenades or distracting them to send a grunt to get his fwoosh on.

regular_bro wrote:
Very good point, actually. But if you already play 40k, it's not that big of a deal, is it?

I don't play WH40k anymore due to 40k's game length and thats partly due to too many dice rolls imao. Last time playing it (7thed) I found myself spending more time on managing the rules (roll for reserves, roll for hits AND wounds AND armour, morale... yadayadayada) than actually figuring out a tactic. I found myself sticking to skirmishers; quality not quantity.

And my question targetted rather in a electronic direction. Cause a little bit automatization could help to get a faster game... virtually streamlining without actual streamlining.

Lord Royal wrote:

regular_bro wrote:
Very good point, actually. But if you already play 40k, it's not that big of a deal, is it?

I don't play WH40k anymore due to 40k's game length and thats partly due to too many dice rolls imao. Last time playing it (7thed) I found myself spending more time on managing the rules (roll for reserves, roll for hits AND wounds AND armour, morale... yadayadayada) than actually figuring out a tactic. I found myself sticking to skirmishers; quality not quantity.

And my question targetted rather in a electronic direction. Cause a little bit automatization could help to get a faster game... virtually streamlining without actual streamlining.

The problem I can see with digitalising the rolling mechanism is that people wouldn't trust it as much as dice. if you just press a button and it means that my unit dies, I would find that very anticlimactic. There's a lot to be said about the drama of a critical set of rolls - a unit of 3 or 4 gretchin trying to prise the last wound off a dreadnaught to win the game, for example. if you just press a button to get to the conclusion faster, it's not as immersive at all.

Digital aids would work much better for the bookkeeping side of things than the random number side of things. but as you would need some sort of camera system or smart dice to integrate the dice into the digital aid, the result could be a lot of data entry. I have worked doing data entry, it was mind numbing - not a good selling point for a game!

I don't think that this would be a problem, since RNG is a huge part of turnbased rpg video games and noone has a problem with them. And with an electronic component you can have more detailed HP, so a normal standard model could have more than 1 HP; a thing that isn't used due to avoiding to many tokens on the table. But with an app you don't have this problem.
So to say that kind of system would be a classical wargame to the point of an attack and than changes itself into (ie) Darkest Dungeon.

Even today there are people who use dice apps. But for the more suspicious folks it could be switchable in the menue settings between dice and diceless... that's a simple toggle switch. But the version with dices is (simply because there are more things to do) significantly slower.

And with games like blood bowl we can see that it at least works in the direction from analog to digital, but I don't really see why it shouldn't work the other way around, too.

I know there are a few tries who tried to accomplish that (Golem Arcana and the other failed one). But they had the huge flaw, that even movement was tracked, so you had to move your models twice (once in the app, once on the table). Through that the analog part was degraded into an overpriced gimmick... not to mention what ie. Golem Arcana needed besides that (those crappy scanning pens... cool idea but too complicated).
If you play a game with digital support you don't want it to be an obstacle, which was the case imao with those games.

Of course that the hit algorithm is simple and transparent is oblitaroy, so that you can at least follow the math in the protocol.

PS: I write my bachelor in game design about that topic.

The greatest obstacle for truly random electronic RNG is that if you use a common roller and know the algorithm, you can abuse it by feeding it data to yield the outcome you desire when needed, or if it generates values based on system time... See what I'm saying? They don't necessarily use extensive processing power, it's just the integrity of the RNG you must question. There's loads of authenticators, key-fobs and other electronic locks nowadays - if your biggest issue with a game is not being lucky enough, why are you playing it? If you really HAVE TO cheat to win at a game, anyways, I'd rather lose. At least I earned it. Also, it's not like people are actually dying... If you don't have fun losing, you picked the wrong hobby. Part of learning the game is getting your army tablula rasa'd by some cheese whiz huffing dweeb. It's not cool to intentionally cheat either - people stop playing with you faster than daemons can outflank. I remember goofing in a skirmish game as Necrons with my buddies during 4th I think it was? Had nightbringer and three light destroyers - my buddy with everyone's favorite powered armored faction wipes out my destroyers and then I charge the IG army with my nightbringer - eat his Chimera and half the squad inside. Then the Smurf destroyer player points out that I technically don't have any Necrons models on the board anymore - so I was like "oh, you right. Sorry dude." Last part was to the IG player as I remove the nightbringer model and just wait. Nobody batted an eye, just laughed at the irony.

But yuh, I don't see why rolling dice is that big of a deal... It's part of the game. More exercise for your brain and body rather than sitting around idly punching at buttons or klanking keys. Can always program a dice roller to use on your phone, or find one that your opponents don't have any qualms about using.

Maybe I misunderstood you but it's not a discussion about luck and chance. And I don't suggesting to substitute dice on a whim.
And certainly not because I want to cheat... oO
People who hack into dice apps to gain an advantage in a board game have a variety of very serious mental problems imao. And I don't think that those people are widely spread.

But if you write both variants as a float chart for app support...

1) Click on Target in Range
2) App tells you what to roll (ie. 9+ on a D10)
3) You declare Successes on a slider
4) App tells your opponent what to roll
5) Opponent declares successes on a slider
6) opponent suffers damage or does not

1) Click on Target in range
2) App does the annoying part of adding and substracting modifiers
3) opponent suffers damage

...it might get clearer what I mean. It really is a big deal if you think of how many dice are rolled during an avarage tabletop.

I know dice are cool, but they are effectively slowing down the pacing of a game.

And an electronic calculation doesn't need to be intransparent. Look at the digital version of Blood Bowl for example, where you have a protocol with all the rolls and outcomes. If you know the rules you just need to look at the protocol to figure out what's happened during the match.

In an actual tabletop those protocols could be stored. So every game's protocol that is uploaded into the system can be used to balance pointcosts and model rules. In video games (especially online games) it is a common thing to store player data just to learn about your system you can detect balancing issues before a player writes you an angry email. That's the wet dream of every balancer.

I recently work on an unity prototype for that issue. I'm implementing a switch between dice and clicks. Maybe I'm completely off the track and it's really no fun. But maybe it could be something new and engaging.

And don't get me wrong. I don't want to take away anyone's game. I just want to make a new one that rulewise ain't just a copy of the existing stuff.

Dice vs app is more an emotional output question than anything. As players, we experience games emotionally.

Let me give an example using everyone's favorite game to hate monopoly. If you've ever played try to think back on how you felt when you were about to cross your opponents territory. You may have said to yourself I just need X number to land on a safe space! Rolling the dice, in this case, produces tension and depending on what they show after rolled either elation or dread.

An app really can't produce those same emotional extremes, there's no watching the dice spin or feeling them shake in your hands while your prey to the dice gods. There may still be some relief and dread involved but the emotional highs won't be as exaggerated likely.

Then there are many who would rather not know the odds like ol Han Solo.

So what it boils down to is who is your target audience, are they the crowd that loves fistfuls of dice and doesn't care about the odds, are they the type that loves zero randomnesses and think that winning should be based on positioning and other advantages gained through gameplay, or are they somewhere in between.

Once you think you know the answer, playtest playtest playtest.

There's some UX stuff about people looking at the board and looking at their phones.

 Nurglitch wrote:
There's some UX stuff about people looking at the board and looking at their phones.

Not phones. Tablet or PC/Mac. A phone screen is to small to give enough space for a comfortable Tabletop-UI. You have one shared screen.

And of course it's an emotional thing. But I don't want to repeat the feeling of 40k or similar games. Those already exist... and it would be pretty crazy to compete with that.

But I stop hijacking this thread now. If you want to talk more about that topic. Here's the actual thread: https://www.dakkadakka.com/dakkaforum/posts/list/773484.page

Look into Golemn Arcana to see more about this topic..... oh wait..... you can't...... it is a dead game.

Lord Royal wrote:
I don't think that this would be a problem, since RNG is a huge part of turnbased rpg video games and noone has a problem with them.

Well, no. But that's a video game, not a tabletop game. For most people, the tactile elements of the game are important - rolling dice just feels more fun than looking away at a screen. Not to mention that grabbing dice is usually quicker than setting up a roll in a dice app.

You can use cards - Malifaux does, or there's plenty of other wargames that use a deck of playing cards for some or all random elements. Or there's Cobalt-1 which relied on the players picking numbers. Each stat was two numbers (e.g. 2-5); that means you pick two numbers, each from 1 to 5. For an attack, I (as the attacker) pick my numbers using my attack stat, the defender picks theirs using their defense stat. Any numbers I pick that the defender didn't pick cause a hit. For example, my attack is (2,5), the defender's defense is (2-6). I choose 2 and 5, they choose 1 and 2. The 2s cancel out, my 5 is not cancelled so I hit. In practise it was rather cumbersome and a bit too gimmicky, but it's there as an alternative.

I think figuring out a way to automate 3rd party or AI actions for "enemy" models would be a potential big boon for digital resources on the tabletop. RNG seems like small potatoes since dice all ready do the job pretty well.

Because dice per definition are RandomNumberGenerators.

RNG is just a wider definition for dice.

Lord Royal wrote:
Because dice per definition are RandomNumberGenerators.

RNG is just a wider definition for dice.

Yes, which is why I think focusing on RNG for automation is a solution looking for a problem.

There are other problems in wargaming that automation CAN solve and should be looking at instead. Thing slike hidden set-up and movement, AI opponents, list building, etc.

 Easy E wrote:

Lord Royal wrote:
Because dice per definition are RandomNumberGenerators.

RNG is just a wider definition for dice.

Yes, which is why I think focusing on RNG for automation is a solution looking for a problem.

There are other problems in wargaming that automation CAN solve and should be looking at instead. Thing slike hidden set-up and movement, AI opponents, list building, etc.

It wasn't the idea to kill the dice INSTEAD of those things but in addition. (with automation of listbuilding you mean support like an implemented list builder. Not an app that forces you to play certain lists, right?) Movement will not be digitalized as it takes away the model part.
Taking away the dice simply was an idea to push streamlining to the maximum.
In the final version there will be two options to play: one with dice and one without. It's a simple toggle switch in the settings menue, like turning the music on and off. I just like to try that out and give it a chance. On paper it looks very simple and for me (who likes the tactics and miniatures parts of a tabletop more than obeying the rules) very engaging. But I understand the other point of view, and I know what it means to roll a dice (whether it is a bucket and you count your successes or just one and can literally FEEL how close you hit or miss). That's why both options will be in there, so that anyone can play the game as he/she likes.

But as I wrote earlier. There already is an actual thread for that game.

 Easy E wrote:

Lord Royal wrote:
Because dice per definition are RandomNumberGenerators.

RNG is just a wider definition for dice.

Yes, which is why I think focusing on RNG for automation is a solution looking for a problem.

There are other problems in wargaming that automation CAN solve and should be looking at instead. Thing slike hidden set-up and movement, AI opponents, list building, etc.

The most usefull aplication of automation is dynamic list matching, that is utilizing non-static point costs dependant on opposing faction, build archetype and exact build. Many flaws of point systems could finally be a thing of the past this way. But that is a lot more work than a simple proprietary battlescribe clone.

Dynamic list matching? Is that even possible with miniatures?
Wouldn't it be easier to built in balancing tolerances or similar for the weaker side to compensate against a much stronger opponent?
I think of trapping the battlefield with C4 or give your troops supersteroids.
I imagine that some kind of levelling system could work with that, too: "So your Eldar Army is all level 1, but my Sly Marbo is OVER 9000!!!"