3. Game Field Logic

For all tech interested people here you can find the detailed description how the gamefields are stored.

The problem with a board logic like Ludo games is that you have different paths for every team on the same game board. In software development the first integer is mostly 0 so in gaming we can look at the start field for team red as field 0. Now if we look at other teams, field 0 will have a completely different world location (x,y,z) than for our team red. So for the most efficient movement calculation we decided to give each game field in the world grid a "GameFieldProperties" object.

The GameFieldProperties object contains a HashMap with all the different teamIds the field has for each game team. For example the gamefield at (0;0;0) in the world grid is the start field for team red, so it has the teamId 0 for red, but a completely different teamId for blue.

Internally this is represented as a json object which looks like this:

{
  "teamFieldIds": {
    "blue": 12,
    "yellow": 2,
    "green": 32,
    "red": 22
  },
  "garageForTeam": "-",
  "teamEntrance": "-",
  "turnComponent": "-"
}

You can see that in the properties object more information about the game field is stored, like if the field is a garage field, a team entrance or if it has a turn.

The gamefield object itself has even more data stored inside an looks like this:

{
  "arenaId": "0cdfb582",
  "world": "worldName",
  "x": 0.0,
  "z": 0.0,
  "properties": {
    // Represent GameFieldProperties object properties here
  },
  "isGarageField": false,
  "isTaken": false
}

The data indicates if a field is already taken by an entity. This is needed in the movement code to decide if an opponent holds the goal position of your current team.