Simplify Starting PBF Games
-
So currently we have a lot of people struggle to setup PBEM/PBF games for things like tournaments. @prastle brought up some good questions around why can't we make it easier to get started and have TripleA do more of the work. This is especially true now that both this forum and A&A uses the same technology/API.
So the first suggestion is could TripleA start the PBF thread for the user rather than the user having to go create the thread and copy the thread ID into TripleA? Instead they choose to start a new PBF game, select which forum, and input a title. I assume the forum API has a thread creation method and if so I'd think this should be pretty easy.
@RoiEX Any thoughts here? I know you originally wrote the new PBF code for this forum and I essentially extended it for the A&A forum.
There are some other ideas then that extend this concept if we get it to work for PBF. An example is we could create a 'ranked' or 'recorded' field for lobby games that then creates a forum thread to post their games to.
-
@redrum TY
-
@redrum Good points, creating a thread isn't difficult via the api, just another request.
Simplifying the whole process is a little bit more complicated though.
Before starting to think about this, I want to simplify the code first. (Finish my current project)
We could indeed hide the topic id from the user if we simply created the thread via the client. (Not sure how to check exactly if this is a new game, but I'm pretty sure we can check if the history is empty or something.)
Thinking a step ahead we could potentially also have the engine close a topic once somebody wins the game, to be cleaned up by admins. (Can potentially be automated, or half-automated (requires button click) via a custom plugin too). -
I just dug through the code and found a couple of interesting things:
The "Game ID:" Field is something in between misleading and useless, all it really does is change the prefix of the subject in mails (i.e. Replace "TripleA" with something else):
So really the whole field can be removed as nobody probably ever knew this.Also the new dice-server doesn't really support multiple CC addresses for security reasons anyways, so sending an email to an independent third party anyways wouldn't work either in the future unless someone implemented it.
Given that even with a dice server that sends out emails it's hard to 100% verify the savegame wasn't modified in any way (it's certainly possible, but I don't think it would be worth the time checking every single detail every time a turn is made), PbEM/PbF is probably not well-suited for competitive gameplay unless you can be sure nobody is going to cheat (a sudden additional unit in some random territory would probably not be noticed for example). -
What I'm trying to say is that there is certainly room for simplification, by simply removing unnecessary options and adjusting the UI appropriately to guide users through the process.
-
@RoiEX The Game ID field is actually really useful though can be optional if it isn't already and yes probably isn't labeled that best name as its really just a email title prefix. The reason is if you have 5-10 PBEM/PBF games going and are looking to review the rolls for a specific one, it would be close to impossible without some kind of prefix on the dice emails.
Generally, competitive TripleA games are played using PBEM/PBF not the lobby. The way players verify that someone isn't cheating is checking the dice rolls and reviewing the turn history. While you could probably find ways to hack these, it would be fairly difficult and not aware that anyone has ever done it successfully.
Not sure what you mean by not supporting multiple CC addresses. We definitely need to support sending dice rolls to more than just 2 users for team games. Though the difference between TO and CC doesn't really matter and I think they could be combined.
-
@RoiEX Personally I find both IDs (thread-ID and game-ID) extremely useful. While I understand the desire to keep things as easy as possible for every user, those IDs are handy for searching and sorting topics/mails (as @redrum said, too).
Just one of my use-cases of thread-IDs: When testing pre-releases or creating/testing scenarios I always post fragments of games into one of my "test-threads". So whenever there is any fragment I want to post to the forum, I use one and the same thread-ID. I would not want a new topic for every case, then.
So when thinking about hiding the topic-ID from the user I would welcome very much an option to enter a given ID into the UI in order to continue posting there whatever I want. Other players would maybe welcome the opportunity to post multiple games into one and the same thread.
@RoiEX said in Simplify Starting PBF Games:
Thinking a step ahead we could potentially also have the engine close a topic once somebody wins the game, to be cleaned up by admins. (Can potentially be automated, or half-automated (requires button click) via a custom plugin too).
In that case we should also consider how to keep/archive the very last savegame of every game.
-
Some good ideas here. If Triple-A was creating the thread, the Game-ID would presumably be the topic/subject or whatever you call it.
I presume the thread number is returned from the API call to create a new topic? Otherwise it won't work. I don't really see the need to hide the existing options though.
One of the limitations of the dice email system from the point of view of cheating is anyone can download the game and roll some dice, perhaps accidentally. So you can't really hold your opponent to the dice you've received because they can claim that possibility.
Not sure I like the idea of closing the topic on game completion. Wouldn't it only work if the thread starter won? Also, there's the issues with the victory conditions not working properly (checked at the end of round - wrong in Global). Finally, there's people playing non standard victory conditions.
-
while I'm thinking of it, ctrl p doesn't post to forum. Does the Players thing instead. Which I like. Just might want to update that next time it's convenient.
-
Can I suggest the scope of this in any phase one should be limited to just creating a button on the front screen near the "Test Post" button which will create the thread with the subject set to the "Game ID" and update the "Topic Id". Perhaps have it autostart after that, would that save confusion?
Otherwise it's just too unmanageable and unclear what is desired.
-
I like the lines of thought @simon33 . To complement that idea I'd suggest the 'game-id' field to 'remember' previously used values with a drop-down. If a user types a value instead then we have a 'create topic-id' or 'create forum post' button that would populate the topic-id and enable the start button or start the game directly.
-
For how easier to start up games, I've had these two thoughts, short-term and longer/medium term:
(1) drop-down values
IMO likely a quick win here, have the 'to', 'cc' and 'game-id' fields contain drop-down values of previously used values. This would be somewhat similar to how the 'forum' field is a drop-down, but would allow new entries to be added. Useful when switching between multiple opponents when playing multiple games. Picture below has red circle where to add drop-downs, green check to call out the existing drop-down:
(2) Save Game Manager / UI
To load save games today, we show a file menu chooser and rely on the user to find the save game file and load it.
The suggestion here is to build a UI that would show a list of save-games that a user can use to select/load a game. IMO the nice thing here is we can help organize the various save-games and make them easier to launch. For example we could have a 'tab' or a filter to show the auto-saves. Before launching any game the listings would show the map-name, the game type (local/PBF/PBEM/live), game-round.
There's a few things to solve here, mostly how to persist and read data about save games. A brute-force implementation would scan from a list of folders and load each save-game and gather the round/map info that way. Less obvious is how to code/solve for a player listing and to encode & detect if a save game is local/PBF.
An important eventual element of this is that we'll be able to abstract away the physical file and the games to load could include for example PBF and load a file that was posted to forum.
-
I don't know how realistic it is to only select PBF games if you select PBF. I sometimes use PBF games in local mode, e.g. when I'm spectating someone else's game, I don't think we should drop support for that.
Like the idea of a drop down though. I guess it would only hold as long as the serialization cache persists, which sometimes goes away for no apparent reason.
-
@simon33 You're right about the difference on 'game play-type' vs adding more info when loading a save-game. I'm thinking perhaps the game could be smart enough to know it's a PBF continuation from where the file is loaded. If the file comes from physical hard-disk then it's a local game. If the 'save-game' is actually hosted on forum, then the latest version is downloaded and game could be loaded in PBF mode. In this case the 'save-game' file shown in UI would be a virtual place-holder.
I think a very first version of a save-game UI should simply show local save-games and the info about those games. A v2 feature could build on that to have 'cloud-hosted' games.
Alternatively we might be able to update the game to recognize the loading screen, when loading a save game from PBF screen then it would be loaded as a PBF.
-
I see rampaging scope creep. Can we just get the button?
