I will be making a dev log video on YouTube about this probably today or tomorrow, but essentially I'm learning the hard way that you should absolutely build multiplayer games with multiplayer logic first. Making the entire game work with dummy AI characters first and then trying to retrofit it with MP-oriented code will not work well.

Essentially I'm going to have to rewrite the entire codebase for The Lucky Hive to work with multiplayer by mirroring file names for things like singletons and scripts, then implementing it with RPCs, then attaching that new script to the scene to take over. Once that's done, we should be good haha.

Always build multiplayer games with multiplayer-focused code FIRST.

Spent a weekend in Sydney learning Remote Procedure Calls and getting a working demo for The Lucky Hive up and working (just lobby wise), building upon the video demo in my last post.

Now that it's up and running, I've built the new lobby 3D assets and am working on getting it all scripted and running. Sound effects are, funnily enough, probably going to be the hardest thing to get right since I've got the visual design for the game well defined now.

Will post more updates when things are ready. Once MP is done and I can start playtesting, I'll issue some beta keys to some friends, we'll see if the game is fun and then the announcement trailer shall commence.

Below is a screenshot of the WIP new game lobby (before cutscenes are hooked up and UI elements are made).

I have finished what I consider to be the E2E experience for The Lucky Hive (at least in its current state). I have folding, play, showdown logic, elimination logic (barring the WIP player eliminated stuff on the executable/client side), sound effects and a general visual upgrade to lighting, shadows, shaders etc. I'd say the game is in a playable singleplayer state. What needs to happen now is multiplayer.

I've kinda dug myself a hole doing all the game logic before even starting MP work, because my computer science degree taught me that it wouldn't be that hard. Well uh yeah it's not really that hard, it's just very arduous having to go through each file that touches the game and setup MultiplayerSynchroniser scenes/nodes within it and retrofitting each file to be capable of working within a multiplayer environment. What a challenge!

Once I've got the MP working, I'm going to work on a lobby system for pre-game lobbies (with some more 3D models and whatnot) and then getting onto the player victory/endgame scene. Once the MP stuff is done for the core game loop, it's going to be absolutely incredible to have that logic working and interacting with other players within The Lucky Hive.

I've also been playing Balatro a lot lately. I can't believe I used to bag out on this game and diss it because it's a card game. An absolutely amazing indie game and super fun. It just goes to show how a simple game with a simple premise can be so enjoyable.

Anyway, here's a clip of what I managed to get working today (ignore the network jitter, our router's wifi is scuffed and I was just setting the rotation directly, not using a Quaternion.slerp() function for physics interpolation).

Been working on some really cool character select animations. I have been in absolute tears laughing making these. They're so perfect for each character and I think are an absolute highlight of The Lucky Hive. I cannot wait to see people's reactions to this when they fire up the game for the first time and see. I am so proud of these and think it really adds a level of fun to the game.

I've attached some screenshots of how they're gonna look in Blender/Godot (keep in mind these are just animations, not camera work, VFX or sounds obviously).

Made some huge leaps over the past couple of days in terms of logic for the showdown system. I managed to finally get a WIP version that didn't crash and is generally in the ballpark of what I want it to look like, now it's about getting all the pieces in-between functioning and working as expected. I'd say it's like throwing a rope across a ravine to build a bridge. Once I've got all the animations, visual queues and tempo of the showdown system done, that means I can finally certify that The Lucky Hive has a workable demo before multiplayer starts. What an exciting time!

Happy New Year!

Just an update for the end of the year and beginning of the new one. I've been working on getting the showdown element of The Lucky Hive implemented, including massively overhauling the codebase and general systems as my skills with Godot and GDScript have improved. The showdown system is the final element of the core gameplay loop, marking the end of a game. I'm trying to make it fun in a way that gives it a Japanese game show vibe, but also still preserve the amount of information that's normally given to players in poker. Currently the showdown system is on its 3rd iteration, as I had this dolly camera system that would snap to each player and prompt their hand, but it felt really lazy and often would cause information issues since I'd have to hit TAB constantly to compare to other players' hands before deciding. I've attached a screenshot of the WIP showdown system.

Code Overhaul

Currently there is a monstrous file called "Globals.gd" where I have thrown literally everything that couldn't be contained within a scene into this file. Things like turn management, pot data, starting new games, prompting players for new turns and everything. It's getting way too complicated to add something new on since the file is so multipurpose, let alone debug an issue where all scripts are making routine calls to one singleton for information. The plan is to break up Globals into 3 systems, one being called Turnmaster which obviously handles turn data and Potmaster which handles the pot data and player data (about seat locations, is an NPC/AI player, sidepot information, minimum bets etc.). Globals still has a bunch of useful stuff about player information like if they're the executable seat (the person playing the game) and whatnot, but data about if the player is all in or what their total contribution to current round is is all being moved into Potmaster and all turn management data is going into Turnmaster.

Since it's been years since I've done any real software programming outside of web development, so I've had to really appreciate design patterns again and make use of things like factories, prototypes, singletons and whatnot. Unfortunately GDScript is limited in its syntax and capabilities in some areas, such as abstract classes or interfaces, but that's totally fine. Thankfully you can still extend classes and create base classes for things like multiple characters and whatnot. Documenting my code has been tremendously helpful as well in this regard, since often I've come back to ways of doing things and totally overhauled it (such as not realising you can define classes in GDScript for scenes).

Nearing Completion & Multiplayer

Once the showdown system is tested and functioning, I'm going to commence work on the multiplayer aspect of the game. I've done a lot of reading regarding implementation in Godot and it seems like there's a way of synchronising properties as a consumer and then distributing new values/states as an owner (since we're doing P2P multiplayer). Properties that need to be synced would include head movement, states (looking at cards), raise amounts, turn order and stuff like that. It's going to be interesting to see what I can keep on the client side and what needs to be distributed.

Some Other Things

I definitely need to look at the lighting in the game. There was that huge optimisation issue with omnilights causing 40-60M primitives and like 3,000+ draw calls, totally nuking performance, but now the game's lighting looks really poor, especially in detailed areas like looking at cards, flicking chips etc. I think I need to define all cards, chips and low poly things to cast shadows from a light source and hide shadows on the characters (and especially the dealer). Also since playing Balatro this week for the first time I've realised just how many sound queues there needs to be in The Lucky Hive, so I'm working on little animations and jiggles for events and state changes.

Anyway, just a lengthy update, I'm hoping to get the game out sometime this month or at the absolute worst late next month, just depending on my work schedule and complications from things like multiplayer or general bugs/improvement.

Been working hard to get this game into a state where it's fun, stable and in a functioning state (at least code-wise) for the commencement of introducing multiplayer into The Lucky Hive. The new user interface is looking considerably better than the old debug interface, there's a new tab menu to see which player's turn it is, how much money they have and eventually what their latency is. There's also a new "pot menu" so that you can see how much each pot is valued at (up to 5 pots total including the main pot) and the icons of the players who are in each pot.

From here it's about continuing to improve the game's stability, especially when it comes to non-players or what I call "non-executable players", essentially the player that is controlled by the person running the game. I have no idea at this moment as to how this is going to work for multiplayer, but hopefully it's just a matter of syncing up states and the server owner sort of just owns the data. The game is going to be P2P so there's a lot of flows in terms of lobby hosting, syncing states with the owner, negotiating seats at the table (randomly allocating) and also integrating with the Steam SDK for Steam Relay and things I have no idea where to even begin.

One other thing is there was this huge issue with draw calls and an insanely high primitive count on non-Windows devices (like I'm talking 60,000,000 triangles being drawn) and it has taught me valuable lessons with respect to how Godot's lighting works. Having 15 omni-lights all in close proximity drawing shadows on high polycount geometry with no baking will absolutely WRECK performance. I simply turned off shadows for all omni-lights in the game (and removed the downward facing directional light) and the game's total draw calls have now dropped to ~350 and the primitive count is hovering around 800-1.2M (which my Steam Deck handles no problem). Also turning on LODs for static geometry, like the Lucky Hive sign at the entrance to the room, since the geometry was never retopologised or optimised (just decimated in Blender).

Anyway, things are going well with the game, keen to get some more developments over the Christmas period and get started on Multiplayer so we can playtest whilst I'm home for Christmas.

I've created 6 new characters for The Lucky Hive. I'm super happy with how they look and I think they really brighten the game up in terms of visuals but also the personality that they display. I think it's super important that players can select a character they want to look like in the game.

Their names are a WIP but hopefully they're illustrative of what they might look like:

1. Workerman

2. Scoutman

3. Soldierman

4. Remembriar

5. Engineerman

6. Psychicman

This is on top of the Slugman that already exists in the game. Got some new things to learn when getting these guys into the game, especially when it comes to sharing animations and ensuring that things like bone attachments (for left and right hand) sync up properly. I also need to learn a ton about how to program up the script to set the character based on the exported var type (so that you can just set the variable and the code will swap out the meshes, rigs but preserve the animations).

On a quick note, you may notice that the bodies are the exact same and only the head changes. I thought I would learn how to do multi-body bones, rigging or whatever is involved in a future game; my skillset is currently not there to have the positions on the table (like resting on the table) using IK solvers or whatever. Godot is planning on updating this in the near future as well, so there's no point in using a knowingly deprecated system that could be replaced on me tomorrow. I also stupidly deleted the high resolution base mesh for the Slugman, so I can't really go back and re-draw things like the veins or general skeleton.

Once the game is out on Steam, I'll make a post with all the concept art I made for the game and "WIP" stuff that was part of my first game. Anyway, here's a photo of all them, just blankly staring at the camera (in the order that I provided in the list above). Anyway, I'm writing this at 2am on a Monday morning, so I should probably get some sleep.

More coming soon!

Made some great progress this weekend. Added in some more visual effects, cleaned up the end of game showdown logic and also massively improved the way that players actually just interact with the room, their cards and giving their decisions some weight. There are still a lot of improvements that need to be made, such as making a "versus"-style system so you can compare hands to see who won (like a real showdown), since it's quite boring for players to slap their cards down and the winner is just announced.

Before starting that however, I'm moving onto working on some rudimentary player AI so that there can be some decisions made autonomously, rather than me just making the selection myself. Once this is done, it ties in nicely with the beginning of working on multiplayer so a demo can then be released on Steam and feedback can start to be gathered. Hoping all things go well from here, since I'm aiming for an early January 2026 release (at the earliest).

I wasn't super happy with how the players just casually dumped their cards on the table, then the camera panned around, showing them and eventually just announced who won. I wanted to have a system that cut to that player, let them have the decision to fold or reveal their hand and if they were the last person to go, then announce who had the winning hand. This way you sort of didn't "forget" who's hand was what and it was really clear who had the winning hand (or in chopped pots, who won the pot(s) <- (sidepots included)).

Making a bunch more updates, especially when it comes to visuals. Once the site can support images and other media, I'll probably upload a bunch of "pre-demo" screenshots before we release the actual demo on Steam.