Very nice, too bad I didn't know you were at GodotCon.
Devlog #1: New Foundations
Hey everyone! It's been a while since the last update was released, so I wanted to try writing one of these "devlog" thingies to show you all what I've been working on! But first...
... 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.
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!
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:
The new importing UI in v0.2.0, importing a custom asset pack made by a member of the Discord community.
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.
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:
OpenTabletop Alpha 2 - yes, that was genuinely the name of the project at one point.
This is what the game looks like now:
Tabletop Club v0.1.2
And this is what the main menu will look like for v0.2.0:
Tabletop Club v0.2.0 (in progress)
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!
The new transition from the main menu to the game.
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!