pickardj79 / bga-galaxytrucker Goto Github PK

A player can choose not to take the rewards from an enemy card and not lose the specified number of travel days.

Obviously type crew is correct, and sth in the backend is not working as expected.
Unexpected error: loseContentChoice: type (crew) does not match expected type (cell) (at loseContentChoice line 787)! This shouldn't happen. please report this bug with the full error message.

Currently this seems to be not the case, meaning you can look at some cards during the build phase, but the shuffling and flight deck aggregation happens in stPrepareFlight after the buildPhase currently and not respecting the seen cards by the players.

When you leave some goods at the planet because you don't have space or don't want to load it - game throws an error because x == -1. Not sure what x means there but it's definitely a correct situation which need support.

Currently if we need a backend constant (type) to be understandable by code and by dev we define a frontend constant which is a copy of a backend one. We need to find a way to use a single source for constants and they are to be defined everywhere automatically

Implement Combat Zone card

Pirates should fight all players, in player order, and then rolls happen after the pirates are defeated or they have fought all players.

MY NOTES:

GT_StatesCard::stEnemy goes in player order to determine cannon strength, changing to 'powerCannons' state if the player needs to make a choice or 'enemyResults' otherwise. galaxytrucker.game.php::stEnemyResults uses GT_Enemy::fightPlayer to determine outcome of fight and change to appropriate next state (give reward, apply penalty).

A fixing change might be to test win/loss/tie in GT_StatesCard::stEnemy (instead of going to 'enemyResults' state). In all cases record win/loss/tie in database for the player. On win go to enemyResults state. On loss/tie go to next player. Then stEnemyResults can go through players (in turn order) and apply the appropriate result, reusing die rolls for players that have lost (TBD how to do this). Probably want to move this logic to GT_StatesCard for organizational purposes.

Instead of putting "require_once" to each file it's possible to do automatic requiring on demand

There are some lexemes in the code without clienttranslate - we need to wrap them. Also there are couple of lexemes which are constructed using small parts of text. It's against BGA rules about translations - https://en.doc.boardgamearena.com/Translations and could not work for some languages with different word order

When a ship is damaged in such a way that there are multiple viable parts, the player must choose which part to keep.

This is intended to be handled by state STATE_SHIP_DAMAGE and various other states send the game into this state.

There are notify* call sprinkled throughout the code. This makes it hard to look through them all to see if they're consistent (consistent tone, language, etc). Moving them to a single module would make it easy to audit them.

I think this would consist of a function for each distinct notify message. The interface for each would be:
function X($params)

An example might be:

function hazardMissed($params) {
    $game->notifyAllPlayers('hazardMissed', clienttranslate('${type} missed all ships'), $params);
}

// Invoked in the calling code with:
GT_Notif::hazardMissed([ 'hazResults' => $hazResults, 'type' => ucfirst($hazResults['type'])]);

An alternative interface might be to require all params, so the interface is explicit and it's easy to tie what the front end is getting with the back end. The interface for this example would be (this is a case with an optional parameter, which is handled correctly by the front end):

function hazardMissed($hazResults, $type, $player_id = null) {
    $params = [ 'hazResults` => $hazResults, `type` => ucfirst($hazResults['type']) ];
    if ($player_id) ... // code to add player_id
    $game->notifyAllPlayers('hazardMissed', clienttranslate('${type} missed all ships'), $params);
}

// Invoked in the calling code with:
GT_Notif::hazardMissed($hazResults);

This second interface is more verbose but I think I prefer the explicitness of knowing exactly what params are being passed to the frontend for each notif.

@kuwizard - let me know if you think this is a good idea

In galaxytrucker.js we have a looooooong list of dojo.subscribe calls + this.notifqueue.setSynchronous calls.
All of them actually are different just by notification name and delay parameter. We can create a simple array of arrays ['name', int] and process all items from this array in a loop.
Again, it's the idea which is implemented in Bang! and I find it concise and convenient.

With the planets card, the player chooses which planet to land on, then the game changes to a place goods state. The additional backend state change is unnecessary (more complicated) and prevents the player from being able to undo their planet choice.

With this example of client-side states, look for other places where they can be used to simplify the code and improve player experience.

There's a great DB wrapper in BANG!, I would like to reintroduce it here. It really helps with standard operations.
And also as a result of this ticket no raw SQL should be seen anywhere but inside this helper

Conditions to check for when a player has to give up

• Give up if no humans (check anytime a component is lost)
• Give up if lapped on flight board
• No engine power for an Open Space card --> already implemented

Additionally, a player may give up at any time except in the middle of a combat card.

Check rules for giving up (1/2 credits for cargo)

If all players have given up then the round ends. If only one player has not given up, then a number of cards can be automated / skipped (combat, sabotage, spending batteries on engine for open space if speed > 0).

When calling $plyrContent->loseContent($lostCrewIds, 'crew', null, true); with a list of crew ids containing human and aliens (e.g. 2 humans, 1 alien), the BGA log only shows the removed human crew (2 small human crew pictograms) but no alien pictogram.

Power cannons currently only allows selection of which batteries/cells to use to power the cannons. Then it is assumed that forward-facing cannons are powered first, followed by side-facing (check this). However, a player may wish to use a lower-valued cannon to, for example, force a tie with an Enemy and require the next player to fight (and possibly lose, suffering the penalty).

Let's move to more OOP approach and as a first step we need to convert all event cards (e.g. in modules/GT_Hazards.php) from arrays to proper objects.
Also as a part of this ticket let's start creating constants for hazard types as they are pretty much countable.