TODO list (Dec 2025)

[DanVanAtta]

Ranting off a number of things we want to do, some of these are mechanical and others are more difficult:

mechanical/technology (by mechanical, I mean it's just the same change over and over again):

• swap hamcrest for assertj
• update javadoc comments from /* */ to markdown supported javadoc: ///
• convert single line strings to multi-line strings (the new java triple quotes): """
• (servers) change from 'dropwizard' to 'micronaut'
• convert triplea build.gradle files to kotlin (triplea server build.gradle files have been migrated to kotlin already)

architecture:

• modularization:

  • TripleA is pretty monolothic. We want new java modules that we "pull down" from the code. These new modules will ideally have minimal build dependencies, and will not have a build dependency on 'triplea/game-core' . Some examples of things we would want to modularize are things like: { rules engines, battle calculator, UI rendering, map data }

• Organize and proof read documentation

  • we have too much documentation, duplication, too wordy, scattered. Some of it has been consolidated, we need more efforts to consolidate and increase quality of the docs. It is not nicely organized, it is hard to find things, and just too damn wordy...

server-side work:

• world is your oyster here. We kinda only recently moved to having HTTP servers for the backend servers (JSON over HTTP, aka REST). The integrations with the server is so much easier than what it used to be (java objects serialized over raw java sockets). The TripleA project has not really had much opportunity to take advantage of this transition, so - there's a lot of wins.
• ELO ranking system. We would need a reporting mechanism of game history/changes/moves to the server and keep stats.
• single sign-on for server: use the 'forums' server for lobby user identity. One password, one account for all of TripleA (right now it's two, one for forums, one for lobby)

projects (high impact):

• network relay

  • this lets us get rid of bots and increase scaling of multiplayer games. The 'bot' players are a quick 'hack' in order to enable network bridging. What the network relay is, is just a barebones websocket server that relays messages from one game client to all others. This allows for a massive code cleanup, right now we have all sorts and hooks and subclasses for the 'headless' player (bots), and all that code goes away with a relay server. To boot, this is the biggest cost savings available, if we can get rid all of the bot servers except one or two, we'll be reducing TripleA operational budget by 40 to 50%

• plain text save games: base data + game diffs

  • this is a project to get rid of clones of 'game data'. The benefits here are numerous.
    • we get better compatibility of save games to new versions of the engine. Because save games right now are java serialized objects, we have ot make sure all of those java objects stay "the same" in order to deserialize. This is kinda horrible..
    • we get smaller save games, instead of storing a giant blob of bytes (serialized java object), we will have a more minimal and compressable text file. Because the starting is known
    • AI is potentially way faster. Performance analysis of AI code showed it spent most of its time doing game-data clones. With the new save game approach, game-data clones will be effectively gone.
  • what is this project? Instead of serializing gameData to disk to store save games, instead we'll have a plain text file that will be two things: (1) an initial state, ie: a map, (2) a JSON list of "game diffs", basically moves or events; eg: "player 1 moved 1 infantry from Western Australia to Eastern Australia" (the data should be more structured, but that is the gist, we store an initial state and a stack of changes, all in plain-text.

Dice Server Rewrite

This will save TripleA about $15 / month. We're running an expensive and old server because it has the legacy dice server running on it.

There is a rewriten nodeJS dice server! https://github.com/triplea-game/dice-server
Either we can dust-off the nodeJS dice server and see to the final launch steps there, or we can port it to a java server and then do the launch (having a unified java stack, preferably with micronaut would be very nice... but $15/month is well worth a polyglot). The core nodeJS code there is really quite good. Which means that launching the updated dice server might not be too difficult, or it would alternatively be a pretty good 1:1 template to port to a java service.