The goal is to keep things at the utmost possible simplicity. This is just a proof of concept anyway, if it's not going to be very fun to play, so what. Important is, it should be fun to '''create'''.

User Interface

This will most notably carry the simplicity. There are no dialogs or any sort of GUI elements, except a fixed bar of buttons to the left. The left bottom will have an overview map. The right part will be the main screen, with the game map.
Left clicking will be the way to interact with buttons, and to perform actions in the main screen. Right clicking will be used to scroll.



Just a simple square-grid of hexagons.
Maps are currently created randomly.


Fish, Water, Coal, Stone, Iron, Gold



New pathes calculated from now on will not consider the road - but there may still be units walking a path containing the removed road, and goods tagged with a path over the now missing part.
In the former case, units will try to find another path. /!\ TODO: /!\ details? what if no other path? what if a unit is on a road while it is removed?
In the case of items, the items should be retagged with a new path, or sent back, and a replacement order placed. TODO: details? how is it detected?




For each player in the game some things need to be managed.



Networked games run on each client, and use a server for synchronization. The server will do nothing but accepting commands from the clients, and then broadcasting the commands again. But it will make sure that the exact same commands and in the same order arrive for each client, in the same game tick.
A client must run synchronized. That is, it will have a function game.tick, which is run every time the server sends a TICK command. This probably would be fast enough with happening only around 10 times a second - so will need a way to separate game logic from actual animation. For example, if an animation is one second long, that would be only 10 game ticks. But still, it might move something by 100 pixels pixel-by-pixel.


Initial client commands: Initial server commands: Client commands: Server commands:


Lag hopefully isn't that big a problem. Even your own action will go to the server before being processed, but nothing in this game should be time critical.


A central server is used, so cheating attempts by clients could be detected there (e.g. if anything is different than on the host player, we know there has been cheating). A cheating player could be disconnected.
Actually, even for clients it should be possible to detect cheating. Any packet in the chain of packets not possible would mean cheating (or desynchronization). So basically, any tampering with the game state will lead to desynchronization, and the game will end.
Another form of cheating would be to access hidden information. For example, a client could run with the whole map visible, and could eavesdrop on any settings and commands issued by other clients. There's not much that can be done to prevent this.


Being an RTS game, sooner or later you will encounter enemies. To attack them, barracks must be built. They can hold multiple military units, which will attack enemies in the vincinity. A challenged unit will not run away, but await the attacker once challenged. To give not too much advantage to the attacker that way, fights are always one-on-one.


Bot or player?

There are generally two ways to do AI players: Maybe also a hybrid could be found, where AIs behave like clients, but also simulate the server and don't actually send anything over the network.


This is a hard part. Generally, the AI will do this: The starting location should not be too far from mountains (=resources), and also have some initial woods, and stone. Maybe a lake for fish, and some berries.
After that, buildings must be built. Roads must be built. Locations must be chosen.
Finally, other players must be analyzed (it could cheat here by accessing internal info) and attacked.

Common functionality



The Woosls code is written in Python, and follows the Python style guide. That is, 4 space indentation, no spaces around ( and ), and so on.
When using Python for small scripts, you never need care much about code organization, it simply will be readable. For a project like this, there are some self-imposed guidelines: That's about it, I may add more later. But it's all Python code, so there really shouldn't be much possibility to mess up completely, like in most other languages who '''even ignore whitespace''' |)

This does several things (maybe should split it?):

The map module simply contains the representation of the hexagon map.

The game module contains the complete game state. This means map and players.

The server module has the game server. It handles all client requests and sends out the game ticks.

This is where user input is collected and transformed into requests to the server. Replies by the server are received and passed on to the game module.

This module describes a player. A player has units, a roads net, various settings and other things.

Implementation of a single unit.


some minor design decisions