There's a lot about the Bolo architecture that I don't like. I don't like how everything is limited to 16 (16 players, 16 pillboxes, 16 bases...) Everything is constrained around what was Bolo and doesn't have the flexibility and dynamics that I would like to see.
You can change the number of things (players/pillboxes etc) from 16 to 253 easily by changing the #define's in the C code or the static member variables in the java code. e.g.
[code:1:6e25fbe2ea]
/** The maximum items of each type to exist in the game. */
public static final int MAX_ITEMS = 16;
[/code:1:6e25fbe2ea]
For a maximum of 253 game items (of each type) two areas of the code would need to be changed.
1. The user interface, to be able to display everything meaningfully.
2. Some of the networking packet creation/extraction - For example: NetMNT/NetPNB classes or modules. Specifically the make() and extract() functions. They currently save a couple of bytes of network traffic per item by bitshifting some of the data as it is known to fit in a nibble. Searching for utilPutNibble() would locate the instances.
It wouldn't be too difficult to support more then 253 game items or players. The data types would need to be changed to be larger types (currently stored in single bytes) and definition of NEUTRAL would need to be changed (currently 0xFF, 0XFE is also considered special)
Outside of those constraints, the amount of game items is only limited by available memory.
Most things in the WinBolo/JBolo code base is configured by #defines. The grand plan was to externalize them to make the configurable by modders. (Points to anyone who can find my now embarrassingly juvenile post about it 11 years ago on the r.g.b)
For example, with frameworks like Apache MINA or JBoss Netty, there's no reason we couldn't build a network server that could support hundreds of players. Bandwidth would be the only limit. We could also build a server that supports multiple protocols like HTTP/Comet for an in browser game as well as a UDP for more traditional clients and even TCP for those stuck behind firewalls that don't let UDP traffic through.
Latency is more of an issue in WinBolo then bandwidth (however less then the original mac bolo) It is an action/real time strategy game - A pillbox can destroy a tank in a second when angry, a player can turn 90 degrees on road in about 0.7 seconds and dodge some of the shells and survive. I'm not sure what the impact would be in creating, parsing XML , creating XML response, parsing response etc. if an AJAX or HTTP networking transport was used. WinBolo's networking previously used a combination of TCP and UDP sockets (later simplified to just UDP) as using TCP sockets alone could not deliver the data quick enough even when disabling the Nagle algorithm. This is partly due to the protocol itself which is lots of small packets (10-30 second) of around 25-150 bytes each rather then a continuous stream of data.
That said, to implement a different network transport method have a look at the netclient.c / netclient.java file. Its not an interface yet, but provided the send() and ping() calls are implemented it should work. The equivalent file on the server side is servertransport.c. Minor changes would be required in servernet.c to check multiple transports for new data and netplayers.c/java to remember which player uses what transport.
I've been thinking of starting a new code base using JBolo as a guide but working toward an architecture that is more scalable and more dynamic. Some of the suggestions on the Wiki are great (capture the flag, king of the hill, death ball, etc.). I would like to start working towards an architecture that can easily support those kinds of changes.
I don't yet have an answer for implementing different game types (suggestions yes...) as Bolo never had game types or even win conditions. Depending on what direction people want to go - starting from scratch, completing the Java version, rewriting, unifying the C client to a cross platform toolkit I have some ideas....
