A number of you have mentioned that while it looks interesting, the M-Engine needs to be play-tested.  Well that’s finally happening. Game 1 is in a holding pattern right now, but Test Game 2 has gotten off to a good start and after five turns looks to be entering its mid-game phase.

I’m starting this thread as a forum for myself, players, and spectators to comment on the game.  What’s working, what isn’t, what a Crazy Ivan Oatworm is, etc..

It’s pretty easy to follow the game.  I’ve posted an annotated slideshow with a map for each turn.  Under that is the master spreadsheet, which shows all players’ orders and includes a detailed round by round entry for each battle with the occasional comment describing how the engine dealt with the orders.

My impression is that only took a round or two for the players to get a feel for how things work. Orders for the last two turns have been submitted with very few if any questions, and I’m noticing that player’s moves are getting more sophisticated as they realize what the engine is capable of.

This is a pretty-full featured game and I’m expecting that players will start to “push” the engine a bit.  Already we’ve seen scenarios where flex troops have been used, and there have been a few attacks on multiple borders, both from friendly and enemy combatants, but there are a couple of “engine rule specific” scenarios that haven’t occurred yet, and so far players haven’t placed any delayed orders.

I have also up-dated the M-Engine home page to reflect that flex and attack armies are no more. Instead, all armies are now flex armies and a “Min # Dice willing to be thrown” floor is in effect with a default setting of “3”. This should further simplify actual M-Engine play. Simplicity of play is a criterion I think most of us would agree needs to be highly valued.

Let's talk about delayed orders for a bit. If all orders are executed simultaneously and all you can do is delay an order by rounds (e.g. "turn order" in the BAO sense doesn't matter), what's the point of delaying an order if you can just submit that order in your next round/turn?

Oatworm wrote: Let's talk about delayed orders for a bit. If all orders are executed simultaneously and all you can do is delay an order by rounds (e.g. "turn order" in the BAO sense doesn't matter), what's the point of delaying an order if you can just submit that order in your next round/turn?

Just so we're all on the same page..  A turn is: Everyone submits a ton of orders and the engine runs them all.  A round is: The smallest time-frame the engine deals with (a simultaneous throw of dice), so when you delay an order you are delaying it to a later round in the turn.

Let's look at some examples where you might want to delay orders:

Let's say on the last turn (turn 4) of our Game 2, you suspected that CiscoKid would attack W.Africa and then attack S.E. in an effort to move and consolidate troops (which is what He/I was trying to do).

As it was, you ended up confronting 4 Cisco armies on the first round (they had to be called back to defend against you), whereas if you had waited just one more round it was likely you would have met with almost no resistance because they would have taken S.E. and all troops would have moved there.  (Of course as it was you rolled lights out and wiped out all of those armies in a couple rounds), but you put a lot more of your armies at risk than you needed to.

Here's another reason to delay an order by a round or two. Let's say you want to take a territory that has only 2 armies on it, and you can attack to it from 2 territories..  You could come in blazing with 6 dice, but if you did this, you would be putting 4 of your armies at risk because this is a special situation where the defender throws more dice than he has armies. Let's say do it anyways and you lose one from each stack. Now if you had delayed one of those attacks one turn.. you keep the same odds of winning, but if you were able to take out just one defending army on that first round attack -- on the next round you could go in with guns blazing against defender's 1 die thrown against each of your stacks..

Here's another example.  If you have a blitzing maneuver that you think has a better chance of working after your opponents have been bashing each other for a while, delay it for a few rounds.

Similarly, if you think an opponent is going after the same territory you are, let him waste armies taking it, then come in right after and clean up.

There are numerous situations I can think of to delay orders..  In fact, I can think of reasons that you might want orders to only stand for a certain number of rounds.

The way I see it, the engine can do just about anything as long as we can define it.  The question becomes, how much control over minutia should we give players before things get too complicated for the average player.  Delayed attacks seems like a reasonable option because it's a simple value for the player to plug in, and its meaning should be reasonably apparent.  Clearly they're not necessary for solid game-play but you know the hard-core players are going to ask for it.

M57 wrote:

Just so we're all on the same page..  A turn is: Everyone submits a ton of orders and the engine runs them all.  A round is: The smallest time-frame the engine deals with (a simultaneous throw of dice), so when you delay an order you are delaying it to a later round in the turn.

IMO it should be reverse.  BAO it was reverse and currently turn (ids) are known as each individual attack in turn based games.  Round = order of turns.  But, it's your engine :)

Yertle wrote:

M57 wrote:

Just so we're all on the same page..  A turn is: Everyone submits a ton of orders and the engine runs them all.  A round is: The smallest time-frame the engine deals with (a simultaneous throw of dice), so when you delay an order you are delaying it to a later round in the turn.

IMO it should be reverse.  BAO it was reverse and currently turn (ids) are known as each individual attack in turn based games.  Round = order of turns.  But, it's your engine :)

Gotcha. -- I could change it so that it's less confusing for everyone.. a lot of edits, but probably worth it..  It really doesn't make much difference to me - the words seem a little arbitrary ..no wonder I got them backwards.

Okay - gotcha. I didn't realize there were "rounds" to the "turn" - I thought the terms were interchangeable. Good to know!

OK, I'm a little flummoxed buy this round/turn thing.  It is confusing to say the least, and I do understand your point and your argument.

But before I go editing like crazy, I'm going to think this through:

First, a question..

With the regular non-BAO game, is there a distinction between turns and round?

Here are some of my thoughts:

When we say, "It's your turn", you place a bunch of orders, right?  In this sense, a turn as it is currently defined by the M-Engine makes sense.  We're not going to say, "Take your round", are we?

In fact, the only things that have a "pre-defined" order to them with the M-E are the turns.  As I currently have these words defined, rounds do happen in order, but exactly what events happen in each round are unknown until each round is arrived at.  And there can be "rounds" with the M-E where not everyone plays..  In fact, when you really come down to it, with the M-Engine there is no such thing as a turn, just as in real battle.  Maybe I should have Moves with Rounds?  "Make your Move".  Now that makes more sense to me.  Everyone can be moving at once!

I feel like I'm splitting hairs with these definitions.  It seems too easy to justify either way..

On the other hand, I am concerned about confusing the BAO crowd.. What do others feel?

As long as you're consistent, I think it's good to go. I will note, though, that, if the entire point of the engine is to prevent BAO-style turn order gaming, allowing multiple "rounds" in a "turn" is just going to bring that wonderful side-effect back.

The rounds aren't so much an artifact of the move order resolution as they are an artifact of the battle resolution. A "round", as I understand it, is short for "round of rolling"; in other words, each unit involved in ANY battle gets to roll once, and that constitutes a round. Then the losses are apportioned, flex units are drawn back if necessary, and another round commences if the battle has not yet been resolved. Players can't control directly how many rounds there are, and they can only indirectly control what their units are doing in any given round. Thus it is a very different beast, IMO, than the WF BAO engine.

Ah - good point. I didn't even think of that.

Kjeld wrote: The rounds aren't so much an artifact of the move order resolution as they are an artifact of the battle resolution. A "round", as I understand it, is short for "round of rolling"; in other words, each unit involved in ANY battle gets to roll once, and that constitutes a round. Then the losses are apportioned, flex units are drawn back if necessary, and another round commences if the battle has not yet been resolved. Players can't control directly how many rounds there are, and they can only indirectly control what their units are doing in any given round. Thus it is a very different beast, IMO, than the WF BAO engine.

This is pretty much dead-on.  I'm thinking that a round of rolling makes more sense than a turn of rolling, and though this may confuse some potential WF-BAO converts, in the long run I think it makes more sense to build up nomenclature that is dedicated to the way the engine runs.

Regarding your comment about players not being able to control number of rounds played, as with a lot of engine "restrictions", this is really only contingent on how uncluttered and/or simple we feel the player interface needs to be.

There's no reason, for instance, that players couldn't put limits on the number of rounds they want a battle to be fought, or place a stop order after a certain amount of defenders have been killed, or set any number of tactically related criteria with each order.  I'm not saying these are features that we'd necessarily want the engine to sport, but they are entirely possible. At this time-frame there are lots of possibilities.  Some features and rules will be designer decisions, and others player options.

Certainly at this point the trick is to find that one or perhaps two fields of player input whose meaning is inherently clear, and which give players maximum control over the disposition of their forces.

Game 2 Update..

Coming into turn 8 we find ourselves solidly into the middle-game.  All four players are still on the board, but three Super-powers have emerged and the stacks are building up.  We should be seeing some of these big stacks going at each other in the next turn or two.

Attack and/or Transfer style orders have been adopted but in this game they are highly restricted because of our standing "1 mid-turn transfer" rule.

Any concerns that I/we may have had about territories simultaneously having to attack and defend stalling the game out have pretty much been allayed.  In fact, just the opposite seems to be the case. I think the "flex" armies have worked perfectly in this regard.

Players have already attempted with varying degrees of success so-called "blitzing" maneuvers.  As expected, ED (event dependent) orders are commonly being issued and achieving desired results.  Clearly ED orders will make so-called "blitzing" maneuvers much more difficult to execute.

From the FAQs regarding "blitzing".

"The M-Engine defines "multiple moves" as a series of orders that results in one or more armies attacking through more than one territory during the course of a turn.  With the M-Engine (and provided that multiple moves are enabled) you can expend your forces as long and as far as you like (just like in the regular game), but remember, you are not doing this in an isolated time frame.  A "turn" is made up of many "rounds", and theoretically in any given round every territory on the board can be rolling attack dice.  This means that your blitzing armies will not necessarily be advancing unimpeded. You may run into another player who is doing the same thing, resulting in either a direct intertwined attack or in a contest over the same territory.  Or you could be attacked from a flanking territory, which will often be the result of a countering "event dependent" order - one that was lying in wait for your maneuver and would necessarily draw flex armies from your attack.    In fact, your "successful" blitzing order that just moved through 6 territories may have never actually controlled more than two territories at the same time. It's entirely possible that an opponent's stack could be following in your footsteps, catch up to and destroy your forces! The M-Engine lets everyone "move" at the same time, making "blitzing" a bit of a trickier maneuver than in the normal game."

I was looking at Oatworm's orders for turn 9 and thinking he didn't really have to put a delay on his 189 and 190 orders.  As I see it, his intention was to "let?" Exploding R. run through Mid. E. and into E. Africa, then "follow" him into Mid. E. and then E. Africa.  But why?  Why not just put a standard Event Dependent order in to attack ME.. then E. Africa?   There is a slight, slight difference, but either way, the order would kick in as soon as ER takes ME.

I'm beginning wonder how necessary Delayed Orders are.  As it stands, straight ED orders are working as well if not better than I thought they would, especially where defensive tactics are concerned. I think we (at least those of us playing the game) would agree that they definitely have value in defending against flanking blitz maneuvers. Yes, DO will probably make a difference on the offensive end of the things.  The strategy of "let everyone else beat each other up, then go in with the big stack" could bring an extra level of sophistication to the game, but not having it just makes for a different challenge.  Nobody's really used it effectively yet.  Oatworm has place a few DO orders and as far as I can tell, they haven't (or wouldn't have) made much of a difference. Consider that when a noob plays the M57E minus DO, the only thing that they would have to deal with is a Min # Dice Floor, which when you think of it is not really any different than selecting 1,2,3 when you attack in the regular game.

I'm also thinking about the lightning game crowd that all agree to try and pop off a move every 4 or 5 minutes. Clearly this is doable with this engine. Maybe DO could be a designer/player option w/a "disabled" default.

Yeah, I think having "event dependent" OR round-delayed orders makes sense, but there's no need for both. I've been playing with round-delayed since I know Yertle's been hitting the "event dependent" orders fairly heavily and I wanted to see if there was any difference in them.

Two thoughts that are springing to mind while preparing to take my orders...

1. Blitzing is a bitch. Since blitzing is enabled in our game, that means I need to think of the possibility that somebody is going to break through my line of defense and tear apart my interior when making my orders. Consequently, I have to either issue round-delayed or event dependent orders to counter that, most of which may never come to fruition (e.g. "Okay, if Egypt is taken, then let's retake that... wait, what if Congo was taken, too?"). It's really annoying. Of course, this is true of conventional Risk, only you don't get to issue a complex series of countervailing orders to counter for it, so I guess that's an improvement.

2. "Event Dependent" orders are going to be a pain for Tom... I think. You're basically asking Tom to build an engine that allows for "if/then" logical constructs along with a user interface that simplifies it enough where people will be able to use it. For our game, it's not a huge deal because nobody's pulling complex nested trees or attempting if/then/else constructs (I might change that this turn if I can come up with a halfway compelling reason to do so), but it could get out of hand with larger games or more creative players. At the very least, I can't imagine it would be good for performance because, the instant someone submits an ED move, the engine would have to poll all moves and all conditions each dice round to find out if the ED should be completed or not, with each ED requiring a separate poll of the moves on the table. That's an O(N^2) problem right there, which is a mathematical way of saying "WarGear will grind to a halt".

Anybody else have any insights they want to toss into the ring?

Oatworm wrote: Yeah, I think having "event dependent" OR round-delayed orders makes sense, but there's no need for both. I've been playing with round-delayed since I know Yertle's been hitting the "event dependent" orders fairly heavily and I wanted to see if there was any difference in them.

Remember, round-delayed orders are always event-dependent. For instance, if you put in an attack order for round 4 against your own territory, and that territory isn't taken until round 6, the order would be "delivered" in round 4, and "executed" in round 7.  There's very little difference between that and "delivering" it immediately.  As a defensive tactic the delay order just doesn't seem very smart.

On the other hand a delayed attack against an opponent can be a very smart offensive maneuver if you are confident that that he will be attacked by someone else first, unless of course that someone else is thinking the same thing and delays his attack, but then you both risk the possibility that the round never occurs.  This is good because it sets M57E apart from BAO in the order-stacking dept.

However, things can still get nasty. For instance someone could plan an attack somewhere for round 1 and 2 and delay an attack somewhere else that they're pretty sure will last from 3-6, thus ensuring that your their round 7 delayed order goes through.  That's ok with me, because they have to spend armies to do it.  Problem is, if you have unlimited transfers, then you get into the whole moving 1 army back and forth BAO style orderstacking craziness, which we want to avoid like the plague.

I thought up delayed-orders to placate the BAO crowd, which I thought would complain about losing their precious "right to order-stack".  We don't need to do that now.  Event-dependent orders covers a lot of that ground very efficiently, while delayed orders, even with it's safe-guards invites the creative types to invent ways to order-stack.

Now I've got to consider your post about programming concerns..

M57 wrote:

Remember, round-delayed orders are always event-dependent. For instance, if you put in an attack order for round 4 against your own territory, and that territory isn't taken until round 6, the order would be "delivered" in round 4, and "executed" in round 7.  There's very little difference between that and "delivering" it immediately.  As a defensive tactic the delay order just doesn't seem very smart.

Good point - I forgot about that. Honestly, I've been treating them as a poor proxy for BAO-style defensive turn manipulation. On the other hand, I did find an interesting fusion that does nothing for ease-of-computation but does everything for making-things-stupendously-complicated - in my latest turn, I issued set of orders that use event dependent moves with a "if this event doesn't happen by round X, do something totally different" trigger. I have no idea how such a thing would work in the GUI, but it should lead to some interesting results.

So how long until you guys are all just over playing at mfish.net?

Oatworm wrote:

Two thoughts that are springing to mind while preparing to take my orders...

1. Blitzing is a bitch. Since blitzing is enabled in our game, that means I need to think of the possibility that somebody is going to break through my line of defense and tear apart my interior when making my orders. Consequently, I have to either issue round-delayed or event dependent orders to counter that, most of which may never come to fruition (e.g. "Okay, if Egypt is taken, then let's retake that... wait, what if Congo was taken, too?"). It's really annoying. Of course, this is true of conventional Risk, only you don't get to issue a complex series of countervailing orders to counter for it, so I guess that's an improvement.

Realize that if the blitzing stack is large enough, your ED counters will barely slow down the blitz.  E.g., their (blitzing) attack orders to continue attacking into your less defended territories will be realized even as you attack them.. The best you will do is draw down two flex armies ..and potentially only for one round.  The best defense against a blitz, just like in the game, is to get in the way.

Is placing a few extra ED orders really that much of a pain?  It's not like BAO, where you'd have to put in an order for every other round to be sure.. This is a one order and done kind of thing.

If this turns out to be a problem, one solution is to turn off blitzing.  Armies can't go through 2 countries (unless one of them involves a transfer order) I don't think this is necessary, but it is easy enough to do.

A better idea might be to restrict orders such that an army can never be served with multiple orders, (even though only one if any would actually be executed).   For instance, a player can't give Egypt (with 10 armies) orders to attack N.Africa with 5 (ED), East Africa with 5 (ED) and S. Europe with 5 (real)  A restriction like that would severely reduce the amount of Event Dependent orders placed, and it kind of makes sense.  Those troops have to be sitting on those borders ready to go at a moments notice. (..It'll probably make it easier on the GUI, too)

2. "Event Dependent" orders are going to be a pain for Tom... I think. You're basically asking Tom to build an engine that allows for "if/then" logical constructs along with a user interface that simplifies it enough where people will be able to use it. For our game, it's not a huge deal because nobody's pulling complex nested trees or attempting if/then/else constructs (I might change that this turn if I can come up with a halfway compelling reason to do so), but it could get out of hand with larger games or more creative players. At the very least, I can't imagine it would be good for performance because, the instant someone submits an ED move, the engine would have to poll all moves and all conditions each dice round to find out if the ED should be completed or not, with each ED requiring a separate poll of the moves on the table. That's an O(N^2) problem right there, which is a mathematical way of saying "WarGear will grind to a halt".

Anybody else have any insights they want to toss into the ring?

How could there be a problem? Tom is God, right?

Really, I have no clue what all this means for a programmer.  I can barely imagine what a flow chart of the logic would look like, but you are right.  All orders will need to be polled every round to see if they can be delivered.  But it's not like BAO where there are thousands of orders (although I think they only get checked once).  Based on what I'm seeing with our game, we're looking at about 4-5 orders per person per turn, and maybe a quarter of them are ED.  Let's be conservative and say that in an average game about 1/3 of orders will be ED.  That translates to about 50% more orders than in a normal game, but I don't know if ED orders tax the system any differently than a regular order. In a lot of ways, it seems to me that they all have to be treated the same.  So far we haven't gone more than 10 rounds in any turn.. The early rounds are the where most of the action occurs. The last half of most rounds usually only involve one or two conflicts with larger stacks.

My mantra as a musician/composer is.. "If you can hear it, you can play it".  Who knows how or if that translates to programming..

Cramchakle wrote:

So how long until you guys are all just over playing at mfish.net?

Mfish is vapornet.  It doesn't exist. But you knew that.  I'm only going to host 3 or 4 games max. They are time consuming to host, but this is the only way I can think of to test play the engine in way that anyone can follow. I only plan to play each game until we know that the engine isn't being stressed.  There's very little I can do beyond that.

As I've mentioned before, I have no clue about programing, or even how the process would go from here (if it goes at all) so I'm making sure that the games are well documented.  Most of the scenario types have been played out, and in playing the games we've found a few areas where we've made some tweaks, so they have been valuable in other ways.  At this point I'm happy 'cause I know it works.  Now it's just a matter of finding out if people want it ..and then if it can actually be made to work.