Victory conditions

[fcxSanya]

I implemented basic logic for checking victory conditions (only "conquest" for now). There is:

• new code in player class for buildings count tracking;
• EndGameManager javascript component, which check defeat/victory conditions by timer and changes player states;
• new code in session.js, which check state of current player and ends the game if player have been defeated/won:
• mockup gui page for game summary.

[Philip Taylor]

Thanks, this looks like a good approach to me. Some random comments:

In 3-or-more player matches, when one player loses they shouldn't be thrown out of the game immediately - they should be able to watch the rest of the match if they want. They shouldn't be able to order any units around, but they should be able to watch things and chat. (This particularly matters since we haven't fixed the issue where the game freezes as soon as one player leaves). Probably should apply to fewer-than-3 player matches too, so players can continue to chat and take screenshots etc after the end.

I don't think we necessarily want losing all structures to be defeat - it would be better to add a new Classes value like ConquestCritical, so the player loses when they have no critical entities left. (That class will probably include some subset of buildings and some subset of units, but I don't know exactly what, so it's okay to just put that class on all buildings for now.)

EndGameManager uses cmpPlayer.state and cmpPlayer.structuresCount etc - components shouldn't use properties of other components (since those are usually private implementation details), they should use some GetStructuresCount() etc method.

Rather than EndGameManager.GameTypes.CONQUEST, cmpPlayer.GameStates.DEFEATED, etc, I'd be happier with just using strings ("conquest" etc), because of the same issues with using cmpPlayer properties and because it's simpler syntax and because it doesn't provide any less error-checking (given that typos like EndGameManager.GameTypes.BOGUS will happily be accepted and return undefined so there's no compile-time error-detection anyway).

There should be some never-ending game type, for test maps (where we might only ever have one player - currently you win immediately). simulation/helpers/Setup.js currently handles default stance setup - probably game types should be handled similarly for now. (See <ScriptSettings> in e.g. maps/scenarios/Pathfinding_demo.xml for the settings data.)

[fcxSanya]

Replying to Philip:

Thanks for comments, Philip. I updated the diff:

In 3-or-more player matches, when one player loses they shouldn't be thrown out of the game immediately - they should be able to watch the rest of the match if they want. They shouldn't be able to order any units around, but they should be able to watch things and chat. (This particularly matters since we haven't fixed the issue where the game freezes as soon as one player leaves). Probably should apply to fewer-than-3 player matches too, so players can continue to chat and take screenshots etc after the end.

Now when player is defeated, all his units are reassigned to gaia player. Player get a message box with proposition to leave the game.

When player leave the game with exit button from active state it become defeated state.

Also now player always see summary screen when it leave the game.

I don't think we necessarily want losing all structures to be defeat - it would be better to add a new Classes value like ConquestCritical, so the player loses when they have no critical entities left. (That class will probably include some subset of buildings and some subset of units, but I don't know exactly what, so it's okay to just put that class on all buildings for now.)

I added this class to template_structure.xml and template_unit.xml, added counter for conquest critical entities and tracking logic for it to the Player component and changed logic in the EndGameManager.

EndGameManager uses cmpPlayer.state and cmpPlayer.structuresCount etc - components shouldn't use properties of other components (since those are usually private implementation details), they should use some GetStructuresCount() etc method.

I changed it to GetState/SetState functions.

Rather than EndGameManager.GameTypes.CONQUEST, cmpPlayer.GameStates.DEFEATED, etc, I'd be happier with just using strings ("conquest" etc), because of the same issues with using cmpPlayer properties and because it's simpler syntax and because it doesn't provide any less error-checking (given that typos like EndGameManager.GameTypes.BOGUS will happily be accepted and return undefined so there's no compile-time error-detection anyway).

I changed arrays to strings.

There should be some never-ending game type, for test maps (where we might only ever have one player - currently you win immediately). simulation/helpers/Setup.js currently handles default stance setup - probably game types should be handled similarly for now. (See <ScriptSettings> in e.g. maps/scenarios/Pathfinding_demo.xml for the settings data.)

I implemented "endless" game type and add it to Pathfinding_demo.xml, Pathfinding_terrain_demo.xml and Units_demo.xml.

[fcxSanya]

updated diff

[Philip Taylor]

(Sorry for being slow :-( )

This looks great! I just made some trivial changes:

• Changed CMessagePlayerDefeated to be a script-only message (Engine.RegisterMessageType("PlayerDefeated") (is that documented anywhere?)), since the engine doesn't need to know about it.
• Removed structuresCount since it's not used and I think the ConquestCritical thing should be sufficient.
• Made some minor stylistic changes to be more consistent with the existing code.
• Fixed the test failures (from running ./test_dbg).

Otherwise it all looks good. Haven't tested it extensively but we can do that over the next few weeks and see if there's anything important missing (it'd be nice to make the summary screen a bit less empty but I'm not really sure what to put there - do you have any thoughts on that?)

[philip]

(In [8234]) # Add victory/defeat conditions, based on patch from fcxSanya. Fixes #565.

[fcxSanya]

Replying to Philip:

(Sorry for being slow :-( )

You're doing really a lot of things for this project, so some things (like this patch) can wait sometimes.

Engine.RegisterMessageType("PlayerDefeated") (is that documented anywhere?)

I have been guided by this document: ​http://svn.wildfiregames.com/docs/writing-components.html, it seems like "Defining a new message type" section needs to be updated.

Fixed the test failures (from running ./test_dbg).

Oh, I wanted to update the tests, but I forgot.

Haven't tested it extensively but we can do that over the next few weeks and see if there's anything important missing

I tested it some time before submitting the patch, but if any problems will be found, then I'll try to fix them as soon as I can.

(it'd be nice to make the summary screen a bit less empty but I'm not really sure what to put there - do you have any thoughts on that?)

I think we can collect in the playtime a statistic, which is typical for all RTS games: summary gathered/spent resources, created/losted units/building etc, and display this in the summary screen. I want to create a new ticket for this and start working on it (also maybe I'll create a forum topic to discuss this). And probably a one more forum topic/ticket for other victory conditions.