I've been working on a better builder design pattern.  I still don't have anything that works the way I want, but I'm fairly sure I can get there, it just is going to take more thinking.

A builder is a designer pattern that takes units from one territory and turns them into units in another territory.  For example, you could have a map where you have a 'pot of gold' territory that gets added to by factories on the main board.  Then you could allow players to spend N gold to build a missile that has lots of attack capability.  Or you could have an alpha centauri board where players need to mine or extract some resources  that they then turn into components of a space ship, and the winner is first to build their spaceship.

If you haven't read it yet, check out the introductory WarGear Modeling Language post:

http://www.wargear.net/forum/showthread/3328/War_Gear_Modeling_Language

Here is the simplest form of a builder:

The advantages of this simple builder are that it is easy for players and map designers to understand.   The disadvantages are that if you want to increase the needed amount of supply to produce product, you will have to edit your image files.  Also, if someone is using the builder a lot (or if you want to require a lot of SUPPLY to build a PRODUCT) all the clicking can get tedious.

Before I introduce the more advanced builder pattern, I want to show a simple 'building block' pattern.

This is the 'metronome':

It's just a simple 2-cycle that alternates back and forth between territory M1 & M2.  I call it a 'building block', because in more complicated diagrams, I use its abbreviated diagram to reduce clutter.

Putting it all together we have this "Advanced Builder"

This builder is a lot more flexible at the cost of added complexity.  The designer can easily increase the amount of supply that is needed to build a product, by changing the value of the negative self factory on the 'BUILD' territory.  No matter how much SUPPLY is needed to produce a PRODUCT, it still takes the same # of clicks for the user.

Disadvantages are that it takes two turns to build a PRODUCT.  There is also a fatal flaw in this design, that I'll leave up to the reader to find for now (I'll write more with some thoughts on how to fix this flaw when I have time).

I'll give a quick walk through:

WAIT/READY alternate.  When WAIT is active, the player cannot build.

When READY is active, the player attacks from READY to BUILD.  Then they fortify the required N units (8 in this case) from supply to build.

The next turn ING becomes active.  If the player had at least N+1 units in BUILD, they now have BUILD & ING  (i.e. BUILDING).  The next turn having BUILD & ING triggers a factory that deposits 1 in the SUPPLY.

Ozyman wrote:

Disadvantages are that it takes two turns to build a PRODUCT.  

I haven't taken the time to figure it these things out yet, but by any chance, would any combination of Real-Time Factories solve this problem?

Maybe... Probably?  I'm not sure either.  It's complicated enough the current way, so I haven't tried thinking about the real time factories yet.

Ozyman wrote:

Maybe... Probably?  I'm not sure either.  It's complicated enough the current way, so I haven't tried thinking about the real time factories yet.

I think you're making what was going to be my point - the "normal" factory delay is what complicates things and confuses people the most..

For instance, in War of the Roses, If you capture a set of shields you get a regular (standard) in-hand bonus -- most everyone gets that.. But the "extra" bonus that comes from lighting up the marker takes an extra turn to kick in -- Not only that but when someone steals your shields, yes the regular continent bonus goes away, but because of the factory delay, you keep your shield through your next turn -- It doesn't turn over to your opponent until THEIR next turn..  Delays are often a big part of what makes factories so complicated.

Well I don't know.  In some cases, I think it is simpler when factories take a turn to complete, and in others cases more complex.  Sometimes I rely on multiple factories triggering based on the ownership of territories at the beginning of the turn, even though ownership changes because of those factories - I'm not sure how that would translate to real time factories.  I'm not saying the same thing couldn't be done with real time factories & maybe it'd be simpler in the end, but I try to work with what we have, instead of thinking about what I could do if things were different.

Ozyman wrote:

Well I don't know.  In some cases, I think it is simpler when factories take a turn to complete, and in others cases more complex.  Sometimes I rely on multiple factories triggering based on the ownership of territories at the beginning of the turn, even though ownership changes because of those factories - I'm not sure how that would translate to real time factories.  I'm not saying the same thing couldn't be done with real time factories & maybe it'd be simpler in the end, but I try to work with what we have, instead of thinking about what I could do if things were different.

On the other hand, it would be a shame to put together a system that would become obsolete because of a feature that is on the horizon, especially if that system is convoluted, and the solution is simple. 

I'm learning to avoid designing things that I think fall into that category; In some cases, I might even have a pretty good sense that the feature might never come, but I'm not going to knock myself out in the off chance that it does, and especially if the solution is a relatively simple one.

BTW, I'm not saying what your doing is a bad idea.  One about Real Time Factories is they won't change any thing you're bringing up here - In fact, I think they would enhance it...  In my mind, the delay is one of the biggest problems with factories.. Sometimes you want it.. But other times, it's the last thing you want.

Yeah, having thought about it more, I think real time factories would in many cases make things less confusing.  For example, I'm sure my Finite State Machine map would be easier to understand if it had RTFs. 

I don't however think that RTFs are necessarily on the horizon.  Tom is still working on victory conditions, and new features seem to come out about every 6 months+, and we haven't even heard if RTFs are on the list.  I'm not complaining as I feel like as designers we have lots of toys to play with and I'm just getting familiar with the existing stuff.

I'm not too surprised that there is not a lot of interest in my WGML.  I think it is something that will hopefully prove its use over the long term.  Once I have it a bit more refined I plan on adding some pages to the wiki, but I like to use the forum to hammer things out.

The good thing about WGML is that it doesn't need tom's support - I wouldn't worry about it.  It will get support once/if people start using it.

Tom asked about RTFs in th forums once, so I know they are on his radar,  as are I'm sure a number of other designer features..

I'm hopeful that a new wave of factory features comes ..eventually.  I've said it before, but development of factories features should be the focus of Designer improvement going forward.  That said, there are a number of underlying features that are necessary to pave the way for the things that factories can potentially do.

I think not instead of, but in addition to looking at how we can stack and arrange factories to do things - we should be looking at ways that those things can be simplified.  I'm talking about features that save designers from building thousands of factories (like combinations).  Heck, It's not out of the question to envision a "timer" factory or a "cycle" factory.  But a lot of ground work would need to be laid for things like that to ever happen.

Right now RTFs would be a luxury. As much as I think they are important because they will make it possible for designers to make games that make more "sense" because players won't have to wait for a factory or series of factories to kick in.

On the other hand, if Tom were ever to decide to bring in "card membership", we would probably want if not need to have RTFs in place first, but in my opinion, RTFs will be better enhanced if other things get placed higher of the list.

More important and urgent foundational work for factories right now in my opinion is

Per territory abandon/min unit count

Token territories.

The only factory feature that I would consider implementing before these is AutoCaptureNeutral, which in absence of the above two features would offer designers some work-arounds related to what can't be done now.

All of these have broader support from the designer community here.

..paving the way.

Ozyman wrote:

 

Here is the simplest form of a builder:

Might not this be what you mean?

I'm not able to post images here - select files produces the above and insert edit image requires a url

oh well..

definitely agree with your priority list of factory related improvements.

I don't understand your last post.  If you want, you can email me an image, I'll host it for you and then you can link to it in your post.

http://www.wargear.net/boards/designer/5087

this is the image i was trying to post - not really a simplification - but I think clearer..

Ok - Here is the one I think is better & works good.  Let me know if you notice a flaw.  I used M57s new syntax.

Process to build Final Product (U) from Supply (S)

Automatic Factory Actions in Italics 

Player Actions in Bold

Turn 1

P1 is owned by player 1, so turns on "Ready to Build" (R).

Attack from "Ready to Build" (R) to "Build" (B1).

Fortify N units from "Supply" (S) to "Build" (B1).

Turn 2

"Build" (B1) turns on "ing" (B2).

"Build" (B1) and "Player 1" (P1) cancel out and leave "Ready to Build" (R) with zero units.

"Build" (B1) subtracts N units from itself.

Turn 3

 "Build" (B1) and "ing" (B2) produce M units on Final Product (U).

I just realized S does not need to be a circle (i.e. placement disabled).

Notes:

If a player fortifies less than the required N units to B1, they will be lost with no U produced.

The designer could give B1 a max of N+1 units to make it a simpler for players, as they could just fortify 'A' to build a U.  Once the process is started, players can fortify N units from S->B1 each turn to produce M units on U each turn.  This means it takes two turns for the first M units to arrive, but only 1 turn once the "factory is warmed up".

Alternatively Allowing N*P+1 as the max would allow players to stockpile units on B1 to continuously produce one unit every turn for the next P turns.

What does R do?

R keeps the player from 'cheating'.  Imagine you didn't have R.  Instead you might give S a normal 1-way border to B1, but then a player could:

Turn 1:

Attack 1 unit from S to B1. 

Turn 2:

Factories activate -> Turn on B2 & Turn off B1. 

Player can again attack 1 unit from S to B1.

Turn 3:

Player has B1 & B2 so they get M units in U.

So now player has spent only 2 units from S to get their U units.  They didn't have to spend all N units.

By making S->B1 fortify only, we force players to use R to attack B1 before they can use units from S.  By making R unavailable the turn after it is used, it keeps them from immediately retaking B1 if they didn't put enough units to keep it after the -N factory activates. 

Hope I explained that well enough.  Let me know if you see any flaws.