After some thought... tokens would work better for that specifically than combinations, since you want the elimination to be immediate.  Also, if tokens don't count towards territory count, this opens the "per territory bonus" back up in boards with "tracker" territories.  

M57, in the designer, I'd put it under Territories.  Add a tab in the Add, Edit, Delete section that says "Group" or "Class" or something...  Then you would select territories that already exist and name the group.  Then under continents you'd have a tab called "Groups" or "Classes" that allows you to add a Group/Class to the continent.  After selecting a group, it would prompt None, All, or #.  # would let you select a specific number of territories from the Group/Class required to meet the continent requirements.

While it may seem like a specific type of gameplay that I'm going for... I think that opening up the gameplay style of maintaining a specific number of territories has a lot of potential.  Any style of game that you find in a First Person Shooter (Capture the Flag, King of the Hill etc.) would benefit from this format.  I'm currently working on making a MOBA style Risk Map, and I am currently at 818 continents, and the structure for 2 players is almost done...  It's a 6 player game... and it's actually supposed to be a 10 player game.  About 750 of those continents could be summed up in about 6 continents if I could base it on groups.

What I'm trying to do, inevitably, is develop gameplay that resembles moving a single character around in a map.  I thought about doing a big RPG type game, where you take your 1 guy around and accumulate units, then go and fight another guy, then go heal, etc.  This can only be done if I can force you to maintain 1 territory at all times... which I can do... it is just cumbersome.  

Mario Kart is a perfect example.  In my Mario Kart Battle Map, I want you to drive around 1 kart.  You can pick up mystery boxes and shoot your prize at enemies and such.  If a player wipes you off the field, you respawn, but in that action, you get a popped balloon.  When all 3 balloons get popped, you're out.  All of this is completely doable within the current means of Wargear, but it crashes flash trying to load the board in the designer (with all 5000 continents).  Once I started a game on it, it worked fine, but getting in the check on anything is nearly impossible.  

You could also do some fun sports kind of games too.  Ninja ball has you keep 5 units at all times, but the way it happens is so cumbersome that I had to do some really funky things just to get it to seem like it's working.  

And I don't want you to think that I'm afraid of the work.  I made Pong by hand before I understood how the XML editing works, and it has 1500 continents.  

Even with good naming conventions and code editing, it's very difficult to keep track of what everything does when it takes 1000 continents to perform one basic logic function.

Here is the thing.  You've got a hammer.  You've gotten really good at figuring out how to swing that hammer to get the effect you want.  But the tool you need might be a saw.

The feature that you want would be more efficiently described by having autotransfer borders - you conquer across that border, you have to transfer all of your troops.  That enables the effect you are aiming for, and likely is easier to implement.

For yet another approach, Tom could make a game engine engine.  That is, his game engine could be something that had a bunch of configurable callbacks to figure out troop production, placement, etc.  On top of that would be a default engine that is exactly the current site.  But someone like me or Ozyman would be able to write a different engine with different rules on top of it, and then you could build whatever you want on that alternate engine.  (And Tom's time would not be a bottleneck!)

That would be a lot of work for Tom, but if he did it, I guarantee that I'd implement some interesting things on top.  (Factories with production caps being the first!)

There are a lot of ways to create the effects you want with less work for you.  All of them would take some effort on Tom's part.  But if we stop with the first way that you think of to achieve the effect, then we might miss out on something that everyone would prefer.

@btilly, I was just reading a few older threads and chanced upon some of the 'widget' discussions, which sound not to dissimilar from your engine in an engine idea.

http://www.wargear.net/forum/showthread/1744/To_Widget_or_not_to_Widget

@Ed, You want unit autonomy for a single player/unit on a board.  I want something similar for stacks of armies. Restricted Movement Count would do it for my suggestion.  I don't know how related they are (..they are both territory attributes), but it would be nice if there was a larger vehicle like btilly's engine/engine or widgets that open the doors to a host of features ..rather than having tom implement one-offs.

The list of designer desires is long.. and frankly, since factories have been introduced on the site, not much has been checked off the list.  It's clear that Tom's energies have been focused on other areas on the site. Maybe now is a good time to consider a system that is flexible enough to grant as many wishes as possible, yet has more of the feel of a single goal from Tom's perspective.

I made that suggestion when it was late and I was tired.  I didn't emphasize enough the statement that that would be a LOT of work for Tom.

The ONLY way to justify the work is if Tom enjoys feeling like  minor deity for a bit.  And I guarantee that after the initial rush of formerly impossible boards, that designers would come up with requests that still can't be accommodated, and now suggesting ways to accommodate them would require an understanding of programming that few designers have.

Don't get me wrong.  If Tom decided to do that, I would be first to cheer, and I would step up to help designers take full advantage of it.  But it is a hard project.  It will inevitably not succeed as fully as hoped.  And it could not reasonably be justified under any grounds other than, "Tom thinks this is fun."  And I have absolutely no idea whether that kind project sounds fun to Tom.

Tom did express an interest at one point (#8 in the thread). 

And I guarantee that after the initial rush of formerly impossible boards, that designers would come up with requests that still can't be accommodated, and now suggesting ways to accommodate them would require an understanding of programming that few designers have.

Given a full roll-out of a pre-designed system, what might be its limitations?..and what advantages would it have over a piece-meal approach? For that matter, what is it? ..or what could it be?

@btilly, we need people (like you) that program to keep these conversations in the realm of reality.  There is a list of wants. If we could throw them up somewhere - like a google doc, and then look at what type of a system might make a good % of them possible.  Might there be a way to create a working piece of it?  ..like a victory conditions widget, or an in-game territory attribute modulator?

I don't even know where such a discussion should start?  ..envisioning what an engine/engine might look like, and how would it be accessed?

I would love a saw... but all I have is a hammer, so every now and then I request something that seems like a reasonable upgrade to the hammer, without haphazardly unbalancing the tool.  I am not a programmer, though I do know a very small amount of a few programming languages and have a pretty decent understanding of what's required.  I imagined that territory classes would be a much easier manipulation of the hammer than molding it into a saw, or building a saw around it.  If you (btilly) and Ozy and whoever else are willing to put something like this together, believe that I'll be among the first to make whatever I can with it.  

M57 wrote:

Tom did express an interest at one point (#8 in the thread). 

And I guarantee that after the initial rush of formerly impossible boards, that designers would come up with requests that still can't be accommodated, and now suggesting ways to accommodate them would require an understanding of programming that few designers have.

Given a full roll-out of a pre-designed system, what might be its limitations?..and what advantages would it have over a piece-meal approach? For that matter, what is it? ..or what could it be?

@btilly, we need people (like you) that program to keep these conversations in the realm of reality.  There is a list of wants. If we could throw them up somewhere - like a google doc, and then look at what type of a system might make a good % of them possible.  Might there be a way to create a working piece of it?  ..like a victory conditions widget, or an in-game territory attribute modulator?

I don't even know where such a discussion should start?  ..envisioning what an engine/engine might look like, and how would it be accessed?

You have just found the complexity. :-)

What Tom would need to do is list the decisions that happen in the game engine during play.  He would then need to add the ability to have callbacks for each one to an engine other than the one he built.  He would further need to provide a way for people to build alternate callbacks for each one, having thought through the performance/security/etc risks in doing so.  And furthermore for each alternate callback, he'd need to specify how they are to get the board rules from the XML, AND how they are to present those board rules in understandable form for users and designers.

Were I in his shoes, I'd limit the ability to create/modify such engines only to people that I trusted.  The potential for damage is simply too great.

The first obvious source of limitations in this would depend on the way he limits the ability to input rules to an alternate engine.  However that is required to be able to reasonably display to users what the rules *are*.

The second source of limitations is that anything he did not think to put a callback for, can't be overridden.  For example my idea of forced complete transfer across a border as an option is something that could only be supported if he thought of it in advance.  And given that it directly impacts the client UI (which we have 2 of being maintained in parallel), it would not natural for someone implementing this on the server to think of that as being an interesting possibility.

All in all, a huge project.  With major downsides if things go south.

Fun as it is to speculate about what could be done for us, it is worth stopping to consider what I would do were I Tom.  I'm sure at some point that users would encounter bugs that existed in an alternate engine that someone else wrote and is not actively supporting.  The thought of that alone would, were I Tom, be enough to say no.

Edward Nygma wrote:

I would love a saw... but all I have is a hammer, so every now and then I request something that seems like a reasonable upgrade to the hammer, without haphazardly unbalancing the tool.  I am not a programmer, though I do know a very small amount of a few programming languages and have a pretty decent understanding of what's required.  I imagined that territory classes would be a much easier manipulation of the hammer than molding it into a saw, or building a saw around it.  If you (btilly) and Ozy and whoever else are willing to put something like this together, believe that I'll be among the first to make whatever I can with it.  

The "engine engine" idea would be a workshop, not a saw.  The saw analogy is to having borders which, if you attack across them, you have to do a total transfer.

That feature looks fairly simple, but has to be implemented 3x, once on the back end, and once for each client so people don't try to do what is natural but needs to be impossible.  All 3 of those "should" (anyone who has not seen the code - which I have not - cannot truly know what is easy and what is hard) be fairly straightforward.

With it you can imagine boards that are otherwise flat out impossible.  Consider the following.  You start with a fun.  Each gun constantly builds up troops in the barrel.  You can fire at any turn.  When you fire, you get a bullet wandering around that you can steer.  You have as many of these as you want.  You can conquer new guns at any time.  You cannot reinforce.  To kill someone, take their last gun.

That sounds like a fun board to me.  It is straightforward with the "autotransfer border" idea.  It is currently impossible to build.

we need a smilly face with a hand going over the top of its head.!

to symbolize things going over the top of my head :)

 that one maybe?

btilly wrote:

Consider the following.  You start with a fun.  Each gun constantly builds up troops in the barrel.  You can fire at any turn.  When you fire, you get a bullet wandering around that you can steer.  You have as many of these as you want.  You can conquer new guns at any time.  You cannot reinforce.  To kill someone, take their last gun.

That sounds like a fun board to me.  It is straightforward with the "autotransfer border" idea.  It is currently impossible to build.

I could make this map.  If I understand it entirely, I  am pretty sure I can make this map with what we have.

Edward Nygma wrote:

btilly wrote:

Consider the following.  You start with a fun.  Each gun constantly builds up troops in the barrel.  You can fire at any turn.  When you fire, you get a bullet wandering around that you can steer.  You have as many of these as you want.  You can conquer new guns at any time.  You cannot reinforce.  To kill someone, take their last gun.

That sounds like a fun board to me.  It is straightforward with the "autotransfer border" idea.  It is currently impossible to build.

I could make this map.  If I understand it entirely, I  am pretty sure I can make this map with what we have.

How??

Remember, every time the gun fires, you get a new group of troops floating around.  There is no upper limit to the number, but they are never to split or merge.

 the "autotransfer border" idea

I missed this -- how would this work?

M57 wrote:

 the "autotransfer border" idea

I missed this -- how would this work?

If you conquer across the border, you automatically have to transfer all of your troops across it.

This allows gameplay where you want to maintain a fixed number or territories in play.  Which makes the boards that Ed is trying to make a lot easier.

btilly wrote:

M57 wrote:

 the "autotransfer border" idea

I missed this -- how would this work?

If you conquer across the border, you automatically have to transfer all of your troops across it.

This allows gameplay where you want to maintain a fixed number or territories in play.  Which makes the boards that Ed is trying to make a lot easier.

I don't know how I missed it - but a big +1.

As a territory attribute it goes a long way towards creating unit autonomy.  If Abandon ON/OFF could be a territory attribute as well, it would make an even bigger difference.  But I suppose that if it abandoned the territory even with Abandon OFF globally, that would do the trick.

btilly wrote:

Edward Nygma wrote:

btilly wrote:

Consider the following.  You start with a fun.  Each gun constantly builds up troops in the barrel.  You can fire at any turn.  When you fire, you get a bullet wandering around that you can steer.  You have as many of these as you want.  You can conquer new guns at any time.  You cannot reinforce.  To kill someone, take their last gun.

That sounds like a fun board to me.  It is straightforward with the "autotransfer border" idea.  It is currently impossible to build.

I could make this map.  If I understand it entirely, I  am pretty sure I can make this map with what we have.

How??

Remember, every time the gun fires, you get a new group of troops floating around.  There is no upper limit to the number, but they are never to split or merge.

I suppose I could do it, if the bullets are 1 unit large.  Then you don't have to worry about splitting them up, and if you turn off transferring, you don't have to worry about recombining them (or attack only borders, etc.)  

Explain in a little more detail how the guns and bullets work, and I think I can make it happen.

Edward Nygma wrote:

btilly wrote:

Edward Nygma wrote:

btilly wrote:

Consider the following.  You start with a fun.  Each gun constantly builds up troops in the barrel.  You can fire at any turn.  When you fire, you get a bullet wandering around that you can steer.  You have as many of these as you want.  You can conquer new guns at any time.  You cannot reinforce.  To kill someone, take their last gun.

That sounds like a fun board to me.  It is straightforward with the "autotransfer border" idea.  It is currently impossible to build.

I could make this map.  If I understand it entirely, I  am pretty sure I can make this map with what we have.

How??

Remember, every time the gun fires, you get a new group of troops floating around.  There is no upper limit to the number, but they are never to split or merge.

I suppose I could do it, if the bullets are 1 unit large.  Then you don't have to worry about splitting them up, and if you turn off transferring, you don't have to worry about recombining them (or attack only borders, etc.)  

Explain in a little more detail how the guns and bullets work, and I think I can make it happen.

While you own the gun, there is a factory that adds 1 troop per turn in the barrel.

You fire by attacking out of the barrel.  At that point the bullet leaves, and moves as you direct.  Finally hitting another bullet or a gun.

You could make it so that you can only shoot one bullet out at a time, make each territory where the bullets fly have a maximum of 1 unit, and then make it a game of quantity of bullets instead of number of units in the one bullet.

Not that I'm a huge fan of hidden factory programming  tricks (I have used them on a board or two), but it seems to me that it might be easier if the designer could support 'off-board' territories. These would be clearly visible in the designer and available in the history.

Designers would designate a portion of the board, maybe defined by a line that designates the bottom edge of the board (e.g. y=800, where all pixels below 800 don't "print" during games) This would be helpful for designers that have to find real estate for boards that require hundreds or thousands of the hidden factories, not to mention designers would be able to organize them visually (with labels if they want - it's still part of the board) and not have to cram them into tight quarters in strange places - also so that interested players could view them and their workings in the history.

For me, right now, it isn't worth it to work on any maps.  The site is already flooded with many versions of the same thing; and the games I want to make are not currently worth the work and headache that comes with them.  That's the only reason I proposed cleaning up what we already have instead of adding a whole new engine.  As much as I would love a game engine online, that isn't what we have started.  For me to make what I'm interested in making, I need something new.  Whether it be a tweak to what we have, or a whole new thing, I'm pretty much unmotivated to make any new maps at the moment, and have been for months.