I’m happy to report that my first year of this whole “having a job” thing is going pretty well! Although as I predicted, my life both inside and outside of work has gotten incredibly busy, and as such, I’ve not been able to work on the v0.2.0 update at all, and I’ve yet to respond to all of the bug reports and feature requests that I’ve received.

Which is also the reason why when I was notified that the lobby server had stopped working, it took me a while to push this update… sorry about that!

IMPORTANT: You will need to install this update in order to continue playing multiplayer with others.

Thank you to everyone that has shared their support and kind messages in the past year, it has been really endearing to see that people still really enjoy the game even though updates are few and far between at the moment. And thank you to those who have contributed translations for the new languages that have been added as well!

Once again, apologies for the lack of updates over the past year, but hopefully you all understand why. Fingers crossed the next update doesn’t take as long!

Changelog

Added

• Added Bulgarian, Hungarian, Korean, and Tamil as playable languages!

Changed

• Updated Godot WebRTC library from v0.5 to v1.1.0.
• Updated the lobby server’s SSL certificate.
• Updated translations from the community.
• Replaced the “Droid Sans” font with “Source Han Sans” for Chinese.

Removed

• Removed the “Donate” button from the main menu, as the project is no longer accepting donations.

Known Issues

Linux

• When establishing a connection with another client in multiplayer, warnings will appear in the chat box and in the logs about STUN messages not being able to be sent. This is a known issue with the updated version of the WebRTC library, however, from testing this does not seem to affect multiplayer in any way.

The Good News

So I had a plan for what I was gonna do after attending GodotCon 2024 in Berlin (which was amazing by the way, Berlin is an awesome city!), which was pretty much gonna be the same as before: work on the game as much as I can, and get a pre-release of v0.2.0 out as quickly as possible. However, within a few days of coming back to the land of tea and crumpets, an opportunity suddenly came up…

Putting a long story short, after a very long time trying, I have finally landed a full-time job!

Now, I can guess that a lot of you already have an idea of where this is going…

The Bad News

So I’ve been in this job for a few weeks now, and while I consider myself incredibly lucky to have gotten this opportunity, I need to be realistic about what I can reasonably do outside of work and how I can do it while avoiding burn-out.

TL;DR: Going forward, I am simply not going to have the time or energy to work on Tabletop Club full-time anymore.

This unfortunately means that, realistically, v0.2.0 will probably never see the light of day, which feels especially bad to say considering the fact that it was hopefully going to be a great update to the game.

However, I am not saying that I will never work on the game from now on - if any game-breaking bugs or crashes suddenly appear, I will be sure to fix them and release a patch for the game. I’ll also make sure that multiplayer continues to work for as long as possible by keeping the lobby server up.

Plus, I will also keep the various official communities active, such as Discord, Matrix, and the official forum. The game will continue to be playable, and as such, I will still provide support on these platforms, and there will still be players who share their custom asset packs.

Donations

One thing I also wanted to acknowledge is the donations I have received so far: Firstly, I wanted to give an absolutely massive thank you to everyone that has donated to the project up to this point, both on itch.io and Ko-fi. I genuinely thought I was gonna get, like, £10 at most, but the amount of generosity I have received has been absolutely mind-blowing. You guys are amazing!

Secondly, I have taken the decision to shut off future donations. With having a job, income is no longer going to be an issue for me, and I will barely be working on the game as is, so it feels wrong to ask for further donations.

Thirdly, I also wanted to mention that if you donated to the project with the premise that v0.2.0 was going to be released, or you generally feel that your donation is now invalid, then I will be more than happy to refund it. If this is the case, please contact me at drwhut@gmail.com using the same email you used to make the donation, and I will refund the donation to you as soon as possible.

The Nature of Open Source

If there was one decision that I am especially glad that I took before starting work on the game in 2020, it was making the game open source. Not only because I am a huge advocate for open source software in general, but because if it was closed source, I would have had to abandon the project altogether.

Plus, if the project was open source, I genuinely don’t think the game would have gotten as much traction as it did, considering there are lots of, frankly, much more developed alternatives out there, such as Tabletop Simulator and Tabletopia. The fact I made Tabletop Club open source made it an alternative to these projects, which I am incredibly proud of.

Which leads me to my last, but probably my most important point of this entire post:

This does not have to be the end of Tabletop Club’s development.

Due to the very nature of open source software, any one of you has the ability to take the code I’ve written, do literally whatever you want with it, and make it your own. You could keep going in the direction I was going, or you can do your own thing. Literally the only condition you need to adhere to is to keep the copyright notice from the license, that’s it.

If you do end up forking the project, then please let me know! Not only would I love to see what you end up doing with it, but I would also be more than happy to help provide Godot-related support, and if I have time I might even help contribute to the code!

Thank You

Considering this game started out as a hobby project during COVID, I still sometimes catch myself off-guard looking at the statistics… I never, ever expected the game to get as popular as it did, and for that, I want to thank each and every one of you for your support. It genuinely means the world to me, especially so when I was at my lowest mentally. COVID hit me really hard during university, and it got to a point where I thought I’d never recover.

From everyone that helped me playtest the game, to everyone that donated, to everyone that contributed code, to everyone that translated the game into 14(!) different languages, to everyone that made asset packs and shared them, to everyone that shared screenshots of what they were making for the game… Not only did you help the project directly, you also helped me as well. Seeing the reception this game received gave me a huge, and much needed, boost to my motivation and confidence that I sorely lacked post-COVID.

And with it, I can move into the next chapter of my life knowing that this was, without a shadow of a doubt, one of the best decisions I ever made.

I literally cannot thank you guys enough. You’re the best <3

Oh, and one last thing… did you know that there are two easter eggs hidden in the game that no one has discovered yet? :)

The Promise

Before we start, there is one thing I would like to address. Those of you with good memories may remember reading this sentence in an announcement post I made when the official website and forum went live:

Before GodotCon starts on the 12th October, I shall try my absolute hardest to release, at the very least, one pre-release version of v0.2.0.

Today, on the 8th of October, I can safely say that that promise was very ambitious… between general life commitments, visiting family, and me and my friends making our very first cosplays (hint: we’re very excited for season two of Arcane to come out!), I haven’t made as much progress on v0.2.0 as I had hoped I would, so there unfortunately will not be a pre-release for you guys to test out before GodotCon, and for that I apologise.

Now, to start off my redemption arc, I shall proceed to show you some of the things that I have worked on over the last month!

New Objects Menu

Once of the areas of the UI that I felt could definitely be improved the most was the objects menu, as well as all the other menus that involve the player selecting an asset of some kind. For context, this is what the objects menu looks like currently:

While it is functional, there are a few things based on my experience, as well as player feedback, that can be changed:

• All objects are shown by default, with the player needing to either scan through the pages, or use the filters at the top of the window, to find more specific objects.
• The spinning 3D previews can cause the game to hang under specific circumstances, which also led to the error log getting stupidly big and filling the hard drive like there was no tomorrow. This is due to a fundamental issue with the way I handled multi-threading in the game when loading resources (this issue is a big reason why the re-write is happening).
• Due to the fact that the objects are shown as 3D previews, a pagination system needed to be implemented so that not too many GPU buffers were allocated to VRAM.

So for the objects menu in v0.2.0, I had two main changes in mind:

• To change the way objects are organised, so that it is as intuitive as possible to find what you want with the least amount of clicks.
• To use icons instead of 3D previews to not only stop crashes, but also to make the objects menu load faster (especially if you have objects imported with very high vertex counts).

I haven’t fully figured out how I’m going to implement the icons as of yet (hence why there are no icons in the following screenshot), but you can still see what I had in mind for the new objects menu:

In a sense, it works just like a file explorer in that you have objects in various folders, and by default the menu shows you the different types of objects that you can spawn for all asset packs that you have imported.

This structure also allows for sub-folders to help keep assets organised. For example, under “Dice” it will show sub-folders for each of the different number of sides (d4, d6, d8, etc.), and under “Cards” it will first show pre-made decks of cards, since that is most likely what players are looking for, alongside a sub-folder for individual cards, which players can click into if they are looking for a specific card. This also makes stacks of cards easier to find, as they are not lost in the middle of potentially hundreds of cards.

You may have also noticed a small settings button on the top-right hand corner of the window. You’ll never guess what it’s for!

That’s right, you can now change the size and the appearance of the buttons in the objects menu! I bet the founding fathers would cry with how much freedom this menu gives you.

Placing Objects

Currently, when you add objects to the room via the objects menu, it spawns a new instance of the object at the current “spawn point”, which by default is in the centre of the table. This is another area of the UI that I wanted to re-visit, as I personally think it could be a lot more intuitive.

Firstly, the only indication to the player that the object has been spawned is the text at the bottom of the menu, not a visual indicator in the room itself. Secondly, the spawn point is hidden, and players probably don’t know it even exists if they haven’t right-clicked the table to set the spawn point somewhere else. Lastly, this way of spawning objects can easily lead to other objects on the table getting knocked over, especially if players leave the spawn point in the centre of the table, where there are likely to be objects already.

Now, what if I told you that the new system for placing objects on the table is, like, 1000x better:

So when you select an object in the objects menu, the objects menu disappears and you get a transparent version of the object under your mouse, allowing you to place it anywhere you want on the table, or on top of another object if you so wish.

For those of you wondering what it says at the top while you are placing an object, it currently says “You are now placing an object. Congratulations!” - I’m sorry to say that you will be getting no such congratulations when you get your hands on v0.2.0, and that you’ll have to live with control hints instead… once I figure out how to display different controller icons depending on what type of controller is being used (e.g. XBOX, PlayStation, Nintendo, etc.)

Improved Card Meshes

You may have noticed in the last GIF that the Ace of Spades is looking a lot more “curvy” than usual. Well, that’s because it is! In fact, all cards will have curved corners in v0.2.0, just like in real life! I swear, this game is getting more realistic by the minute.

I’ll also be adding a new property to the config.cfg file for cards, so that you can change how big or small these corners are for your cards. You’ll even be able to disable them altogether if you’re more into right angles than curves.

Controller Support

Guess what - everything that you’ve seen so far can also be used with a game controller! But you might be asking, “hey, how do you get to the objects menu without a mouse?”. Well, I’m glad you asked, because it just so happens there’s a GIF right here:

The menu bar at the top of the UI is controlled with the D-Pad. The left and right buttons scroll through the different buttons, and the down button presses the currently selected button.

As for the tools that would usually be in the left-hand side of the screen, my current plan is to have them appear when you hold down the left bumper (LB) button, as a radial menu. Then, while the LB button is held down, you select which tool you want to use by using either joystick to point in the direction of one of the tools around the circle.

Bear in mind that the control scheme is very much subject to change depending on playtesting and player feedback, so this is by no means final!

Physics Jitter Fix

And last but not least, one area of the game that has received probably the most amount of feedback so far, and that I’ve been paying extra special attention to during this re-write, is the physics.

For the game developers that have come before me, that have had to deal with physics engines doing things that make no sense, I feel your pain now. I think with all of the research I have done into concepts like inertia and dampening, I might have a solid shot at getting a physics degree at this point.

All this to say, for most of the physics issues the game has currently, I am pretty much at the mercy of the physics engine, which currently is Bullet. My hope is that in the future, once the game is migrated to Godot 4, that either GodotPhysics or Jolt will be able to recover some of my lost sanity. However, there are some aspects of the physics that I have learnt I actually have control over, at least, when I don’t miss notes in Godot’s documentation…

For example, when you miss the section of the documentation that says “please don’t scale CollisionShape nodes so the physics engine can optimise stuff”, you end up with a dice rave:

You might have seen this issue yourself when rolling dice onto the table, where the dice dances on the surface before eventually settling down in-place.

So when you find the note in the documentation that says “please don’t scale CollisionShape nodes”, and then proceed to not scale CollisionShape nodes, and instead scale the shapes themselves, you get a much more boring dice rave:

This, I think you guys can agree, looks a lot better than it did before! Hopefully, little discoveries like this one will lead to much better physics performance overall in v0.2.0.

GodotCon

That’s it for game updates! Now it’s time to pack my bags and head to Berlin to see some cool things, like gates, walls (well, what’s left of them), towers, and what else? Oh yeah, GodotCon!

I’m really looking forward to seeing what games and tools everyone’s made, and to learn from people way cleverer than I am! If you happen to spot someone that kind of looks like PirateSoftware, except British and not nearly as cool or good-looking, then feel free to say hi!

I’ll also try and post updates from my adventure in Berlin over on Mastodon as well, so feel free to follow me there if you’re interested!

Bis bald! / Until next time!

IMPORTANT: You will need to install this update in order to continue playing multiplayer with others!

The big reason this update is happening is because I’ve recently completed a re-write of the game’s lobby server (previously known as the master server), which is now written in Rust instead of Javascript. If you’re interested in seeing the source code for the new lobby server, the repository can be found here!

If you would like to see the progress that has been made with the v0.2.0 update so far, feel free to have a look through the previous devlogs:

• Devlog #1: New Foundations
• Devlog #2: So many options…
• Devlog #3: Happy Birthday!

I’ll also be posting future updates on my fancy new website as well, so be sure to check in every so often! You can also follow me on either Twitter/X or Mastodon, as I post the updates there as well.

Until next time!

Changelog

Added

• The value of die faces can now be text, as well as numbers. (#209)
• Added a “Donate” button to the main menu that opens ko-fi.com/drwhut in the default browser.
• Added Brazilian Portuguese as a playable language!

Changed

• The format of the face_values property has changed from VALUE: ROTATION to ROTATION: VALUE, allowing for multiple faces of a die to have the same value.
• Updated documentation domain from tabletop-club.readthedocs.io to docs.tabletopclub.net.
• Replaced the “itch.io” button on the main menu with a “Website” button that opens tabletopclub.net in the default browser.
• Combined the “Discord” and “Matrix” buttons on the main menu into one “Community” button that opens tabletopclub.net/community in the default browser.
• Updated the master server’s URL and SSL certificate.
• Updated the documentation.
• Updated translations from the community.

Removed

• The AssetDB no longer requires that the face_values property has the same number of elements as the number of faces on the die.

New Website

As you may already know from previous devlogs, I am currently knee-deep into re-writing the entire codebase for Tabletop Club for the first major update of the game, v0.2.0. And since I’m treating the update as a semi-reboot of sorts, I also wanted to take the opportunity to finally publish a full-on website for the game. So, after some blood, sweat, and tears, and maybe one or two ritual sacrifices, the website is actually, for-realsies, live for all to see!

It’s got all the cool things you expect from a website nowadays, like a fancy home page showing off what the game offers, a download page, a news page with all of the blogs that I’ve made, as well as a new community page with links to all of the official community channels! I think I’m also legally obliged to tell you that there’s now also a privacy policy, if that’s your favourite flavour of jam.

To be honest, I put off making a website for the game for a good while for one particular reason - I don’t entirely vibe with the state of front-end web development at the moment. At least, compared to when the internet really got going, there’s so many things to consider like different screen sizes, about a million different CSS stylesheets to choose from, and any number of “frameworks” to actually create the website… Luckily, after looking around for a while I ended up finding a framework that I actually kind of like - Jekyll. Unlike more complicated frameworks like Django or React which have all sorts of features and models, Jekyll goes back to the old days of just mostly writing your own HTML, but with a lot of tools to help you re-use certain sections of code, as well as neat in-built features for things like blogging (which is being used right now!). At the end of the day, it’s a static website generator with a bit of scripting, which is exactly what I was looking for!

If you’re interested in how the website is made, like everything else in the project, the code is available on GitHub. And as always, if you come across an issue with the website, please don’t hesitate to open an issue and let me know what’s wrong! If however, the issue is about the website’s security, then please email me instead, at drwhut@gmail.com.

New Forum

Since I decided that I was going to make a website for Tabletop Club, I also wanted to make a dedicated forum for it as well. There’s already an official Discord server, as well as an official open source Matrix server, but the main issue that kept bugging me was that these forums were not available on the open internet. That is, you have to have either a Discord or Matrix account to join, or specifically join as an anonymous user. Either way, Google’s web crawlers aren’t gonna be visiting either of these any time soon.

With this in mind, I wanted to get two birds with one stone: not only did I want to have a community forum that was accessible to the open public (that in turn, would be picked up by web crawlers and subsequently be shown on search engines), but I also wanted to have a place where anyone could download asset packs made by the community. Since I had already decided that a dedicated asset pack database was not going to happen for v0.2.0, my solution was (drum roll please)… The Tabletop Club Forum!

It uses the open source platform Discourse (slight side tangent, the documentation is awesome by the way, thanks guys!), and it’s been set up with a number of categories to start off with:

• Announcements, which is essentially just a copy of the website’s news, but you guys can reply!
• Asset Packs, where you can download and share your custom asset packs!
• Help, where you can get support for the game, whether it’s playing it, or importing custom assets.
• Forum Feedback, where you can share feedback… about the forum. This one’s pretty self-explanitory.
• General, for everything else!

If you think there should be more categories, feel free to let me know in Forum Feedback!

I also wanted to mention as well, this is my first time setting up a dedicated email for anything, ever. I’ve tested this new email with multiple methods, and I think I’ve set up everything correctly, but either way, if you try to create an account, and you do not receive a verification email, please let me know! Make sure to also check your spam folder as well, just in case.

Flatpak Update

A big part of the reason why I’ve gone through this whole setting-up-a-website stuff is actually because of the Flatpak version of the game! How are the two related, you may ask? Well, I’ll tell you!

Back in the olden days of last year, I knew I wanted to publish the game as a Flatpak so Linux users could very easily download the game from their distro’s software centre, and have it automatically update. But in order to do that, I needed to come up with an app ID that would uniquely identify my game amongst all the other cool apps on Flathub, like Blender and Inkscape! So at the time, I decided to go with io.itch.drwhut.TabletopClub, since I had published the game on my itch.io page. I could have also gone with io.github.drwhut.TabletopClub, since the source code for Tabletop Club is hosted on GitHub, and to be frank, I wish I went for the latter. Why? Because of verification.

One fateful day long after I had published the game to Flathub, I noticed something strange… a great big “Unverified” alert by the game! The mere presence of that alert shook me to my very core, and I was distraught… It was also a problem since new users would probably not be comfortable downloading the Flatpak anymore, and for good reason. So I set out on a mission to get my app verified - and crashed and burnt at the first hurdle.

In order to verify your app on Flathub, you need to put a file with a specific token on the website whose domain is represented in your app’s ID. So for the ID that I was using, io.itch.drwhut.TabletopClub, I needed to somehow create a text file under the drwhut.itch.io domain. The thing is, as you may have already figured out, I do not own the itch.io domain. So I can’t put the file there. Therefore, I can’t verify my app. Ever.

So, my only course of action was to rename the app ID. Luckily, Flathub have added a semi-easy way to do this, but it’s not 100% seamless from the user’s point of view. Just to really, absolutely, positively make sure that the app ID would never need to change again, I decided to make the new app ID net.tabletopclub.TabletopClub! Now, since I own the tabletopclub.net domain in its entirety, I can place the special file there and prove to Flathub that it is actually me publishing the app, meaning the app is now verified!

What does this mean for you guys? If you haven’t downloaded the Flatpak version of the game before, not much, except for the fact that the link to the Flathub page is now here.

However, if you currently have the io.itch.drwhut.TabletopClub Flatpak installed on your system, you will need to update it. Hopefully, your distro’s update manager should handle this automatically for you, but if you come across an issue updating the app, then you will probably need to run the flatpak command manually in the terminal:

flatpak update

It’ll say that io.itch.drwhut.TabletopClub has reached end-of-life (which is kind of a morbid way of putting it, to be honest…), and that it has been rebased to net.tabletopclub.TabletopClub. It’ll then ask for confirmation that you want to uninstall the old app and install the new one, enter “y” on this.

This process will convert the app on your system from the old, unverified version to the new, verified one. It should also carry over your old settings and notebook contents.

Future Plans

So with the website, forum, and verified Flatpak now published, what’s next on the agenda? As you can tell I’ve been in a server-side sort of mood lately, so after this announcement is posted, I’ll get back to re-writing the lobby server, which you can read a bit about in the last devlog that I posted!

After the new lobby server goes live, I’ll be back to working on the v0.2.0 update, in which I’ll be starting work on the brand new, way-more-intuitive objects menu! Once that is complete, as well as a couple of other revamps, I’ll be sure to write a devlog to update you all on the progress I’ve made, and to get your feedback on the changes.

In the long term, there’s a medium-sized elephant that I would like to address, which is GodotCon 2024! For those that don’t know, it’s the annual conference for the Godot Engine, which is the free and open source game engine that powers Tabletop Club, and this year it’s being held in Berlin, Germany in October.

Now, I don’t know about you, and I may be a little bit biased when I say this, but I personally think that Godot is an OK piece of software. I’m joking - it’s bloody amazing. And I know for a fact I’m not the only one that thinks this. So, to satiate my need to nerd out about Godot, game development, and open source software in general to others who also like those things, and as an excuse to exacuate England for a bit (if you know, you know…), I shall be attending GodotCon this year!

Because I’m attending this year, I really want to have at least something from the v0.2.0 re-write to show off on the show floor. I don’t usually do this, because I, like many other game developers, am absolutely rubbish at deciding deadlines and sticking to them, but I make this promise to you:

Before GodotCon starts on the 12th October, I shall try my absolute hardest to release, at the very least, one pre-release version of v0.2.0.

Now, I know enough about myself to know that there is a 100% chance that I will not be able to release v0.2.0 fully before GodotCon, that’s just an unrealistic expectation. However, I think I can get a functioning alpha or beta version of the update released before then - it probably won’t be feature complete, and it’ll have some bugs for sure, but that’s why I make pre-release versions of the game, so that you guys can test it and find the issues that I couldn’t.

It’ll also be a really good opportunity for you all to give your feedback on the re-write, and to let me know what you think of the new UI and controls. I’ve been working on this update since late last year, and I’m super proud of what I’ve done so far - so I’m absolutely determined to get it in a playable state, and I’m super excited for you guys to try it, hopefully, in October!

Donate

You knew this plug had to be somewhere in here, right? 😉

Although, I feel like I have a pretty good excuse for plugging my Ko-Fi here! Since I needed to purchase not only a domain, but also a virtual private server (VPS) as well as an email service for the forum, all of these things are coming at a new monthly cost for me.

So if you like the project, and you would like to help contribute towards the running costs of the new infrastructure, then please feel free to donate on my Ko-Fi page! Any donations, no matter how big or small, are hugely appreciated.

And with that, I bid you all adieu! If everything goes to plan, next time you hear from me, I’ll have some more things to show off from the v0.2.0 update!

Now you may be asking yourselves, why is this an eventful day? Nothing ever happens on the 29th of April! Well, you see, that was true only up until last year... because Tabletop Club officially released on the 29th of April, 2023!

Unfortunately, I only realised the game's birthday was coming up a few days ago, and so I don't have any special events planned or an update for the game scheduled to release, so instead I've decided to word vomit through the internet in your general direction with details about what I've been up to, and what I've got planned for the future, as well as a question for you all!

More Multiplayer Improvements

In the last devlog, I mentioned that I was refactoring the multiplayer code from the ground up in order to make lobbies less error prone and to give more feedback when something went wrong. Now that the new foundations have been laid, I've started work on re-writing the in-game systems themselves with the new improvements.

The first thing I did was create a new UI for the player list at the top-right corner of the screen. Currently, it looks like this:

It serves its purpose in showing the list of players currently in the room, but it could definitely look a lot nicer. Fortunately, now it does!

• The room code has been made a lot bigger, and spacing has been added between the letters for easier legibility.
• The "Hide Room Code" button that previously took up a lot of screen real estate is now a small icon button.
• A new copy button has been added, which when pressed, will put the room code in your clipboard so that you can paste it to other players.
• Instead of as just text, each player is now represented with a coloured button, with each button being the same width. The colour of the text and the border will automatically be adjusted depending on the player's set colour.
• The host of the room is now shown with a crown icon alongside their name.

I've also been re-working basic object operations, like locking them in place or deleting them, in order to reduce the amount of network traffic that is sent between the client and the host.

Currently, if you were to select 100 objects and delete them, the client would send 100 different packets to the host, each with the "delete" command and the ID of the object. For small amounts of objects, this works well, but if you end up deleting thousands of objects at once (unlikely, but possible), then there is a lot of redundant network traffic being sent.

Now, only one packet is sent from the client to the host, with the same "delete" command, but this time with a list of object IDs - this will significantly improve the amount of traffic sent to the host, and thus the operation should be a lot faster now when it is being done on a lot of objects. I'll be doing optimisations like this across the entire game when I am able to.

As of right now, I am currently trying to figure out a solution for a fundamental problem that plagues the game, although most of you might not have come across it... If you have happened to import a lot of custom assets, eventually you will get this warning when you host or join a multiplayer game:

For reference, the AssetDB is a database the game uses to keep track of what assets have been imported. Usually when a client joins a room, the host will send a compressed version of it's AssetDB to the client, and the client will compare it to it's own to make sure there aren't any discrepancies. If there are, the player is made aware and the game will offer to download any missing assets from the host if they want to.

The only issue is, if the compressed data is bigger than 64 KiB (which is equivalent to 65536 bytes), then it is impossible for the host to send the data to the client. This is because of a hard-coded value within the WebRTC library that the game uses, which can't be changed in the project settings, even though it is shown as an option.

To get around this and allow the clients to send packets bigger than 64 KiB, I have one of two options: either re-compile the WebRTC library with a bigger hard-coded value like 1 or 2 MiB, or add functionality within the game itself to split data into multiple chunks and send it chunk-by-chunk. Since I've had a pretty bad experience in the past trying to compile the library myself, I've decided to try and go for the latter.

However, this decision would open up a whole other bag of worms. For example, what would happen if a player joins a room while data is being transferred? What if a transfer is happening, and the recipient leaves the game during it?

After a lot of thinking, I think I've come up with a two-part system that will work. The first is what I've just described, which is a system that will break large amounts of data into multiple parts and send it chunk by chunk. The second is what I call a "state freeze" system.

I'll go through an example of how I'm thinking it will work: Say for example, two players are currently in a multiplayer game, and there are a lot of objects on the table and they've been painting on it as well. Let's say a third player wants to join the game - they need to get the current state of the game from the host, but it's a large amount of data to send, so it needs to be sent in chunks.

The issue that arises in this example is that in between the host saving the current state as data and it being sent to the new player, the client that was originally in the game can modify the state of the game during the transfer, either by moving an object, deleting it, changing it's colour, etc.

That's where the state freeze comes in. Before the host starts the transfer of data, the host will tell all of the clients to "freeze" their game. This would involve the players not being able to do anything on the table, and most likely a "Loading..." panel coming up on the screen. This way, it is almost guaranteed that the clients will not be able to modify the state until after the new player has received it in full.

That is essentially what I am currently working on at the moment! By solving this issue, hopefully the host will be able to send it's AssetDB to clients no matter the size, and there can be a ton of objects on the table, and it should no longer matter as clients should always be able to receive it.

Master Server 2: Electric Boogaloo

Speaking of multiplayer, another aspect of it that I'm planning on re-writing is the master server. For those that don't know, the master server is a program that keeps track of multiplayer rooms, who is hosting them, and which players are in them. So whenever you either host a game, or join someone else's game in Tabletop Club, the game will be talking to the master server.

The current code for the master server is based on code from Godot's own example repository. It definitely works, as lots of players have created and joined rooms, but there's a few potential issues that can arise.

Firstly, it's written in Javascript. I have... opinions... about Javascript as a language, but I will keep myself calm and explain my utter hatred for the programming language in another devlog... maybe.

Secondly, and probably more importantly, the server is single-threaded. This basically means that the server can only deal with one request at a time. So far, the game doesn't really have more than two rooms going at any given time, so this isn't really an issue currently, but if for whatever reason the game gets super popular, and a ton of people start creating and joining rooms at the same time, it will start to slow down the server a ton.

Thirdly, the server has limits for the number of rooms that can opened and players that can join hard-coded into the script itself. This means that if I ever need to increase the limit of how many players can join, then I would need to stop the server, change the source code, then run it again, which is very much less than ideal, as anyone that was in a multiplayer game in that time would see themselves kicked out when the server was shut down.

So, my solution for this is to switch from using what might be my least favourite programming language to my all-time favourite: Rust. For those that don't know, Rust is very similar to languages like C or C++, but it has a ton of features that make it really hard to write code that can break during runtime.

In particular, I am using what's called an "asynchronous runtime library" called Tokio, which is just a really fancy way of saying it can do multiple things at a time in a clever way. So far, I've managed to get it so that it can detect connections from clients, and it can read whether they want to host or join a game.

However, the primary reason I am now writing a new master server using Rust is for it's error handling. In essence, with the way you write code in Rust, you are forced to deal with all of the potential errors that can occur with an operation. For example, if a connection to a client drops suddenly, or if a message fails to send. For this reason alone, I am already a lot happier with the code compared to the current version, as I know how the server will react now if something goes wrong.

Plus, I have added a way for the server to repeatedly check it's configuration file for updates, and if any of the values change, it will update it's runtime values accordingly!

This means I can, for example, increase the maximum number of rooms, or the maximum number of players per room, without having to restart the server.

Currently this code is in a private repository, but once it's ready for testing I will make it public and release it under the open-source MIT license.

Back To The Future...

Shortly after I've published this devlog, I will be getting back to solving the packet size limit issue that I was discussing before, and after that it will be getting the host to sync it's state with new clients again!

In the long term, I'll be continuing to go through the game and improve it across the board, fixing fundamental issues that are in the game currently, and by adding small quality-of-life changes where I can.

Once thing that I'm also planning on doing that I haven't mentioned in any of the other devlogs is that of a dedicated forum for Tabletop Club. Currently, the only way to receive support for the game is by either joining the official Discord or Matrix servers, or by messaging me directly via email or Mastodon. While these options work okay, I would also like to have an option available to people that don't necessarily want to create an account. So, once I have a dedicated server up and running, I am planning to use the open-source platform Discourse to host a community forum for Tabletop Club that is accessible to everyone, which can be used to ask for support, suggest new features and improvements, and to potentially share community-made asset packs with others, which is one of the big features that I think the game needs most.

Speaking of big features, since all of this work is for the upcoming v0.2.0 update, I want to try and add at least one big feature as well, on top of all of the re-writes and smaller changes. An online database of asset packs was one of them, but the potential forum mentioned previously would be a good temporary alternative, I feel. The remaining highly-requested features have been the following:

• Automation using the Lua scripting language.
• An in-game asset creator.
• Migration to Godot 4.
• Releases on more platforms, e.g. The Web, Android, iOS.

So to finish, I want to get your opinions: Which of these features would you most like to see in the first major update for Tabletop Club?

Please let me know what you think in the comments! You can also message me on either Twitter or Mastodon, or you can discuss it with the community in either the official Discord or Matrix servers.

And before I go, I'd like to plug my new Ko-fi page once again - if you want to support the project and help the v0.2.0 update come out quicker, and to help chip in for the costs of hosting a dedicated server in the future, any and all donations would be extremely helpful!

Until next time :D

But first, there's something that I need to do. Something that has been lurking in the shadows for months, that I have neglected up until now, and that my career as an independent, open-source game developer depends on. That's right - shameless plugging!

Donating via Ko-fi

Are you a fan of free, open-source board game simulators? Do you want to see more stuff more quickly in said board game simulators? Do you like making random men on the internet so happy that they start squealing and make random unintelligible noises??

Well, come on down to the one-stop shop for all your money-induced, stranger-pleasing needs! For as little as five pounds (no, not the weight, you freedom lovers), you can be safe in the knowledge that your favourite board game simulator will get even better, with awesome new features like:

• An online database of asset packs!
• An in-game asset pack editor!
• A Lua scripting API!
• An upgrade to Godot 4!

So, what are you waiting for? Visit the brand new Ko-fi page now and donate to the melon who just word-vomited this segment and somehow it kind of worked out??

New Options Menu

If you haven't read the last devlog, the TL;DR is that for the v0.2.0 update I'm in the process of re-writing the majority of the game due to the fact that, although it worked for the most part, I wasn't happy with the code and some aspects of the UI. So far in the re-write, I think the area of the game that has improved the most from a visual standpoint is the options menu:

Audio

• The tabs at the top, as well as the buttons at the bottom, have been given icons.
• All of the sliders in the options menu now show values.
• The "Effects Volume" setting has been renamed to "Object Volume" to better express its function.
• The "OK" button has been removed, and the "Apply" button will only become clickable once changes have been made.

Controls

• What was previously the "Key Bindings" tab has now become a sub-menu within the "Controls" tab.
• Similar settings have been grouped together.
• When hovering over settings with the mouse, or when they are focused with either the keyboard or a controller, hints will be shown at the bottom of the menu.

General

• A note has been added under the "Language" setting warning that translations may not be complete, and explains how they can be contributed.
• Custom UI elements have been created for controller support. The "Autosave File Count" setting has one of these new UI elements.
• The "Open Assets Folder" and "Reimport Assets" buttons have been removed from the options menu, as they will be added in the future "Collection" menu.

Player

• A preview has been added for what the player's name and colour will look like in-game.
• The colour picker provided by the Godot Engine has been replaced with custom colour sliders for controller support.
• A warning will now appear if the player name is invalid.

Video

• Added the "UI Scale" setting, which adjusts how large the UI appears relative to it's default size.
• Added a "Graphics Quality" preset setting, which adjusts all of the advanced graphics settings for you based on levels of visual quality. For new players, this will be set to "Medium" by default.
• All of the advanced graphics settings are now hidden by default, but a toggle has been added so that they can be adjusted manually.
• A restart is no longer required when changing the "Shadow Detail" setting.
• The Fast Approximate Anti-Aliasing (FXAA) method has been added, which is more performant than MSAA, but can result in slightly blurry edges. This is the default anti-aliasing method for new players.
• Added settings for adjusting the brightness, contrast, and saturation, of the game.

Key Bindings

• Actions have been grouped together by type.
• All actions can have up to two bindings now, instead of just one.
• Bindings can now be removed by holding down the Escape key while they are being set.
• Added actions for rotating the camera up, down, left, and right. By default these are bound to the arrow keys.
• The mouse wheel's default binding of zooming in and out can now be adjusted.

Multiplayer Refactor

After completing the new options menu, I set my sights on the multiplayer back-end. Luckily, I actually did somewhat of an OK job with the code the first time around, so this was mostly a case of tidying it up, improving the UI, and dealing with every possible outcome that could occur.

You may notice that there's a new toggle: it hasn't been fully implemented yet, but the plan is that as well as being able to share room codes with your friends so that they can join your game, you will also be able to host games in "Direct Connection" mode, which uses IP addresses instead of room codes. This way, you don't have to rely on the game's lobby server in order to play with each other, and you can host games easily over the local network (LAN). With port forwarding, you'll also be able to host games over the internet as well.

Both the "Host Game" and "Join Game" menus now explain the process of hosting and joining a multiplayer room, and include a note about the necessary internet connection and possible system permission pop-up.

Entering the room code is now also supported on controller by pressing the up and down arrows next to the text boxes, which will cycle through the alphabet.

You can now also hide the room code from this menu as well as in-game, which will be useful for anyone that streams the game live so that you don't need to switch scenes as you are setting up a multiplayer game.

The process of hosting and joining multiplayer rooms has been greatly improved - previously, the game would enter a loading screen to go to the main game scene, and only after it had fully loaded would it attempt to setup the lobby. This meant that if something went wrong with the setup, the player would be put into a second loading screen back to the main menu to show the error:

In hindsight, this was probably one of the worst design decisions I made... but I have now redeemed myself!

Now, the entire setup process happens within the multiplayer menu. If something goes wrong (for example, the client can't connect to the master server, or a connection couldn't be established with the room's host), then an error is shown there and then on the menu, with no loading screens whatsoever. You can then try again straight away without having to navigate back through the menus.

You can now also cancel the attempt to setup a multiplayer game as it is happening. This can come in handy if you're noticing that it's taking a bit too long to connect, although if it takes too long the game will eventually give up after about 30 seconds.

With the updates to the multiplayer back-end, the game now properly detects and handles silent disconnects. This is where the connection between two clients gets lost without either client purposefully causing it, for example, when one client's internet connection drops all of a sudden.

Furthermore, in v0.1.x the game would kick the player back to the main menu when the connection to either the master server or the host was lost. That is no longer the case - if the connection to the master server is lost, then the room will continue as is, with the only issue being that no new players will be able to join until a new room is made. On the other hand, if a client's connection to the host of the room is lost, then the game will switch to singleplayer mode on the fly, and will give the player the choice to either continue in singleplayer mode, or to go back to the main menu to try and reconnect with the host:

Chat Window Update

As well as the options and multiplayer menus, the chat window has also been given a fancy new look:

Previously, the chat window was only shown when the player was in a game. Now that the game scene and the main menu scene are one and the same, the chat window is now also shown in the main menu, where the player can invoke commands if they wish. This also means that errors and warnings that are thrown when importing custom assets are now shown in the chat window instead of in a separate import log.

You can now also press the Enter key while in-game to immediately start typing a message to the other players, as well as the forward slash (/) key to start typing a command.

Other updates to the chat window include:

• Using the up and down arrow keys while typing a message will now cycle through the player's message and command history.
• The chat window will now make itself transparent when the mouse is being captured elsewhere, for example, when rotating the camera.

Documentation Update

The tools used to build the project's documentation have been updated, and as such, the appearance has been updated dramatically:

• The webpage now has dark mode support, which can be toggled at the top of the page.
• Icon links have been added to the left-hand navigation bar, which link to the project's various websites.

macOS: M1 & M2 Crash Fix

When v0.1.0 first came out, the library used to provide multiplayer WebRTC functionality only had x86_64 support for macOS, meaning that those of you using ARM processors (like the M1 or M2 chips) were not able to run the game without using Rosetta.

Now that the library has been updated with ARM support, this should fix the crash for M1 and M2 users, but this requires testing.

What's next?

Now that all of the elements of the main menu are pretty much done, I'll finally be moving on to the in-game systems! The first thing I'll be revisiting are the objects, more specifically, improving the code that handles players moving them around the room, and trying to make the selection outline clearer, especially in player's hands. After that, I'll be re-organising the absolutely mammoth CameraController script, and attempt to split it up into multiple different scripts so that it is a lot more maintainable overall.

That's pretty much it for this update! You can find the full list of changes made for the v0.2.0 update so far here.

Until next time!

GodotCon 2023

... I need to admit something. I did plan to write and publish this update before GodotCon this past weekend, but time is an illusion and it doesn't actually exist. Now that I'm back in smelly old England, I just wanted to quickly mention how awesome GodotCon 2023 was! For those that don't know, it was a community-run conference dedicated to the free and open-source game engine Godot, which is what Tabletop Club runs on top of. And to be quite frank, without the Godot Engine there would be no Tabletop Club. Well, I guess I could have made it in Unity, but umm... yeah.

It was absolutely wild to meet so many people in one place from all over the world that share the same passion that I have for not just Godot, but open-source software in general. All of the talks that I attended were super interesting and informative, I got to see some absolutely amazing projects from people much more talented than I am, and I'm now even more excited than I was before for where the future of Godot and its community lies! Once again, thank you to everyone that helped make it possible, and I hope to attend next year's conference for sure.

Past Regrets

So, I actually have a second thing that I need to admit... when I started developing Tabletop Club back in 2020, I made some very questionable design decisions in the code that I, to this day, very much regret. I'm not going to go into too much technical detail in this post, since it's being written for a general audience, but for some reason I decided very early on that the AssetDB (the database that holds all of the information about custom content that has been loaded in), as well as room states, should be JSON-like dictionaries instead of structured Resource types. I also decided that the "TabletopClub" asset pack, the one that comes bundled with the game, should be imported when the game loads like all other packs, instead of coming with the game pre-imported. There's a whole list of things that I regret doing while developing the game, and it's the main reason why the first major update, v0.2.0, may take a while to come out.

There are a lot of new and cool features planned for v0.2.0 which I'm very excited about, but before I could start working on any of them, I had a decision to make. Either I add on top of what I've already done, which is a working, but fundamentally flawed, codebase that I know could be better, or start re-writing the game in a much better way so as to make the whole project more maintainable in the long-term, but any new features would have to wait until the re-write was complete. Ultimately, the decision I made was to start the re-write now while the project is on the smaller side, instead of re-writing a much larger project later down the line. But while this meant that new features were not going to be implemented for a while, it did however give me the unique opportunity to improve different aspects of the game at a fundamental level as I went!

AssetDB 2.0

The AssetDB, as well as the entire importing system for custom-made assets, has been entirely re-written from the ground up for v0.2.0.

NOTE: While none of the old code exists in the new system, it has also been designed such that asset packs made for v0.1.x will still work properly in v0.2.0.

Everything in the AssetDB is now what's called a Resource within Godot, which basically means that each entry within the database needs to have a specific set of properties, with each property having it's own built-in validation. This is in stark contrast to before, where each entry could theoretically contain any bit of information it wanted, valid or not, and while there was validation, it was more of a band-aid solution added to the AssetDB once I realised just how often I needed to check the metadata throughout the code. Overall, this means that the structure of the AssetDB is a lot more defined that it was before, which will lead to fewer asset-related bugs down the road.

Secondly, since asset packs are now represented internally as resources, this means that I can now move the default asset pack from being in its own external folder like all other packs, to being integrated into the project itself. This means that instead of having to import all of the bundled assets when you first load in, all of them should come pre-imported which will significantly reduce the loading time when first launching the game.

The loading time has also been vastly reduced by the fact that you don't need to wait for all of your custom assets to be imported before entering the game! When the game starts, the default pack will already be there and ready to use, and your custom assets will be loaded in the background:

Once this process is complete, the plan is to update the necessary UI elements (like the objects menu, for example) with the new assets, so that you can start using them. It might take some time to make this work in all cases (I'm still hashing out the details on how this would work when joining a multiplayer game while importing is still in progress), but overall this change should make the game feel and load a lot faster than before, even though it takes around the same amount of time to import new files. Although this isn't planned as of right now, another potential prospect this new system opens up is the idea of loading in assets mid-way through play, instead of needing to manually re-import all custom assets, or by restarting the game.

Lastly, while this isn't something that players will see, these fancy things called unit tests have been added to the source code. They're special scripts that check each section of code that I've written, by giving them specific inputs, and checking to see if the outputs are what they expect. Every level of the importing code is checked this way, so even though I haven't tested it with a variety of asset packs, I can be confident that the vast majority will work because of these tests. Of course, there will still be bugs and issues that I haven't thought of or found yet, but the number and frequency of them should be much lower than before.

Improved UI

Another area that I wanted to change up as I started the re-write was the interface. While the interface definitely works in the current version of the game, it sort of feels a bit... prototype-y. For reference, this is what the interface used to look like:

This is what the game looks like now:

And this is what the main menu will look like for v0.2.0:

As you can see, there's a few changes that have been made to the main menu:

• The layout has been completely re-worked to make the buttons that players will use the most bigger and more apparent.
• Icons have been added to each of the buttons to make their purpose clearer, and to have the player be less reliant on translations (full credits for the icons can be viewed here).
• There is a new "Collection" button - this is where players will be able to see the asset packs they have imported in a lot of detail, and one day, be able to create and modify their own in a specially-made editor!
• All of the various hyperlink buttons that were previously at the bottom of the screen are now unified into one link button.
• The falling objects have been replaced with the default table.
• The default table is now actually textured!

Why is the table in the main menu now? Well, that's because the main menu and the game scene are now one and the same!

Instead of having a loading screen when going from the main menu to the game scene and vice versa, the camera now smoothly transitions from orbiting the table to the player camera's position! This means that once you get past the first loading screen, there will no longer be any more loading screens after that (the only exception will be loading pop-ups when loading a previous save file, or joining a multiplayer lobby), since everything the game needs to work will be loaded in at the start.

Although it's hard to show in a GIF, the main menu can now also be navigated entirely using a controller as well! This is one of the big planned features for v0.2.0, which is full controller support so players who can't use a mouse and keyboard, or are on a device like the Steam Deck, can play the game properly (it is technically possible to play the game on the Steam Deck right now using the mouse control scheme, but it's kinda finicky. Thanks to Rie for letting me test the game on their Steam Deck during GodotCon!).

Not Done Yet...

That's all I've got to show for the v0.2.0 update so far! But hopefully this devlog shows that A. I'm still alive, and B. I take the word 're-write' very seriously. I've learned a lot by developing Tabletop Club, both about the Godot Engine and about programming in general, and I'm gonna try my damn hardest to take everything I've learned in my many years of coding and make the best repository of code I've ever written, and as a result of that, give all of you a better experience with the game.

If you're at all interested in the full list of changes that have been made so far, you can have a look at the changelog here! And I'll be sure to update you all every so often with the progress of the v0.2.0 update. Until next time!

IMPORTANT: You will need to install this update (or a future update) in order to continue playing with others in multiplayer!

While this update is merely a nibble, I've got a whole lot of stuff cooking in the background (by background, I really mean the 0.2-rewrite branch), which I'll be sharing the details of soon!

Changelog

Changed

• Updated the master server's SSL certificate.

This is a relatively small patch which fixes a few bugs that players had found, as well as adding new translations from the community - in fact, so many translations were submitted that you can now play the game in both Chinese (Simplified) and Polish! 😁 A huge thank you to everyone that contributed since the initial release, you guys are awesome!

Once again, apologies for this patch taking so long to get out - I had taken a break from developing the game after its initial release, but once I was ready to work on it again, I suddenly got super ill and couldn't work on the game for longer than ten minutes at a time, which was super aggravating... the issues still persist today, but thankfully they are a lot less limiting than they were. Now that the patch is out, I'm gonna try my best to work on the first major update, v0.2.0, but development may be a bit slower than anticipated due to my health.

So what has been changed, I hear you ask? Well, as it turns out I have a list of things that have been changed since the initial release right here! What are the chances??

Changelog

Added

• Added Chinese (Simplified), Polish as playable languages!

Changed

• All links to the documentation now go to the stable version by default, rather than the latest version.
• The game will not longer allow stacks containing only one item to be made in the stacks.cfg file.
• Updated translations from the community.
• Object metadata shown in tooltips in the objects menu is now truncated if it is too long.

Fixed

• Fixed an escape character error in the description of the music track "Lobby Time - Kevin MacLeod".
• Viewing the stable version of the documentation now shows the correct version instead of "master" in the title.
• Fixed non-ASCII characters not displaying in error and warning messages in the import log.