Create account / Log in

VASSAL 4 model description

Discussion area for the development team.

Moderators: uckelman, Tim M

Re: [messages] [Developers] Re: [Developers] Re: VASSAL 4 mo

Postby bdgza » July 20th, 2011, 10:56 pm

uckelman wrote:> In VASSAL, when playing FtF, the other player is the master with the
> model and the other player is a slave? Or does both have their own
> models that are kept in sync? Or (very unlikely) is the model completely
> separated and shared between the clients on the server side?
>

We could do any of those by having Views which supported the right
operations (such as querying a remote Model). I was supposing that each
user would have a Model locally, though, as rendering in the standard
GUI View will need to retrive quite a bit of information from the Model.

--
J.


It would be best to keep syncing the model between all players, as the current VASSAL does. If the host crashes everyone else still has the complete gamestate (to save or continue after the crashed player recovered). What perhaps could be improved upon is the implementation – detection of sync-loss or network failure. It's rare, but it has happened that games have lost sync. Quicker notification of and more information about loss of network connection with other players and/or the VASSAL server would be nice.
bdgza
 
Posts: 311
Joined: February 26th, 2010, 10:51 am

Re: VASSAL 4 model description

Postby Brent Easton » July 21st, 2011, 12:31 am

If I understand Joel's thinking, we will be looking at a model where any players PC can become a server. Sort of like online multi-player games where one player sets up as a server and everyone else connects to him. The Central Vassal server would then become more of a 'tracker' that lists what player servers are running (and marked as public) and what games are being played. Since every Vassal instance can potentially be a server, then if the current server goes down, the other Vassal instances should be able to negotiate with each other and 'choose' a new server.
User avatar
Brent Easton
 
Posts: 3090
Joined: December 21st, 2007, 3:06 am
Location: Berry, NSW, Australia

Re: VASSAL 4 model description

Postby Brent Easton » July 21st, 2011, 12:35 am

Re: Properties. Some properties (Thinking Calculated Properties from 3.2) will be un-cachable. It will not be possible to create listeners on all items that may affect theire value. Apart from this, I have no problems with Property caches/indexes in general as long as the Listeners are got right.
User avatar
Brent Easton
 
Posts: 3090
Joined: December 21st, 2007, 3:06 am
Location: Berry, NSW, Australia

Re: VASSAL 4 model description

Postby Brent Easton » July 21st, 2011, 12:55 am

Re: Actions. From the sound of it, you are suggesting that all actions will be implemented by writing code/scripts?

I don't quite understand how you intend to implement the variety of behavior we have now. I suspect a lot of the basic traits could be folded into one mega-structure (eg. delete/clone/mark when moved) etc. How will other behaviors be added to a counter and how will they interact with each other. While the Decorator pattern has drawbacks, it provides and extremely rich set of interactions (eg. a rotatatable counter with a seperately rotating turret, all with a label that does not rotate).

Presumably one of the properties the model of a counter will have to provide is an image that represents the current view of the counter? This image may be different on different clients, depending on counter ownership etc.
User avatar
Brent Easton
 
Posts: 3090
Joined: December 21st, 2007, 3:06 am
Location: Berry, NSW, Australia

Re: [messages] [Developers] Re: VASSAL 4 model description

Postby uckelman » July 21st, 2011, 9:13 am

Thus spake Brent Easton:
> If I understand Joel's thinking, we will be looking at a model where any
> players PC can become a server. Sort of like online multi-player games
> where one player sets up as a server and everyone else connects to him.
> The Central Vassal server would then become more of a 'tracker' that
> lists what player servers are running (and marked as public) and what
> games are being played. Since every Vassal instance can potentially be a
> server, then if the current server goes down, the other Vassal instances
> should be able to negotiate with each other and 'choose' a new server.

Good summary. This is the idea.

--
J.
User avatar
uckelman
Site Admin
 
Posts: 8798
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: [messages] [Developers] Re: VASSAL 4 model description

Postby uckelman » July 21st, 2011, 9:14 am

Thus spake Brent Easton:
> Re: Properties. Some properties (Thinking Calculated Properties from
> 3.2) will be un-cachable. It will not be possible to create listeners on
> all items that may affect theire value.i

I don't see it. Can you remind me of how Calculated Properties work
again?

--
J.
User avatar
uckelman
Site Admin
 
Posts: 8798
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: VASSAL 4 model description

Postby Brent Easton » July 21st, 2011, 9:30 am

A Calculated Property is a mathematical expression using the values of other properties, some of which may be dynamically generated

Here's an example:

Strength + Will + GetProperty("Power"+Level)

The resulting value is the total of the Strength property plus the Will Property plus one of the Multiple PowerX properties, depending on the current value of the Level property.
User avatar
Brent Easton
 
Posts: 3090
Joined: December 21st, 2007, 3:06 am
Location: Berry, NSW, Australia

Previous

Return to Developers

Who is online

Users browsing this forum: Google [Bot] and 2 guests