In order to unit-test front-end properly, there needs to be a way to make sure, that random number generator always produces same numbers for the same moves both on mainnet and regtest. Hence, we need a way to manually feed seed into mainnet generator, and then use same for the regtest, which will make them identical

Implement basic inventory for characters as well as piles of loot on the ground. Allow characters to drop stuff and pick stuff up on their current location.

Items are just identified by keyword strings and an integer count for them.

It seems that DynObstacles takes a non-trivial amount of time in its constructor, basically filling up large std::vector<bool> instances with zeros. At least for empty maps, this makes up almost all processing time during syncing (and about 10ms on my system per block).

We can probably optimise this, e.g. by using some kind of sparse data structure where we split the large DynTiles vector into parts and only initialise those parts that are changed.

Thus, we should first create a benchmark for DynTiles, covering just construction, construction + setting and construction + setting + 10x more reading, or something like that. And then use that for proper optimisation.

When processing updates to multiple characters in a single move, we currently simply iterate over the update value in JsonCpp's iteration order. This corresponds to "sorted by key as string", since it uses std::map behind the scenes. That is well-defined and works, but I think it would be better to explicitly define the order in our own code; and perhaps do it sorted by ID as number, which is more logical.

Thus, we should update TryCharacterUpdate to first extract all the IDs and corresponding character-update-JSON-objects into a std::map, and then process all of them in the order defined by the std::map<IdT, Json::Value>.

This will in theory create a fork, for rare cases where e.g. a single player tried to prospect a single region with two of his characters in a single move, and their IDs have a differing order when seen as string vs integer. That will most likely not happen anytime soon, but we should still only apply the change on master and not the 0.1 competition branch.

With the new PendingMoveProcessor from libxayagame, we should implement custom logic to track pending moves in the Taurion GSP. The information we need (for now) is waypoints of characters that are being moved, as well as new characters being created.

The format of the pending data could be like this:

{
 "characters":
   [
     {"id": 123, "waypoints": [...]},
     {"id": 456, "waypoints": [...]}
   ],
 "newcharacters":
   {
     "name": [{"faction": "red"}, {"faction": "blue"}],
     "other": [{"faction": "green"}, {"faction": "green"}]
   }
}

Add the GPL v3 as license and add appropriate copyright headers to all relevant source files.

Names of characters are just a cosmetic at the moment and not used for anything important. They should be removed completely, so that characters are just tied to a Xaya name (the owner) and identified only by their IDs.

This also obsoletes #2.

In addition to attacks with a single, auto-selected target, we should also implement attacks that affect all enemies in their range at once. For this, we should be able to mark attacks as area: true. Then instead of target finding, we just need to mark if there were any targets in range (so we can retrieve those attackers later on again). And when dealing damage, we simply run through all L1 targets again.

A single random roll for all of the affected enemies is fine, so that the attack is "consistent" in any single turn. (I.e. the randomness affects the attacker side, not the target side.)

Spawning should be done in a random location (100 tiles around current centres). Also, if that location is already occupied (obstacle or other vehicle as per #4), then the nearest free spot should be chosen around it.

When a proper distribution mechanism for vCHI is designed and implemented, we need to remove the vCHI airdrop from #120 (at the latest before launch of the full game).

When prospecting a region, we should not only remember who did it, but also randomly distribute prizes. There should be a fixed set of prizes to distribute, so we need to track how many of which type are still available. We also need to define the probabilities for winning each type of prize.

Accounts should only be able to have 20 characters at any time. If they have that, then creating more will not work. Also transfers of characters will not go through if the recipient already has 20 characters.

We should keep a list of (target, attacker) entries, to keep track of who killed some character. On this list, we want all owner names of whom characters damaged the target in the last 100 blocks.

When a character is actually killed, then 1000 points (or some other value of it) should be distributed evenly to everyone on its current kill list. With those points, we should create a leader board of Xaya names.

Currently, Fighter is essentially a manual polymorphism implementation (a wrapper around either Character or Building handles, exposing the combat-related things with a common interface).

Instead of that, we should just use the new CombatEntity superclass to access common stuff, and then use std::unique_ptr<CombatEntity> as the handle type. FighterTable should probably stay, so that we can query the union of buildings and characters easily.

A lot of functions in the core game logic need general "context" information, like a BaseMap or Params instance, or the current block height. Rather than pass around / store those things in an ad-hoc fashion whereever it is needed, we should put all that basic read-only data into a Context class and just expose that one everywhere.

The Context should hold (initially) a BaseMap, Params, the block height and the block time. For processing pending moves we should be able to create a Context that does not have a known time (and just CHECK-fails when the time would be accessed).

Currently, arbitrary strings can be used as character names (excluding the empty string and names already in use). We should probably restrict that somewhat, at least with some maximum length. Probably we should also exclude unprintable characters and stuff like that.

In dd41ab2, we set the cost of a character down to 1 CHI for testing of the work towards 0.2. Before we finalise that version for the next competition, we should decide on the "real" cost a character should have then and update it again.

When a region is prospected, we should randomly select one type of resource that can be found there, and randomly determine how much there is. Both may depend on the physical coordinate of the region. Then this is stored together with the block height when it was prospected in the region data (replacing the current storage of an "owner").

Also, after 5,000 blocks (or some other length of time) has passed and all resources are gone, it can be prospected again.

Prizes will work as items instead of being tied to regions, as described in #49.

Buildings should be able to "take part" in combat, just like vehicles. They will have HP (shield / armour) and may as well have attacks (for turrets at least). We can use the centre coordinate for target distance purposes.

When a building is destroyed, then all characters in them + the vehicles they are in will just die / be destroyed. All inventory items (from building accounts as well as character inventories) will be combined into a single "building inventory", and then each position will have a 30% chance to drop on the floor, rather than being destroyed as well.

For placing buildings in the frontend, we need a new state-less RPC that returns all shape tiles for a given building type + centre + rotation.

With the latest Xaya update that allows for multiple name_updates per block per name - we can make the Taurion frontend only control one name (as they no longer need to wait for pending moves to be processed before they can do another action with a name).
This may have some very small disadvantages over allowing the user to control multiple names (such as lying and tricking people) but it should make the game more personal and immersive. You are then that "account", and all your stats/skills/reputation can be built up with that account.

With that, we should also make each name be locked to one faction. This will further increase immersion and fun factor. It does not seem right/logical for 1 person/account to play 2 different factions simultaneously.
This then has the small disadvantage that someone could create a client which allows it to control more than 1 name - thus being able to play more than 1 faction.. but again we think the positives outweigh the negatives.

Players can of course also just run multiple Taurion Unreal front ends if they want to (as is done in many MMOs).

Especially for movement in a convoy, we should allow sending the same update command to multiple characters. E.g. by changing the character-ID-string to a comma-separated list of IDs:

{"c":{"1,5,42":{...some command...}}}

Before starting the 0.2 competition, we need to update the list of prizes and their probabilities to what it will be in the actual competition (for now, it is just gold/silver/bronze with the chances of the last competition).

The findpath RPC method is currently completely decoupled from game state, but it should take dynamic obstacles into account (at least buildings). This needs some thought, as it is good to have the RPC decoupled - so that e.g. light clients can run path finding locally instead of having the Charon server do it.

Perhaps we could make it so that you have to pass in the set of buildings first, or set it with a separate RPC in some "global state". That is likely good enough for what we require of the RPC (since proper pathing will be done in the GSP itself anyway), and would work for light clients.

To actually acquire prizes in the upcoming competition, players will need to bank their "prize items" as well as resources. We should design the detailed logic of how this works and then implement it.

For easier set up of testing scenarios, we should implement a "god mode" that allows character teleports in regtest mode only. This would be admin commands (so only someone controlling g/tn can do it as an additional layer of protection), and only be interpreted on regtest mode.

With that, we can greatly simplify and speed up the moveCharactersTo Python function for integration tests and make it less flaky.

A full mining point "set" for the second competition should require 20 (instead of 200) for each resource. The base amount of resource found should be 7-14 (instead of variable based on resource type) for all raw materials.

drop and pickup properly reported in pendings, while 'start mining' action is not reflected in pendings at all

We should stop giving out prizes for prospecting when the competition ends. I.e. turn off prizes when the first block nTime is seen that is beyond the timestamp 1571148000.

In #52, we allow reprospecting of a region after 5,000 blocks without any more conditions. After we have implemented mining of resources, we should allow reprospecting only when all resources have actually been mined from the region.

We should add a hardcoded test building on the map (or maybe allow god mode to place buildings), and then implement entering and leaving buildings for characters. It should work like this:

• Each building has a centre coordinate (and some shape around it, but that is not relevant yet).
• A character can have the "intent" to enter a given building, which can be set with a move and will be stored in the character state.
• When a character with intent to enter a building is within L1 range X of the building's centre, then it will automatically leave the map and enter the building.
• When inside a building, no combat is happening. The character is "off the map".
• Through another move, a character can leave the building again. This will put them onto a random free spot within radius X, like spawn (overflowing to further away if needed).
• X is a number that is fixed per building type.

@xaya:

for the dmg
for 10 range weapon, please make 1 to 20 dmg
for the close range, make 5 to 30

In #52, we included just some dummy resources so that we could implement and test the basic prospecting framework. For the upcoming second competition, we need to fully define the stats and specs of mine-able resources:

• What types of resources there are.
• How much cargo space each type uses.
• How much cargo space a character has.
• Where and how much the resources are distributed on the map when prospecting.
• After how long a time a region should be prospectable again.

The fame system should not allow fame to be taken from the same person by the person that killed them with 2 hours (or equivalent).

This is to reduce someone losing all fame in just 1 battle.

However - to add some complication..

If 2 players attack a person who has already had fame taken (within 2 hours) from one of the attackers, then the victim still loses full game (100), but the person who had not received fame yet only gets their "share", in this case half (50).

So essentially some of the fame vanishes.

Vehicles should act as obstacles to other vehicles of the same faction, so they are not allowed to stack on a tile (i.e. each tile can have at most one vehicle of each faction on it).

Near the centre of the map, prospecting should not yield any prizes.

The final obstacle map for movement in Taurion is built up from two parts: The base obstacle layer and dynamic obstacles, which can be buildings and the vehicles of your own faction.

Movement consists of two phases: If a character has only waypoints (because they just started movement or just reached a previous waypoint), then we run path finding to compute the exact steps to the next waypoint. If a character already has such steps, then we just follow them.

Both of these need the obstacle map. But we should change the obstacle map for path finding only to only consist of the base map and buildings, but not vehicles.

This has two advantages:

1. In the current system, if a character's next waypoint is blocked when path finding happens, then the character will simply stop. That is not necessary if the block is by a vehicle, because that may very well be gone by the time the character reaches the waypoint.

2. Making the path finding independent of vehicle positions makes it easier to parallelise this heavy computation in the future.

In the end, vehicles would still act as obstacles, because they will be taken into account during the "follow the precomputed path" phase anyway.

Define more of the real building types, based on the shape data. Energy plants are ignored for now. Enter radius for the non-ancient buildings should be set to "5 + max (abs (tile coordinates))".

The common buildings provide all services (like a command centre).

There should be some pre-defined starter zones (e.g. in roconfig or new map data), associated to some faction. Other factions cannot enter the area at all (it acts like an obstacle to them). The same faction is faster by some factor within them.

Instead of not giving any prizes in a 2k radis around the centre, we should reduce the chance for prices by 50% in a 3k radius.

For mining found resources on a region, each character should have a "mining speed" as stat - just how many units of the mine-able resource per block. Then, we need a new command "start mining" - this will just make a character stop if moving, and from then on mine the resource where they are until the inventory is full or the resource is depleted. If a character starts moving, mining is stopped as well.

We should allow the roconfig data to depend on the chain the game is running on. In particular, for regtest it should merge in the test item types, but keep them out for mainnet and testnet. It could just be another instance that gets merged in (with additional types and parameter overrides) on regtest.

When this is done, we can also use it to migrate some (or maybe all?) of Params to values in the roconfig proto instead.

"inventory" : -{
"fungible" : -{
"silver prize" : 1
}
},

Need also to report total volume, as it might differ now for different item units

https://github.com/xaya/taurion_gsp/blob/546e45aa899e96ba22c6d66857999b1174993e9a/proto/roconfig/items.pb.text

"prize" missing for fungible prizes, hence it fails at:

F1219 21:43:55.652307 18640 character.cpp:227] Check failed: mit != itemData.end () Unknown item in character inventory: Defender shotgun prize

adding ' prize' to the fungible item names at items.pb.text fixes it

Characters should be able to set a reduced speed while moving, e.g. to allow faster vehicles to escort slower ones. This can be as simple as adding an explicit "set speed" command, that would be in effect until the next waypoints are set. That could then be a second proto field besides speed, and movement would always use the smaller of the two values.

I thing, at move moveprocessor.cpp, here:

      const auto mit = itemData.find (entry.first);
      CHECK (mit != itemData.end ())
          << "Unknown item to be transferred: " << entry.first;

its possible to break GSP, if we push name update with drop/pu item with some random unsupported name. If will fail this check and broke GSP. Not 100% sure tho

Prizes should be given out as (cargo-space zero) items. So instead of tracking prizes won through data stored with the region state, we just "mint" a prize item and put it into the prospecting character's inventory upon discovery.

When the owner of a building changes the configuration (e.g. service fees or who is allowed to use it), this should probably take effect only after a certain amount of time. Otherwise owners might be able to trick others into paying more than necessary, or at least making a journey in vain.

For that, we could replace the config data in the building proto with an array of (block height, config) pairs, and look up the config to use based on the current block height. (We can then also clear out parts that are already in the past.)

Needed, when building for windows, same as in libxayagame:

CXXFLAGS+=" -DGLOG_NO_ABBREVIATED_SEVERITIES"

Some items and vehicles are specific to factions. This should be specified in the roconfig for them, and there will be certain restrictions on their usage by other factions.