TripleA development
-
How far is 2.6 from completion?
-
@lafayette said in TripleA development:
To solve this, there are some major projects we can do, but the easiest and fastest way is to rip out unused or hardly ever used features.
So @RogerCooper made a good point about triplea currently "being" a mature project at this point. I wonder if 2.5 stable should be set aside and only have critical updates such as :
https://forums.triplea-game.org/topic/3124/nodebb-1-17-and-later-breaks-pbf-compatibility/11
added when necessary and then 2.6 and future new stuff could be added in the above quote.Basically 2.5 is a stopping point. Do the rip and tear and make a newer and better triplea. Hopefully less frustrating for developers and encouraging new people to contribute, while still keeping the current game going.
I'm gonna ping you guys, what does @RaiNova @frigoref @RoiEX @djabwana @ssoloff @redrum @tvleavitt hmm ... guess idk his. W/e missing some others too.
For non Develop type coder people @Panther @TheDog @Cernel @RogerCooper @wc_sumpton @ubernaut @SilverBullet think ?
Apologies to the main users I've missed, but all should chime in anyway
-
@beelee I think that is good idea. 2.5 stable only receives critical fixes. 2.6 has ripped out unused features or hardly used features. This is where developers, like myself, who want to contribute to the project can come in to help and not be burdened by possibly affecting the outdated features or designs of the older code base.
I would suggest that you start with no backward compatibility between save games of 2.5 and 2.6 until you can prove that the fixes to the current game save corruption issues will allow that compatibility to be honored.
A clean break also gives the team a chance to reexamine some of the design choices for how maps are created and consumed by the software. Major changes might have to be made over slow deprecation of tags/files. A conversion tool for map makers would help to take the sting out of the change.
-
@magicstyck right on Yea idk if I explained it that well but current prereleases seem to be putting bandaids on the existing stable. My understanding is that if you fix this, it could mess up y, that could mess x and t and then that could ...
Anyway, making it not attractive to work on.
Just call Triplea done and basically start over. tic tac mode if needed
Just a thought not a critcism or a bad one anyways lol
-
@magicstyck How important is backwards compatibility with saved games? I would expect to play a given game through with the same version. Backwards compatibility with mods is more of an issue.
If someone has the time, skills and energy to restart from scratch, I would be supportive. Especially if a new effort had substantial compatibility with existing mods.
-
@beelee not sure i can give an opinion unless i know what those "unused features" actually are.
-
@beelee said in TripleA development:
...
For non Develop type coder people ... think ?I would agree of course.
My current problem is that I simply do not understand 2.6.
Until 2.5 stable it was sort of easy to me to follow development. I understood many of the pull requests, I understood improvements of rules compatibility, I understood UI improvements.
With 2.6 I somehow got lost. Most of the pull requests became sort of cryptic and not understandable to me. I saw some fixes with to me unclear consequences regarding game play (such as rules compatibility for example). As far as I understand it the reason might be that 2.6 development started to have a somehow different approach. Also it might be caused in my person, of course, as I am getting older and maybe my understanding of current programming decreases.
I am somehow afraid that - in case 2.6 would be released "soon" - who will care to transport the "news" to the users? Currently the users do not seem to have the highest priority. As some really disturbing issues don't get resolved. In the past I have in most cases been able to help users out of trouble.
Currently - when it comes to unresolved issues or 2.6-issues - I - in many cases - can only point to the Github issue cue - where most of the issues get hidden in the mass. Who is going to help me with user support?Again - this is not a complaint from my side. There are only a few active people who care. Our time is limited, our priorities are different.
This is again just another description of my worries, of my feeling concerning the status-quo.This is why I would definitely vote for 'optimizing' or 'repairing' the current stable.
-
@beelee Do the rip and tear and make a newer and better triplea.
@LaFayette How much work would that be? How would we get the developers invest their time?
@ all: How much should a rewrite still be a tribute to Axis & Allies?
- Would you require all variations of sub vs. destroyer/fighter?
- Must the game engine support turning a damaged unit into an infrastructure unit that is than converted to a winner's unit of the initial type (that's how BC270 Wars handles walls)?
- Must the UI still imitate the battle board of the board game or would zooming into the battle territory be near enough to A&A?
- Would we again have Napoleonic Empires without Napoleon?
- Would you be keen on better music/sound effects?
- Should the game engine support parallel playing?
-
@rainova
The initial rewrite must be able to read most of the current crop of maps/scenarios, otherwise their will be no maps/scenarios to play.Initially no extra functionality should be added to the rewrite as that will just add to the development and testing time.
Subsequent versions can add functionality.
The devs should design the new version with the future direction in mind.
Just my 2 cents. -
@thedog the rewrite/new stuff should be independent of what is now. What is right now should be kept the way it is and people can continue to play for as long as there is enough interest and a couple hundred bucks a year to keep it going.
-
@beelee I agree we should get the open issues under control. I've started a thread dedicated to that.
-
@thedog said in TripleA development:
The initial rewrite must be able to read most of the current crop of maps/scenarios, otherwise their will be no maps/scenarios to play.
Agreed. I'd suggest not requiring to be able to load games saved with 2.x.
Regarding subs/destroyers/fighters I'd suggest to only support the version considered best by the players - with the devs having a say if a slight variation is technically much better.I also agree, that we might throw over board supporting some maps - especially in the early versions.
@Cernel
Regarding walls to be taken over by the winner of the battle: I support this requirement. But it should not be based on the current non-infrastructure/infrastructure concepts. The devs should come up with functionality supporting such a feature not accitently but by design - so the code is comprehensible. This also applies to the "just conquered" markers in BC270 Wars: They should not be implemented as units (requiring territories also being units), but as a feature of its own. -
@rainova said in TripleA development:
@beelee I agree we should get the open issues under control. I've started a thread dedicated to that.
yea I feel bad as my limited skills can close few of them. Gonna be a thousand soon.
-
@rainova said in TripleA development:
@Cernel
Regarding walls to be taken over by the winner of the battle: I support this requirement. But it should not be based on the current non-infrastructure/infrastructure concepts. The devs should come up with functionality supporting such a feature not accitently but by design - so the code is comprehensible.I disagree. Although it can be based on a more direct feature (whatever that would be), the current way it is done is good too and totally neither incidental nor even a hack. It is all based on a series of actually supported features, acting as intended: that units may turn into other units when taking damage, that this may happen also when the damage is equal to their hit-points, that some units ("infrastructures") cannot be hit by normal attacks and are conquered with the territory, and so on. None of the features used to implement the rule is doing anything more than what it is supposed to do, as far as I know.
This also applies to the "just conquered" markers in BC270 Wars: They should not be implemented as units (requiring territories also being units), but as a feature of its own.
I disagree that what said for the previous case applies to this one too. This case is near-to completely different from the previous one as the markers are actually doing nothing substantial: they are merely visual aids for the players (the game plays the same if you remove them in the code within the game file). However, I would agree that the TripleA program should visually indicate what are the territories conquered during the same turn, if it makes any difference, but it does not, so I used units to hack it. I guess the reason why such an obvious feature never existed is due to the fact that, in the simple basic games, only the placement of new "factories" is influenced by this, and you place such units rarely enough that it is easy to remember what are the territories which you conquered on the same turn.
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.
-
My thoughts concerning
@rainova said in TripleA development:
@ all: How much should a rewrite still be a tribute to Axis & Allies?
The tribute to A&A (at least) to me is the fundament of my identification with the project.
TripleA does not stand for "Armies Attack Arbitrariliy". It stands for
- Would you require all variations of sub vs. destroyer/fighter?
TripleA requires the support of the core rulesets to enable play on current and future maps as well in current as in future TripleA versions.
- Must the game engine support turning a damaged unit into an infrastructure unit that is than converted to a winner's unit of the initial type (that's how BC270 Wars handles walls)?
The game engine should support customizations and specialities intended by map makers.
Currently sometimes a workaround is needed to achieve intentions.- Must the UI still imitate the battle board of the board game or would zooming into the battle territory be near enough to A&A?
What would "zooming in" show then? IMHO the "conduct combat phase" is not about territory sightseeing . But about resolving the conflict represented by the battle-board. To me this is somehow the highlight of every turn.
- Would we again have Napoleonic Empires without Napoleon?
This is not an engine topic but a quick fix within the map repository in case someone misses Napoleon.
- Would you be keen on better music/sound effects?
No. That's just distracting bling-bling in my opinion. As well as eventual graphic "enhancements".
- Should the game engine support parallel playing?
No. That'd be a totally different game. Of course that might maybe be interesting in another context.
-
@panther said in TripleA development:
- Would you be keen on better music/sound effects?
No. That's just distracting bling-bling in my opinion. As well as eventual graphic "enhancements".
I think sound effects deserve some love. I think that out there there are many less popular free games which have better sound effects than TripleA. Sometimes I think the sounds in TripleA are so poor that it is worse than not having them.
I think the two main things to improve, regarding sound effects, is allowing having per-unit costumized sounds when placing and when selecting units and having background sounds, possibly multiple background sounds per map, so the user can pick one.
Example:
https://forums.triplea-game.org/topic/275/units-specific-placed-sounds -
Maybe. Of course this is a question of personal "taste". I always turn sound off when using TripleA. But of course I understand your ideas / use cases.
-
-
Also, turning on/off map sounds should be a setting per map (or, more precisely, per skin) (like the "zoom" setting). Meaning that you should have sounds on every time you open a new map, and turning sounds off should affect only the skin of the map you are looking at.
-
I would love to rewrite some of the low level stuff and have some ideas on how to do it, I'm just short on time.
The biggest issue I see is the game file format itself. XML is fine, but we should use an XSD not a DTD and have the structure of the file reveal more of the available options instead of relying so much on generic properties with weird operators (like splitting a string on colon) that require extensive documentation.
The biggest benefit too is that map makers can leverage xi:include to include fragments of common elements (like units) into mods/skins/whatever.
Then we can also code generate the map saving/loading code with JAXB, removing a ton of boilerplate and and making games backwards compatible instead of using Java serialization.
But yeah... so much to do at my job and I have a family, so not too much time to do work stuff but for fun!
