TripleA 3.0 - Design Proposal & Discussion
-
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
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?
-
@rainova Some questions coming from a greater perspective... but the wrong one. Your perspective is that you want to create a modern, succesful game with many players. And I think that simply isn't the goal of this community. Sure, it'd be nice, and we'll take it if it comes along the way, but that isn't the goal. There are certain fundamentals that make TripleA what it is, for example the core loop: build an army, conquer new territories, collect more income, build a larger army, repeat. Staying true to all these fundamentals, maintaining compatibility with the hundreds of maps we already have, etc. are the primary goals, and all future improvements need to respect that.
almost three generations after WWII: should WWII really be the defining scenario?
Well, I've personally invested significant effort into inventing ways to make a non-WWII map interesting, and I agree that there is much more potential left untapped here. However, the game rules have been invented to model WWII, so it shouldn't come as a surprise that the rules fit WWII the most.
will still 2D pixel graphic still do in 2024+ (we do have color!)?
With 3D graphics there would be no such thing as a mapmaker, I'm afraid. Also, what do you mean, look at the list of top rated games on Steam, most of them are 2D.
half of the investment of a normal media product (movie, computer game) goes into marketing What share of our efforts should go into marketing?
Well, I've considered doing let's plays on YT. But I think you get the wrong idea. Right now it's pretty much @LaFayette working mostly alone on the code, plus like three-ish mapmakers that are somewhat active.
The question I think you are really asking here is whether or not TripleA is the game you are looking for - which is a perfectly legitimate question to ask! In many ways it would be much easier to create another game from scratch that is at least somewhat inspired by TripleA, and maybe that is your path forward, only you can tell. But I don't see why the TripleA community, which is glued together by the shared interest in TripleA, would also coincidentally have a shared interest in another, very different game.
In spite of all of the above, your perspective is a nice one to have, and your questions will probably lead to a productive discussion.
-
2D graphics will still be a thing in 2024 and can benefit from higher resolution/larger screens (1440p>1080p).
Nothing wrong with trying to build a new strategy game from scratch with an updated set of objectives, but TripleA 3.0 is more about trying to keep the old game running.
A suggestion for Technology: maybe improvements in machine learning will make it to the mainstream and can be used to improve future game AI.
-
@rainova I think implementing a simultaneous turns system (everyone takes its moves secretely, and, once everyone is done, then all moves are sent to the host and applied simultaneously) would be awesome on many levels. It would be much better if also a timer is implemented with it. The moves may be unlimited or somehow limited in number (default unlimited).
A recent game by Larry Harris, called "War Room", is an example of simultaneous turns system (I'm not saying to copy that: it's just an example of the concept.):
https://drive.google.com/file/d/1rXOjH5WIny_9AqpfJFTVu6dK5A4X_OdJ/viewAnother example of the concep is Diplomacy:
https://en.wikibooks.org/wiki/Diplomacy/Rules -
Can the 256px baseTiles and reliefTiles be done away with and the whole 2 layers of the map be read as just 2 files?
Each file could be of the order of 8000 x 6000px.
-
@cernel I think implementing a simultaneous turns system (everyone takes its moves secretely, and, once everyone is done, then all moves are sent to the host and applied simultaneously) would be awesome on many levels.
Have you played Diplomacy in real? I did as a teenager: When the parents of a friend were out for the weekend, we used the whole house: The map laid in the living room, and then we retreated for negotiations who supports whom in the next move. It's still (after more than 30 years) an awesome memory
It would also allow simultaneous attack by multiple players, which IMHO TripleA is badly missing (including a player changing sides during battle
). -
@cernel larry said in a recent interview that all of his games going forward will be simultaneous turns
-
@cernel Simultaneous movement and resolution would be big change, probably require a completely new engine. I am not sure it would be a worthwhile endeavor.
Much of the tactical element of TripleA involves the need to consider counterattacks. This would be lost with simultaneous movement.
Diplomacy achieves simultaneity by using an extremely simple combat model and a very limited number of units.
War Room uses simultaneous orders with sequential resolution, a workable compromise. This can be done in a computer game, but it will look very different than TripleA, Take a look at the computer version of the Game of Thrones boardgame for a good implementation of this sort of game.
-
i am not a tech guy, i am just hoping we have less issues going forward. we lost a lot of players with the latest lobby roll out.
-
@rogercooper said in TripleA 3.0 - Design Proposal & Discussion:
Much of the tactical element of TripleA involves the need to consider counterattacks. This would be lost with simultaneous movement.
Interesting observation. Two considerations:
- It would be advisable simultaneous turns to be customizable per game so to make groups of simultaneous turns so not necessarily involving every player (you could then have simultaneous turns for all Axis and for all Allies separately, for example, so 2 turns per round).
- It would be very interesting to add the possibility of not forcibly resetting states every round so that, for example, all units that moved on a round will be unable to move on the next one (so making them unable to reposition themselves before a counterattack on the next round).
Especially the feature number 2 would be great to avoid simultanous turns reducing the strategic chess-like value of the game.
-
There is a longer topic here, but essentially TripleA 3.0 would serve to solve the big-ball-of-mud problem.
There are a lot of interesting things we could yet do, but are constrained. Furthermore the code is very brittle because concerns are not separated and testing is left to mostly manual or end-to-end testing. Overall the efficiency for updating the code is just extremely low, it is very time consuming for minor updates. This is due to updates being piled on top of one another without better engineering the underlying code, by multiple different degrees of quality being used, etc. For example, the casualty selection algorithm is a holy mess, how units are rendered on the map is a mess, how units are created in code is a mess because it requires a full reference to the full game data object (so in effect every game entity has a direct link, is coupled, to every other game entity).
But let's go back to the OP and the goals of 3.0:
(1) converting network code to be websocket (remove java.nio sockets).This would modernize the network code and allow us to build more features that use networking. Today it's a custom RPC framework and if it goes wrong it's a nightmare to troubleshoot. There was a feature to manage bots that was done via RPC and broke, after nearly 8 hours of debugging there was no progress made. 8 hours for no result, and this is just one network integration.
(2) implementing a network relay server to replace headless botsThis would reduce some of the major pain points in TripleA of unstable bots. Our number 1 cost, about 70% of the TripleA operating budget is bots. We would also be able to scale far better and host almost unlimited bots in a transparent manner.
(3) Text-based save games. Rather than serializing java objects we would instead store text based game state changes.This would fix a lot of the problems in the data model. We'd be able to unit test far more easily, second we would have a lot more room to make changes and maintain compatibility in a far simpler manner. Today there are a number of changes you just can't make because Object A is serialized, and object B and C depend on that, so you can't modify C and B as you would want (and if you do, it silently breaks save games).
Second, a text based save would be far faster to serialize and we could get a 10x increase in AI performance by doing this. Most of the time AI spends 'thinking' is doing battle calcs, the long pull on that is serializing game save data. If we convert that to text it'll be faster, but also the data model would be much improved and perhaps that step could be cut out completely.
Then there is the bottom line where the technical debt of TripleA has been for a long time past a tipping point of where future development is not really feasible. It's just the case that no one person has enough time to do everything that would be needed to make moderate improvements. So we need this to fundamentally change so that development is easy and we wouldn't have a series of developers come and go (it's a pattern, folks contribute for a few months, realize it's a mess, that the cost/benefit analysis is actually completely skewed towards cost, and then people just don't have enough time to pay these absurd time costs).
-
So, TL;DR, 3.0 is a plan to redo the underlying architecture of the TripleA code to drastically pay down a lot of technical debt items that are otherwise effectively killing the project.
-
Off-topic, I really hope 2.6 will be released soon. Map-makers have been in a limbo for the better part of a year, with a prerelease they can tune the maps for which is considerably different from the release the community plays them.
-
@silverbullet what exactly happened that caused so many people to leave?
