TripleA 3.0 - Design Proposal & Discussion
-
To give some outside feedback: I first tried triplea 4 years ago. I thought it had potential, but also many limitations. I recently tried it again.
The v2.5 release plays fine and there are some improvements to map xml (so thanks to the devs and map-makers for their continued efforts).
From a UI (user-interface) standpoint however, it isn't a huge improvement over v1.9: many of the issues remain.
I just tried v2.6 pre-release, the main thing I noticed was that it unzipped my existing maps in downloadedMaps...Even though it may not be the dev focus, I do hope v3.0 will offer some noticeable UI improvements.
Looking at the code, some of it at least seems quite easy to do, so I guess it comes down to individual contributions ? -
I'd like to see incorporating fractional numbers.
-
@schulz
I think you mean decimal numbers specifically for the variable createsResourcesList so you can have upkeep costs of say -0.2, instead of integer numbers ? -
@thedog Exactly, plus players wouldn't be forced to buy more than one of those units that have fractional costs (like in NML,NWO and WaW).
-
@butterw You were lucky with 2.6. An earlier version erased the majority of my mods without warning. (I had backups)
There were a lot of changes made in 2.6 with little community discussion. For example the mapName and Notes properties were deprecated.
Mods are now being stored in Github repositories as multiple files, rather than a single zip file. Github is an excellent tool for program development but is not very suitable for storing mods. We need to think about how mods should be stored & downloaded.
-
@butterw said in TripleA 3.0 - Design Proposal & Discussion:
To give some outside feedback: I first tried triplea 4 years ago. I thought it had potential, but also many limitations. I recently tried it again.
The v2.5 release plays fine and there are some improvements to map xml (so thanks to the devs and map-makers for their continued efforts).
From a UI (user-interface) standpoint however, it isn't a huge improvement over v1.9: many of the issues remain.
I just tried v2.6 pre-release, the main thing I noticed was that it unzipped my existing maps in downloadedMaps...Even though it may not be the dev focus, I do hope v3.0 will offer some noticeable UI improvements.
Looking at the code, some of it at least seems quite easy to do, so I guess it comes down to individual contributions ?There are a few UI suggestions from me in the Feature Requests subsection. For example,
https://forums.triplea-game.org/topic/1676/new-method-for-board-scrolling -
@cernel It's temptoing to remove the scrolling edges of the map at this juncture for 2.6, it would be an easy removal.
3.0 as described is already a 1-3 year project, I don't expect to see any UI improvements as part of it. OTOH, the UI will finally be far more modularized, it'll put us in a better position to do so.
-
-
In my opinion the UI is mostly ok and just needs some tweaks to improve the user experience. The fact that there is no massive UI overhaul planned for v3.0 should encourage potential contributors to make the required changes knowing their efforts will not be wasted.
-
Maximizing on screen map real estate should be a target, and fullscreen mode should be available. In windowed mode, the menu should be hidden by default and displayed with a hotkey (ex: Alt). The status bar could be used a lot more.
-
Mouse scrolling at edges can already be deactivated with:
Engine settings > Map Scrolling > Mouse Scroll: 0I tried out different values with the sidebar minimized and found that the scrolling confort was greatly improved by changing the default values on my system (tested on ww2_v5, with 90% map zoom, @1080p):
- Mouse Scroll changed from 30 to 5
- Mouse wheel scroll changed from 60 to 100
- Arrow scroll changed from 70 to 500. (I had forgotten about CTRL)
An enhanced version of the territory finder (CTRL+F) with a short-list of map specific favorites could be a great way to jump around large maps.
-
-
Some games use Ctrl+F1 to F4 to mark the screen and then use F1 to F4 to return to that marked screen.
-
Would be great to have the internal dice roller reinstated for forum games.
https://forums.triplea-game.org/topic/2151/feature-request-reinstate-internal-dice-roller
Often promised "for the next release", never implemented, unfortunately.
-
@panther i'm not sure i understand the utility of using the internal roller for anything but local/live games.
-
Please look here:
https://forums.triplea-game.org/topic/187/internal-dice-sender-cleanup
to learn about the background. -
@panther yeah i get what it is i just don't understand why. in a PBF/EM game what's to stop someone from rolling until they get the results they want.
-
@ubernaut Sure, I think we all know why an external dice server is offered and why one usually would prefer to use it.
But that is not the point here. The other thread shows why an offline alternative is useful in special situations..
-
@panther ok sure i guess there is some non-zero value to this feature but personally, i think we got our priorities mixed up if we are putting into this in front of the now long-standing bug where mac players cant play these kinds of games at all.
-
Instead of battling a feature that has been erroneously removed and its return has already been discussed consensually - just not been done - you could simply add your Mac-related issue to this thread.
I am sure that every user of this forum has his own ideas about priorities of this project. My requests are ususally based on my experience dealing with "the other" forum - but I have stopped expecting anything when asking for something already some time - if not years - ago,
-
@panther wasn't trying to change the subject (i actually considered this prior to sending the reply), but couldn't think of a better way to make my point.
i feel the value of this particular feature is extremely limited seems only useful for troubleshooting, not an actual PBF/EM game (at least not for any competitive game).
but now i'm repeating myself so I'll get off the soapbox.
-
Is there a list somewhere of which parts of the code are "nasty"?
I agree with the list/proposals, not that I expect to be much help with them. So frustrating dealing with this code sometimes.
For my own minor project I've been trying to figure out how to have the lock history option (discussed elsewhere). It's such a pain slogging through parts of this code; there's dozens of places with similar subsections, and it's not at all clear which one you're supposed to use, or how they all fit together, or if they're even being used anymore; and often you have two-line or nearly zero line functions, or interfaces, that just bounce through some other one line function and so on through several different packages. Is there a good flow diagram somewhere showing how all the various packages are supposed to interact to actually create the game? Can IDEA create useful ones?
How often are sections of code changed and/or they need to be understood for something? Many parts of the code have rather thin documentation in their comments, so it's not clear how they all are meant to fit together or do.
I had tried running in debug mode within IDEA and Tracing the actions, but that was no help in actually finding the portions of the code I want. In part cuz I'm not familiar enough with how to get it to work right with this setup; it seems very hard to know when to go into a function to get more detail (ie using Step into or whatever it was called), or whether to step over it. It goes through so many null or unimportant actions in the basic cycle of waiting for input, that it's hard to tell when it's even gotten to the input you wanted to see results for.
-
Is there a list somewhere of which parts of the code are "nasty"?
Most of it. There are some good designs at the core but a number of factors have come into play. We're seeing an example
of uncontrolled growth where so much was tacked on without overhauling the existing design. The code base out grew the original
design quickly and from adding on features without revisiting the design.A few items are particularly constraining and tied to technology. For example how save games are done, many core objects
cannot be changed or else it would break save-game serialization (compatibility). This in turn requires a person to work around
this and further degrade the design.Thus, we would try to eliminate some of these core design problems by redesigning key parts of the system, creating fire breaks and then grafting as much of the existing code onto these fire breaks as possible.
I would hope the updated lobby code is reasonable, that is the newest and is an example of a rewrite. There are still constraints in there that make it not ideal, but hopefully it seems far better than something like one of the delegates or battle logic methods.
I agree with the list/proposals, not that I expect to be much help with them. So frustrating dealing with this code sometimes.
Yes, I think developer attrition is largely due to this fact as well. It takes time to sink in but there comes a realization that these
grand plans are simply not going to come to fruition because it is such a slog.For my own minor project I've been trying to figure out how to have the lock history option (discussed elsewhere). It's such a pain slogging through parts of this code;
The history, and how bots are done are examples where the code was obviously rushed and the original design did not cleanly handle this. Furthermore technology gets in the way and some of the gnarly areas are because the swing code was not nicely split from the game logic. These are just examples of how the code base is difficult to work with and hence why a more drastic re-design and partial re-write is merited. At the end of the day I think we are not going to clean our way out of this and we need to start trying to re-write our way out.
Is there a good flow diagram somewhere showing how all the various packages are supposed to interact to actually create the game? Can IDEA create useful ones?
Not really, the package structure would ideally be restructured a bit to help with cohesion. Instead of having similar things be next to each other, we'd have related things be close together in packages. In this way the public API of the package is small and meaningful, but we are certainly not there. In part 3.0 would need to begin with an example of such a flow diagram, a system/architecture diagram essentially =D
How often are sections of code changed and/or they need to be understood for something?
Changed, not often. Understood, super frequently, most estimates are that for every minute you spend writing something, others speed a total of 20 reading it multiple times over. Now, also take into account the tangle you mentioned above where the code invokes other parts of the system, you have to read and understand those, and anything they call. Because the system is designed so, there is a massive spider web of code that must be read and understood to change much.
I had tried running in debug mode within IDEA and Tracing the actions, but that was no help in actually finding the portions of the code I want. In part cuz I'm not familiar enough with how to get it to work right with this setup; it seems very hard to know when to go into a function to get more detail (ie using Step into or whatever it was called), or whether to step over it. It goes through so many null or unimportant actions in the basic cycle of waiting for input, that it's hard to tell when it's even gotten to the input you wanted to see results for.
Conditional break points can help here. It's not easy overall though, and time consuming.
-
@zlefin said in TripleA 3.0 - Design Proposal & Discussion:
How often are sections of code changed and/or they need to be understood for something? Many parts of the code have rather thin documentation in their comments, so it's not clear how they all are meant to fit together or do.
More comments in the code would be better IMO.
I haven't used the debugger so far. I'm using object introspection, stack trace functions, and print statements:
- obj.getClass().getName()
- Thread.currentThread().getStackTrace()[1].getMethodName()
- public static void pn(Object obj) { System.out.println(obj); }
There is also a Lombok @Log logging module.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login