As in previous posts, here is the updated progress sheet:
What has changed in comparison to the last update:
- AI: a good chunk of progress has been made, and there are more details about this further down in the update.
- Multiplayer: a lot of things are working, however the main “missing” parts are the timing mechanisms (async timeouts, gaining time per executed action, etc.).
- Track Actions/Tapestry Cards/Tech Cards/Civilization Actions: these are all done, except one thing – the final civilization ability of the Isolationists. I am pushing this until it is easily verifiable within the GUI.
- Audio: some more progress has been made in regards to the music, in-game sound effects are largely finished, but still need to be tuned.
- Porting Logic to Lua: this is close to finished, the last part is the “bridge” between Unity and Lua, in terms of exchanging the game’s state.
- There is a new entry: Automa! In the 4th developer update – just after the survey – I announced that we decided to include the Automa into the digital version. This was not yet added to the progress sheet though, but has been added now.
- Localizations: some progress, I have received most “asset” localization files (i.e., card texts, etc.) from the various local publishers Stonemaier Games is working with.
- Unit Testing: code coverage with tests increased, however it is not as high as I would like it to be (and is probably not going to be as high as I’d like for the alpha, but it is what it is!).
Now, let’s talk about the alpha version. My goal for the alpha was to have a “fully-functional” core experience of the game. By this, I mean that the game part itself matches the analog version for normal gameplay of a 3 – 5 player game, i.e., all game components are implemented according to the official rules.
Thus, the focus of the alpha version is online multiplayer.
So, the alpha will now entail:
- Online multiplayer for 2- 5 players.
- Most likely no Automa, Shadow Empire, or AI – yet.
- Very limited accessibility options. These might be added during the course of the alpha, but I’d prefer to do a separate test run amongst a number of specifically selected people who’d mentioned their need for accessibility options in their survey answers.
- No localization for the alpha – the alpha version will be in English.
- No tutorial – the alpha is meant for players who already have experience with the game, so the tutorial is not needed for this version.
Once we get very close to the alpha, I will post a Google Form so that anyone can register to take part. This will be shared on Facebook, Twitter, Discord, and on here.
Why Development is (Seemingly) Slow – Timelines
I had trouble thinking of a good title for this section, as it is a very general one on progress being made, timelines/deadlines, and so on. From the outside, it can easily look like development is progressing very slowly, especially due to the sporadic dev updates recently, but let me assure you – this is not the case. There are good reasons why dev updates have been more infrequent lately.
We are currently behind the original timeline estimation which I gave to Jamey last year, and which is noted down in our contract. However, I spoke to him some time ago with an updated estimation and he was ok with it. There are a few reasons for this:
- I usually work with an ‘error factor’ on the estimated number of hours tasks will take. This means that if I estimate a task to take ‘X’ number of hours, I then multiply ‘X’ by this error factor to add a general buffer to account for the unaccountable. Over time, previous estimates give a more informed decision on what this factor should be. In this project, my factor was a bit off, likely due to the nature of a lot of tasks not being pure software development.
- Several things that we learned through the survey weren’t included in the original estimation, e.g., Automa, Shadow Empire, and a more in-depth focus on accessibility options.
- The decision to port the core game logic to Lua was not included in the original estimate, so even though this will save us time later down the line, it has increased the initial effort needed to reach a first playable version.
- As some of you may know, some time ago I created the Red Rising scoring calculator. I was excited about the Red Rising game, and wanted to give something back after having the chance to do the Tapestry Digital Adaptation. Even though I worked on this in my private/free time, it definitely did diminish the energy I had generally, and thus had an unplanned impact on the development of Tapestry.
- Tapestry is a pretty complex game – from a software developer’s viewpoint. I delve into this topic a bit further down in this update, but one of the things that makes Tapestry very cool – the fact that you can explain most things very easily to a human by just following the literal description on the cards – actually makes it very complex for a machine.
- Lastly, some unexpected private issues arose that cost me some time to resolve, and, as it has had on everyone, the pandemic definitely had an impact as well.
Now, fortunately we are currently still on track for the updated estimate, but to get to this point has definitely been a lot of pressure. For the last 3 months I have essentially worked through weekends, taking only one off, to increase the likelihood of getting the alpha out in time. This is also the reason for the infrequent updates, as I usually write them on weekends or during my “non-productive” time. With time racing I actually had it in my mind that the last update was only a short time ago, but after checking I see it has now been about 2 months 😉 Sooo… yeah, it is easy to lose track of time in such a stressful situation!
Tapestry’s Complexity and Finding Bugs
Tapestry’s rulebook polarises people! I am on the side of those loving it. Given the large replayability, and the variability of situations within Tapestry, I doubt that any “mis-play” of a situation would result in an unfair advantage – as long as it is consistently played that way. With “mis-play”, I don’t mean playing differently than the rulebook specifies, but rather in terms of situations that aren’t completely defined in the rulebook. Therefore, I don’t think that a more detailed rulebook is needed for humans to play the game. However, for a digital implementation, the machine has to know how to resolve every situation. This means that for situations in which the rules don’t exactly specify how to resolve, I must first try to find if there is any old thread on BGG or Facebook, or if someone has asked about it on the Stonemaier Games website’s comment section. If not, then I have to check if it is a detail that can easily be amended later, or if a change means more elaborate changes are needed in the code. If it is just a small thing, then I’ll make the decision. If not, then I’ll either make a new thread on BGG, or ask Joe on Discord. Joe is extremely helpful and patient with questions, so a big thanks goes out to him again!
Let me give you a few examples:
- If during execution of a tapestry card this same card gets overwritten (via Nuclear Bomb or Printing Press) the rest of the tapestry card is not getting executed anymore. As a specific example:
I play Age of Discovery (“WHEN PLAYED: Roll the science die. All players must advance on the resulting track; only you gain the benefit (you may pay to gain the bonus).”) and roll Military and advance into Nuclear Bomb, which lets me cover Age of Discovery with a different tapestry card. Thus, my opponents do not get to advance anymore.
This means that during execution of a specific tapestry card the machine always has to check in between whether that card still is “visible”. (If interested, see the discussion on BGG)
- In a situation where two players would gain “indirect benefits” how is the order determined. Specifically, imagine someone (A) played Marriage of State (Choose a track and an opponent. After they gain any benefit on that track, you gain it too (do not gain the bonus).) and a different player (B) plays Alliance (Choose an opponent. You cannot conquer each other’s territories. Whenever they upgrade a tech card, you gain the benefit after they do.). If the targeted player (C) advances into Electronics and chooses to do the upgrade action last, both Alliance and Marriage of State would trigger at the same time. Now, the simple answer to this is “in player order”, but if player (C) is not the “player that started the turn” and instead just got that benefit due to some other effect, then the “player order” does not refer to (C) but to the player who actually started the turn. (If interested in this convoluted example see BGG)
- In a situation that was discovered during AI training, an interesting edge case led to a bug (also posted on Facebook):
The player had the Inventors and during their income turn they triggered their civilization ability on an opponent’s tech card. In this case the Inventor’s ability lets you upgrade that tech card, with the following steps in order:
- The opponent gets the benefit
- You gain the benefit
- If the card is upgraded to the top row, you get to take the card from the opponent and place it in your bottom row.
Now in this specific example, the opponent managed to trigger discarding the card with his benefit (via advancing into Nanotechnology). So, the question then became – does b) trigger? Does c) trigger? After a short discussion with Joe, it was ruled that b) triggers but c) doesn’t. Which thematically fits, “you work on a tech upgrade together, but the opponent then decides to destroy it”.
As some of you might have seen, Tapestry is currently in alpha on Boardgamearena, and I have seen quite a few people complaining about issues/bugs. Maybe the above examples make it more understandable why bugs are quite tricky to resolve in Tapestry.
A lot of these situations I discovered during AI training, which is something I assume BGA doesn’t do (at least I wouldn’t see a reason for it). During AI training, the models encounter millions of different situations, triggering all kinds of bugs. Internally – for those interested in the technical side – this happens via “assert statements”. An assert statement basically checks a condition during runtime. It says, “here at this line, we assert that XYZ is the case, if not we exit with an error”. In the third example above, the assert statement was triggered at the moment the card should have been transferred from the other player to the Inventor and it – in human language said – “assert that this card still belongs to the player we take it from”. Asserts are something that is usually only active in development mode, while in production mode, i.e., when a user actually would play the game, these statements are inactive. This is usually done because some asserts are “safety” checks that, even if they fail, don’t necessarily lead to a deviation from expected gameplay.
Nonetheless, this means that if a player reports a bug later on, I can just take the game seed and their “game action log” and replay it locally with enabled asserts, to hopefully find the cause of the bug much more quickly.
The next update will (hopefully) coincide with the start of the alpha test and will also contain the first part of an AI multi-part series.