Student Group Studying TripleA

beelee

@jtkenny heh heh my understanding is the code architecture is like a pile of spaghetti. Lotsa of people involved over the years. I'm not a developer either. Can't even get the source code dialed in lol.

Reason I'm responding is, funnily enough, my OM worked in the Comp dept for 30 years at ISU. lol

I guess I'll go ahead and ping these guys for ya as long as I'm here

@LaFayette @RoiEX @Myrd @redrum

Captain Crunch

deja vu no wai

TheDog

@jtkenny
Remember Im no dev, but while you wait, check this out.
https://github.com/triplea-game/triplea/tree/master/docs

Especially
https://github.com/triplea-game/triplea/tree/master/docs/development

RogerCooper

Your group should think about rewriting the code from scratch, without significant change in functionality. Reducing the technical debt would be an interesting exercise and useful contribution to the project.

This is still the best general area movement wargame engine around, there is a lot of potential.

LaFayette

@rogercooper This might be an interesting read for you: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

It's a tough call to rewrite, it often does not work out well and you wind up with with two legacy code bases and more problems.

I think the strategy to try and decouple major modules might be the best way to go. Once that is done, we can then re-write those modules. An analogy, we would re-arrange the code so that it is more like a frankenstein, with a well defined arm connected at the shoulder. At that point it would be easier to redo the arm and reconnect it compared to rebuilding the entire monster.

LaFayette

@jtkenny Wow, that is very cool!

This documentation might be of help (but is legacy): https://github.com/triplea-game/triplea/tree/master/docs/development/design

We are in process of modularizing triplea and we have broken up some of the code into sub-modules. 'game-core' is what was previously the one-and-everything module and still is to some extent. The lobby code is in the 'spitfire-server' module and we have that pretty cleanly broken off now. 'game-headed' and 'game-headless' are high level modules that were meant to be the specific partitions of those code base and eventually everything in 'game-core' was intended to either "move up" the stack or "move down" the stack. We have a few modules for low level map-parsing code and we are in something of a position to try and create a "map-data" module to present a better interface to 'game-core' for accessing map data. There would be a lot to do to further break apart the 'game-core', for example I would like to have a module that is focused on just applying game-mechanics that is apart from the rest of the code.

The major initiatives we have right now is to:

Change how game data works and save-games work so that we have 'game-change-deltas' which stack on top of each other. Right now 'GameData.java' is a god class that maintains the current game state and when the game is saved, this is serialized to disk (via java serialization). 'GameData.java' represents the latest in game-state. Instead of this, we would want to have as a starting point a map (which can then have its data loaded on-demand) and a series of game-change objects. From this we could re-create the latest game state by using the map data as a starting point and then applying the game-deltas.
Remove the headless-bot code in favor of network relay. There was an old urgent need to be able to host without a publicly available IP. To resolve this, a 'headless' game-client was created that looked like another game-player but was headless and could then be launched in stand-alone instances. To replace this, we are looking to have a 'relay' server that sits as a single node that opens websockets to clients and then any message sent to the relay server is then sent to all other connected clients. I've got something of a start on this but it could use quite a bit more work.

We could use help also in just shear project management, documentation & automated verification. There are a number of features too that are pretty high on the list. One of which is 'turn planning', allowing a person to 'plan' their moves async while another player is taking their turn. This would look a lot like edit mode except we would keep a history of the pending moves (and/or purchases) and allow a player to 'replay' those moves when it is their turn. This would potentially really help speed up game play.

Overall, as hinted at, the architecture is a bit of lava-flow. There are some elements to it that are pretty well defined but then broke down a bit at scale and/or suffered from efforts that were done in a rush. We've made good progress for automation and testing which helps the code-base from being 100% legacy, but it is still sometimes very difficult to work within the code. For example, rewriting how battle-supports is done would be great. If we could represent units as "unit-type+count" rather than representing every individual unit, some algorithms would become a lot easier and a lot faster (specifically in the battle-calculator code, which the AI is heavily dependent upon for performance).

There are some interesting tweaks that could be done to the AI, though that is not necessarily super well architected.

The AI was meant to be plug-and-play and a key interface for game-players was created such that human players and AI players would only need to implement the same interface. Hence the game engine would invoke the key APIs of that interface when a persons turn came up, the AI would auto-calculate a response vs the human implementation uses UI components to listen/request for user input.

The network code was designed such that it was transparent if the game was being played single player or multi. This has a lot of the 'bridge' and 'delegate' concepts that you'll find throughout the code. The overall concept is good, but the code backing the 'bridges' and 'delegates' we are working to replace with JSON over websocket communication to simplify (compared to a custom Java network serialization protocol that TripleA currently implements).

Happy to answer any questions that come up.

LaFayette

Another thought of a good project/place to contribute would be trying to isolate code into a new module. Isolating major functionalities would be pretty huge as it would help clarify and simplify its dependencies on the rest of the codebase. That would allow for good iteration within those sub-modules.

@jtkenny What kind of contributions are you thinking of? is your group looking for a small project, or more looking to contribute refactorings/cleanups/tests/patches/bug-fixes?

LaFayette

@jtkenny I'm really intrigued and we could use support. Hopefully the project is something that your team would like to continue working on after the semester is over.

Regardless, descriptions of the architecture would be better placed in a document and then referenced here. Short of that, I'd look at 'GameData.java', 'MapData.java' and then there is a bunch of network code. The execution of game phases is meant to be handled by 'delegates' which have a direct analog in the XML. The delegates are ordered in sequences and then executed, allowing the XML to specify a lot of customization. The delegates are not generic and some are very specific to support the game rules and phases. You could start from the bottom of the stack at how game data is parsed from XML and then learn from there. You'll find that sub-modules sometimes have their own architecture. For example, there is a custom XML parser that is built with a key principle of having java classes represent the XML data as-id. Those classes are then converted by a logical parser that converts those classes into game-data entities (ie: delegates).

Otherwise.. we are very much in process of evolving the architecture of TripleA which quite long ago breached scaling thresholds and became quite messy as work continued.

jtkenny

@lafayette Our assignment states that we need to open and complete two to three pull requests. The first one can be small for a small fix or documentation update. The others must be substantive, so most likely the answer to your question is a combination of both.

LaFayette

@jtkenny Sounds like the first PR is perhaps something more to go through the PR process and be something of a minimal update. That is really reasonable since there are a number of steps to get up and running and to be able to push a branch & PR it.

"substantive" could use clarification. We try to have all updates be incremental and that requires some planning. Ideally all PRs are under 500 LOC so that they can be reviewed in one session by a reviewer. This implies that a 2000 LOC change would want to be split up across at least 4 PRs. For example, if adding a new feature, the first PR might be adding the feature flag and an if statement where the update will occur, eg:

if(ClientSettings.someFeatureFlag.getValue().orElse(false)) {
   // TODO: implementation code will be filled out here
}

Then a next update would start filling out an implementation, followed by testing and then finally a last PR that removes the if block (removing the "feature flag") and any cleanup.

Some fixes in the code base while small, could be pretty 'substantive' (ie: consequential). There are lots of automatic error reports that are uploaded that could be the starting point for relatively small-medium sized updates.

Happy to give guidance if you indicate area of interest.

Cernel

I think sounds are the most neglected part of TripleA.

Here it is a feature request of mine, on the matter:
https://forums.triplea-game.org/topic/275/units-specific-placed-sounds

Other things would be getting a sound every time you click on units and having background sounds, general, per turn, per phase (keeping playing only for as long as the phase is active) and per phase and turn.

Another thing would be able to order the priority by which support bonuses/maluses are assigned (For example, if there is an artillery which can support an infantry or an elite, to decide which gets the support.). I've a feature request open for that too.

jtkenny

@lafayette I think what our professor meant by substantive would just be that is a more major change rather than just a small bugfix. I am assuming that this could be spread across multiple PRs if necessary to meet your requirements for a PR. Nevertheless, if there are any small issues we could start looking at for our first PR, just let us know and we would be happy to get started.

LaFayette

@jtkenny Understood regarding a substantive update. Let's discuss before you get started as much as possible to help grease the wheels. It can be very tricky to break up larger PRs into smaller, but we can try our best.

FWIW, some studies have shown that code review effectiveness drops off dramatically after about 30 minutes (and that reviewing for more than hour is beyond diminishing returns). Similar studies have shown that a typical person can review up to about 500 lines in 30 minutes. Thus, to have a PR reviewed in one sitting (ie: in one day) requires it be under 500 lines. Reviews split across several days is difficult for everyone involved. How small to split up PRs is a preference of the project and organization. Generally we want them about as small as possible (we have super limited review capacity. It wouldn't be bad to have other members of your team do reviews of PRs you submit, that would help for some first passes and give you valuable experience. Coding, writing tests, and code reviewing are all independent skills)

For good issues to tackle, it would be really nice if we labelled more as 'good first time issues', but the labelling/intake of issues is pretty neglected for a lot of reasons. Regardless, the 'error reports' are all valid problems, fixing any one would be a good bug fix. Look for the error reports with a '2.6' version: https://github.com/triplea-game/triplea/issues?q=is%3Aissue+is%3Aopen+label%3A"Error+Report"+2.6%2B

For the error reports, the biggest challenge is usually reproducing the error. Once you can repro, it's easier to discuss a fix and/or just fix it directly at that point.

beelee

Hi @jtkenny

Can you keep us updated with what you guys want todo and have done so people can follow along ?

Thanks

LaFayette

Checking in:
@jtkenny has everyone in your group done the following?

set up an account in github
cloned the code
set up IDE (intellij preferred)
ran the 'verify' script to run all tests
- installed docker and have started a local databsae
able to launch the game client
able to launch the lobby

The above is a bit the ABCs before being able to make any updates. With luck the developer setup documentation makes the above very easy and straight forward. If not, please ask and/or update the setup documentation to fill in any gaps

I was thinking as well about the architecture documentation task that you have as part of your assignment. It would be great to have that be included in the official docs! Though, it might be a lot more tractable to look at the architecture of a single sub-system rather than the whole app. For example, the lobby has a pretty well defined architecture, network communication has a pretty well defined one, and how map parsing is done to get game objects has a pretty well defined design as well.

ebbe

@thedog @jtkenny
1. Displaying how many of a unit can purchased and blocking the purchase of too many units see the image below, the units with a ≤
2. calculating how many units can be placed this turn, in this example 11.

These are on the top of my Wishlist too !!!! ; )

jtkenny

@beelee This is the issue we selected to try to work on, although so far we have been unable to replicate the error: https://github.com/triplea-game/triplea/issues/11097

So far we are thinking that maybe this is because we are on the 2.6 version of the game, and this may be on a later versions, but we also haven't been able to figure out how to move forward to this version.

jtkenny

@lafayette Yes our entire group have completed these steps for the most part. I have been able to run the application in IntelliJ on my computer, and I think everyone else has as well.

TheDog

@jtkenny said in Student Group Studying TripleA:

but we also haven't been able to figure out how to move forward to this version.

Not sure what you mean, but I think you need to install multiple versions of the TripleA game
So download a Triple version, but when installing it, use the version as the install path
eg install to TripleA-2.6+14163
like;

and therefore download the source of the version that you want to change.

Im not sure the one issue you have selected, is actually an issue. I'm sad and have no life and I use TripleA daily and I have not seen this error message, speaking as a xml coder of many maps and many errors.

Being selfish the biggest impact you could make for us TripleA-ers is in the 2nd post of this thread, as lots of maps have this style of unit restriction.

If you met this restriction and gone over a unit limit, TripleA resets all your purchases and you have to start over, not a good experience for a player to have.

LaFayette

@jtkenny There is a tag pushed on each release that matches the release version number. You should be able to checkout the exact version via: git fetch upstream; git checkout 2.6+14163 (I'm assuming you named the 'upstream' remote as 'upstream', git remote -v should indicate the name to use).

The version in the error report does correspond to the game-client version that sent the error report, seemingly this (issue #11097) should be something that you can reproduce in 2.6.

It might be most fruitful to see how and where returnFire could be null. That might then give you a path for reproducing the issue.

Re: local dev setup

Just want to be sure that your team is all able to run verify script and not just launch the game from IDE. The verify script is useful since it runs all tests & static checks in one-go. It has more requirements then just running the game since you need to install docker (which then provides you with a local databse). If that works, then you'll be able to launch all components of the stack and not just the client application. To add to that, verify is particularly useful for PR verification - it can be quite endless to push updates and wait for the build to fail on relatively random issues compared to running verify locally (which is all in the name of reducing developer iteration time)