Skip to content
This repository has been archived by the owner on Sep 25, 2022. It is now read-only.

Edition 1 roadmap #122

Open
iasoon opened this issue Oct 6, 2016 · 12 comments
Open

Edition 1 roadmap #122

iasoon opened this issue Oct 6, 2016 · 12 comments
Milestone

Comments

@iasoon
Copy link
Member

iasoon commented Oct 6, 2016

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:

  • Game rules
  • Implementation plans
  • A team

Dates

  • Week 1(13/02...) Bottle Bats themed codenight in preparation for the event(= focus on platform).
  • Week 4(06/03...) Public Battle Bots introduction event
  • Week 8(17/04...) Public Battle Bots codenight & discussion (=focus on writing bots)
  • Week 11(08/05) Grande Battle Bots finale tournament

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.

@iasoon iasoon added this to the edition 1 milestone Oct 6, 2016
@wschella
Copy link
Member

wschella commented Oct 6, 2016

Dates:

  • Week 1(13/02...) Bottle Bats themed codenight in preparation for the event(= focus on platform).
  • Week 4(06/03...) Public Battle Bots introduction event
  • Week 8(17/04...) Public Battle Bots codenight & discussion (=focus on writing bots)
  • Week 11(08/05) Grande Battle Bots finale tournament

@iasoon
Copy link
Member Author

iasoon commented Oct 6, 2016

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.

@wschella
Copy link
Member

wschella commented Oct 6, 2016

The ideas i'd like to see implemented this year are:

if there is time left, these are my options:

@iasoon
Copy link
Member Author

iasoon commented Oct 6, 2016

Is there a tactical difference in having variable fort defense versus variable troop generation? (stationing troops in your fort is defense)

@wschella
Copy link
Member

wschella commented Oct 6, 2016

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.

@wschella
Copy link
Member

wschella commented Oct 6, 2016

Also, the variabele troop generation is a dubious name, as it means both:

  • various forts have various static but different generation rates
  • forts have dynamic generation rates based on other factors (nearby friendly forts, current population, etc...)

@iasoon
Copy link
Member Author

iasoon commented Oct 6, 2016

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.

@iasoon
Copy link
Member Author

iasoon commented Oct 6, 2016

These unit generation / combat rules all seem interesting, but I feel we should pick one or two to avoid overcomplicating the game.

@wschella
Copy link
Member

wschella commented Oct 6, 2016

I'd say Large Army Bonus and Fort Defense, as I feel these would have the largest impact on the zerg-meta.

@tl3ilaxu
Copy link
Member

tl3ilaxu commented Oct 6, 2016

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.

@wschella
Copy link
Member

wschella commented Oct 6, 2016

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.

@iasoon
Copy link
Member Author

iasoon commented Oct 6, 2016

I think we already cancel out the large army bonus with fort defense bonusses.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants