Open iasoon opened 8 years ago
Dates:
As for the game rules, there are some interesting ideas on the wiki. Personally I'm mostly interested in the regions and variable fort defense proposals, and a rule that would make having large armies more advantageous.
The variable fort defense bonus would match well with a rule that would make attacking from multiple directions much better, so that strong forts can be captured anyways. but require additional planning.
The ideas i'd like to see implemented this year are:
if there is time left, these are my options:
Is there a tactical difference in having variable fort defense versus variable troop generation? (stationing troops in your fort is defense)
Yes, both would be strategic holdings, but a you'd want to keep high-generating forts closer to your core, and high-defense forts closer to the edges of your territory.
Also, the variabele troop generation is a dubious name, as it means both:
Hm, connected friendly forts might be an interesting idea, because it allows you to actually siege a castle by trying to cut it off as much as possible.
These unit generation / combat rules all seem interesting, but I feel we should pick one or two to avoid overcomplicating the game.
I'd say Large Army Bonus and Fort Defense, as I feel these would have the largest impact on the zerg-meta.
Maybe only add Large Army bonus when attacking forts. Might spice things up and might just avoid ball of death armies(civ 4 style). Also makes thematic sense since large armies are way more effective in sieges.
I'd say large armies are very effective in fieldcombat as well. But I like that idea; maybe we can reverse it tho? Only have the Large Army Bonus in fieldcombat, and not when attacking forts. Since you can't call back troops, a ball of death would just run to it's death to well guarded forts.
I think we already cancel out the large army bonus with fort defense bonusses.
Badass BottleBats Edition 1
The time has come to lay out plans for edition 1 of Badass BottleBats. Let's collect all relevant information and discussion in this issue.
We need:
Dates
Implementation proposal
I propose splitting the current implementation into several parts, which will be described in the following sections.
The game server
We would host a dedicated game server that will do matchmaking, run the game logic and keep track of bot ranking.
Bots will communicate with the game server through a websocket. They identify themselves by sending a secret token.
It should be possible to either ask for a match to be made, or to manually create a game which a friend (or nemesis) can join.
All communications should go over JSON because it's simple and extendible.
I propose to write this server in Golang, and I volounteer to work on this.
The bot nursery
We should offer hosting for people who cannot / don't want to host their bot theirselves. This is neccesary because otherwise the event of two people going in to matchmaking at the same time will be quite infrequent :) These bots should of course be sandboxed. We could limit the total cpu time a bot can use, so that our resources won't suffer too much. These bots should play just enough to rank them, and provide an opponent for a lone wolf in matchmaking (how do we orchestrate this?)
The client
Of course we want to keep the entry barrier as low as possible. Implementing bot authentication and communicating over websockets is not that nice for beginners, so we should offer a friendly client that can start your bot and communicate with it over stdin/stdout. The client could also visualise the match as it is being played, keep track of your different bots, yada yada. I propose the client to output line-separated JSON to the bots, so that parsing is easy.