openset

Unknown — Wed, 27 May 2026 00:00:00 +0000

OpenSet is a full-stack platform I developed with my friend over the course of about three months (June-August 2025). I'm writing this now as the official end of the project.</p>

OpenSet was born out of frustration with the lacrosse management systems used by local teams I played with. Most teams used the same outdated platform. I saw an opportunity to build a better platform when my former coach started his own association. I was to build the platform, and they would be my first customer.</p>

Over the summer of 2025, I grinded out the initial release of OpenSet, just in time for the fall lacrosse season. In total, the website handled a few dozen registration, and processed over $9000 in player fees successfully.</p>

tech stack / architecture</h2>
Since OpenSet was to be a real production platform, we needed to make careful architecture decisions. We also decided to support multiple tenants out of the box, even though this never happened--we only had one customer. That meant choosing our architecture before starting to build.</p>
We decided to use Vercel for hosting, mostly because we have no DevOps experience. Vercel is amazing to get things up and running quickly, provides amazing features out of the box, and just works. However, I would end up slightly regretting this decision later on: Vercel was quite expensive for our project, as we had the pro tier for 2 team members; this was also a failed opportunity to learn some DevOps and build on a more complex cloud platform. At the end of the day, we wanted something that worked out of the box, and that's what we got.</p>
For our database, we used Supabase. So easy to set up, great developer experience, and free. We didn't have a large amount of data so this was perfect. We used the Drizzle ORM on the backend, which was an absolute pleasure to use. Modern webdev feels a little too easy. Just make sure not to get supply-chain-attacked by NPM though ;). The Supabase buckets API was also amazing. Having image storage alongside Postgres made development almost trivial.</p>
With Vercel and Supabase, the only remaining tool to complete the larp stack is NextJS. However, we decided to go with SvelteKit, because we have more experience with it and it's also much more enjoyable to use. Svelte has to be the greatest framework: it's incredibly intuitive--most of the time; it's lightweight and not bloated at all; it supports vanilla typescript/javascript--all the svelte files are just HTML + JS + Svelte add-ons.</p>
For payments, we went with Stripe--pretty obviously. I had heard of how well it worked, but never really used it. The DX was amazing.</p>

challenges</h2>
The biggest challenges we faced building OpenSet were the following:</p>

Building a platform with multiple tenants, each with their own subdomain, theming, and customization.</li>
Implementing payments to third-party bank accounts with Stripe.</li> </ul>
The first was mostly an issue with subdomains--we wanted each team to be able to pick their subdomain on our platform. That ended up being awkward, especially because we built on Vercel with a single SvelteKit project. We ended up with a pretty hacky solution: a server-side hook that parses URLs and checks for tenants.</p>
The second challenge was more severe: working with webhooks rapidly turned into a headache, and the stakes were much higher--as I mentioned earlier, we automatically transferred more than $9k in player fees to our customer. Webhooks, while they are obviously the right way to approach payments on Stripe, felt hard to work with: it seemed as though pointing them to `localhost</code> didn't result in successful delivery of the payloads. That meant I had to set up a test environment on Vercel and made it feel much more like a real project: I actually needed a staging environment alongside production.</p>`
`conclusion</h2> Even though the project was kind of a financial flop--I only got one customer and lost money overall--the experience building real software I gained was absolutely worth it. Deploying a quality product that was going to handle thousands of dollars proved to be much harder than simply spinning up localhost</code>. A great experience.</p>`



summer of math exposition 4
Unknown — Tue, 26 Aug 2025 00:00:00 +0000
Fully homomorphic encryption (FHE) is a novel encryption method first developed in 2009 by Dr. Craig Gentry. FHE allows arbitrary computation on encrypted data. Think, an AI model provider that can't see your prompts or the model's output. Or a CRUD app that can't read your data.</p>
For the 4th edition of the Summer of Math Exposition (SoME)</a>, I presented an overview of FHE. I covered the basic math concepts behind FHE and a brief history of the developments and techniques.</p>
The highlight was definitely interviewing Dr. Craig Gentry, the creator of the first FHE scheme in 2009. I talked with him for 2 hours, and the video features many highlights of that conversation.</p>
In the end, I did pretty good in the competition, finishing 48th out of 187 video entries. The biggest problem with my video is that I didn't understand the math behind FHE enough. Honestly, it's very complicated. I was also short on time when producing the video--I recorded it in two days, if I recall correctly. I started late in the contest. That means my video doesn't go very deep into the math.</p>
If I participate in SoME next summer, I'll try to make a video with more advanced math. Specifically, I'd like to explore bootstrapping, the technique that enabled the first FHE scheme.</p>
Watch the video here!</p>
</iframe>


corne keyboard
Unknown — Sun, 01 Dec 2024 00:00:00 +0000
My latest ergonomic build (December 2024)! This is the Corne keyboard. And I think this one is the</em> one. The design is super clean, the keys feels super nice and the 50% layout is perfect. Everything is open-source and configurable, of course. I got the kit from a small web store called SplitType</a>. The kit was super convenient (no soldering required, it's hotswap) and worked out of the box after a quick 5 minute build. This is by far the best keyboard I ever had and I hope to use it for a very long time.</p>
</p>
</p>


epoxy table
Unknown — Tue, 20 Aug 2024 00:00:00 +0000
Here is a small epoxy resin table I built with my aunt. I've always been fascinated with the transparent material and the idea of casting objects inside of it.
When my aunt offered to help me build one, I couldn't resist. I decided to cast a motherboard from an old Dell PC I bought at a flea market. I love the way
cast circuit boards look. Their intricate details are perfect for resin casting.</p>

A picture of the resin table</em></p>
For the feet, I went with these</a> from Amazon. In my opinion, they look very nice with resin and are very simple to install.</p>
</p>


summer of math exposition π
Unknown — Fri, 16 Aug 2024 00:00:00 +0000
In the summer of 2024, my friend Torge and I participated in the Summer of Math Exposition</a> Pi edition. This is a math explainer contest. We used the awesome Manim CE</a> library to explain E. F. Codd's relational model. This model, first published in the 1970s, is the precursor to SQL. E. F. Codd's work, while it isn't as well-known as SQL, was hugely influential. We explored the model and its mathematical query languages, relational algebra and relational calculus.</p>
Watch the video here!</p>
</iframe>


dactyl skeletyl keyboard
Unknown — Thu, 01 Aug 2024 00:00:00 +0000
In August 2024, I built the Bastard Dactyl Skeletyl</a>, a split ergonomic, curved mechanical keyboard.
This entire keyboard is open source: I 3D printed the case with my FDM printer, and I got the keys printed in MJF nylon from JLC3DP</a>.
The keyboard comes pre-flashed with VIA</a>, so I can easily customize the four-layer layout to my liking and add complex macros.
It's a 40% layout, meaning it only has 36 keys, including six thumb keys. While that's not a lot of keys, it drastically reduces the distance my fingers need to travel.</p>

The Dactyl Skeletyl on my desk</em></p>
Thoughts on the keyboard</h2>

Open-source: The open-source aspect is fantastic. You can either buy a prebuilt keyboard or build it yourself by just purchasing the PCB kit. I chose the latter because I wanted to learn soldering.</li>
VIA: Customizing the keyboard with VIA is super intuitive and effortless. With only 36 keys, it's crucial to be able to choose which shortcuts to include in the layout.</li>
Curvature: The curved design wasn’t a hit for me. It makes my fingers travel a bit more than a staggered key layout would.</li>
Instability: Due to the 3D printing, the keyboard’s base is very light and tends to move around on my desk while typing. It's quite annoying, so I’m considering getting a metal base.</li>
</ul>
</p>
I ended up replacing the thumb keys with some Guy Fawkes keycaps. They came in a Vim keycap set.</em></p>


8bit Duels Devlog Part 8 - Final Devlog
Unknown — Mon, 21 Aug 2023 00:00:00 +0000
Hey everyone,</p>
8bit Duels has finally been released! After one year, I am proud to have completed it. I have explained everything in a release YouTube video. Watch it here: https://www.youtube.com/watch?v=maKARl89Qos</a></p>
I will now move on to other projects, probably not game development. It's been a really fun experience.</p>
Bye for now,</p>
- ThousandthStar</p>


8bit Duels Devlog Part 7
Unknown — Mon, 24 Jul 2023 00:00:00 +0000
Hey, welcome to yet another 8bit Duels devlog. It has been almost 4 MONTHS since my last post, mainly because I was
waiting to have completed the UI (menus) before releasing another devlog. However, I am not quite done, so I thought I'd
share my progress so far. I have also implemented the debug mode setting, have added my chiptune song to the main menu,
and have improved my workflow through Github Issues.</p>
UI Library</h2>
To build the whole UI, I initially decided to go with the default bevy_ui</code> crate. I tried to use egui</code> for a bit, then experimented with
kayak_ui</code>. In the end, I settled with the default UI crate, since, while being extremely verbose and requiring a lot of boilerplate,
it is simple in all its aspects.</p>
However, I have just discovered the belly</code> crate which leverages the power of Rust macros to provide
a declarative UI framework that is directly translated to bevy</code> components. I will rewrite my whole UI
using belly</code>, as it removes all of the boilerplate associated with the bevy_ui</code> crate. It is also extremely simple
to use, and UIs are declared using eml</code> syntax (similar to html</code>).</p>
UI Changes</h2>
Main Menu</h4>
For the main menu, I drew an animated background with the four characters currently implemented in the game (Skeleton, Reaper,
Kraken and Spider).</p>

Image of the main menu UI</em></p>
Settings Menu</h4>
The settings now are stored inside the config.ron</code> file (inside the assets folder). This isn't ideal, as I load the file
with standard IO. I may change it in the future by creating a custom Bevy asset type for the settings. Anyways, here is the
settings menu:</p>

Image of the settings menu UI</em></p>
In-Game UI</h4>
The in-game UI is by far the longest to implement. I have laid out most of the UI widgets, but I still have to connect it to the
logic (so the buttons can... you know... do their buttoning).</p>

Image of the in-game UI</em></p>
That's it!</h2>
Yes, that's it! 4 months of work, and only this! I agree it isn't much progress, but I was extremely busy with some other projects,
and school of course. Now, I just decided to rebuild the whole UI, *sigh*. It should be much faster though. The belly</code> crate is
awesome, and I highly recommend it to all my fellow game developers using bevy</code>.</p>
Pixel Artist</h2>
I am not exactly an artist, and I am slightly unsatisfied about the pixel art in 8bit Duels (someone else made it, but they aren't
going to continue helping out with the project). I am considering AI art (using Stable Diffusion) to redo all the art, but
AI isn't quite ready to do pixel art (from what I can tell). If any pixel artists are reading this and would like to contribute some
art (there isn't much to do, as the characters don't have animations), please join the Discord server</a> so we can talk.</p>
Contributions</h2>
If anyone is interested in contributing code to 8bit Duels, please join the Discord or open/comment on issues on the Github Repository</a>.
Many new features could be implemented, and I am open to feedback. For example, the Discord community told me that a dark mode
may be preferable for the UI. It would be great if others implemented suggestions such as this, as my main focus is to add the missing features to 8bit Duels.
There is no documentation in the repository, and barely any comments, but if anyone asks me about how my messy code works, I will
gladly guide them so they can contribute.</p>
Conclusion</h2>
As I always write, if you made it this far, thank you. I will try to finish a minimum version of 8bit Duels before the end of the summer.
This is mostly a learning project, and it has absolutely succeeded in this regard. I am grateful for all of you following my progress.
I may switch over to web development using Rust of Javascript after I am done with 8bit Duels. Anyways, I am not quite done. I will see you in the next devlog, hopefully soon!</p>


8bit Duels Devlog Part 6
Unknown — Wed, 29 Mar 2023 00:00:00 +0000
Hey again 👋 ! I'm back with another devlog for my game 8bit Duels!
This is devlog #6 and it includes some pretty interesting bits. Let's get into it!
Also, to discuss the game and follow the development more closely, you can join the Discord</a>.
A Revolt bridge is also available, please message me privately if you want to join that instead.</p>
Changes</h2>
This devlog includes mostly gameplay polish change, to make the game easier to understand and to follow.</p>

Indicator for stunned troops</li>
Selected troop indicator</li>
Ownership indicators</li>
Movement animations</li>
Attack animations</li>
In-game chat feature</li>
Settings menu</li>
</ul>
Indicator for Stunned Troops</h3>
Before, the only way to tell if a troop was stunned was to click it and look on the sidebar UI.
Now, a simple yellow outline will tell you without you needing to click the troop.
It looks like this:</p>
</p>
Selected Troop Indicator</h3>
Now, the selected troop is highlighted with black square corners like this:</p>
</p>
Ownership Indicators</h3>
Now, if you own a troop, it will have a blue background.
Enemy troops on the otherhand, have a red background, just like this:</p>
</p>
Movement Animations</h3>
These are the new movement animations for the troops.
I had to rewrite the code for ownership indicators for the animations to work correctly.
The method I was using before was very dumb: I assigned ownership indicators to troops every frame, and that lead to some bizarre bugs.
Instead, I now just spawn them as children of the troop they indicate the ownership of.
That way, it is a lot simpler to control them (making them invisible when the troop is performing an animation).</p>
</p>
Note:</strong> this is a GIF, and the pixel art is a bit weird. I wasn't able to get normal videos to work,
so I stuck with this. If anyone know how to add an MP4 video to Hugo, please send me a message.</p>
Attack Animations</h3>
These are the new attack animations:</p>
</p>
In-Game Chat Feature</h3>
The game now has a chat in game! This means you may discuss with your opponent while player.
Usernames are also coming soon (although they will just be local, there is no account system yet).</p>
</p>
Settings Menu</h3>
Here is the new settings menu:</p>
</p>
The server address is the only working setting at the moment though.
As mentioned before, usernames are coming in the future.
Also, while debug mode is technically working, it doesn't show anything else more than the usually game.
That is also coming in the future.</p>
Conclusion</h3>
If you made it this far, as always, thanks for reading!
I pour a ton of time into this project and hope to see it be played soon.
You can test the game locally by downloading the code (Github</a>). Just remember to add -- dev</code> when using cargo run</code> to not make the game crash when running two instances.</p>
Finally, here</a> is a little chiptune song I've been working on.</p>


8bit Duels Devlog Part 5
Unknown — Mon, 02 Jan 2023 00:00:00 +0000
👋 Hi again! This is part 5 of my devlog where I code my multiplayer turn-based strategy game.
It's been a while since I made a devlog, so there's quite a bit to unpack here.
Priorities have changed for the better, gameplay mechanics have been established, a community chat has been created, and an artist has joined forces with me to create the game!
There's been quite a bit of progress made in the code as well. Without any further ado, let's get into it!</p>
Announcements</h3>

Testing Community</h4>
</li>
</ul>
I knewly created a Discord server (link</a>) for anyone interested in testing the game.
There, I will post updates on the development of 8bit Duels, and I'll set a server up when the game will be in MVP stage.
The game is almost ready to be played, so join if you want to be notified of that!</p>

New Artist</h4>
</li>
</ul>
One of my friends agreed to make pixel art for my game! He is way more talented than me, so the art is much better and detailed with his help.
You will see more of his work down below.</p>
Prioritizing Gameplay</h3>
After I left off the devlog last time, I started working on the game's UI. However, this just detracted me from the gameplay coding.
I also had issues with the UI library I was using, and wasn't making any real progress.
However, once I started focusing more on the gameplay, things started to pick up rapidly.</p>
Gameplay Elements</h3>
Since my last devlog, I have added many things, the most important of which being the turn system.
Now, players each take turns placing troops, moving them and attacking with them.
I also added the ability to spawn troops, and to win the game with them (if the are on the last row of the board and have the ability to move, then you can use them to win the game).
When a player spawns troops, it is automatically stunned for one turn. While stunned, it can't attack or move.</p>
I also added the two game currencies. The first is the number of pawns, which determines how many troops a single player can have on the board at the same time.
When placing a troop, you loose one pawn. When one of your troops dies, you gain one.
One interesting mechanic this brings is the possibility to make troops that require more than one pawn to be placed, and they might be more powerful.
Another possibility would be to add a card ability that would increase your total number of troops.
The other currency in my game will be the number of spirits. These are used to buy troops.
The initial concept behind them was the idea that you would make pawns become alive by being infused with spirits.
The more powerful the troop, the more spirits it needs to be spawned. Also, when you defeat an enemy troop, you gain half of the spirits that were spent to spawn that troop, rounded down to an integer.
Players also gain one spirit every turn.</p>
Troop Abilities</h4>
To make the gameplay more interesting, I added these new abilities (they haven't been fully implemented yet):</p>

Spirit Collector</strong>: When the troop that has this ability defeats an enemy, the player receives all of the spirits spent to spawn the enemy, instead of half.</li>
Multi Attack</strong>: When a troop has this ability, it can attack multiple times per turn (the amount of maximum attacks changes per troop).</li>
Stun</strong>: This troop has the ability to stun enemy troops when attacking them.</li>
</ul>
There are many more abilities to come.</p>
Troops</h4>
Skeleton</strong>: The skeleton got a new sprite, which looks like this:</h5>
</p>
Here are the stats for the skeleton:</p>

Health Points</strong>: 5</li>
Attack Damage</strong>: 3</li>
Spirit Cost</strong>: 2</li>
Abilities</strong> None</li>
</ul>
Reaper</strong>: Here is the new reaper!</h5>
</p>
Here are his stats:</p>

Health Points</strong>: 6</li>
Attack Damage</strong>: 4</li>
Spirit Cost</strong>: 5</li>
Abilities</strong>: Spirit Collector</li>
</ul>
Kraken</strong>: Here is the new kraken!</h5>
</p>
Here are its stats:</p>

Health Points</strong>: 12</li>
Attack Damage</strong>: 1</li>
Spirit Cost</strong>: 5</li>
Abilities</strong>: Multi Attack 3</li>
</ul>
Spider</strong>: Here is the new spider!</h5>
</p>
Here are its stats:</p>

Health Points</strong>: 4</li>
Attack Damage</strong>: 2</li>
Spirit Cost</strong>: 4</li>
Abilities</strong>: Stun 1</li>
</ul>
Conclusion</h3>
If you've read this far, thank you! This devlog was pretty long, and I think I will no longer be showing snippets of code in the future.
The code, as always, is available on Github</a>.
That is all for me, I will see you in the next one!</p>


8bit Duels Devlog Part 4
Unknown — Fri, 25 Nov 2022 00:00:00 +0000
Hello! Welcome to the fourth part of my devlog where I develop my multiplayer turn-based game. I previously didn't have a name, but I have decided to name it 8bit Duels! I think this fits the theme pretty nicely. Anyways, on with the devlog!</p>
Refactoring</h3>
This devlog is all about refactoring, and how I made my code cleaner. I did this by creating a workspace shared between the client and the server. This allows me to directly serialize and deserialize packets into ClientMessage</code> and ServerMessage</code> enum variants. One reason I adore Rust is because you can pass parameters to some enums. This is great in my case, as I need to send some data between the client and the server. These changes were suggested by a user in the Rust gamedev Discord server (link to their website</a>).</p>
This refactoring was done over most of the networking code, so I won't show everything here. The code is on Github here</a> if you want to check it out (stars are greatly appreciated).</p>
The main thing is that I now need less logic to handle packets. Before, I was creating some raw JSON in the client and putting a packet-type</code> value in the object. I was then matching that value on the server-side, and vice-versa. This is an extremely bad practice, and it resulted in longer tedious code, since I needed to also get the other variables in the packets by their name in the JSON object. Now, I've just created a shared common</code> package along with the client and server packages. It contains these simple API packets:</p>
#[derive(</span>Serialize</span>,</span> Deserialize</span>,</span> Debug</span>)]</span></span>
pub enum</span> ServerMessage</span> {</span></span>
    // 1st param: whether or not the player is player_1</span></span>
    StartGame</span>(</span>bool</span>),</span></span>
    StartTurn</span>,</span></span>
    // 1st param: the `CardEntity` to spawn</span></span>
    SpawnCard</span>(</span>CardEntity</span>),</span></span>
    /*</span></span>
    1st param: the initial x position</span></span>
    2nd param: the initial y position</span></span>
    3rd param: the final   x position</span></span>
    4th param: the final   y position</span></span>
    */</span></span>
    MoveTroop</span>(</span>i32</span>,</span> i32</span>,</span> i32</span>,</span> i32</span>),</span></span>
    AttackTroop</span>(</span>i32</span>,</span> i32</span>,</span> i32</span>,</span> i32</span>),</span></span>
}</span></span>
</span>
#[derive(</span>Serialize</span>,</span> Deserialize</span>,</span> Debug</span>)]</span></span>
pub enum</span> ClientMessage</span> {</span></span>
    Deck</span>(</span>Vec</span><</span>Card</span>>),</span></span>
    MoveTroop</span>(</span>i32</span>,</span> i32</span>,</span> i32</span>,</span> i32</span>),</span></span>
    AttackTroop</span>(</span>i32</span>,</span> i32</span>,</span> i32</span>,</span> i32</span>),</span></span>
}</span></span></code></pre>
Using serde_json</code>, a great JSON library, I can just serialize and deserialize packets into enum variants. These are handled like so on the client (I removed, the logic, since it's very straightforward):</p>
if let</span> Some</span>(message)</span> =</span> guard</span>.</span>pop_front</span>() {</span></span>
        match</span> message {</span></span>
            ServerMessage</span>::</span>StartGame</span>(is_player_1)</span> =></span> {</span></span>
                // Starting the game</span></span>
            }</span></span>
            ServerMessage</span>::</span>SpawnCard</span>(card_entity)</span> =></span> {</span></span>
                // Spawning troops</span></span>
            }</span></span>
            ServerMessage</span>::</span>MoveTroop</span>(start_x, start_y, end_x, end_y)</span> =></span> {</span></span>
                // Moving troops</span></span>
            }</span></span>
            ServerMessage</span>::</span>AttackTroop</span>(start_x, start_y, end_x, end_y)</span> =></span> {</span></span>
                // Attacking troops</span></span>
            }</span></span>
            _</span> =></span> {}</span></span>
        }</span></span>
    }</span></span></code></pre>
On the server, we have something similar, but with ClientMessage</code> instead.</p>
Conclusion</h3>
If you made it this far, thanks again for reading! This devlog was pretty short since there wasn't much to explain. I do plan on finishing this game as soon as possible, but I am very busy at the moment, so progress is very slow. With that, I hope you enjoyed and are somewhat hoping to try out my game in the future. See you next time!</p>
Special thanks to the user who helped me improve my code. Hints on grammar and best practices are always greatly appreciated.</strong></p>


8bit Duels Devlog Part 3
Unknown — Sun, 09 Oct 2022 00:00:00 +0000
Hello Readers! Welcome to the third devlog on this series where I code a multiplayer turn-based strategy game! If you haven't read the three previous posts, go check them out! This week, I created a simple and exciting selecting system for my troops. Without further ado, let's get into it. Hope you enjoy!</p>
Troop selecting</h2>
In the last devlog, I talk about how I implemented the spawning mechanism in my game. Essentially, placing some troops on the board. This went very well and is now fully functional. However, we still need to be able to select those troops and move them. This is what it looks like after this week:</p>
</p>
Here the skeleton is not clearly distinguishable, so I'll make sure to change some colors for next time.</p>
</p>
The code for this was actually quite long, so I'll simply sum it up for you. Essentially, we spawn on every board tile two entities, one for movement interactions and one for attack interactions. These both have their own separate components named MoveInteraction</code> and AttackInteraction</code>. They are always invisible, except when the SelectedCardEntity</code> resource (which is an Option<CardEntity></code>) contains an entity. When that happens, if they are close enough to that entity, we show them. Pretty simple, right? Well, this took around about 200 lines of code. However, I think the result is definitely worth it.</p>
Meme of the week</h4>
</p>
Conclusion</h4>
In conclusion, this was a very short devlog for this week, and it's a bit late. Normally, I would post on Friday, but I think I'll start doing it on the weekends. I may even only post every other week, since I don't have enough progress to show for after a week.</p>
In addition, the code is now on Github for everyone to see! You can find it at here</a></p>
Finally, I would like to say thank you if you read this post all the way. This was a short one.</p>


8bit Duels Devlog Part 2
Unknown — Sat, 01 Oct 2022 00:00:00 +0000
Hello readers! This is my progress for week 2 of coding my multiplayer game with Rust and Bevy. This post is a bit late, and should’ve been out yesterday, but I wasn't able to make it in time. Anyways, here is my progress this week. As a reminder, this is only a side project, and I don't work on it for extended periods of time, so progress is slow.</p>
In this post, we will cover three things:</p>

Asset loading</strong>: how I load the sprites for my game and access them throughout the code.</li>
Spawning troops</strong>: how I send the packets required to place troops on the board, which needs to be slightly different for each client.</li>
Game art progress</strong>: my two new sprites for the game.</li>
</ul>
In this post, I will also show an image of how the game looks at the moment so you can give feedback in the comments, and maybe even come up with a name for the game (it still doesn't have one). Without further ado, let's get into it!</p>
Asset loading</h3>
I have decided that all my character sprites will be 8x pixel art tiles. The best way to handle that is to put them all in a sprite sheet and use Bevy's TextureAtlas</code> struct and store it in a resource (Res</code>) for our systems to use. This is done as such in the game/card.rs</code> file:</p>
// game/card.rs</span></span>
</span>
pub</span>(</span>crate</span>)</span> struct</span> CardSprites</span>(</span></span>
    pub</span>(</span>crate</span>)</span> Handle</span><</span>TextureAtlas</span>>,</span></span>
    pub</span>(</span>crate</span>)</span> HashMap</span><</span>String</span>,</span> usize</span>>,</span></span>
);</span></span>
</span>
fn</span> load_card_sprites</span>(</span></span>
    mut</span> commands</span>:</span> Commands</span>,</span></span>
    asset_server</span>:</span> Res</span><</span>AssetServer</span>>,</span></span>
    mut</span> texture_atlases</span>:</span> ResMut</span><</span>Assets</span><</span>TextureAtlas</span>>>,</span></span>
) {</span></span>
    let</span> sprite_sheet</span> =</span> asset_server</span>.</span>load</span>(</span>"sprite_sheet.png"</span>);</span></span>
    let</span> atlas</span>:</span> TextureAtlas</span> =</span> TextureAtlas</span>::</span>from_grid</span>(sprite_sheet,</span> Vec2</span>::</span>splat</span>(</span>8</span>.</span>),</span> 1</span>,</span> 1</span>);</span></span>
</span>
    let</span> atlas_handle</span> =</span> texture_atlases</span>.</span>add</span>(atlas);</span></span>
    let mut</span> card_sprite_map</span> =</span> HashMap</span>::</span>new</span>();</span></span>
    card_sprite_map</span>.</span>insert</span>(</span>"skeleton"</span>.</span>to_string</span>(),</span> 0</span>);</span></span>
</span>
    commands</span>.</span>insert_resource</span>(</span>CardSprites</span>(atlas_handle, card_sprite_map));</span></span>
}</span></span></code></pre>
Here, we load the sprite_sheet.png file, which is in our assets folder. We tell Bevy to parse it as a grid of 8x8 tiles. This gives us a TextureAtlas</code>, from which we store a Handle</code> (sort of reference struct for Bevy) into our CardSprites</code> resource. This resource also contains a map that allows us to get the index of a character's texture with its name. This makes it very simple to add more characters later on. In other systems that need to access these sprites, we can just add Res<CardSprites></code> to the function arguments. That is very helpful, as we will see later on.</p>
Spawning troops</h3>
Now for the interesting part. We can finally start putting some stuff on the game board! To do this, we first have to go into the server side and code a way for it to send spawning packets to the clients.</p>
// net/packets.rs</span></span>
</span>
pub fn</span> spawn_troop</span>(card</span>: &</span>Card</span>, x_pos</span>:</span> i32</span>, y_pos</span>:</span> i32</span>, flip_board</span>:</span> bool</span>)</span> -></span> Packet</span> {</span></span>
        let mut</span> json</span>:</span> Value</span> =</span> serde_json</span>::</span>from_str</span>(</span></span>
            r#"</span></span>
            {</span></span>
                "packet-type": "spawn-card"        </span></span>
            }</span></span>
        "#</span>,</span></span>
        )</span></span>
        .</span>unwrap</span>();</span></span>
        if let</span> Value</span>::</span>Object</span>(</span>ref mut</span> map)</span> =</span> json {</span></span>
            let</span> card_entity</span> =</span> CardEntity</span>::</span>new</span>(</span></span>
                card,</span></span>
                if</span> flip_board {</span> 4</span> -</span> x_pos }</span> else</span> { x_pos },</span></span>
                if</span> flip_board {</span> 8</span> -</span> y_pos }</span> else</span> { y_pos },</span></span>
            );</span></span>
            map</span>.</span>insert</span>(</span></span>
                "troop"</span>.</span>to_string</span>(),</span></span>
                serde_json</span>::</span>to_value</span>(</span>&</span>card_entity)</span>.</span>unwrap</span>(),</span></span>
            );</span></span>
        }</span></span>
        Packet</span> { data</span>:</span> json }</span></span>
    }</span></span>
}</span></span></code></pre>
This is mostly some simple JSON object creation. However, notice there is an argument called flip_board</code>. If it is set to true, this boolean makes it so we flip the x and y positions of the troop on the board (it's a 5x9 board, that's why there's the 4 and the 8). This is necessary to insure that both clients see their perspective of the game. Here is what the handling of this packet looks like on the client side:</p>
// net/packet_handler.rs</span></span>
</span>
"spawn-card"</span> =></span> {</span></span>
    if !</span>matches!</span>(packet[</span>"troop"</span>]</span>.</span>clone</span>(),</span> Value</span>::</span>Null</span>) {</span></span>
        let</span> result</span> =</span></span>
            serde_json</span>::</span>from_value</span>::</span><</span>CardEntity</span>>(packet[</span>"troop"</span>]</span>.</span>clone</span>());</span></span>
        if</span> result</span>.</span>is_ok</span>() {</span></span>
            let</span> card_entity</span> =</span> result</span>.</span>unwrap</span>();</span></span>
            let mut</span> sprite</span> =</span> TextureAtlasSprite</span>::</span>new</span>(</span></span>
                card_sprites</span></span>
                    .</span>1</span></span>
                    .</span>get</span>(</span>&</span>card_entity</span>.</span>card</span>.</span>get_name</span>())</span></span>
                    .</span>unwrap</span>()</span></span>
                    .</span>clone</span>(),</span></span>
            );</span></span>
            sprite</span>.</span>custom_size </span>=</span> Some</span>(</span>Vec2</span>::</span>splat</span>(tile_size</span>.</span>0</span> *</span> 0.8</span>));</span></span>
</span>
            commands</span></span>
                .</span>spawn_bundle</span>(</span>SpriteSheetBundle</span> {</span></span>
                    sprite,</span></span>
                    texture_atlas</span>:</span> card_sprites</span>.</span>0.</span>clone</span>(),</span></span>
                    transform</span>:</span> Transform</span>::</span>from_xyz</span>(</span>0</span>.</span>,</span> 0</span>.</span>,</span> 500</span>.</span>),</span></span>
                    ..</span>Default</span>::</span>default</span>()</span></span>
                })</span></span>
                .</span>insert</span>(card_entity);</span></span>
        }</span></span>
    }</span></span>
}</span></span></code></pre>
Note:</strong> we need to add card_sprites: Res<CardSprites>,</code> to the function arguments so that we can access the sprites we loaded earlier.</p>
Here, we get the troop data from the packet if it exists. This returns a CardEntity</code> (if you don't know what this is, go check out the the week 1 devlog) that we can use to spawn the new troop. Here, it is placed at the (0, 0) coordinates. This is because we have another simple system that takes care of positioning the entities. This is what is looks like if we spawn a skeleton at (0, 0).</p>
</p>
Game art progress</h3>
This week, I drew two very simple sprites that I'll hopefully  using by next week for character interactions. The blue tile is for movement and the red one is for attack.</p>
</p>
</p>
Meme of the week</h3>
It's that time again!</p>
</p>
Once again, if you made it this far, thank you so much for reading. As for me, I'm out, and I hope to have some good progress to show for next week!</p>


8bit Duels Devlog Part 1
Unknown — Sat, 24 Sep 2022 00:00:00 +0000
Hello readers! Welcome to the week 1 devlog of my multiplayer game using Rust and the Bevy game engine. In this post, I will talk about my progress for the first week. This isn't the beginning of the project, but rather my first devlog. Without further ado, let's get into it!</p>
Please note that you are more than welcome to comment on my code. Hints on how to make it more efficient, performant, etc. are greatly appreciated.</p>
Packet handling and bug fixes</h2>
I have just started the networking between the client and the server, and I already have had to fix two small but impactful  and hard to find bugs (one was hiding in plain sight but I was too stupid to see it). But first, we have to take a look at how the networking in managed on both the client and server side. They both make use of threads to read and write to each other via TCP. They also use the std::sync::Mutex</code> class wrapped in a std::sync::Arc</code> to safely manage mutable references to the packet queues (more on them later).</p>
Client-side</h4>
Related files:</h6>

client/src/net/mod.rs</strong></li>
client/src/net/input.rs</strong></li>
client/src/net/out.rs</strong></li>
client/src/net/packet_handler.rs</strong></li>
</ul>
Because of how the Bevy engine works, to get our packets to be read by the game, we need to pass them as resources to our App (Bevy uses the ECS</a> architectural pattern). These resources can then be used by the systems that run on every time the game updates. These resources typically are tuple structs, because Bevy needs every different resource to be a different struct. We use a VecDeque</code> object to make a queue for the packets, because it allows us to push data to the end of the queue, and then pop the front of it. Hence, we declare the queues as</p>
// mod.rs</span></span>
pub</span>(</span>crate</span>)</span> struct</span> QueueIn</span>(</span>pub</span>(</span>crate</span>)</span> Arc</span><</span>Mutex</span><</span>VecDeque</span><</span>String</span>>>>);</span></span>
pub</span>(</span>crate</span>)</span> struct</span> QueueOut</span>(</span>pub</span>(</span>crate</span>)</span> Arc</span><</span>Mutex</span><</span>VecDeque</span><</span>String</span>>>>);</span></span></code></pre>
These create a way for our handle_packets</code> to process and write packets.</p>
// packet_handler.rs</span></span>
fn</span> handle_packets</span>(</span></span>
    mut</span> queue_in</span>:</span> ResMut</span><</span>QueueIn</span>>,</span></span>
    mut</span> queue_out</span>:</span> ResMut</span><</span>QueueOut</span>>,</span></span>
    mut</span> commands</span>:</span> Commands</span>,</span></span>
    mut</span> state</span>:</span> ResMut</span><</span>State</span><</span>GameState</span>>>,</span></span>
) {</span></span>
    let mut</span> guard</span> =</span> queue_in</span>.</span>0.</span>lock</span>()</span>.</span>unwrap</span>();</span></span>
</span>
    if !</span>guard</span>.</span>is_empty</span>() {</span></span>
        let</span> packet_to_read</span> =</span> guard</span>.</span>pop_front</span>()</span>.</span>unwrap</span>();</span></span>
        let</span> packet</span>:</span> Value</span> =</span></span>
            serde_json</span>::</span>from_str</span>::</span><</span>Value</span>>(packet_to_read</span>.</span>as_str</span>())</span>.</span>unwrap_or</span>(</span>Value</span>::</span>Null</span>);</span></span>
</span>
        if</span> matches!</span>(packet,</span> Value</span>::</span>Object</span>(_)) {</span></span>
</span>
            if let</span> Value</span>::</span>String</span>(string)</span> =</span> packet[</span>"packet-type"</span>]</span>.</span>clone</span>() {</span></span>
                match</span> string</span>.</span>as_str</span>() {</span></span>
                    "server-start-game"</span> =></span> {</span></span>
                        state</span>.</span>set</span>(</span>GameState</span>::</span>Playing</span>);</span></span>
                    }</span></span>
                    "none"</span> =></span> {</span></span>
                        println!</span>(</span>"bad packet from the server!"</span>)</span></span>
                    }</span></span>
                    &</span>_</span> =></span> {}</span></span>
                }</span></span>
            }</span></span>
        }</span></span>
    }</span></span>
    drop</span>(guard);</span></span>
}</span></span></code></pre>
Here, we get the first packet (which is a String</code> read from the TcpStream) in the queue and deserialize it using the serde_json</code> crate. This parses it into a Value</code> object, which represents JSON data. We then get the "packet-type"</code> field from the JSON object, and if it exists, we use a simple match</code> statement to handle the packet. You can also see that in the declaration of the function (functions represent systems in Bevy) that we tell Bevy to get the QueueIn</code> and QueueOut</code> resources, which is where the packets are located. We also need to drop()</code> the MutexGuard</code> (which gives us control over the queue) at the end of the function to let the rest of the code access it.</p>
To read the packets from the server and to send the packets to it, we have too very basic threads that are spawned in input.rs</code> and out.rs</code>:</p>
//input.rs</span></span>
pub</span>(</span>crate</span>)</span> fn</span> spawn_input_thread</span>(</span></span>
    queue_in_ref</span>:</span> Arc</span><</span>Mutex</span><</span>VecDeque</span><</span>String</span>>>>,</span></span>
    mut</span> reader</span>:</span> BufReader</span><</span>TcpStream</span>>,</span></span>
) {</span></span>
    thread</span>::</span>spawn</span>(</span>move ||</span> {</span></span>
        let mut</span> buffer</span>:</span> [</span>u8</span>;</span> 1024</span>]</span> =</span> [</span>0</span>;</span> 1024</span>];</span></span>
        let mut</span> received_data</span>:</span> usize</span>;</span></span>
        loop</span> {</span></span>
            received_data</span> =</span> reader</span>.</span>read</span>(</span>&mut</span> buffer)</span>.</span>unwrap_or</span>(</span>0</span>);</span></span>
            if</span> received_data</span> ></span> 0</span> {</span></span>
                if let</span> Ok</span>(string)</span> =</span> std</span>::</span>str</span>::</span>from_utf8_mut</span>(</span>&mut</span> buffer) {</span></span>
                    let mut</span> guard</span> =</span> queue_in_ref</span>.</span>lock</span>()</span>.</span>unwrap</span>();</span></span>
                    guard</span>.</span>push_back</span>(string</span>.</span>replace</span>(</span>"</span>\0</span>"</span>,</span> ""</span>)</span>.</span>to_string</span>());</span></span>
                    drop</span>(guard);</span></span>
                    buffer</span> =</span> [</span>0</span>;</span> 1024</span>];</span></span>
                }</span> else</span> {</span></span>
                    println!</span>(</span>"Got an invalid UTF-8 packet!"</span>)</span></span>
                }</span></span>
            }</span> else</span> {</span></span>
                break</span>;</span></span>
            }</span></span>
        }</span></span>
    });</span></span>
}</span></span></code></pre>
We are using a 1024 character buffer, which should be more than enough for the packets we will receive. One thing to note, and which caused a lot of headaches, is that we need to remove every \0</code> (whitespace) character. This happens because the buffer is always larger than the packet, which causes it to add unnecessary characters to the end of the String</code>. This causes serde_json</code> to fail to parse the packet.</p>
// out.rs</span></span>
pub</span>(</span>crate</span>)</span> fn</span> spawn_output_thread</span>(queue_out_ref</span>:</span> Arc</span><</span>Mutex</span><</span>VecDeque</span><</span>String</span>>>>,</span> mut</span> stream</span>:</span> TcpStream</span>){</span></span>
    thread</span>::</span>spawn</span>(</span>move ||</span> {</span></span>
        loop</span>{</span></span>
            let mut</span> guard</span> =</span> queue_out_ref</span>.</span>lock</span>()</span>.</span>unwrap</span>();</span></span>
            if</span> guard</span>.</span>is_empty</span>() {</span>drop</span>(guard);</span> continue</span>;}</span></span>
</span>
            if</span> stream</span>.</span>write</span>(guard</span>.</span>pop_front</span>()</span>.</span>unwrap</span>()</span>.</span>as_bytes</span>())</span>.</span>is_err</span>(){</span></span>
                panic!</span>(</span>"Error Writing to the server!"</span>);</span></span>
            }</span></span>
            drop</span>(guard);</span></span>
        }</span></span>
    });</span></span>
}</span></span></code></pre>Server-side.</h4>
On the server side, we use a similar technique with the packet queues. However, here, they are managed by a Game</code> struct which owns and operates on them (a Game</code> represents a duel between two players). There isn't much to see here, since it's more of a simplified version of the client side, and we don't use Bevy for the server.</p>
Common protocol</h4>
I haven't started coding the gameplay yet, but I've established a way to communicate the Card</code> (or Troop, haven't decided on the name) data over the network. On both the client and the server, we have a game</code> module, which contains the file card.rs</code>. In this file, we define the structs that represent our Card</code> data:</p>
// card.rs</span></span>
#[derive(</span>Serialize</span>,</span> Deserialize</span>,</span> Clone</span>,</span> Debug</span>)]</span></span>
pub struct</span> Card</span> {</span></span>
    name</span>:</span> String</span>,</span></span>
    type_</span>:</span> CardType</span>,</span></span>
    hp</span>:</span> f32</span>,</span></span>
    attack</span>:</span> f32</span>,</span></span>
    cost</span>:</span> i32</span>,</span></span>
    abilities</span>:</span> Vec</span><</span>CardAbility</span>>,</span></span>
}</span></span>
</span>
#[derive(</span>Serialize</span>,</span> Deserialize</span>,</span> Clone</span>,</span> Debug</span>)]</span></span>
enum</span> CardType</span> {</span></span>
    TROOP</span>,</span></span>
    SPELL</span>,</span></span>
    BUILDING</span>,</span></span>
}</span></span>
</span>
#[derive(</span>Serialize</span>,</span> Deserialize</span>,</span> Clone</span>,</span> Debug</span>)]</span></span>
pub struct</span> CardEntity</span>{</span></span>
    card</span>:</span> Card</span>,</span></span>
    current_hp</span>:</span> i32</span>,</span></span>
} </span></span>
</span>
#[derive(</span>Serialize</span>,</span> Deserialize</span>,</span> Clone</span>,</span> Debug</span>)]</span></span>
enum</span> CardAbility</span> {</span></span>
    ProduceGold</span>(</span>i32</span>),</span></span>
}</span></span></code></pre>
As you can see, we have two Card</code> structs and two enums. The Card</code> struct defines the troops' stats, including their abilities, which are defined in the CardAbility</code> enum (more abilities will be added later). This will be useful when we need to code the game logic and check a troop's properties. The CardType</code> struct does not yet serve a specific purpose, but I still included it. Finally, the CardEntity</code> struct represents a troop that is on the game board. It needs an additional hp (health points) property.</p>
That concludes the brief coding progress progress made during this week.</p>
Game art progress</h4>
I've finally decided on my color palette, and made this simple 8x skeleton pixel art, which I hope will be in the game at some point. I'm truly a beginner when it comes to art, however.</p>
</p>
Meme of the week</h4>
It's time for the meme of the week:
</p>
Conclusion</h4>
If you made it this far, thank you very much for reading. This has been the week #1 of my multiplayer game devlog. I hope to continue this series and post updates every week.</p>


8bit Duels Devlog Intro
Unknown — Sat, 17 Sep 2022 00:00:00 +0000
Hello readers! This is a short post introducing my first blog series, where I will document my process creating a multiplayer turn-based game. The game is not named yet.</p>
Below is what I'll explore in this post:</h2>


What I'm making: in this section, I'll tell a bit more about what kind of game I'm making as well as what are my expectations and goals for this project.</p>
</li>

Language and tools: I will cover the technology stack behind my game. This includes the programming language and the game engine as well as how the game will work. I will also cover the code editor I'm using.</p>
</li>

My schedule: I'll explain briefly what my expectations are regarding post frequency.</p>
</li>

The content. I'll detail what my posts will include.</p>
</li>
</ul>
Without any further ado, let's get started!</p>
What I'm making</h2>
I'm making a multiplayer turn-based game. The game is inspired by chess, because you will be able to move your troops across the board, but it is more heavily inspired by Clash Mini, a game from Supercell (link to the clash website</a>). With this project, I aim to learn more about game development. I also hope to discover the wonderful (or rather awful) world of networking and all the bugs that will come with it. There is no deadline for the game, as progress is very slow and inconsistent. In the end, I hope to make the code open source, depending on how proud of it I am 😅.</p>
What I'm using</h2>
I'm using Rust for this project, along with the Bevy game engine (an amazing open source ECS game engine that you can find here</a>). I am currently coding a server from scratch using, you guessed it, Rust. Currently, there is only one server for all the clients, but this game is more of a proof-of-concept than a game I consider will actually get a player base. However, things are subject to change in the future. To edit code, I use Vim (which I've just started using but already adore) with Rust-Analyzer and coc.nvim, which are a must for Rust development.</p>
My schedule</h2>
As mentioned before, progress on the game is very slow, as it is only a side project and is not on my list of priorities. I do plan on making a post per week regarding the game, though this is subject to change. These posts will come during the weekend, but the schedule is subject to change and I may of course miss some weekly posts. This is more of a way to document my game development experience instead of a serious content series. However, I will appreciate any comments and interaction if you, the reader, is interested.</p>
My content</h2>
In my weekly posts, I plan to cover my weekly progress on my game, as well as a dive into some of the code. I will also show small sneak peaks in the form of images or videos. Finally, I will try to include a programming related meme that I made in each of my posts. I usually also post these on Reddit here</a>. This is this post's one:
</p>
That about wraps up my first ever blog post! Thank you for reading, and I will see you in the next one!</p>

openset

summer of math exposition 4

corne keyboard

epoxy table

summer of math exposition π

dactyl skeletyl keyboard

8bit Duels Devlog Part 8 - Final Devlog

8bit Duels Devlog Part 7

Main Menu</h4> For the main menu, I drew an animated background with the four characters currently implemented in the game (Skeleton, Reaper, Kraken and Spider).</p> Image of the main menu UI</em></p>

8bit Duels Devlog Part 6

Changes</h2> This devlog includes mostly gameplay polish change, to make the game easier to understand and to follow.</p> Indicator for stunned troops</li> Selected troop indicator</li> Ownership indicators</li> Movement animations</li> Attack animations</li> In-game chat feature</li>

Indicator for Stunned Troops</h3> Before, the only way to tell if a troop was stunned was to click it and look on the sidebar UI. Now, a simple yellow outline will tell you without you needing to click the troop. It looks like this:</p> </p>

Selected Troop Indicator</h3> Now, the selected troop is highlighted with black square corners like this:</p> </p>

Ownership Indicators</h3> Now, if you own a troop, it will have a blue background. Enemy troops on the otherhand, have a red background, just like this:</p> </p>

In-Game Chat Feature</h3> The game now has a chat in game! This means you may discuss with your opponent while player. Usernames are also coming soon (although they will just be local, there is no account system yet).</p> </p>

8bit Duels Devlog Part 5

New Artist</h4> </li> </ul> One of my friends agreed to make pixel art for my game! He is way more talented than me, so the art is much better and detailed with his help. You will see more of his work down below.</p>

Troop Abilities</h4> To make the gameplay more interesting, I added these new abilities (they haven't been fully implemented yet):</p>

Troops</h4>

Skeleton</strong>: The skeleton got a new sprite, which looks like this:</h5> </p> Here are the stats for the skeleton:</p> Health Points</strong>: 5</li> Attack Damage</strong>: 3</li> Spirit Cost</strong>: 2</li>

Conclusion</h3> If you've read this far, thank you! This devlog was pretty long, and I think I will no longer be showing snippets of code in the future. The code, as always, is available on Github</a>. That is all for me, I will see you in the next one!</p>

8bit Duels Devlog Part 4

8bit Duels Devlog Part 3

Conclusion</h4> In conclusion, this was a very short devlog for this week, and it's a bit late. Normally, I would post on Friday, but I think I'll start doing it on the weekends. I may even only post every other week, since I don't have enough progress to show for after a week.</p>

8bit Duels Devlog Part 2

Meme of the week</h3> It's that time again!</p> </p> Once again, if you made it this far, thank you so much for reading. As for me, I'm out, and I hope to have some good progress to show for next week!</p>

8bit Duels Devlog Part 1

Client-side</h4> Related files:</h6> client/src/net/mod.rs</strong></li> client/src/net/input.rs</strong></li> client/src/net/out.rs</strong></li>

Related files:</h6> client/src/net/mod.rs</strong></li> client/src/net/input.rs</strong></li> client/src/net/out.rs</strong></li>

Meme of the week</h4> It's time for the meme of the week: </p>

Conclusion</h4> If you made it this far, thank you very much for reading. This has been the week #1 of my multiplayer game devlog. I hope to continue this series and post updates every week.</p>

8bit Duels Devlog Intro

Main Menu</h4>
For the main menu, I drew an animated background with the four characters currently implemented in the game (Skeleton, Reaper, Kraken and Spider).</p>
Image of the main menu UI</em></p>

Indicator for Stunned Troops</h3>
Before, the only way to tell if a troop was stunned was to click it and look on the sidebar UI. Now, a simple yellow outline will tell you without you needing to click the troop. It looks like this:</p>
</p>

Selected Troop Indicator</h3>
Now, the selected troop is highlighted with black square corners like this:</p>
</p>

Ownership Indicators</h3>
Now, if you own a troop, it will have a blue background. Enemy troops on the otherhand, have a red background, just like this:</p>
</p>

In-Game Chat Feature</h3>
The game now has a chat in game! This means you may discuss with your opponent while player. Usernames are also coming soon (although they will just be local, there is no account system yet).</p>
</p>

New Artist</h4> </li> </ul>
One of my friends agreed to make pixel art for my game! He is way more talented than me, so the art is much better and detailed with his help. You will see more of his work down below.</p>

Conclusion</h3>
If you've read this far, thank you! This devlog was pretty long, and I think I will no longer be showing snippets of code in the future. The code, as always, is available on Github</a>. That is all for me, I will see you in the next one!</p>

Meme of the week</h3>
It's that time again!</p>
</p>
Once again, if you made it this far, thank you so much for reading. As for me, I'm out, and I hope to have some good progress to show for next week!</p>

Meme of the week</h4>
It's time for the meme of the week: </p>

Conclusion</h4>
If you made it this far, thank you very much for reading. This has been the week #1 of my multiplayer game devlog. I hope to continue this series and post updates every week.</p>