TripleA 3.0 - Design Proposal & Discussion
-
@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?
-
@ubernaut imo, it was the roll-out of the new lobby and all the bugs when the new lobby became the only lobby.
-
I'd like to see the task/to do lists broken up a bit more thoroughly and actionably. Not that it's vital or anything.
It'd be nice to see what exactly needs to be done for 3.0 and 2.6, and what's being waited upon. What the new architecture is going to be in terms of package structure and calls and so forth. In particular I'm not sure how separable the various parts of the proposal are, and how much has to be covered as part of one big unified rework.
I also hope we manage to fix the issue with global and tww at some point, even if only as an eventual result of replacing the bots with the new network code.
-
@zlefin 2.6: https://github.com/triplea-game/triplea/projects/25
The biggest item is thorough testing of the 2.6 engine.
-
@alkexr said in TripleA 3.0 - Design Proposal & Discussion:
With 3D graphics there would be no such thing as a mapmaker, I'm afraid.
There are lots of map makers out there.
Choosing the right basis for our own work may become a smaller project of its own. Some are a joy to play with, e.g. Mapgen 4. (A much simpler map maker would of course do.)Also, what do you mean, look at the list of top rated games on Steam, most of them are 2D.
I did. The most popular games are 3D now.(Apart from classics and cookie maker). For TripleA 3 I think about something like the total war strategy map - or the game of thrones board game online. Freeciv web is unsing 3d units.
-
@rainova i think you are oversimplifying the situation i don't think personally, there's any real benefit to making this game 3D and it would come with a shit ton of overhead. the game is a 2D game, 3D would only be a graphical change and would arguably make the boards harder to see. also, the mapmaker doesn't just make maps its also is used to wire them up into playable map files. we have a lot of enhancements that are much more applicable to this game than just making it another 3D game. personally i'd would also argue there a ton of 2D grpahical enhancements that would have better impact on user experince.
-
Nice. On that project sublist, there doesn't seem to be issues attached to it in a linked way that can be edited; ie if I were try to working on one, how do we note that and avoid duplicative effort? Do we make new github issues for work on of those and put our details in there?
Is there already a thread or something covering the direct map download details? I might try working on that as something small and easy. But someone may've already started on it, and I have a feeling there's been some discussion fo it already somewhere, but I'm not sure where.
-
@lafayette I would be down and I've sometimes asked to play my 270BC Wars in the 2.6 lobby, but no-one has ever wanted to so far.
-
@zlefin Either open an issue to discuss & coordinate or open a forum thread. Either one would be a good place to outline the design and approach.
In the 'triple-dot' menu on the project cards, there is a 'convert-to-issue' option FWIW.
-
for me I'm not seeing an option for convert to issue on the project cards. The triple dot menu only has copy card link.
I probably don't have something setup right on github.
At any rate I'll see about opening up an issue soon.
-
(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
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.Could the second reason be eliminated: Why does the battle calculator make a copy of the game save data in the first place?
(The first reason for text-based save games still being strong enough to make it an important issue to move forward.) -
@rainova said in TripleA 3.0 - Design Proposal & Discussion:
(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
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.Could the second reason be eliminated: Why does the battle calculator make a copy of the game save data in the first place?
You cannot rely on the game file (xml) only, because how units behave and what units every player has access to may change in the course of the game (because of technology and triggers). The point is that only what matters should be loaded, not everything. My best guess is that nobody bothered making it efficient because, as long as you only play the basic games or such, it is virtually timeless anyway (unless maybe in case you play for hundreds of rounds, which virtually never happens). I believe that currently the game which suffers the most from it is "270BC Wars": I have to wait about 6 seconds for the battle-calculator to become usable.
-
To be continued in Topic 3077 - fast-battle-calculator
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