TripleA development

Panther

@panther said in TripleA development:

IMHO the "conduct combat phase" is about resolving the conflict represented by the battle-board. To me this is somehow the highlight of every turn.

When you deal with this conflict: Do you rather think of it as a battle or of a struggle between opposing military formations during a 3-6 months period (i.e. the duration of a turn)?

Some rules lean towards the former - e.g. the submerge capability or the fact that you cannot partially retreat (in general).

Improvements in the display of the conflict may depend on this preference.

It is simply one battle of - sometimes more sometimes less - battles.
Resolving the batttles by the outcome of the dice rolls is most important.

Panther

@rainova said in TripleA development:

@panther said in TripleA development:

What would "zooming in" show then?

It may show the bombarding ships and the related transports on the edge of the display.

The map could be turned in a way that the invader is coming from the left.

Infrastructure units of the territory could be displayed behind the defender, walls in front of them.

If artists are interested, it could actually show a bit of landscape.

These are just the four of my ideas I can most easily sketch out. Once we prodvide the opportunity, artists may come up with better and more.

I am also thinking about a more modern, drag & drop UI.

What for? If I wanted animated pictures to create atmophere I would watch films or buy other computer war games.

Imagine people playing in leagues or ladders - sometimes playing five or more games at a time. They usually don't want to see those animations. It is distracting and - depending on the animation - a waste of time. They are busy developping strategies, see how they work out and continue from there.

Panther

@rainova said in TripleA development:

This gives the impression you are playing TripleA mostly for the game logic and hardly for the atmosphere of the time, the setting, the personalities. Does this describe your approach towards the game?

Correct. There are other games having this atmospheric approach.
To me it is a strength of TripleA to have a priority on the game mechanics - while allowing for a certain amount of customization including some atmosphere.

Other approaches - such as Beamdog's 1942 Online - are maybe more "atmospheric". But you can read reports of people who are enerved by the bling-bling shipped with it.

Really - for atmosphere and animations and whatever there are countless alternatives on the computer games market.

I, too, love scenarios like the GoT or WoW approaches, also historical scenarios. It is great how the map makers succeed to bring atmoshere to the games with the tools TripleA gives.
I am not against optimizing or careful enhancement.

But please let us not bloat up and by this reduce the straightforwardness of our TripleA software.

zlefin

I just hope it doesn't take too many more years for the unit transfer bug in bots to be fixed, so global and TWW can work right without editing.
sadly there's nothing else I can do on it.

In general I like the plan of just doing basic/essential fixes for now, while having a long term plan for a 3.0 that reworks the code base from the utter mess it is now.

UI-wise; I'd say triplea is fine without bells and whistles; but having optional add-ons for more atmosphere should be fine, as long as it's well compartmentalized. Much like Dominions, the user-base is a niche one that's fine without fancy graphics because of the good gameplay.

wirkey

@zlefin said in TripleA development:

I just hope it doesn't take too many more years for the unit transfer bug in bots to be fixed, so global and TWW can work right without editing.
sadly there's nothing else I can do on it.

In general I like the plan of just doing basic/essential fixes for now, while having a long term plan for a 3.0 that reworks the code base from the utter mess it is now.

UI-wise; I'd say triplea is fine without bells and whistles; but having optional add-ons for more atmosphere should be fine, as long as it's well compartmentalized. Much like Dominions, the user-base is a niche one that's fine without fancy graphics because of the good gameplay.

Don't ask me when and why but it seems like the unit transfer bug in TWW was solved. I recently played a game in the lobby within a bot and encountered no problem.

zlefin

@wirkey

I just ran a test in bot 204, and the bug is still present, in both Global and TWW. Do you remember which bot you used?

This fits my long-standing theory, in that the problem is that most of the bots have not updated to v 2.5.22294; and the solution is to get the bots to properly update the version they're using, which is something I do not have access to.

wirkey

@zlefin I don't really remember, but I usually try to play the 900s

frigoref

@cernel said in TripleA development:

Generally speaking, I personally believe that everything should be always visualized, nothing left to the memory of the player. This said, there are far more important missing matters, like the fact that TripleA fails to show retreat ways and which units can retreat until after you start the specific battle (and, in the current 2.5 stable, it doesn't even do that during the battle!), or the fact that the remaining movement of air units is not displayed, to name just a couple of such problems.

@Cernel Do we have feature requests for them on github? If so, could you please link them?

Cernel

@frigoref Not that I'm aware of.

Most of the times I open an issue nothing comes out of it, so I tend to open issues only for matters that I consider very important.

What I mentioned are some of the most important matters amongst the least important matters, as the game failing to show something is not much of an issue for experienced players.

For example, if I would open an issue for anything right now, I would probably ask to support the ability (which should exist in every basic game) to withdraw submarines individually (as TripleA incorrectly limits the decision to all or nothing).

Cernel

To be clear, when I said "there are far more important missing matters", I meant "there are far more important ones of such kind of missing features" because I was talking of "merely visual aids for the players", specifically the "just conquered" markers of 270BC Wars mentioned by @RaiNova (which just show what are the territories conquered on the current turn: a very scarcely important matter, in my opinion).

frigoref

@cernel
I think adding them as a new topic in Forum - Feature Requests & Ideas is the best so we do not lose the idea, the community can comment on it and we can sort the feature requests by votes.
This process we should try to keep and follow even though (or maybe especially because) we are not having a lot of development capacity right now.

Cernel

@frigoref Unless I'm missing something, I don't think currently we are even clear if and how (and where: here or GitHub) anyone is tracking feature requests at all, really.

This is how feature requests used to be tracked:
https://forums.triplea-game.org/topic/182/guidelines-and-feature-request-list

MagicStyck

@rainova said in TripleA development:

@magicstyck @djabwana If we work on accelerating the PR process, how much time would you then volunteer to TripleA improvements?

Like most devs, my time fluctuates based on work and family priorities. I could reasonable volunteer time of 3 hours a week or more.

What would be required to make these improvements worth the time for you?

PR reviews in a timely manner would go a long way. PRs that sit for long periods of time and never merge are annoying. PRs that are for documentation changes should be reviewed quicker than technical PRs.

Also not holding up the merge of PRs which are purely technical with non-technical objections. For instance: rehashing over and over the wording of comments or objections that it might affect something completely unrelated to the PR.

Would you be satifsfied with purely technical improvements like fixing the serialization and cleaning up the code base?

Absolutely. The goal, for me, is improvement of the software. Cleanup, bug fixes, closing gaps, is all part of that.

Would you expect that we can marshal the required dev capacity by merely improving the dev process?

Yes. In my experience, when the process is easy to adopt it is easier to inspire more people to help out.

Would it be worthwhile to discuss other ways to make development more attractive? If so: Would it suffice to adress the developers currently active in the TripleA community or should we try and recruit developers who are currently not part of the TripleA community?

It's always beneficial to discuss ways to attract others to help out, whether they are part of the TripleA community or not. It sounds like the current developers are burnt out and need help to move things forward. If someone is offering to help, whether they are in the community or not, let them help.

Making development more attractive comes as part of the cleanup. It has to be easy for a developer to setup an environment quickly and able to debug what is happening. If they have to jump through a thousand hoops to get started, your going to lose them.

frigoref

@rogercooper
Could we get an overview about the contributing people and their core area on the github Wiki?
https://github.com/triplea-game/triplea/wiki/Contributors

Would be nice if people could make their entry there so we have something that we can organize ourselves better.
@LaFayette Maybe you can list all users with merge rights?

ubernaut

@frigoref curious why i'm labeled inactive on your list

Panther

@frigoref
Also what do you mean by "area" ?

frigoref

@panther @ubernaut
Area wäre z.B. Maps, Development oder sowas. Wenn es so eine Unterteilung nicht gibt, kann man das auch weglassen.
Bitte gerne selbst pflegen und ggf. neu gliedern

Cernel

I don't recall I've ever known what I'm supposed to do if anything.

LaFayette

@MagicStyck

It has to be easy for a developer to setup an environment quickly and able to debug what is happening. If they have to jump through a thousand hoops to get started, your going to lose them.

Have you tried to seek out help about any of these hoops?
Which of these hoops have you had to jump through specifically?

@frigoref

@LaFayette Maybe you can list all users with merge rights?

https://github.com/orgs/triplea-game/teams

The team that allowed for 'write-access' was 'secret'. I updated it to be 'public', it should be visible now.

The main areas of TripleA are:

System Admin
- Make sure the systems are running
- Deploy software changes to the systems
QA
- proactively looks for bugs in the latest tripleA release. Specifically, they don't look around in just one area, but they try to execute every code path in TripleA possible, they click every button, every toggle, make every movement scenario and combination to validate that everything works correctly
Developer
- submit PRs on github
Development Maintainer
- Reviews PRs, they are the ones responsible for fixing problems post-merge
- Fixes pre-release problems (other peoples bugs)
- Fixes major live problems reported to the project
Project Maintainer / Leadership
- communicates about the project & project priorities
- arbitrator
Bug Triage / Issue Maintainer
- try to help people through issues
- ensure that issues have full information or close them
  - full information being things like "which map", creating a save game at the point of problem, etc.
Map Admin
- maintains map repository, ensures maps are well cataloged and made available for downloaded
Map Contributor
Forum Moderator
Lobby Moderator
Graphics/Designer
Treasurer

@Beelee

You propose a grand re-write. Those tend to go south and never wind up completed. The goal of 3.0 would be to make the system more modularized. As an analogy, instead of having one giant frankenstein monster, 3.0 would make that monster more like Mr Potato head, where we could more easily swap out the arms and legs. We would still have some large problems to solve, but though would be an order of magnitude smaller and generally much more tractable.

@djabwana

There are circular object references that break serialization to XML or JSON. The plan for save game is to only save the game data changes to disk. To do this we need to change the guts of TripleA to be able to dynamically build a 'game data' object using only a given 'map ID' and list of game data changes.

How much PR pain do you think there would be on a second pull request compared to the first one? IIRC a lot of your issues were due to being a new contributor and I don't think would have had the same issues on a second or subsequent PR.

Second, how do we fix review issues? I do recall there was some major problems introduced after several updates, problems which should not have happened. This is very salient because I think around 70% of all PRs introduce at least one bug. It then goes on to the maintainers to find and fix these. Hence, a first time code-submitter gets the worst of all worlds, issues that come up becuase they are not familiar with the project, and extra scrutiny because it's more than likely problems will be introduced and it's a goal that any contributor introduce zero problems. If the contributor agrees to be a maintainer, then the bar is lowered, otherwise each change needs to be well done and 100% correct (this is software, it must all be correct).

So, if we use the reasonable 3 hours per week standard, and it takes a good hour to review code, and another 10-20 minutes to test it; seemingly there is not much time to do that more than once or twice a week. How can we improve turn-around times in this kind of scenario? My thoughts were that we continue to add more automated review checks and continue trying to be unrestrictive about smaller items (perhaps you should have seen some of the blockers from earlier on in this project if you complain about keeping comments in sync with the code as too much of a a details as that).

MagicStyck

@lafayette said in TripleA development:

@MagicStyck

It has to be easy for a developer to setup an environment quickly and able to debug what is happening. If they have to jump through a thousand hoops to get started, your going to lose them.

Have you tried to seek out help about any of these hoops?

Which of these hoops have you had to jump through specifically?

When setting up my dev environment for this project over two years ago, it was a lot of trial and error to get it working. Documentation was old or flat out incorrect. When analysing the code base to work on a change, there are little to no design documents to help answer some of the basic questions. Over those two years some of those documents have started to appear but still large gaps exist. For instance, the legacy documentation lays out a design that the current software begins to deviate from. How much still applies? What does not?

Infrastructure code, which should be stored in separate repos, is in the root tree of the application causing bloating and confusion of what is import to running the code and what is not. I've worked with a lot those technologies so I know what to ignore as "not needed" when working on the code base. New contributors to the project will not.

Any change to the code proposed as an issue with how TripleA applies, even if it only affects the supported rulesets, is met with hostility based on "this might affect my game which doesn't use that ruleset", "might break game saves", and "shouldn't be considered because I don't agree with the Larry Harris accepted interpretation of the rule". There wasn't even a PR for the fix yet, just a conversation. https://github.com/triplea-game/triplea/issues/9067

No credit for work done. I helped out on a PR regarding Docker and NodeBB. I wrote the container and the documentation for it. I got a "thanks" and no credit on the merge. If you check contributors for that work, my name doesn't appear yet here is all my work. What does it take to be considered a dev or a contributor for this code base?

Original conversation: https://github.com/triplea-game/triplea/pull/7799
PR of the work: https://github.com/triplea-game/triplea/pull/7906

No response or direction at times. Conversations just die. I was loading a skin in the current release (2.5) and ran into an issue that has been open for awhile. I decided to help out on fixing it. I did the leg work, got stuck, reached out got a little help. I got a random statement about skin being different in 2.6 than 2.5. I asked if 2.5 is open for patching. Crickets. https://github.com/triplea-game/triplea/issues/8102

So yes, hoops. Hoops that discourage participation of offering up PRs to fix issues.

Second, how do we fix review issues?

I would suggest not holding up PRs based on non-technical issues. For instance, this PR (https://github.com/triplea-game/triplea/pull/9963) was not merged for over 2 months because of a disagreement on adding a comment line which could have really been added later. Was that comment line truly worth holding up a technical fix that was agreed would bring consistency?

I do recall there was some major problems introduced after several updates, problems which should not have happened. This is very salient because I think around 70% of all PRs introduce at least one bug. It then goes on to the maintainers to find and fix these. Hence, a first time code-submitter gets the worst of all worlds, issues that come up becuase they are not familiar with the project, and extra scrutiny because it's more than likely problems will be introduced and it's a goal that any contributor introduce zero problems. If the contributor agrees to be a maintainer, then the bar is lowered, otherwise each change needs to be well done and 100% correct (this is software, it must all be correct).

What does it take to agree to be a maintainer? What is the process? What does it entail?