TripleA 3.0 - Design Proposal & Discussion
-
@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.
-
Documentation only fixes tangled code so much. Simpler core design will make documentation less needed and at the same time more useful.
The idea behind 3.0 is we redesign the major modules of the systems and create 'fire breaks' in between. A key question is how far can we go before breaking compatibility or before we hit the point of no return on a grand redesign. The idea is to get to that grand redesign, but exactly how is in question and needs design what it'll look like and how we get there.
-
@lafayette
Might this approach work for v3- Keep the current XML file structure as is
- A rewrite of the TripleA code (not from scratch), but taking code already written and rearranging it.
- Tempt past and present coders to stitch the code back together as they know they dont have to struggle/fight against the current structure.
- New code for the file saving format
From what little I know, the coders time could be better spent coding , than unpicking the old code, working around it and patching it up, putting patching on top of patching.
Yes the above will not have a working version for awhile, but hopefully it will be much leaner and cleaner.
A new XML structure format might be better in a later version say 3.5.
Just some thoughts from the side lines.
-
@thedog said in TripleA 3.0 - Design Proposal & Discussion:
From what little I know, the coders time could be better spent coding , than unpicking the old code, working around it and patching it up, putting patching on top of patching.
That is kind of part and parcel to the task, it is somewhat intrinsic and describes what has been happening now for 15 years.
A new XML structure format might be better in a later version say 3.5.
Having new core data structures could be very important for re-arranging the code. Patching it together sounds much simpler than it will be. Removing all constraints of the existing design could prove to be very important lest the fire breaks will continue to have legacy design that has been holding us down.
New code for the file saving format
Almost all of the core data structures are tightly coupled to save game. A 'unit' and the concept of a 'unit type' cannot have any alterations because those code objects are encoded onto hard disk. We cannot change them in nearly any way without breaking save game. An overhaul of how the code is structured and data is required to enable a new save game format. Those same objects are mapped pretty directly to the XML, revisiting this from the ground up implies it all may change drastically.
There is a lot of uncertainty here, though having a green light to make radical changes is a key component to 3.0. I'd rather release a 2.7 sooner. Though, we have been trying to rearrange and fix core code design for half a decade now, it does not seem to be effective enough to really be successful.
-
@lafayette How about these guiding questions regarding TripleA 3.0:
1. Community
- TripleA is created by an inline communit.y How do we want that community to be (size, communication within the community, productivity, identity,….)?
- How does TripleA 3.0 have to be to attract such a community?
2. End User Product
- What type of computer game attracts people in the years 2024+?
- Platform (desktop, mobile device, …)
- Genre
- almost three generations after WWII: should WWII really be the defining scenario?
- should TripleA 3.0 to the end user essentially be a collection of strategic war games?
- is it still attractive to resemble board games?
- Game Logic
- is a greater war really won because the victors could produce more/tougher battle units?
- is productivity really mainly determined by the territory you possess?
- shall 3.0 still be completely turn based? can we have the players wait less for the other players by doing something in parallel (e.g. choosing their production)?
- Prettyness
- will still 2D pixel graphic still do in 2024+ (we do have color!)?
- Attraction
- half of the investment of a normal media product (movie, computer game) goes into marketing What share of our efforts should go into marketing?
- Audience
- … or are we happy developing a game (gaming platform) for ourselves?
3. Technology
- How much is TripleA about the end user product and how much about playing with technology?
- Which technologies do we want to play with?
- Shall we go web?
4. Development Path
- How much work will this be`?
- Is it feasible? In what time?
- Do we need a continuous development path from 2.x to 3.0? How?
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