From a different thread for discussion..

M57 wrote:

Board Widgets

Consider that instead of Ed having to create a scoreboard from scratch, there could be a "Score Widget."

Designers would simply designate areas on their boards for widgets. Unlike the Player Color Area on WG boards (which I always thought was a nice feature), Board Widgets would have functionality; they could be tied to victory conditions, or make local or global changes to board conditions (think dice-mods, disable/enable borders).  They could affect all players, or individual players. On the front end, they could be tied to things like factories, cards, unit count, even luck stats. I haven't given it that much thought, but I'm sure folks could come up with interesting ideas.

In order to let designers retain the graphic integrity of their boards as much as possible, most widgets would simply be text and color fill, and the designer would have a number of fonts and sizes to chose from.

The nice thing about this idea is that it is completely scalable on top of the two existing engines.  For instance, Tom could code a Score Widget and be done if no one comes up with any other ideas.  Different widgets could be created to enhance different engines.

 

tom wrote:

Interesting idea - how would you drive what appeared in the widget? Would it just be a counter of various things like # units owned, # continents owned etc?

M57 wrote:

Well, this would be what would be up for discussion.  The idea itself is scalable, so It might be interesting to start with a widget that just counts just what you mention, units or continents owned ..with the option of tying it to a victory condition.  For instance, on a board with 9 continents a designer could set victory conditions to something like 6+ continents owned.  

I'm thinking about execution from the designer's perspective.  I'm sure there are different ways to make this happen and I don't know how hard they are to code, and there are other things I'm unclear about and/or have put little or no thought into..

Should the widget area include the image, or might there be a button in the designer that uploads separate widget images?

How do widget sizes account for different numbers of players?  Remember how on WG you had to make room for 9 or 12 or whatever number of players even if only 2 were playing?  It would be nice if the widget could somehow auto-scale.

Depending on how widgets get implemented, I have some pretty wild ideas about how they could be used, but before I throw yet another one of my elaborate hair-brained schemes out there, I'm curious to find out how others interpret this idea.

Honestly the idea of 'widgets' doesn't seem too clearly defined.  I understand the idea of the score board.  And I could see a way for Tom to add a dropdown 'widget' menu, where you select a widget and then fill in some parameters/select some territories/borders, etc. and then it auto generates a bunch of continents/territories/etc.

But something like the assassination would (I think) require a change to the game engine, so isn't really in the same class as something that just auto creates some map features.

One possible solution is something that Neros and I have been working on (although not much progress lately).  The idea is for a little program you could run that would give you a GUI interface to some of the Python code that he & I have written.  I hope he doesn't mind me sharing this mockup:

https://picasaweb.google.com/lh/photo/3xYOsUZzjPJawmYkNNwsyp4ZaovkZkDakqCO0wCC3D8?feat=directlink

This would not be as nice as something built write into the editor, but should be reasonably easy to use.  Just export your map.  Then run this program and select the 'widget' you want added.  Then import your map again.  The main advantage is that it frees Tom from having to add all this himself.

If people are interested in something like that I could move it further up my priority list.

Ozyman wrote:

Honestly the idea of 'widgets' doesn't seem too clearly defined... 

Yup.  ..and depending on what the idea evolves into, the actual word "widget" may end up being a misleading misnomer.

 ..I could see a way for Tom to add a dropdown 'widget' menu, where you select a widget and then fill in some parameters/select some territories/borders, etc. and then it auto generates a bunch of continents/territories/etc...

Case in point.  This is not at all what I had in mind, but yours may be the way people wish for the idea to go.

Ozyman wrote:

One possible solution is something that Neros and I have been working on (although not much progress lately).  The idea is for a little program you could run that would give you a GUI interface to some of the Python code that he & I have written.  I hope he doesn't mind me sharing this mockup:

https://picasaweb.google.com/lh/photo/3xYOsUZzjPJawmYkNNwsyp4ZaovkZkDakqCO0wCC3D8?feat=directlink

O, I'm not exactly sure what your program's potential is, but I'm talking about creating a space on the board that is not only linked to board conditions, but also potentially affects them.   I think you're talking about code for designers. Minimally, I'm talking about a space that relays information to players, but I envision that information as being all but necessary for play.  Here's an example.

Consider a fogged game where victory conditions are to own 7 of the 10 continents (or designated territories, factories, etc.) on the board.  Players are not able to see who owns what because the game is fogged, but the widget appraises players of who's ahead.  Technically, victory conditions do not need to be be linked to the board ..just the data in this case.

So what ever happened with this idea?  Seemed like a very cool feature but the discussion was left open-ended...

IMO, it sounds like 'widget' is just a catch all term for any sort of functionality that a map designer could imagine/want.  So until it gets nailed down as something specific, there is really no where to go.

As an example of something a bit more specific.  Ed Nygma has talked about various ways to combine factories to do cool things (digital displays like the score board, counters that count up or down, etc.).  I could see these being packaged up into a one-click solution.

Ozyman wrote:

IMO, it sounds like 'widget' is just a catch all term for any sort of functionality that a map designer could imagine/want.  So until it gets nailed down as something specific, there is really no where to go.

As an example of something a bit more specific.  Ed Nygma has talked about various ways to combine factories to do cool things (digital displays like the score board, counters that count up or down, etc.).  I could see these being packaged up into a one-click solution.

I suppose we could call that a designer widget, but really everything on the designer page is a widget in a sense. 

I was thinking in terms of something that's part of the game (I.e., it's viewed or used by players) but isn't part of the game board per se. So it could be a pop-out, but it could also be a designated space on the board that has non-attack/defend/fortify functionality and is not a territory .It could be things like counters, modifier buttons, cards, graphs, ..who knows.

The luck graphs and related pages that we have now could fall into the category of a widget except that the designer has no say in it's functionality.

I think the idea has promise, it just needs to be defined in such a way that a generic widget can be customised to do whatever the designer wants without having to add new code and rules to the site every time (which takes a while given the request queue). As ever the devil is in the details with this stuff.

tom wrote:

I think the idea has promise, it just needs to be defined in such a way that a generic widget can be customised to do whatever the designer wants without having to add new code and rules to the site every time (which takes a while given the request queue). As ever the devil is in the details with this stuff.

So how about a generic designer interface with basic add-on modules.  The entire "widget" would then be the customized collection of add-on's that the designer selects.  The basic modules would receive, process, and output information depending on their function.  But the "widget" interface would receive, output information in the same way, no matter what modules were included.  This is how chemical engineering programs like ChemCAD work.

For example, let's say you have 3 available modules: one module sorts in-game player names and information, another module is a flashing lights display, and another module is a counter/scoreboard.

Designer X could use just the first module and the last module to produce a live scoreboard.

Designer Y could use the first and second module to cause flashing lights whenever the lead player is overtaken by another in bonus.

Designer Z could use all three modules to cuase a flashing lights display whenever all players' scores are even or odd.

These examples are basically what I envision a successful "widget" to be: an area to compile modular functional building blocks that have the code already created.  This will help new map designers who have great ideas but aren't that adept at coding.

Thoughts?

AttilaTheHun wrote:

These examples are basically what I envision a successful "widget" to be: an area to compile modular functional building blocks that have the code already created.  This will help new map designers who have great ideas but aren't that adept at coding.

Thoughts?

I don't know how to code, and I'm not even sure what your x, y, and z examples work, but I think I like the part about "designers who have great ideas but aren't that adept at coding."  Can you clarify? When you say "aren't that adept", are you talking about those who have little ..or no coding ability?

M57 wrote:

AttilaTheHun wrote:

These examples are basically what I envision a successful "widget" to be: an area to compile modular functional building blocks that have the code already created.  This will help new map designers who have great ideas but aren't that adept at coding.

Thoughts?

I don't know how to code, and I'm not even sure what your x, y, and z examples work, but I think I like the part about "designers who have great ideas but aren't that adept at coding."  Can you clarify? When you say "aren't that adept", are you talking about those who have little ..or no coding ability?

Correct.  The modules would do the coding for you and would have a description of their inputs/outputs in plain language.  This way the designer could easily drag and drop them into the widget area.  The widget area could contain as many or as few modules as they wanted.

I'd see these being especially useful for motion before/after a turn that right now is being simulated by 1000s of factories (see Ed's Pong scoreboard).

AttilaTheHun wrote:

I'd see these being especially useful for motion before/after a turn that right now is being simulated by 1000s of factories (see Ed's Pong scoreboard).

Then I'm pretty sure we're on the same page.  The scoreboard is one of the first things that came to my mind as well.

For example, let's say you have 3 available modules: one module sorts in-game player names and information, another module is a flashing lights display, and another module is a counter/scoreboard.

Designer X could use just the first module and the last module to produce a live scoreboard.

Designer Y could use the first and second module to cause flashing lights whenever the lead player is overtaken by another in bonus.

Flashing lights are fine, but they are fluff IMO.  I'm much more interested in modules that affect gameplay, and though in an of itself your module #1 doesn't do this, combined with another module it becomes a critical component of a mechanism. 

E.g., Module "SB" is a scoreboard that counts the number of "critical" territories held. This information is linked to module "VC" which checks for victory conditions.  Let's say 6 of 10 critical territories need to be held to win the game.  Module "VC" makes this easy.  Just set the output of "V" to "SB">5.   Without modules, the only way I can think of to do this would be to create a capital for each player that is tied to 10C6 (or 210 combinations of six) territories which in turn create factories which take out all capitals.

In the above example, the output of module SB needs to be seen by players (it's a fogged game and the designer wants the suspense to build), so it requires a widget space (either on the board in a pop-out window).  Module VC needs no display.

The above two modules are linked in series, but suppose that we also want to have module "ADM", which is linked to the output of SB. Module ADM modifies the attack dice of a given territory owned by a player and kicks in when that player's SB output is >2.

These modules are effectively working in parallel.  Both VC and ADM require the output of SB but they operate independently of each other.

M57 wrote:

AttilaTheHun wrote:

I'd see these being especially useful for motion before/after a turn that right now is being simulated by 1000s of factories (see Ed's Pong scoreboard).

Then I'm pretty sure we're on the same page.  The scoreboard is one of the first things that came to my mind as well.

For example, let's say you have 3 available modules: one module sorts in-game player names and information, another module is a flashing lights display, and another module is a counter/scoreboard.

Designer X could use just the first module and the last module to produce a live scoreboard.

Designer Y could use the first and second module to cause flashing lights whenever the lead player is overtaken by another in bonus.

Flashing lights are fine, but they are fluff IMO.  I'm much more interested in modules that affect gameplay, and though in an of itself your module #1 doesn't do this, combined with another module it becomes a critical component of a mechanism. 

E.g., Module "SB" is a scoreboard that counts the number of "critical" territories held. This information is linked to module "VC" which checks for victory conditions.  Let's say 6 of 10 critical territories need to be held to win the game.  Module "VC" makes this easy.  Just set the output of "V" to "SB">5.   Without modules, the only way I can think of to do this would be to create a capital for each player that is tied to 10C6 (or 210 combinations) of factories.

In the above example, the output of module SB needs to be seen by players (it's a fogged game and the designer wants the suspense to build), so it requires a widget space (either on the board in a pop-out window).  Module VC needs no display.

The above two modules are linked in series, but suppose that we also want to have module "ADM", which is linked to the output of SB. Module ADM modifies the attack dice of a given territory owned by a player and kicks in when that player's SB output is >2.

These modules are effectively working in parallel.  Both VC and ADM require the output of SB but they operate independently of each other.

Excellent ideas...

I’ll propose that Widgets should be used to enhance/modify default game rules based on changing in-game conditions. This thinking may be too “in the box” or restrictive, but it's a start and it might be scalable. Perhaps there could be a different set of Widgets that aid in the "default" design of a board, but I would contend that for now those "more static" features can still be incorporated into the existing set of designer tabs.

Two or more Modules are necessary to make a Widget.  I’m thinking there could be three, or perhaps just two types of Modules.

• Counter Modules output a value or condition.
• Modifier Modules alter default board conditions or settings, either locally or globally.
• Display Modules publish the output of designated Counter and Modifying Modules to a single pop-out window (though perhaps this function could be incorporated into the above two modules).

Examples of Counter Modules:

1. Number of territories controlled by player
2. Total number of units by player
3. Number of units on a specific territory
4. Number of continents, factories, or “specifically identified territories” controlled by player
5. Identify owner of territory(s) (0 = Abandoned, 1 = Neutral, 2 = indeterminate, 3 = any player?, or by player color?)

Examples of Modifier Modules:

1. Dice Mod by territory, border, player, etc.
2. Victory Condition
3. Lift/apply fog by territory, continent, board, etc.
4. Activate/deactivate a territory and its borders
5. Activate/deactivate a Bonus or Factory (Ed N. would probably go nuts with this one)
6. Change one or all of the designer maps! (for instance in conjunction with the activation of new territories)

Examples of Widgets:

• The defense dice of a territory/border could be modified by +1 when its unit count exceeds a certain number. (C1)
• A territory and its borders could be activated once a specified territory is occupied by any player (E4), and new map could be simultaneously displayed to make the new territory "appear". (E6) 
• When a territory is occupied by neutral armies its defensive dice  are modified by -2. (E1)
• A territory(ies) becomes fogged when its related continent is controlled. (E3)
• A factory is activated/deactivated when a specific player occupies it. (E5)

By default, board conditions revert to their original state when a module condition is no longer met (There could be a checkbox that deactivates this feature for each module.)

Ozy, do you think you could turn your Wargear attack odds calculator into a widget that was available in-game?

I don't think you would need to make it a 'widget', and it sounds different from what M57 envisions for widgets.  Probably you could use greasemonkey to make it available.  I don't know much about that.  IIRC, IRoll11s created some greasemonkey plugins, so maybe he could say how hard it would be.  I don't mind looking in to it, but since it is a new area for me, it will probably be a while until I figure out how to make it work.

An Odds Calculator does not fall too far outside the definition of a widget as proposed (i.e., to "enhance/modify default game rules based on changing in-game conditions).  We just have to change the definition of a widget such that changing in-game conditions is optional.

For instance, you could use a Counter module that would output the data of a highlighted attack (how many armies, dice mods, etc) to a modifier module called Calculator, which would then output to a display (pop up window, on board, etc.).  I don't see any reason that a Modifier module must modify some territory attribute or game rule.  Just change the name of that class of module to something more vague like Engine. 

Suggestion:

It would be nice to have a Turn/Round counter available for each game board.  This would probably fit well with the widget concept.

The advantage of having this counter is to at-a-glance tell how many rounds or turns have transpired since the start of the game. 

+1

AttilaTheHun wrote:

Suggestion:

It would be nice to have a Turn/Round counter available for each game board.  This would probably fit well with the widget concept.

The advantage of having this counter is to at-a-glance tell how many rounds or turns have transpired since the start of the game. 

A turn counter is all well and good, but the reason to incorporate it into the land of widgetdom would be if you wanted to tie the turn count to an event or events.  I.e., on the 1000th turn all continental bonuses double, etc.

I don't envision widgets as data dashboards, at least not primarily.  Tom can throw all that info on the player stats part of the game page easily enough.

Edit:  After posting I looked at my earlier posts and realized that this is an example of a counter module that could easily be routed to a display module that has no effect on board conditions.  In essence, a little dashboard.