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

You can now download 2.0 from the triplea-game.org website

Changes are listed on the release notes

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.

It'll be hard to say more until we know more about this problem. FWIW, save games have always required parts of the original map (for example territory names IIRC). There has been an attempt over time to reduce the dependency on an existing map, but for sure you do need a map to load a save game for that map. Name hacking will be unreliable but could work if you know what you're doing.

The error message would ideally be much better, this is kinda poor on the TripleA engine part.

Try running the XML through a validator, it might be able to give you an idea where the problem is:
https://www.xmlvalidation.com/

If you still can't find the error in the validator, try commenting out large blocks of the XML and re-validating until you have a valid XML. Then uncomment blocks until you find the part that is giving the validation error.

FWIW, bot code was pretty minimally updated, but we had a lot of modifications in 2.0 in general and it would not be too surprising if there was something changed in there that impacted this.

@Zaroph do you have any specific maps in mind where this would be particularly useful?

responding to your various questions/concerns @Cernel

due to the traditional terminology being not always followed.

The traditional terminology is frankly wrong and made up, hence the confusion - but that is really besides the point.

By "Map Versioning" do you mean that the maps will have a version or are you referring to the version numbers within the game (xml) files?

The version number in the XML files would go away completely and the entire map would be versioned.

the map folder name will change with every version, so to allow to have more than one of the same map on your terminal (similarly to when, in the past, new TripleA instalments were not overwriting any previous ones)?

TBD, but likely so.

A thing I always disliked about the current map updating system (beside the time inconsistency due to the time between the map update and the moment in which someone merges your PR to update the "triplea_maps.yaml") is the update versioning number, that it is itself meaningless but for prompting users to update.

Yup, the version number in the triplea_maps.yaml is purely for notification purposes. It's much more involved to know the last version that users had and the existing game code has no concept of map versions. (Game versions are also there just for display purposes, that does not even trigger anything, it's only used for display in the lobby 'GV' column).

Will the process be the same (meaning the first time you add a map it will be version 1, the first update will be version 2, and so on)? In the moment that was not really a map versioning number, I'd rather keep track of it by registering the date in which the update was made (maybe limiting to no more than 1 update per day), which would also be a valuable information per se.

When a map is updated would be tracked. A single incrementing sequence for versions is likely. We are getting a bit ahead of ourselves as the game engine does not support multiple map versions. How that is to be done is TBD.

We could easily get into a state where a map truly becomes the XML file and the assets are decoupled from the map. Notably we could have a 'unit editor' feature where unit images, flags, resources, etc are all uploaded individually. Then a game would reference such elements by ID value. When you launch a game you'll have a units folder that has a collection of unit IDs and they are brought in as needed. This avoids all overlap between map resources and allows for map-makers to pick and choose which graphics they would want. Same thing could be done for map polygons. For now though the focus is on deprecating triplea_maps.yaml with a for-like replacement that can be interacted with from in-game.

If there is a map versioning akin to the release versioning in the current "triplea_maps.yaml" (meaning the first time you add a map it will be version 1, the first update will be version 2, and so on), I think it would be better the version being kept within the map folder

I don't think that is readily possible. What if two people update a map at the same time? How do you know a version before you go to upload it? What happens if one version is worked on for a long time and you then do not know the right version number. The version number I think must be external to the map, it should probably not be aware of any other map variants and just worry about being complete in of itself. Any version matching would then be the responsibility of tracking and the game engine.

(so it will be an actual map versioning) and a versioning increase being strictly required every time anything part of the map is changed

Very likely each map upload will be write-once and then read-only (immutable). When uploaded it would get a tracking ID and a version number to know which ones are which and which is latest.

you have to increase both the game version and the map version

That almost certainly will be unnecessary and both versions are just going to be removed from the map-maker domain.

if you change only any element outside all game files, you have to increase the map version but not the version of any game).

A map and its games are going to be more tightly bound. Perhaps even moving to where they are 1:1 and then it becomes a needless distinction.

as I'm not really understanding everything that is being said about this new process.

What is not clear?

Going down the micro-service route could likely hurt us more than it helps. I wouldn't want to break out functionality to that low of a level without additional reason to do so.

@RoiEX the moderation aspect you're suggesting is pretty close to what I'm thinking. The trusted users would have a queue of maps and they'd approve them at which point they would become live. Though, I am nervous about the overhead and complexity that could create. If we lock down the map URLs to github based ones, then we can delay that feature for a little while at least.

I'm working on a few things that I hope map makers will really like. I'm opening this thread to discuss the details while still in design and building out the code.

The initial rev will focus on automating the reading and writing of: https://github.com/triplea-game/triplea/blob/master/triplea_maps.yaml

Currently forecasting this to be a 2.2 or a 2.3 feature.

Naming the maps server

I'm gonna start with the most important : )

The lobby server is currently code-named 'spitfire'. We're going to have a second server for maps, I'm thinking to call it the 'stuka' server.

Github Project

FWIW, this is the github project link where progress can be observed: https://github.com/triplea-game/triplea/projects/17

All dev issues regarding that project can be found with this link: https://github.com/triplea-game/triplea/issues?q=is%3Aopen+is%3Aissue+project%3Atriplea-game%2Ftriplea%2F17

Getting map list from Stuka

The first thing is the game engine will be updated to pull its map list from stuka instead of reading a github file (https://github.com/triplea-game/triplea/blob/master/triplea_maps.yaml). The stuka server would a database to generate the list of maps and return that back to the game client. Essentially this will be exactly the same info as found in the YAML file, but retrieved from database

Pushing update to Stuka Map Index

This is where it gets good. The next step will be to add a UI to triplea-game where a person can open a menu and fill in fields needed for a map version. First you'll enter credentials same you would to log into the lobby server. Then you'll see a UI where you'll be given a list of existing maps that you can update or you can upload a new map. You'll then be given another UI to either publish an update to an existing map or fill in fields for a new map. You can then click 'publish' and your map index will be created in database (no more PRs to update the YAML file).

From then on, anyone downloading maps will see the new or updated map.

For some period of time the server will continue to read the YAML file on github, so we'll still have a legacy route where if you update the YAML file the server will be (eventually) updated. This file will disappear once all clients are migrated to using Stuka.

Considerations

Map Ownership

Map updates will be limited to only those that uploaded them. We'll need to assign owners to each of the maps. This will probably be seeded by the current owners, though most are just the map admins. Anyone who is an 'owner' can update a map.

Sharing Maps

I'm thinking it will be nice to be able to have multiple people be able to push to a map. I'm thinking we can add a UI option for a map owner to add additional people who are allowed to update their map (remember for now it's just the map index information, so not as profound yet as actually just updating the XML, but we'll be getting there )

Map QA & Moderation

An important element here is that new maps can just start appearing on the system. This is potentially bad from a moderation perspective (hopefully nobody will be quite this bored, but bad things can happen). Currently we are gatekeeping maps as we control when a map is updated, when the download URL is updated, and we can see whenever any map contents are changed. This will be relaxed and we won't be able to control when maps are added.

To this extent, we'll probably need a 'moderation' flag on maps, to indicate that maps a 'raw' and could contain anything. I'm not sure if we want to by-default make these available to the public or require that a map-moderator look at the map first and flag it's okay. The latter is a bottleneck and requires resources. We can perhaps label a pretty large group of users as 'trusted' and allow them to do the map-moderation.

Map Versioning

Currently the engine only supports one version of any map, the latest. I'm intending for this to be relaxed and for the engine to be able to manage multiple versions of a map. The different versions will continue to be transparent to the game engine and it'll work only with the latest, but we're laying the foundations early to support multiple map versions.

If we are going to seriously consider YAML, I suppose it deserves its own discussion thread.

We'd have to be sure we would want to do that. I think there is a lot of good flexibility it gives us. Though we'd probably want to 'freeze' the XML spec of maps and just keep that working while the YAML version gets new attributes over time.

@alkexr good considerations. We can certainly add/create attributes for AA, eg:

   attributes: [ artillery, air ]
   aa_attacks: { count: 3, dice_sides: 6 }
   bombing_damage: {dice_sides: 10, number_rolls: 3}

It's a bit limited to make all attributes just be an 'option' tag. The XML doctype makes that kind of move attractive. Moving to YAML makes that a lot more fluid, we could model options much more accurately.

For frontiers being turned on and off, we could add a triggers attribute to the production rule, and/or add a name field to it so it can still be referenced from triggers.

@Cernel Costs being a list allowed for multiple cost elements, eg:

      costs: 
        - {resource: PUs, quantity: 8}
        - {resource: Oil, quantity: 2}

For purchases resources, good consideration if we are going to remove the production frontier tag. To replace it we'd want to update the resource list and add a similar production rule to that.

@All/

At this point, despite my earlier reservation, I think there are two larger questions at play now:

• 1. Do we do a grand update of the map spec? Is a much larger project in order?
• 2. Do we consider using YAML as the updated spec? Splitting the game engine parsing logic to keep the existing XMLs the same and to have a new parsing logic module for YAML would arguably be easier than having multiple XML versions.