create user ok: status ok, user name
create user bad: status bad, reason
login ok: status ok, user name, player name, player id
login bad: status bad, reason
logout: status ok

teď některý z těch operací hodí 500, některé nějaký jiný kódy etc. s tím nemohu prakticky nic dělat..

• passively regenerated life per tick
• repaired life and cost per tick with the repair command

also add repair type of command

• calling database procedure

Any particular reason why we are using logrus

From https://github.com/sirupsen/logrus:

Logrus is in maintenance-mode.

Check out, for example, Zerolog, Zap, and Apex.

We could switch to Zap (we use it at work and have no issues with it).

https://github.com/uber-go/zap

should decommission return any money?
something like half of the buy cost multiplied by current life fraction?

@curusarn wrote:

Hmm, I don't see a reason why not. It can give people ability to change strategy mid game. I don't see any possible abuse because even with getting half your money back it's expensive to do this.

We might see someone rush to build a "shipyard" and sell their mothership to get a lot of money at once. This assumes that there is a cheap enough "shipyard". And I don't really think we mind people doing this.

I would not like it if you could construct new ships at one planet, buy resources, send the ship elsewhere, sell the resources, and sell the ship with a profit, instead of flying it back.

What to do with the current cargo on the ship?

Should presence of another shipyard be required for the decommission?

in DB column is tinytext in api it is array of numbers - what is correct?

some thoughts? how many ships and resources should players afford at the beginning?

due to some recent changes in the database structure, combat and trading reports have ids that reference ships or wrecks.
it would be nice to add wrecks to the /api/data endpoint.
specifically their owner and position.

I thought it would be nice to have blocked parts of the map - it makes ship distribution harder and may also force huge battles for some narrow passes.

But navigation would be hard, and it is probably not worth it.

But we may introduce (in later stages of the game) AI, which would guard some parts of the map. Like a turret. This could lead to similar behavior changes

should we add command for repairing ships?

@curusarn wrote:

TL;DR: Imho we should. No having repairs could make aggressive strategies too easy and too powerful. And if there are too many ships dying then trading becomes very hard.

Imho it makes sense to either:

allow any ship to repair itself anywhere (this way the repairs would have to be kinda slow so that it's not very easy to repair all of your ships)
allow shipyard ships to repair other ships (this way the repairs could be super fast because they are constrained by number of shipyards player has)

Extra notes:

Dangers of no repairs
Imho could be hard to defend yourself effectively. E.g. someone can send ships to attack your mothership or cargo ships and gradually kill them because of lack of repair. It could be really hard to write a meaningful defense against these "wear down" strategies. If there are too many ships dying then trading becomes very hard.

Issues with automatic passive regeneration
I was considering if automatic regeneration amount would work. It could be hard for us to tune the regeneration amount imho. Also making ships "wait" so that they repair in safety without setting any command on them is weird - it requires bots to remember that they have the ship waiting on purpose.

Should repairs be paid?

Create OpenAPI (Swagger) specification for the main game server.

make planets slowly orbiting their star.

what do you think?

There should be a server which will store all the historical data with timestamps).

This is useful for debugging and analyzing the bots (e.q after night)

Those should be possible to visualize and if we have a play button to display events in high fps (like a movie) it would be perfect.

allowing additional players to connect to the game "in the middle of a season" can bring significant inbalance into the game.

possible solutions:

• allow registering new players at any time - their new spaceship spawns somewhere
  • newly spawned players ship can greatly hurt some existing players giving unfair advantage to others
  • great for prototyping
• allow registering new players at any time - picks one from pregenerated spaceships
  • pregenerated spaceships are sitting in the game obstructing some areas
  • newly connected player can still hurt some existing players more than others
  • great for prototyping
• have dedicated registration time before the season starts
  • this is the most fair
  • not good for prototyping as it requires to wait for the whole season to finish
  • possible improvement: shorter seasons in the beginning when prototyping is most prominent (as low as 5 mins?) and gradually prolonging the seasons to the full length (1 or 2 hours)
• allow registering new players in specified number of ticks in the beginning of each season
  • fairly fair
  • not good for prototyping
  • same possible improvement as above

... more ideas or thoughts?

• reject trade command with planets that do not trade that resource
• reject buy command if it would exceed ships capacity
• reject sell order if the ship has insufficient cargo

additional idea for consideration:
add optional parameter to allow bypassing these validations (default false)
justification: players may plan ahead to have other ships trade with the one issuing the command thus solving the problem

static data and reports apis:

• add optional season parameter which allows retrieving historical data

data api:

• add optional parameters season and tick (both or none) which allows retrieving historical data

Do we have some ideas/ wireframes for the UI?

I have it a thought and I would not render all ships (because it would be a mess).

I would just have graphics for

• Empty space
• Planet
• ship
• Planet with ship

On hover or maybe always when there are multiple resources on one place i would use something like this (with player colors)

On click there should be detailed info about that place (like ship names)

I have an idea.

We can request data from the database after each tick call and store it in a container (cache) instead of calling the database with each client request. For the majority of game data, it is guaranteed that it will not change between the ticks, therefore there is no need to fetch it every time.

What do you think?

We should load the configuration from a file.

added reports to data:

• combat events
• trade events

not added:

• averaged resource prices
• profiling
• player score - this is already contained in data

https://github.com/gdg-garage/space-tycoon/blob/master/api/swagger.yaml#L294

see the origin of the discussion #40 (comment)

what do you think about ships construction taking several ticks?

possible idea is that the ship is actually created the first tick, but with only half its maximum life, and then the construction continues by repairing the ship to full life.

is it possible to have some infrastructure for testing?
specifically, i would like to test behaviors in the database.

example testcase:
restore database from the repository,
run this sql to add a player, a ship, a move command, and run several ticks of simulation.
verify that the ship has reached its destination.

there are a lot of edge cases that would be nice to test regularly, such as multiple ships trading with one planet at once, or several ships transferring goods to one ship simultaneously, etc..

Just an idea we discussed with @curusarn in person.

Maybe we can change the parameters for map generation during the epochs to force the bots to be more clever. The number of planets and their distribution (clusters) comes to mind.

Something like - lowering the number of planets for each epoch to make the game more aggressive.

Please add a auth section to swagger https://swagger.io/docs/specification/authentication/cookie-authentication/

Currently, I need to have hacked-in url overrides in the visualization client during development, because the default is https://space-tycoon.garage-trip.cz/api, which obviously does not exist.

We should unify the server api and a website provider to have same url, so that the api url can always be relative.

Remember that the teams will likely want to use the website while testing their bots on their individual testing servers too.

Possible solutions:

1. the go server will also serve the website
2. add a proxy in front, which would redirect /api to the go server and everything else to some simple http server for the website

Thoughts?

what should happen with destroyed or decommissioned ships?

change them into a wreck - an empty but valid object with no owner?

what to do with other ships commands referencing the destroyed/decommissioned ship?

what to do with any cargo that was present at the ship when it was destroyed or decommissioned?