Efficient Note Taking 🔗As my company starts belatedly revamping our corporate structure a lot of things have been changing, including my personal spiral towards a manager schedule vs a maker schedule lately. One thing I have noticed as I track more and more disparate things is that if I don’t start taking better notes now I’m going to fall behind and drown in forgotten caveats sooner than later. The less effective I am at tracking what I need to do (outside of task based work), or need to know across a breadth of projects, people, and responsibilities, the less effective I am going to be at supporting my team.

Intent 🔗My goal is to use this specific blog post to serve as both a starting point, and something I can refer to which describes the last three years of my career. Hopefully providing the reader with some context as to various decisions, cultural settings, and hurdles which helped define choices I have made and will make from here on out as I continue to add more content here. As to why I have started a new blog in particular, I’ve been trying to come to terms with completely changing roles from an Individual Contributor (IC) to a Software Engineering Manager over these last few years.

Background 🔗I work at a relatively large 150 employee Japanese social game company as the Lead Infrastructure Engineer on one of their various game projects. My primary duties include building server infrastructure, automating all the things, helping the server programming team out so they can focus on their jobs and not worry about the rest, and handling things if it all goes south. (DevOps, SRE, etc.) Discussion 🔗We have a small Kubernetes cluster which I run in order for the client team to be able to test their changes against the stable staging server build and the ever changing development build.

I’ve been working on Armored Bits for about a year and half now and it’s coming along quite well. After this latest server refactor the game should be programmable (playable) before the year is out. My Haskell programming skills have skyrocketed, and all is well with the world. Still, eating vanilla ice cream and never mixing it up with strawberry or chocolate on occasion can get a bit dull. With that in mind, I’ve started a small side project in an attempt to fulfill two goals.

Well, it seems some German folk, specifically vektorweg and focx, have convinced me to write a blog post about some random topic I puked out over Twitter earlier this evening. The following is some convoluted and potentially incoherent rehashing of an idea I’ve been stewing on for over a decade. Background 🔗Before I dive into what the actual premise of this post is I’d like to provide a little background about my mindset.

Ok, admittedly the title is a bit misleading, but hear me out. We absolutely love what we are doing and are having a blast. However, if you truly want to be a successful indie game dev you probably shouldn’t do 99% of the things that we are doing. The goal of this post is to describe the challenges we face while making an incredibly non-traditional game, as well as give a feel for all the parts and pieces which are involved with our vision of the still far off release of Armored Bits.

Update: A Warning 🔗As pointed out by /u/tdammers: “Note that this isn’t a win-win; you’re sacrificing some type safety for convenience. One particular advantage of the typed approach is that the only bit of configuration-related code that can possibly fail is the part that parses the YAML file into your typed data structures; any mistakes you make elsewhere will amount to compiler errors. By contrast, the “dynamic” approach defers all schema errors to run time, so if your YAML file happens to not match the expectations of your code, you won’t find out until that code actually runs.

Previous Posts 🔗 Part 1 - Networking & Message Protocols Part 1 Followup - A brief followup to my original post. Topics 🔗In today’s post I will cover which messages we shuffle between the server and clients and their purpose, how the game world is fundamentally managed, and how we use an Actor class to help manage scene objects. Messages Between Server & Clients 🔗We’ve built our game so that the server only sends data the player AI has strictly requested, with a few minor exceptions such as game state changes.

I am ridiculously proud of this little bit of code: data Range a = Range a a between :: (Num a, Eq a, Ord a) => a -> Range a -> Bool between a (Range b c) = a > b && a < c betweenl :: (Num a, Eq a, Ord a) => a -> Range a -> Bool betweenl a (Range b c) = a >= b && a < c betweenr :: (Num a, Eq a, Ord a) => a -> Range a -> Bool betweenr a (Range b c) = a > b && a <= c betweenBoth :: (Num a, Eq a, Ord a) => a -> Range a -> Bool betweenBoth a (Range b c) = a >= b && a <= c Results in:

This is a quick followup to my previous post Haskell Game Server - Part 1 which covers a few changes I made after some great feedback, and grievous debugging of a crazy issue. Changes to Server.hs 🔗The following things were pointed out to me: Use forever instead of recursive calls to the same function as it makes your intent clearer. readMessage should exist and be paired with sendMessage rather than wrapped up in the unrelated runClient.