I find the gamestate very redundant in some aspects, look at where I commented bellow.
Also, only one building can be placed at each map coordinate[][], why save a list of buildings.
“gameMap”: [
[
{
“x”: 0,
“y”: 0,
“buildings”: [
{
“health”: 5,
“constructionTimeLeft”: -1,
“price”: 20, //We know this by game config
“weaponDamage”: 0, //We know this by game config
“weaponSpeed”: 0, //We know this by game config
“weaponCooldownTimeLeft”: 0,
“weaponCooldownPeriod”: 0, //We know this by game config
“destroyMultiplier”: 1, //We know this by game config
“constructionScore”: 1, //We know this by game config
“energyGeneratedPerTurn”: 3, //We know this by game config
“buildingType”: “ENERGY”,
“x”: 0, //We know this by cell
“y”: 0, //Also know this
“playerType”: “A” // We know this by Cell Owner
}
],
“missiles”: [
{
“damage”: 5, // We know this by game config
“speed”: 1, // We know this by game config
“x”: 3, // We know this by map [x][y]
“y”: 2, // We also know this
“playerType”: “A”
}
],
“cellOwner”: “A”
},
I am not critizing anything just giving insight/suggestions around that logic.
We realize that there is repetition in the state, but this is to cater for a variety of different approaches in the various languages. For example, if you filter the json state to give you a list of just buildings which will be easier to iterate, then you might lose the cell information. We are also keeping our options open for future add-ons to the game since we plan to update the game rules after each of the two first phases.
Also, the things you mention are known via the game config, are there because your bot can’t read the game config each round.
I hope this clarifies our decisions a bit better. If you are still unclear or want to know more about a specific thing, don’t hesitate to ask further.
Thank you for the reply.
The thing I mentioned “game config” = game detail in the state.json file. My bad.
Awesome thanks for the heads up for the update of rule after each phase!
I think these should not be removed, If they are removed I generally will have to hard code it in somewhere and since they can change, I’d be happy if they stay in in the state file
Having redundant info in the state.json causes no harm and does in fact make it easier to set up your game state, so I kindly request that the file be left as is.
People have varied methods for reading this file and use it in different ways, so let’s keep it open and accessible.
To clarify, we will not remove this information from the “buildingStats” field.
Only plan on removing it from the buildings already on the map, but if too many bots are already using this info, it will cause more harm than good if we remove them
I kindof use bothl as an example I use weaponcooldown in the building info to get the cooldown while the buildings cooldown tells me the current cooldown of that building. Please don’t remove these