Variant versioning, variant updates, brain meltdown

[Martin Bruse]

So, I guess we should try to figure out a way to simplify updating variants.

To start with, the different parts of a variant that cause different problems when you change them are:

- Adjacency maps

- Province names

- Nation names

- Special rules

I believe that adjacency maps we can just update. Nobody pays us for this, and if old games didn't adjudicate correctly that's sad but nothing I'll lose sleep over. Old games would still be possible to see without things breaking, which is what I care about.

The same probably goes for special rules - nothing about them would prevent old games from rendering properly.

Province and nation names, however, are trickier. They are saved both in the adjudicator (which you want to update), in the database (which will cause problems if you try to view an old game with invalid names), and in the client (in the cached variant list) where it will prevent a clean update even if you update all old games in the database.

Someone brave should try to run the server locally, and see what happens if you change province or nation names, while trying out combinations of updated and non-updated databases and local variant caches.

I suspect lots of things will break - the server, IIRC, uses the nation name a lot to pair the game member to units, supply centers, and chat channels. Maybe even in more places? And the client does similar things as well, even if I don't know how much it actually uses the cached variant map for this.

Maybe, just maybe, updating the UI to handle long nation names are preferable to all this hassle? :)

[Chris Babcock]

Variant versioning needs to happen. I started looking at nJudge code 10 years after the platform peaked and started coding for it 20 years after it originated. By that time, 80% of the open bugs were variant related. Community policy was to never mark anything "Will not fix" (not to mention the policy of not fixing anything), but circular dependencies between the judge behavior and the two external utilities sites meant that *something* would need to be broken. You know how long droidippy lasted compared to your expectations? Diplicity is much more sound architecturally than droidippy or nJudge. At this point, it will easily be in use 30+ years from now. You might as well run with it.

Chris

--
You received this message because you are subscribed to the Google Groups "diplicity-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diplicity-de...@googlegroups.com.
To post to this group, send email to diplic...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Martin Bruse]

Yeah, variant versioning is probably the good solution, but it feels extremely cluttery :(

Every time I try to think about how it should be incorporated in godip and diplicity I get vertigo.

Let's explore it though. What parts of variants need to be versioned, and why?

[tttppp123]

I agree - variant versioning is the right solution here.

In addition to your list I would include:

- Units

- SVGs (Assuming viewing the old version is important)

- Order definitions

- Variant name?

> ...if old games didn't adjudicate correctly that's sad but nothing I'll lose sleep over

This is already the case to an extent. We have fixed several bugs that were 'exploited' before the fix.

For names of provinces, nations, etc. we could potentially add some indirection. E.g. Include a new optional field "display name" which is distinct from the id of the province.  Possibly this would help with Chris' idea of supporting multiple synonyms for names of things.  Probably this is a bit of a hack fix though - I think it would be better to embrace versioning.

Versioning will also be useful if we want to encourage variant designers to use the platform.  We already include a variant version field, but perhaps we also should have a code version field too?  Vdiplomacy has this, and it would help in the hypothetical case where we want to change the names of nations for a technical reason. :-P  (BTW I've now made chat more usable by ellipsis-ing long nation names).

[Martin Bruse]

I agree - variant versioning is the right solution here.

Probably yes, but the complexity it adds has a big cost, both up front and long term. Is it worth it? How important _IS_ excellent variant support (which variant versioning supposedly supports)?

In addition to your list I would include:

- Units

- SVGs (Assuming viewing the old version is important)

- Order definitions

- Variant name?

Right.

For names of provinces, nations, etc. we could potentially add some indirection. E.g. Include a new optional field "display name" which is distinct from the id of the province.  Possibly this would help with Chris' idea of supporting multiple synonyms for names of things.  Probably this is a bit of a hack fix though - I think it would be better to embrace versioning.

Yeah, slightly hacky, and it shouldn't be that often we need to do it. But for translation purposes we would still something like that.

Maybe when we build (if we build) i18n support this will solve itself.

Versioning will also be useful if we want to encourage variant designers to use the platform.  We already include a variant version field, but perhaps we also should have a code version field too?  Vdiplomacy has this, and it would help in the hypothetical case where we want to change the names of nations for a technical reason. :-P  (BTW I've now made chat more usable by ellipsis-ing long nation names).

Code version field?

The ellipsis you used, some long names become somewhat hard to understand when they become so short.

We should probably solve the problem in some better way with a smarter layout, but I can't think of what right now.

[tttppp123]

Maybe we should provide different length nation names for clients to use:

Full: Principality of Kiev
Short: Kiev
Abbreviation: P

For most variants full and short would be the same, but abbreviation could be a single character abbreviation (potentially using Unicode). As a suggestion, maybe 'short' could be limited to 10 characters?

Colour coding would go a long way to helping people link the map with other screens in the UI.

[Martin Bruse]

The "short" version already exists, of a kind: In the chat notifications, the system (don't remember whether in server or client) creates "shortest unique abbreviation" to use when creating notification titles.

I also thought that it would be useful if you could click a province in the map, and get a toast or similar with the unit and SC owner. Also to simplify understanding which color is which.

[Chris Babcock]

Inline reply. Old school. 

On Tue, May 29, 2018, 1:55 PM Martin Bruse <zond...@gmail.com> wrote:

I agree - variant versioning is the right solution here.

Probably yes, but the complexity it adds has a big cost, both up front and long term. Is it worth it? How important _IS_ excellent variant support (which variant versioning supposedly supports)?

Variant players are often core players who need more variety to remain engaged in the platform.

Variant designers drive traffic. They bring established players they know from all platforms to the platform where they are testing their variants. They often become developers, bring developer partners from other platforms, or renew interest in the platform among current developers. They are an unending source of interesting challenges.

Variant support didn't make sense on droidippy where player attrition and infrastructure costs were insanely high, but Diplicity is architecturally sound in both its processing and social model. Most enhancements are going to be around long enough to have sufficient cumulative impact to justify the work, it's just a matter of where they fit in the game scheme of what needs to be done first.

In addition to your list I would include:

- Units

- SVGs (Assuming viewing the old version is important)

- Order definitions

- Variant name?

Right.

For names of provinces, nations, etc. we could potentially add some indirection. E.g. Include a new optional field "display name" which is distinct from the id of the province.  Possibly this would help with Chris' idea of supporting multiple synonyms for names of things.  Probably this is a bit of a hack fix though - I think it would be better to embrace versioning.

Yeah, slightly hacky, and it shouldn't be that often we need to do it. But for translation purposes we would still something like that.

Maybe when we build (if we build) i18n support this will solve itself.

Or you can make i18n support easier to build with this decision.

The design I'm familiar with includes:

A 3 character abbreviation or token that is used internally for all storage and transport mechanisms. These abbreviations are NOT localized or case sensitive, but case has been overloaded for application specific purposes on some platforms. (Damn C coders!) 

A long name that is preferred for output. 

A shorter name that is used for output when space constraints apply that are not severe enough to require abbreviations.

A list of aliases that is used only for input processing in NLP.

So, yes. An internal representation that is expanded to display in a context sensitive manner is desirable. This can either be implemented as part of i18n or as preparation. Media size and TTS support are desirable outcomes.

Versioning will also be useful if we want to encourage variant designers to use the platform.  We already include a variant version field, but perhaps we also should have a code version field too?  

Since the variant version field already exists, the only addition necessary is patch level. This is for cosmetic changes or any change necessary for correct operation of the variant on the server that does not represent a change in the player experience.

Another desirable here would be a field to describe the development status of the variant - development, testing, stable, obsolete (or whatever is comfortable with the development community) - and CHANGE LOG. 

Diplicity is a platform, which means supplying the platform tools necessary for those building on it to do the job right. It's an application of the Golden Rule from developer to developer. You build the tools you'd want to have available. 

Chris