A new Javascript build from the ground up
-
I'm starting to learn programming through a year-long series of classes; we'll be covering Javascript, HTML, CSS, React, Node, Express, Postgres, some of those maybe not, maybe others added if curriculum changes. For my portfolio project I'm making a new TripleA in JavaScript. I will not be receiving support from the instructors, they're responsible for administering the curriculum at a certain pace.
I expect I could do it alone, but I know I'll save loads of time and do way better if I get ideas from the community - developers, players, or even non-players that hear about the project that want to chip in.
To anyone commenting, I shall be very clear, my expectation is comments and references do not entitle anyone to copyright or trademarking. I'll be running the show in terms of deciding what's put in, it's my portfolio project. I don't expect to finish the project within a year, it might be quite a while, I don't know how long it'll be just yet.
Things I'm currently seeking information on:
-
What's an effective way to read and write data? I'm figuring on representing the entire history of the game, including dice rolls, in a JSON file. What I don't like is the file would be rewritten at least three times a turn plus any manual saves and would be pretty large. Maybe even rewriting a pretty big JSON file wouldn't be an issue? If there's another particular file format that has low read/write overhead, what is it, specifically?
-
What graphics program should I use to make the map and pieces? The display has to convey information effectively on phone screens, and I want to use very low system resources. Ideally I only want to re-draw areas that have been altered, I think. I do plan to include a utility to facilitate user-created boards, and user-created pieces (and user-created rules, and to make it all as easy as possible).
-
I'll be supporting in-game chat, a note system, written, audio, and/or commentary files that can be turned on/off to play simultaneously with game replay, badges, seasonal play, campaign mode, PvE mode, and "commander" decks drawing random cards. Game statistics exportable to .csv format, and data analysis charts, graphs, and summaries. Any recommendations for packages or other things I should look into in those regards are welcome.
-
Suggestions are welcome but may not be implemented.
Any comments or suggestions that want to be acknowledged in the (eventual) release, please leave a name to acknowledge you under. It'll be at least a year until first release (if then).
Why not just go with TripleA? I've heard the Java codebase is a dinosaur, plus I'm learning JavaScript anyways.
If TripleA mods approve, maybe this could be split out to its own forum. Altered gameplay, commander decks, data analysis, commentary system, AI functionality, and a lot of other features planned for inclusion with this project aren't in TripleA.
-
-
@aardvarkpepper this is an open source project you can do whatever you like in terms "doing your own thing" but any derivative work would still be covered by the OS license and as such you would have no copyright or legal rights in terms of said work.
not a lawyer but that is my understanding
-
As I understand it, what I'm working on won't be covered by the OS license. Not using TripleA's code, not even parts of it.
-
deja vu no wai
-
Quoting lafayette from another thread:
The major initiatives we have right now is to:
- Change how game data works and save-games work so that we have 'game-change-deltas' which stack on top of each other. Right now 'GameData.java' is a god class that maintains the current game state and when the game is saved, this is serialized to disk (via java serialization). 'GameData.java' represents the latest in game-state. Instead of this, we would want to have as a starting point a map (which can then have its data loaded on-demand) and a series of game-change objects. From this we could re-create the latest game state by using the map data as a starting point and then applying the game-deltas.
When a player opens Game History and rewinds the visible state, then what happens? Right now, GameData.java contains the current game state, and when a player accesses Game History, GameData.java looks at . . . what, a separate JSON file? or is it already loaded into memory? and makes changes to the visible board state by "undoing" moves? Is that it?
Far as applying game-deltas, why is that? I'd thought to do something similar; I was thinking maybe if I'm having a single big JSON file and constantly overwriting it, that's going to be hard on system resources (even if JSON files are small, rewriting a file that's 99% the same, seems like little point). Also sending small JSON files back and forth means less data usage (on phones especially). The question is what happens with the small JSON files. I figure they have to be recombined into a main file eventually for when a player wants to view the game's full history, or output the game's full history to .csv. Sound right?
- Remove the headless-bot code in favor of network relay.
I don't know about networks yet. Oof. But I want to avoid port forwarding - but also allow players to play multiplayer without needing to go through a server. That's going to be a bit weird, yeah.
But this 'relay' server thing - basically Blizzard's Battle.net?
One of which is 'turn planning', allowing a person to 'plan' their moves async while another player is taking their turn. This would look a lot like edit mode except we would keep a history of the pending moves (and/or purchases) and allow a player to 'replay' those moves when it is their turn. This would potentially really help speed up game play.
I'd thought to speed up gameplay too, but by adding features that change gameplay, UI visualization, and minigames for while a player wasn't actively taking their turn. But pre-moves, yeah, super. I could do a variation of that with the templated AI assistants that'll be in my build, I like that a lot.
If we could represent units as "unit-type+count" rather than representing every individual unit, some algorithms would become a lot easier and a lot faster (specifically in the battle-calculator code, which the AI is heavily dependent upon for performance).
So the AI is using a battle calculator, which is about what I'd thought. It isn't using attack/defense value plus double hit points, or something like that, somewhere? What is it, 40-50 runs, or 500?
I'm working on a binomial calculator that doesn't use RNG; it calculates the true probability with small errors introduced from rounding and binary. I wanted to express results in fraction form but denominators get too big too fast. I don't know yet whether it'll be faster to calculate or access from a table; your thoughts on what I'm working on (low requirements on mobile) and/or if it would be suitable for TripleA?
The network code was designed such that it was transparent if the game was being played single player or multi. This has a lot of the 'bridge' and 'delegate' concepts that you'll find throughout the code. The overall concept is good, but the code backing the 'bridges' and 'delegates' we are working to replace with JSON over websocket communication to simplify (compared to a custom Java network serialization protocol that TripleA currently implements).
I haven't much of an idea when it comes to networks. But is it something like, if turn order is USSR, Germany, UK, Japan, US, if UK sends its turn, then it's the JSON for USSR, Germany, and UK? The game checks to see if any illegal moves are performed during UK's turn and if so bounces an error and request a re-send; if all moves are judged legal then it checks through USSR's and Germany's turn that was sent, versus the local JSON of the recipient. If the sent and local files match, then the local JSON is updated with the JSON sent over the network with UK's turn.
Or do you have some sort of validation to check to see if UK's turn is corrupted? Or if not, then how are discrepancies between sent and received files handled? Unless a master copy is kept on a server; but I'd like to avoid the need for a server for player versus player direct connection games. (though still having a server option where validation is important for ranked play and things).
-
@aardvarkpepper Unless you plan to maintain compatibility with the existing mods, why do TripleA at all? Create a new project for an area movement wargame engine that is capable of playing Axis & Allies style games and avoid the technical debt of TripleA.
-
@rogercooper Well yes, new project is what I had in mind. TripleA is Java, and I'll be doing JavaScript. It sounds like the two are related, but not so much.
But I do want to get input from the community. Others are going to have different takes on solutions than what I'd considered, and the earlier I can build with those in mind, the better.
E.g. time between turns. I know chess has implemented pre-moves on various platforms. But I hadn't considered implementing it in Axis and Allies, though it does make sense. What are you going to do to occupy your time while other players take their turn? I'd thought, build in other features. But pre-moves would often shorten a player's turn length, which would mean everyone plays faster, which cuts down on game time. That's a really big improvement that I can't ignore.
Then there's lots of things that veteran developers would be able to advise on, like things to watch out for programming for multiplayer (even for turn-based), maybe someone's got some proposition for how casualty removal should be allocated. Having a few "defensive profiles" as they did with 1942 Online just isn't nearly enough at all, but automated controls will be cumbersome. I have a few ideas on that score, but it could be someone has something elegant and simple that I just haven't considered (like pre-moves on other players' turns.)
As to compatibility with TripleA, I'd like that, but that would require a discussion on . . . what would I call it, the data structure of each of the programs? Which is a thread subject of itself, and there's the documentation things going on.
-
@aardvarkpepper said in A new Javascript build from the ground up:
and I'll be doing JavaScrip
That would allow for playing in a browser or as standalone app using browser technology (Electron), isn't it?
-
Yes.
I'll be building a lot of server connectivity into the application as part of my portfolio project, and I expect I'll be porting to a different language after a year. So parts of it won't be browser standalone. But singleplayer won't require online connectivity.
-
@aardvarkpepper Sounds good. Would that require the current game-xml-files to be "rewritten" in JSON ?
-
I'd never require anything of TripleA developers.
The way I figure it, I build out my portfolio project, get implementation suggestions from developers and feature suggestions from the community. If the project works and becomes popular, then I'll definitely be looking at .xml and JSON.
If my project depended on TripleA data files, then I think the GNU General Public License might apply. Wouldn't want that. But I believe compatibility with TripleA data files would effectively bring loads of existing assets to my project without my needing to surrender license rights.
-
@aardvarkpepper If I understand things correctly, XML files can be automatically converted to JSON.
-
@aardvarkpepper content would be covered by copyrights of original creators if i'm not mistaken
-
@ubernaut If you're referencing copyrights of original creators for mod files for TripleA (like BigWorld and such), good point. (Was that what you were referencing?)
Doing things properly would require contacting all authors involved with a mod and obtaining their permission before trying to port anything over. Even if it weren't a matter of legality, it would be proper.
Thanks for making the point. If that's not what you were referencing, oops. (But a good point to consider regardless.)
-
@aardvarkpepper yup
interested to see what u r cooking up! -
Recommend this reading: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
I'm a bit concerned you'll find the "90% done, 90% left to do" could become a problem. Notably the scope of what you are undertaking is quite a lot. Generally I think we will be best off by continuing to modularize the larger components in TripleA which would then allow us to divide-and-conquer and rework those components in more isolation.
There is no issue if you write something that is able to read map XML files. Though, the XML format is highly coupled to the internal representation of the game, so you will likely find that it's unnecessarily convoluted (for a ground-up project) and not necessarily flexible in ways you might want. I suspect the game (java) representation was done prior to the XML representation and hence it not being a good generic fit.
Right now there is no way to represent the save game state as JSON. The idea to move the game state to be a series of 'deltas' would be to change the way saves are stored on disk. Notably instead of having an absolute record of truth (the one game save representing the latest state), it would be more of a ledger system. Bank account balances work that way, the bank does not store "you have $10", they store "you started at 0, then added 2, then subtracted 1, then added 9"
-
@lafayette lol that guy is a funny read
