TripleA Needs your help!

We need help finding any remaining problems in the 2.0 beta. We'd like to release 2.0 imminently, we've almost all major bugs fixed. We're at a bottleneck where we don't have enough labor to test everything to get this release out. Your support of time and effort is really appreciated here and will help get 2.0 launched sooner.

We're inviting everyone to be an early release beta tester. We're asking you to:

• download the latest TripleA
• test anything/everything, all menus, all game play configurations, all rules, play a game through
• report any problems that you might find

Instructions

• Download the latest TripleA prerelease here: https://github.com/triplea-game/triplea/releases

• Run the installer, install to a folder named somethign like "TripleA-{Version}" or similar so you don't overwrite your existing TripleA installation.

• Launch the game, click on anything/everything, test everything!

• Report any problems that you see, new or existing: https://github.com/triplea-game/triplea/issues/new

Word of Caution

Since you are testing a beta, there could be stability issues, you might see crashes or other issues. We really want any of these to be reported so we may properly fix them.

Good luck and thank you to all those that step up to help.

We want TripleA to grow, to gain new features, game-play be easier, faster, maps more interesting and everything prettier.

So, how can you help?

• create bug requests directly into the bug tracker after a problem has been identified in any forum thread
• avoid having a dev do anything you can do yourself
• do not PM dev's asking for something to be done, instead create a bug tracker item

Background:

I would like to address and point out the scaling problem TripleA has. As TripleA has grown from a small project, where one person could handle the code, another could handle communication and submitting bug reports, as the volume of people and traffic has grown, this no longer works

Development is one of the slowest things to happen for TripleA. Most interesting features take perhaps anywhere from 10 - 50 hours of work. The way I see it, those that can code, we want them to spend time coding, not doing general communication on forums, not finding bug reports on forums and transferring them to bug tracking, not managing maps, and generally not doing anything that could not be done otherwise by the community.

The trick I think for scaling is we need to be sure that we update any process so that a team of people can handle the item rather than just an individual. If for example "Joe" handles all maps, then when the amount of map stuff is too much for "Joe", we'll see a backlog. If "Joe" goes on vacation, everything stops, and if Joe gets tired of spending 20 hours a week on maps and backs away, then everything grinds to a halt. Worse yet, if Joe leaves, all the know-how Joe had in his head leaves too, and suddenly not only is there nobody to manage maps, but nobody even knows how to manage maps.

Teams solve this, if all map items go to a queue, and a team works on the queue, people can take vacations, people can rotate in and out. The team has incentive to document how the team operates so that new team members can join and become effective and everything doesn't stop when one person leaves.

Without a team handling items, when it is individuals, we do not scale.

We see this problem mostly in bug reports and change requests in forums. If we rely on individual developers to read, distill and create bug reports, then we have a bottleneck and an individual responsible for a process. If that individual stops creating bug reports from problems reported in forums, then we won't get any new items in the bug queue. Notice, the bug queue is a process that goes to a team, all developers work on it. We could easily have the one developer not create a bug report and fix the problem, but then we are into the "silo" problem to an extreme.

We have a lot of map controls, unit size, search territory, unit highlight, map zoom, that are buried behind magic keys or various view menus. These are difficult to find and easily adjust.

I'm opening this thread to discuss options. Some were discussed in context of unit flags and movable unit highlight in this thread: https://forums.triplea-game.org/topic/1524/toggle-flags-and-toggle-highlight-movable-units-updates/30

Needed are good ideas of where we can place the various items and what kind of UI treatment we can provide.

So we need:
(a) a survey of the various settings and features that are better pulled out from the menus and placed behind a UI control
(b) a mock-up and ideas of how/where everything can be placed and what kinds of UI controls would be good for containing those elements.

Background: TripleA QA team has been operating for some time:
https://forums.triplea-game.org/topic/268/volunteers-needed-early-release-testing-group

We have coordinated mostly via gitter channel: https://gitter.im/triplea-game/QA

We coordinate testing via a pretty simple google spreadsheet:
https://docs.google.com/spreadsheets/d/1CSZ4s7wBLcvgue_IHwl-CbjQd95qj8hhR8m89ngCzbU/edit#gid=0

When there are multiple green bars lining up, meaning multiple people have reasonably checked as much of the game as they can, that version of the game can become the latest release.

Opening a dedicated thread to discuss these ideas.

From: https://forums.triplea-game.org/post/29462
@Hepps created this mockup:

I like the idea of action buttons, but I don't think we'll be able to agree just yet which ones should be on the game screen and which ones accessible in menus.

Let's focus here then on the minimap. Moving the tabs and map to bottom probably won't be that difficult. The translucent background might take a bit more work, but could be possible. It probably would make sense to make that a setting so that users can control translucent vs not.

Please add in any extra 2 cents, or thoughts on this topic.

Why the QA team?

The QA team is essentially a way to coordinate multiple people to test the software before it is released. The team was created in response to a number of problems.

• Development team had trouble tracking results and general confusion on "is it safe to release?". With a defined policy and tracking, we can now look at the testing results and know when a specific version has been confirmed to be okay for release.
• the TripleA code base is very difficult to modify and repeated releases kept introducing small but extremely significant bugs. Regression testing for any of these is a huge effort, and needs to be done repeatedly as the code base is constantly modified. It's too large of a task for just one or two developers, hence the QA team.

How will we know if the QA team is successful?

• The number of major bugs reported by users to github issues will go down and head towards zero
• The number of times a release is 'rolled back' will go down and head to zero

Where is the QA team heading?

• Still formalizing how we operate, but we're getting pretty close to a stable operating process
• Long term try to work with development team to reduce the number of items being hand tested
• Short/medium term, formalize testing a bit, a few things are getting through, perhaps a testing check list of all features and cases that need to be checked would be a good start

While play-testing with the unit scroller, I thought it would be really useful to have a notification prompt when all units have moved. This avoids having to check the 'units left to move' count and makes it more clear why subsequent 'next' or 'skip/sleep' presses do nothing. Curious if there any suggestions or comments to this. Below are some screenshots of what it looks liike:

If clicking the 'do not show again' button:

And a sample of the game setting for this config:

Just a heads up, it looks like there is opportunity to drop assets distributed with the game engine. I'll be focusing mostly on removing sound files that are only used by a few maps and will instead move those assets to the map itself.

I'll post a zip of the assets before removed and will add a list here of the files removed & moved to specific maps. The net result is that the images/sounds distributed with the game will be a bit fewer and will need to be included by maps specifically if they would want to use them.

Sorry, that was a bit of a dig @RoiEX; your work on JavaFX is eagerly awaited. It's a reality with this project that tasks that should take one full time week, take a lot longer. It's really tough to work on projects when you only have 3 hours at a time here and there. I can think of some examples where professional work really occupied my time and various TripleA tasks that should have been one full time day instead took a month. I keep wondering if we're fool-hardy to have resurrected TripleA from its life-support-only mode 4 years ago, this project was nearly effectively frozen because it needed so much work to get anything done. The optimist part of me thinks that we've payed a lot of that cost, and if we're effective/efficient, we can really do some interesting things now.

Thinking about this overnight, and given the lack of further input, let's go ahead with the repository:

• it's less work in the long run if we'll migrate to it anyways
• combining zip files to consolidate later sounds like a lot of busy work
• browsing through many pages of forums is also a bit tedious
• it's not the easiest to just download images from forum posts
• being able to download a single zip file for all assets is very convenient
• having the files be located in the correct folders should make it easier to use

So, I created this repository: https://github.com/triplea-game/map-maker-assets
It has been seeded with the unused assets that are being dropped from game engine.

To upload files, navigate to the folder where you want to upload a file, then click the 'upload files' button:

To download the contents of that repo to a zip file, click the "Clone or download" button and then "Download zip":

I think that is compelling enough of reason. I think the order of operations is to first simplify the existing code, attach testing to it, then think about next steps. Eventually we'll want to be able to serialize more easily the battle state to save games. I think to get there we'll need a way to recreate the current battle step more easily rather than have it be computed and then steps added and those added to the state that is then saved. That is perhaps confusing, but said another way, we should be able to determine the next battle step based on the game history and current state rather than relying on having a data structure be serialized and then re-loaded.

@Trevan said in Refactoring MustFightBattle:

BattleState

A class called BattleState for the parameters seems fine. What's the argument for making it mutable? Why not use a toBuilder to pass updated copies of it as needed? It's very similar to a mutable object but instead you copy it to make changes.

@Panther said in Cold War 1965 - Official Thread:

A defending ICBM on the other side is not intended to attack a territory but attacking units instead?

FWIW, a defending ICBM when attacked always suicides and is removed. It's in part meant to represent nuclear first strike. There can be a house rule whether AA fire can prevent this or not. It introduces a dynamic where producing an ICBM can in turn cause the opponent to use any they have in stockpile thereby trading them. If someone can get ahead by more than 1 ICBM then they have an advantage. Being able to place nuclear bombers (which have quite massive range of 10 IIRC) in position to be able to strike at a factory that could build a ICBM is a valuable suppression technique to trade an expensive nuclear bomber for an even more expensive ICBM, typically preventing an opponent from building one in that case (which makes kamikaze even more potent of a setting, which AFAIK is somewhat often toggled to on for this map)

Would be nice to loop in the OC. AFAIK this map is usually played with Kamikaze turned on, a standard opening move is to nuke the single US ICBM and send a nuclear bomber on a suicide mission to take out the other two ICBMs, leaving US with zero by their turn.

Are you still having trouble? What is the full path of where you have files that were listed for changes and the full path from the last dialog in the previous screenshot you were sharing? Are those the same?

I don't think you need to add a local repository given the first screenshot, that seems to be done already. It looks like all you need to do is to 'push' to sync your local changes with the remote repository.

@Trevan Feel free to post a draft PR with work-in-progress and add a comment to the places that could use help with.

Overall, incremental and early PRs are the ticket. Early feedback and bite-sized pieces are the golden ticket. In part what you are doing is relatively difficult, if not just to do it well and get it cleanly reviewed - so thank you for the effort and hang-in there.

Moved to development.

In short @Trevan , yes, would be welcome. MustFightBattle has some of the worst metrics for technical debt, so it's a great area to fix up.

Any such updates need to be done with care though as the code is complex and could easily cause an unnoticed regression. Using tests to help with that move and validate the logic would be excellent. We should perhaps discuss a test strategy so that not everything needs to be tested by setting up a game data object but instead decomposed to use mockable strategy objects.

At the end of the day, still breaking it u and using a package structure to cluster the behavior would be excellent.

I don't suspect it would be quite that complex. Wordiness can be solved. In any case the code to implement all the rules is going to be more complex than any such table, without the table we are lacking a specification to be sure the code does everything correctly (which leads to our current state where it's difficult to modify any feature in triplea because so much is jumbled together and nonsensical and lacking a clear specification). Regardless I don't think such speculation is argument against even trying.

Thanks for clarification, if I could summarize:
V2: casualties simply get to fire back if a destroyer is present
V3+: first strike is removed if opposing side has a destroyer

@Cernel regarding LL, with two rolls against a 4:
1/9 chance for 0 hits
4/9 chance for 1 hit
4/9 chance for 2 hits

The odds are really good you'll get at least one hit, if not 2. With just one roll, you have a 1/3 chance for the 2nd hit, with the two dice you have slightly better odds for two hits. That means in LL, when attacking a naval fleet, you'd expect more often to have more casualties attacking with 2 subs and a bomber than you would 2 bombers (even though the attack power is the same).

Personally I think a big misnomer of LL is that players reduce risk and/or are not playing odds. With subs, fighters and surface fleets, in LL you can get 3 hits with an attack power of as little as 8. Meanwhile a defender if rolling together will not have a chance for 3 hits until you get a power of at least 13, and below 12 there is a chance to have only one return hit.

Few questions I wonder about related to this:

A) If a subs first strike has been neutralized, would it be less confusing for it to simply roll with the rest of the attackers?

B) Is it incorrect for neutralized first strike subs to roll first if there are opposed subs? For example, 1 sub, 1 cruiser vs 1 sub and 1 destroyer. If subs roll first, and the defender subs hits with a first strike, could the attacker choose as casualty the submarine that has already rolled instead of choosing the cruiser? Is that rule compliant?

C) In the LL case, having subs roll on their own is significant as it can create an excess number of casualties. For example, 2 subs with a bomber might be 'better' to roll 2 times against a 4 (with two hits being quite likely) vs rolling 1 time against a 2 (unlikely) with 1 guaranteed hit. With the right combination of units you can increase the number likely LL hits with multiple rolls, creating some outsized attacks (example, subs, surface ships and planes can all roll individually, potentially outrolling a stronger defensive force). In such a case if destroyers force subs to roll with the rest of the attacking ships, that'll reduce the number of LL rolls (something which I think has been a bit of a loophole in LL).