Ramblings from the shipyard.

One of the infamous parts of creating an MMORPG is managing the networking behaviors. Whether it be a horde of 100 clients connecting at the same time or a large guild overwhelming your servers by all fighting in one area, there are a number of problems that can be extremely difficult to test on your standard home setup. And let’s say your home setup could support 500 of your own clients, you still need a way to give those clients instructions. I won’t claim that I can give you a comprehensive overview of all the testing methods out there. I can’t even defend that the ones I have chosen are the most efficient. But I can share how my initial attempt at this problem is shaping up today and some of the insights it's already given me.

Yesterday was my first time attempting to connect 100 clients at once to my game servers. The fact that I could even perform that test was extremely exciting and the results were relieving to say the least. One of the scariest parts of this whole “indie MMORPG” adventure is finally getting answers.

Scale Testing in Atma

Atma employs a few different types of automated tests. Considering how fascinated by testing I am, I’m sure this won’t be my last post on the subject. To keep this post simpler than my brain wants it to be, I’m just going to focus on the scale testing I'm currently working on.

I’ve been excited about scale testing since the start of the project and had to show a lot of restraint to not implement it in the first month. Nowadays it actually answers critical questions and gives the project some much needed technical validation. The scale test orchestrates tens to hundreds of clients at a time and pushes commands to them to control their behavior in game. The most critical areas I’m looking at today are the login flow and major performance markers.

Today's Test

To perform this scale testing I’ve augmented my existing development tool AtmaSuite with a section dedicated to this type of test. The general goal of the scale testing is to allow for quick bring up of many Unreal clients and to coordinate their behaviors. Unreal clients are a bit heavy though. A piece of me considered creating minimal fake clients that just did the login flow, but using legitimate Unreal clients was both simpler and allowed me to create actual connections and handle real Unreal RPCs between client and server. It meant my server was none the wiser that it was working with bots and could test real gameplay against my servers which was critical for real performance testing.

The Goal: connect 100 clients to a server, tell them to run around, and see what happens.

Setup

Today's test is going to have our servers using a test configuration. Real production servers will use a shipping configuration which should squeeze out some more performance for us, but strips a lot of valuable debug and performance metrics as well. It's also worth noting that this is one of my first times really stressing the Iris networking system which was moved from beta to production-ready in Unreal 5.8. I haven't been able to find a ton of metrics for it online so hopefully throwing my hat into the ring will help someone else similarly interested in the performance of Iris.

Here’s a quick rundown of the important parts of the scale test process which will hopefully make this admittedly overwhelming image a bit more clear.

• Select a realm or have a new one created for the test
• Set a fan out time, which gives each client a time window to perform their commands. Think “everyone create your character within 1 second” versus “everyone create your character some time in the next 30 seconds”.
• Set an island join target, which can allow me to funnel the new clients onto a specific island instead of going through the normal island assignment flow
• Choose if I want the clients hosted on my PC or on an EC2 instance
• Configure which insights trace channels I want running on my servers
• Select which EC2 instances are used to host my coordinator, the servers, and the clients.
• Click the start test button

For those unfamiliar with EC2, think of it as just a computer I can rent from Amazon.

Most of these settings are just reused from previous runs so starting a new test isn't actually that much clicking.

What is the Coordinator?

This section is a bit dense, but you aren't missing out on anything if you skip it unless you are interested in setting this up yourself.

The coordinator is a small application that each client and game server in my test connect to. The Unreal processes connect to it on startup and listen for commands they should be running. The coordinator is responsible for managing groups of clients and letting me know when a connection is lost or if a client has reported an error and the command was not properly handled.

When I run with local clients I run the coordinator on my own machine, but when running with clients on Amazon EC2 instances I run it on its own instance. This simplifies some connection behaviors. The Unreal processes are the initiators of the connection. When they sit on EC2 instances, that outbound connection to my computer would be refused due to a common router behavior known as NAT. There are ways around it, but they are additional complexities without much benefit. Initiating a connection from my machine to that one coordinator is trivial, and my current configuration for these EC2 machines eliminates the NAT concern all together. So the coordinator runs on its own instance.

Clients

Initially I ran with Windows clients. However, everything about it was worse than when I tested with Linux ARM64 clients. I’m not planning to support Linux clients on release, but since these tests are about the server and backend I had no issue using Linux clients for testing purposes. Thankfully, the only real blocker I had with ARM64 was that I needed to exclude some Steam modules from my build and then everything worked great.

The clients all run headless and seem to run without issue on ARM64 machines. Headless mode means it runs without any graphics which significantly reduces the amount of resources each client needs and eliminates some failure paths Linux typically encounters with games. It's worth mentioning that Linux ARM64 machines are also significantly cheaper in AWS. As a nice surprise, both the instance and my game processes seem to start up much faster (based on feel, not profiling).

Let's take a look at a run

For these tests I’ve used the following EC2 instances:

I start my run by simply configuring my settings. Yesterday I discovered that with large amounts of clients I actually have some issues in the character creation stage when I have fan-out set to five seconds. That’s potentially the first major discovery of scale testing! For this demonstration I’ll dodge that and use a 15 second fan-out, meaning every client will perform its action sometime within a 15 second window.

Once the clients are in the world we can do our first test. Let's start a trace, then set the clients to wander and see if we can capture this moment happening in Unreal Insights.

Traces are downloaded automatically after they are captured and made accessible through another panel in the app.

The above screenshot of incoming packets shows two small green dots that represent incoming packets. I've clicked the first one to inspect it and we can see a small block saying "ServerRequestMove", proving this is the client trying to wander.

The profiler is showing 50 outgoing connections (it starts at 0) to choose from which is additional validation that 50 clients actually connected to the game server. The size of outgoing packets at a glance also look very reasonable.

A quick look at the timing insights shows us a few areas we may want to investigate.

The BaistaScript system is spending a ton of time on timer logic, and our replication system has a few areas taking a hefty chunk of time. Investigating these is outside the scope of this post but it's good to have these on our radar.

Anyway, let’s have some more fun with it. Let's add another 50 clients and try to reach 100.

After adding the additional clients it’s pretty clear something went wrong. The clients with red boxes around them are showing an error and, well, they moved back to the character ready bucket instead of to the world bucket. Double clicking a client brings up the tail end of their log, which confirms the join failed and has an error code for us to look into.

At first this seemed like a failure but on further inspection this was actually working exactly as intended. Each client was creating a fresh character which was being assigned its own personal island. The current world layout system however restricts each server to only supporting 72 personal islands each. The 28 rejected clients simply didn’t have room on that server to create an island. Sure enough, re-testing with two servers up showed successful connections across the 100 clients but split over two servers.

Splitting the clients over two servers doesn’t really let us hammer the server performance though. So I decided to leverage the join target option that allows me to spawn these test clients on an existing island instead of spawning their own.

Pushing to 100 Clients

I’m expecting performance to take a considerable hit when we have not only 50 more clients, but everyone is in the same area. If you aren’t familiar with networking performance, costs typically rise exponentially instead of linearly as nearby player count increases. This is because each additional player not only needs to be sent their own information, but every player that can see them now also needs to be sent information about them. Let’s take a look.

Looks like all 100 clients are successfully connecting to the server. Now let's see if our performance predictions were accurate.

You can see very clearly where I toggled the bot behavior between wandering and idling. Wandering creates more position data to send to each client so as expected the outbound networking was significantly increased. I’ve also selected a single frame to look at the outgoing data (the bottom of the image). If I grab this same frame from the timing insights, it was certainly more expensive than our previous 50 client test. I’ll admit though, performance is looking better than I expected for our first scale test.

And for some final validation, let's take a look at our tooling. During production this will be how we get a quick overview of if there are any servers really struggling, so let's make sure the view reflects our current stress test. The first of these images is when my clients were all set to idle, while the second is when they are set to wander.

The memory difference here seems insignificant, but the outbound network jumped massively and server CPU did increase. Also my client machines seem to be hitting their limit now that things are moving around. I'll admit this is the highest outbound net usage I saw, while it typically hovered around the 280 KB/second mark. Just for a quick sanity check, I took a random section from the earlier 100 client wandering insights trace and it seems to show about 3 KB/second going out to that client. So for 100 clients, the numbers add up within reason.

Overall this is great news though. CPU and memory are the harder levers to control. Outgoing network is lower than I expected honestly and doesn't seem like it will be a long term problem, but can be an area for some cost savings.

It's worth remembering this doesn't represent real gameplay, it's simple path finding spam. We'll need to include more scale tests where we spawn tons of buildings as well as ship combat in the future. Just for fun, I thought I'd jump into the server to see what it looks like with 100 players running around. After all, numbers show the server isn't stressed. But how does it feel?

Ok that was pretty fun. And as a player I'm not seeing any issues running around the world which is awesome.

Wrapping Up

Well this is where things stand today. From here I have quite a bit to investigate and a few improvements to make on the tool. There are certainly some intermittent issues in the create character and join world flow. The performance itself looks pretty solid but there are a few packets that are being sent that can be mitigated such as AtmaGameState sending the current server time (a default Unreal behavior) and some pretty surprising metrics around my tick-based timer system. Pretty soon I’ll be adding the server auto-scaling behaviors as well, which this tool will be extremely valuable for testing. I also need to look at better ways to monitor API Gateway, Lambda, and DynamoDB during these tests. Some analytics are also pointing to concerns around the moment these 100 clients join together causing significant server stutters. While a 100 client storm is production is either a champagne problem (or a bot problem), it will be worth looking into to make sure it can't occur at lower counts as well.

It’s far from perfect but it’s already found a couple of issues for me and given me a lot more confidence in the technical approach of the project. I’ll continue to improve the tool and when I have some more exciting things to show off I’ll make another post with some more updates. In the next post maybe we'll try and push as many clients as possible before we overwhelm the server.

Some bugs hit you in the face. You launch the game, run around a bit, the entire UI stops working or your character can't move anymore. These are the ones most of us are probably used to. But sometimes bugs lurk for weeks or months on end without ever surfacing. Do these ones really matter? You could argue a bug no one experiences isn't really a bug at all. I'm not writing this post because of how serious this particular issue was. Instead, it was just a really rewarding moment when I accidentally discovered it.

Analytics

As a small indie developer, my ability to schedule and execute playtests can only take me so far. At some point the game needs data to act on. About two weeks ago I added analytics into Atma which is something I've been excited about for a long time.

I've worked with analytics in the past. In fact, one of my first ever assignments as a professional developer was integrating one of Activision's proprietary analytics libraries into Unreal Engine for the Tony Hawk's Pro Skater 1 + 2 remaster. Implementing is one thing, analyzing is another. I've taken a quick stab at querying some information and making a dashboard when I was with Disruptive, but never anything significant. I certainly never developed any real confidence in how to efficiently use analytics features.

For now, that didn't matter. I just needed to start tracking information. Learning to use it is something that can come with time. As a way to test my initial implementation, I started asking Claude to look at my analytics data and create little test reports for me. And it did a pretty good job! Well, a lot of its conclusions were...misleading to say the least. It doesn't really understand the game or what was being tested. But the data was real, the charts were fun to look at, and one report had a particularly interesting piece of information hidden in it.

The Bug

With this report I was really curious to check out some newly implemented combat stats. The bar graph tracks three player combats and shows some damage dealt and some taken. My initial impression was that it looked great. The line items underneath them seemed odd though. There were five. Maybe this is just Claude messing up with its report, but another interesting piece is that the two extra combats showed zero damage dealt and zero damage taken. Not much of a combat really. So we investigated a bit more.

Reviewing

I'll be honest after all these years of programming I'm a bit embarrassed by the exact bugs here. But this blog is about transparency in the development process, not covering these things up to make me look good.

It turns out a dying ship has about a 1.2 second delay before it is actually destroyed. This was a hack implemented by Claude to address an edge case where killshot hitsplats wouldn't have time to render on the actor, and I simply missed it by reviewing too carelessly. There's no reason to keep the ship alive after death on the server. Clients will have to find another way to properly handle their cosmetic behaviors. This alone didn't cause the zero damage combats though.

The other issue was the machinery behind the cannon component. I try to funnel most unit actions through my BaistaScript system for consistency. When units die, it cancels all existing BaistaScripts. I didn't hold to that for ship firing. Instead, the ship's controller managed its own firing logic. The UAtmaScript_FireCannon was bypassed entirely for AI ships. In effect, this issue meant an extra FireCannon call could succeed during our 1.2 second death window from the previous issue. So the simple fix here is to stay consistent and make sure AI are using the FireCannon script as well, which means it gets cleaned up when a unit dies and cancels the running scripts. Another angle to tackle this from is performing a simple IsAlive() check in the cannon firing function.

Well, normally that's exactly what would happen. Except my ships have another glaring issue. They never fired their death scripts at all. They fired a death event and triggered the death virtual function but never the death script. At the moment the death flow is split between a virtual function on the actor and a bespoke UAtmaScript_Death, and I find that confusing. I remember initially setting this up and not being able to decide on how I wanted it to behave long term. Well, we are finally at the point where that split is costing us. So death in general needs to be reviewed and hardened.

Going Forward

It's likely that all of these bugs would have been caught in one way or another eventually, but I smiled because they were caught by my new analytics. Going forward it's pretty clear that analytics has the potential to be a great bug catching tool. A player logs out with 50 extra wood and didn't pick anything up or harvest anything? Could be something to look into. Someone killed a tier 8 battleship with their tier 4 battleship? Maybe an exploit, maybe a bug, maybe the tier 8 simply didn't have any ammo and just sat there for 45 minutes. Did someone delete a character when they weren't online? These are the types of questions that can be really difficult to encounter during normal playtesting but trivially caught with proper analytics in place as Atma scales up.

The hardest part now is figuring out what questions to ask.

Yesterday I had a playtest in Atma with a good friend Luke Mason. Luke has playtested before so he was not diving in with fresh eyes. The playtest did send him down a mostly unfamiliar route though which helped get some early insights on our recent weeks of progress.

The Playtest Goal

This playtest focused on an early tutorial system I've been working on, a first look at ship combat, and general intro pacing to the game. The tutorial system includes basic building controls, creating your first ship, gearing it up, and fighting your first pirate ships. This system had a very early playtest a few weeks ago where two of my friends went through the building section of the tutorial and gave some early feedback. That mostly developed into UX (user experience) improvements and a noticeable need for some help learning ship combat. Going into this playtest, one of my largest concerns was the new tutorial taking too long for the average player to get into their first ship combat. I have ideas on how to address it, but decided to wait until after the playtest before executing on them.

My Thoughts on Tutorials

On the topic of tutorials, I don't really like them. I prefer when games teach themselves through a player's own curiosity and exploration. Unfortunately it feels a bit naive to think Atma could get to that point in a reasonable amount of time with the minimal artistic experience that I have. So the goal for now is to introduce a traditional tutorial. I'm trying to keep it short, sweet, and to the point. As the UI and UX of the game improves I'll slowly start stripping away pieces of it until it becomes more of a generic hint system or maybe dissolves completely. Until then, the tutorial exists and needs to be playtested.

The playtest structure

I started yesterday's playtest asking Luke to record the experience. His instructions were to simply make a character on the correct realm and work his way through the first two tutorials the best he could. I informed him I would interject at one point when I needed him to make a specific decision (which was admittedly unnecessary information to give him) and that I would only jump in with hints when I felt like his experience was being tampered by a bug, significant UX issue, or he was going down a distracting path. The goal was to let him explore as much as he could on his own, but there are certain areas of the game where the existence of a distraction was a valuable enough insight and we didn't need to spend the time exploring it. For example, at one point he started fighting chickens which was noted, but land combat had minimal value to this playtest. He was also able to ask questions if he felt stuck and no longer had an idea what to explore. Again, simply knowing he was at a dead end was enough for me to move forward. Struggling for one minute compared to five minutes on how to cut a tree would not be a valuable use of time.

Other than that, the playtest was as hands off as I could make it.

Servers for the playtest were hosted in us-west-1 on Amazon EC2 instances. I used a c7g.medium (1 vCPU, 2GB ram) instance using a linux arm64 build in Test configuration. The client was also built in test configuration for windows and distributed through steam.

The Biases

To frame this playtest in a more accurate light, let's review some of the biases going into this playtest.

• Luke has played Atma before. His previous playtest was "build a house". He has experienced the building system and general controls, but has not experienced these specific tutorials or ship related content.
• Luke is invested in my project as a friend. We went to college together and kept in close touch ever since. We've always jumped on calls for big career updates or just to see how each other is doing. Luke is invested in my project and wants it to succeed. He isn't going into this project as a player trying to get their time or money's worth. He's going into it as someone who wants to really dive into a friend's creation, look through every nook and cranny, and most likely wants this playtest to be smooth.
• Luke is a VFX artist with an interest in game design. He wants to pull out and comment on the little things that matter. He's been a part of playtests before and has even conducted them himself. He explores not just the world but every visual element he can find and often sees the world through a developer's lens. Without a doubt, there is more effort put into solving a problem in this playtest than someone who just found the game on steam might be inclined to put in.
• Luke knew he was signed up for a one hour playtest. This session simply cannot test a five, 10, or 30 minute retention.
• Luke is a builder. He likes games where he can be creative and artistic. He generally avoids heavy combat games or high risk games. The harvesting and crafting tutorial we are asking him to complete are right down his alley, but the ship tutorial is fairly averse to his normal player goals.

It's important to keep these things in mind when we create inferences from the playtest. We will need to acknowledge what questions this playtest cannot answer for us and find playtest coverage in the future that can help us address those. But this leaves a lot on the table for things we can learn today.

How Did it Go?

First, I think it's valuable to share my morning-after impressions from the playtest. With a night to let the experience settle in, there are a few things that stand out to me.

Overall, the playtest went really well. There were very few stuck moments, only a couple of significant bugs, and Luke was able to destroy some pirate ships by the end of it. My favorite moment of the playtest was watching him creep up to a pirate trade route, gauge his distance carefully, and then have a tier 5 merchant ship send him into a panic. The merchant ship was completely harmless (as long as he didn't attack it), but he hadn't learned that yet. It was great to see the presence of these ships actually have impact. He was able to acknowledge which ships were strong and which were weak, who he should pick on, and showed a sense of genuine tension as he picked his first targets. There was investment in his ship.

Initial Impressions

• Tutorialization - Promising. Needs a little bit of tuning. I'm confident we can move forward with the merchant and explorer tutorials next and polish up the battleship tutorial along the way.
• Ship combat - Promising. Definitely some things learned here, but overall this was a success for the current state of the game.
• Pacing - Unclear. On one hand, it felt like it took a long time for him to get onto the high seas. On the other hand, it seemed like he enjoyed his time getting there.
• Build Quality - Fine. The server crashed during the playtest, but I already had a fix ready locally. This was more of a process issue where I didn't upload the correct build. There were quite a number of UI and UX issues that definitely need attention before the game will start feeling more professional.

Playtest Notes

Below I'm going to share my exact playtest notes from yesterday. I haven't reviewed these at all up to this point. Below the notes I'm going to pull out a few of them that I felt are worth exploring in a bit more depth. These are raw, unedited, and literally sitting in a notepad file on my desktop.

luke playtest 8-14-2026
                    
                    hard to read create character text. light gray over lighter gray is bad
                    create character name popup takes up tons of space should be a bit smaller.
                    still no cursor present for hovered tiles - maybe not necessary?
                    panel icons are long overdue to be replaced - player wanted to check their inventory and it took some time
                    was about to complain that the controls disappeared when he started hovering his placements. but then he saw them in the side bar
                    R to rotate did not work.
                    Build a crafting table-> Build the crafting table
                    thinks construction gets faster as he levels up
                    equipped with a drag-drop instead of right-click equip
                    Build the warehouse -> Build A warehouse
                    
                    Build a warehouse highlights did not show. but he found his way through it anyway
                    Wants to be able to hold down to move his character instead of click tiles. Or at least he expected that to work - started spam clicking to get the behavior he wanted
                    wasn't sure what the 8 meant (it was an experience drop)
                    
                    Is a bit confused why his two wood isn't working at the warehouse. dropped it on the ground instead. The warehouse requires 2 planks
                    
                    Woods in the warehouse do not have "Wood" after their name
                    Steel Ore -> weird. 
                    
                    we should center the tutorial progress drots
                    
                    Battleship entry shouldn't hover at the "Use the dock to build a ship" stage. it should highlight the Build button for all 3. let the player choose
                    
                    He isn't seeing that he can craft multiple resources at once with a right click
                    
                    Ship type subtexts are AI written -> need to rewrite by hand
                    spent some time reading the ship types. acknowledged battleship is the middle of the pack but has the most canons. did notice the provisions thing - biased by previous conversation after last playtest tho
                    
                    wood repair kit -> remove (a pulse every 2s) text
                    provisions - bad description
                    we need to do a pass on all items
                    
                    warning texts are not red and not center justified
                    "all cannons draw from this shared cannon stack" - kindof unnecessary.
                    "They fire from any bearing around the ship" - also weird wording. not really necessary to explain that yet
                    
                    dropping repair kit into ship cargo isn't moving the whole stack. right click transfer does work
                    
                    tutorial title could also be centered
                    
                    anvil tutorial step had no highlights. but he was still able to find it
                    
                    
                    bug happened again after docking his ship. he can only click on Z = 0 and cannot walk here on things higher than that
                    
                    found the fishing spot. tried to fish. noticed the failure text saying he needed a rod. moved on with the tutorial.
                    
                    Is thinking he might be able to craft a stone pickaxe as an upgrade to his wooden pickaxe. not a bad idea! maybe make it level 5?
                    Found the tier drop down. changing it to tier 2 didn't show stone pickaxe so he left. but it also didn't show any tools. would be good to show the tier 2 tools there.
                    
                    
                    Not clear when crafted items go into the ship cargo instead of the inventory
                    
                    ship told him resources would be drawn from warehouse. but then he expected items to be drawn from warehouse for crafting as well. he figured it out. but it was a brief stumble
                    "craft 2 sets of cannonballs" - sets was a new word. he paid a bit of extra attention to that. didn't steer his decisions tho.
                    cannonballs are still really small. should make them 2x2
                    decided to make more cannonballs than it asked him too cause he had extra stone
                    
                    "Contracts build reputation with different factions" -> "Battleship contracts build reputation with the Fighter faction"
                    
                    
                    Found the manage ships panel while looking for the contracts section. made sense to him. its pretty ugly tho
                    
                    in the shop - items you can not afford should have red text on the coins. items you cannot buy at all should be grayed out (bad ship tier) with some description when you hover
                    Inconsistent naming between contracts - Combat as a type instead of Battleship or Fighter. lets name it for the faction - Fighter. and lets show some reputation and stuff like that.
                    15 ships! thats so many - first impression of the contract. and agreed. we are planning to go to 10
                    he's wondering if he gets the reward per ship or for doing the whole contract - interpreting it as a total value for now which is correct
                    
                    not super clear when you accept the contract
                    
                    Map not auto opening after reading a map. map should auto open after reading the item and the island icon should have animated
                    
                    read ship movement as grid based movement but liked the feel
                    
                    Immediately recognized a stronger merchant ship showing up. hovered it and saw it was tier 2 right away. also noticed some are battleships right away
                    is now looking for his pirate contract to figure out where to go
                    is trying to remember what his contract said and has no way to review it. didn't go for the tutorial - was more interested in his contract
                    is choosing to fight white sail ships instead of pirate ships - seems to have lost sight of the tutorial
                    beat the white battleship but survived with only 3 health. another battleship then came in and attacked him even tho he was out of combat - combat didn't seem to end when the first ship died?
                    repair at the dock is still a thing - but it was also kindof a good experience in this ship. intended to be removed but lets re-evaluate
                    
                    
                    is now realizing the white sail ships are not pirate ships
                    is now out exploring for pirate ships. but isn't using his map
                    tested collision against ships - didn't hurt each other - good
                    
                    
                    remembered the pirate island was west of his island (or just hasn't rotated camera and got lucky going left of screen) - lets follow up
                    remembered his map. moved over to the pirate island - is still seeing merchant ships. he found the black sailed ship and sees its a merchant. is trying to attack the level two merchant. attacked it a few times then realized it was a tier 2.
                    is now looking to repair. anchored. started using kits
                    is now using all of his repair kits at once. over-repaired. didn't get full value of his kits. definitely wasted some
                    
                    am going to direct him to heal himself with a cheat since he would have gotten to full health with those repair kits that were wasted
                    
                    he is now looking for a tier 1
                    
                    found another pirate. is recognizing they are high level.
                     is running away from them. but is now thinking they might not aggro so was going to go back and check. then hit terrain and got distracted by a tier 5 ship. got scared. couldn't figure out why he couldn't move
                    found a tier 1 ship was a bit confused why it was called "merchant ship" but recognized the black flag.
                    had to remember tank controls.
                    fought the tier 1 merchant. is now low on cannonballs. didn't seem to immediately recognized that.
                    did see he should anchor to loot
                    tier 1 merchant hardly hit him - intended
                    he thought he was just invulnerable till he took a small hit.
                    but he did remember he put on ship armor that made him tanky. is just thinking tier 1 ships hit very low damage.
                    sees he is out of cannonballs so is going home
                    seems to remember a teleport command
                    found another island on the way home
                    thought it was his - realized it isn't - wants to mark it on his map. couldn't figure out how so he sailed on. i stopped him and asked him to find the dock - but he just docked ont othe island to explore
                    charting is not obvious - but he also didn't do the charting tutorial. should still call more attention to uncharted islands
                    is remembering he saw the zoomed out version of the island (the standin) and doesn't remember seeing valuable resources so isn't expecting to find much. partially biased from a conversation from a few weeks ago where I mentioned that was a thing. great he remembered it tho
                    did find chickens.  asking him to act like the chickens do not exist since land combat is a distraction from this playtest and may have bugs that negatively impact the experience.
                    
                    coin indicator is not updating -  coins were in the ship storage. just not updating in the hud
                    
                    docking on the island had the same issue trying to walk on Z != 0
                    
                    realized he could have gotten some stone on the chicken island but needed his crafting bench anyway
                    
                    is preparing stone to go fight the 15 ships - but i'm directing him to do a bit less because we are going to wrap up playtest soon
                    
                    curios - rewrite description
                    
                    he is often checking both anvil and crafting bench quite a bit to see where to make things - i'm realizing we should experiment with changing the background color or texture. some visual change. to help associate what you created with what panel it was in. and create a subconcious connection between stations and the items they make
                    
                    didn't build any repair kits before leaving out the second time
                    
                    wants to sell the glass bead he found
                    opened up the shop. couldn't figure out how to sell things
                    pretty confusing that he has to open the ship menu manually to sell it. but he did eventually do so.
                    750 provisions sounds like enough hes sailing off without selling that curio. i'm letting him since most players wouldn't have found one
                    
                    
                    hes worried if he attacks the merchant ship it might agro the tier 3 merchant next to it. he isn't sure but hes worried.
                    seems to be sailing around quite a bit instead of hanging out at the trade route
                    
                    not getting the warning message when  of provisions
                    
                    saikling all the way back at low speed is a bad experience - could die or use the teleport but isn't seeing that
                    not getting the warning for being belo 40% health and therefore travelling slower
                    
                    
                    
                    Q n A
                    
                    -- asking him about any first impressions he has after completing things
                    
                    Boat section slowed down quite a bit compared to the quick successes of the land combat
                    15 felt high for amount of ships he could take down in a reasonable amount of time. at least for the first tier 1 contract
                    wanted some more surprises during that time or more beats
                    
                    did see a lot of goals being set
                    
                    -- asking about what goals he has set for his player type as Luke not just what I egged on. what things he finds interesting at this point and things he might go into next
                    Is saying the battleship wasn't super appealing but he was interested by the merchant idea. brought up how he saw elder wood. he set that as a goal he wants to find the elder wood and saffron in the game. 
                    
                    wants to capitalize on his own wits and is interested in merchant
                    
                    from previous playtests knows building is a big part and wants to continue doing that
                    is assuming other players are focused on combat so he wants to go find rare islands and stuff
                    did see some promises of the stuff he is interested in so that was cool. made a lot of notes in his head of things to check out later
                    
                    -- what is your player fantasy for merchant in terms of how you perceive atma so far
                    wants to have lots of ships
                    some sort of established trade routes within his guild
                    bringing value to other players who he is working with, who are in turn focusing on things he is less interested in like fighting bosses and bringing back loot he can use to build up the base
                    wants to be able to find his role. do the things hes interested in and benefit the people doing things he is not interested in
                    
                    -- any areas you felt lost, confused, or frustrated? anything still resonating with you when you look back?
                    remembers when he was initially confused by having to do things to his ship and he kept looking at ship view which was very new - a bit overwhelming - a bit confused what the tutorial wanted from him. he did open this view before the tutorial anticipated
                    maybe we can consider locking the menus until they get to that stage in the tutorial
                    definitely confused about how slow he got after provisions. would be frustrated if we didn't end there

A lot of these notes are small bug fixes or quick tweaks to wording that don't really need much explanation. Some of them might not make much sense to people less familiar with Atma. I'm going to pull out the points that read loudest to me and give some initial impressions and insights. I'm reviewing this as I'm re-reading it so these thoughts are fresh initial impressions, and my actual interpretation or plan of action might change as I let them marinate.

29 notes

panel icons are long overdue to be replaced - player wanted to check their inventory and it took some time

Yep. These are pretty misleading and need a more intentional design.

equipped with a drag-drop instead of right-click equip

A sign that the player wasn't naturally exploring right-click menus. This costs time and can add friction and makes the game feel less polished.

Wants to be able to hold down to move his character instead of click tiles. Or at least he expected that to work - started spam clicking to get the behavior he wanted

I've thought about this as well and heard it from other playtests. I did try a quick implementation of it and it felt a bit odd, but it could be worth giving it another shot. Also worth acknowledging the feature might not be my preference but if players want it, it could be worth adding as an option.

wasn't sure what the 8 meant (it was an experience drop)

Experience drops like this are pretty typical in games that I play, but I have to remember that many players might not be accustomed to them. It could be worth finding a way to make this more clear but for now I'm just going to keep an eye on it.

Is a bit confused why his two wood isn't working at the warehouse. dropped it on the ground instead. The warehouse requires 2 planks

The player hasn't learned to check the chat box for failure messages yet, and the plank icon might be too small making it not read quickly as a different item than the one he's used already. For now I think the gentle nudge is to increase icon size and see how that goes.

He isn't seeing that he can craft multiple resources at once with a right click

This one stands out because right-click needs to be a clear tool for players to use. We want people to right-click everything that has additional actions to see what they are. The tutorial has a subtle mention of this but it's one of the first things the player sees, and isn't reinforced after that initial step.

Ship type subtexts are AI written -> need to rewrite by handwood repair kit -> remove (a pulse every 2s) textwe need to do a pass on all items

This one I'm a bit ashamed of. I use Claude to do a lot of my coding, which isn't my issue, but I really want everything in Atma to be hand written. It's part of my connection with the game. Unfortunately sometimes Claude puts in temporary descriptions for items and I don't notice it. I'll need to do a full review of the texts in the game and rewrite anything that I didn't write myself before the next playtest.

dropping repair kit into ship cargo isn't moving the whole stack. right click transfer does work

Inventory UX has been an issue popping up over multiple playtests. The intended design isn't unique or complicated in any way, so this is a sign that the underlying system and tests need a review. I can't keep spending time playing whack-a-mole with the inventory UI.

bug happened again after docking his ship. he can only click on Z = 0 and cannot walk here on things higher than that

Now this one is a bug that has been haunting us for a while now. The issue only happens after the player leaves their island and comes back to it. They can click to walk to any Z = 0 tile but anything greater than that seems to fail. Performing actions that requires pathing works great. So there seems to be some issue with the coordinates the client is calculating for a tile or how the server is handling terrain MoveTo queries, and the issue is somehow related to travelling between spaces.

Is thinking he might be able to craft a stone pickaxe as an upgrade to his wooden pickaxe. not a bad idea! maybe make it level 5?

A stone pickaxe makes a lot of sense. Slotting it in at level 5 could be a nice progression beat where players can chase a very early self-driven upgrade. However, the game is largely built around the tier system right now and, as often as possible, wants level requirements between tiers to stay the same. A stone pickaxe would either be tier 1.5 or take the place of tier two iron at level 10. Could it just be a stronger tier one tool? It breaks the conventions of the game, which may feel sloppier than it's worth. For now, it's tabled.

Found the tier drop down. changing it to tier 2 didn't show stone pickaxe so he left. but it also didn't show any tools. would be good to show the tier 2 tools there.

Just a nice piece of validation that a recent UX experiment is going well. Previously, recipes for all tiers were shown in the list creating quite a bit of clutter.

Not clear when crafted items go into the ship cargo instead of the inventory

More of a personal note than anything, but this caught my eye as something that will most likely confuse some players. It didn't have a negative impact on this playtest, but I'm wondering if a short animation of item icons going into their respective panel icon could help alleviate potential pains. We do have a slightly unique experience with two inventory systems existing instead of one and that's something we have to get players used to.

ship told him resources would be drawn from warehouse. but then he expected items to be drawn from warehouse for crafting as well. he figured it out. but it was a brief stumble

We have a note on the ship building panel that informs players that resources can be drawn from the warehouse. This originally served to solve a problem where ships needed more resources than you could carry at once. And I still want to preserve the ability to have a ship upgrade cost more than 10 of each resource, but in today's playtest it did cause some confusion. When crafting at the crafting bench and anvil he also assumed his resources would be drawn from the warehouse. He was able to discover the real behavior in a short amount of time but this is something we should keep an eye on. It could be worth removing that text until it is actually needed.

in the shop - items you can not afford should have red text on the coins. items you cannot buy at all should be grayed out (bad ship tier) with some description when you hover

There's no two ways about it, the shop UX is awful. The icons are all temporary and the entries don't indicate what you can and can't purchase. This needs a full pass now that the shop is involved in the core gameplay path.

15 ships! thats so many - first impression of the contract. and agreed. we are planning to go to 10

Yep. I saw this one coming. 15 is too many. I was debating changing this before the playtest and am now even more validated to do so. I think 10 might be the sweet spot, but am also considering going down to five for the first contract and moving up to 10 for higher level contracts. I want you to feel that reward of completing something early on, and I have little concerns around economic balance here since tier 1 rewards will pale in comparison to higher tier rewards.

not super clear when you accept the contract

Like the shop, this panel needs a full make-over.

Map not auto opening after reading a map. map should auto open after reading the item and the island icon should have animated

This is a significant bug. My own testing recently found that using the map item lacked significant user feedback, so I added a mechanism that automatically opens your world map and animates in the newly revealed location when you use the item. But it clearly seems bugged and none of that happened. I interjected at this point and let him know what should have happened and had him manually open the map.

read ship movement as grid based movement but liked the feel

Just an interesting note! I wasn't sure if players would pick up on the grid based movement of ships. This might be his own biased knowledge of the game kicking in, but players that know the game is grid based are going to have an easier time controlling the ships than players who think it's truly continuous movement. They'll have a little better understanding when their ship takes a bit longer to do some turns than others. And knowing he enjoyed the general feel was great.

Immediately recognized a stronger merchant ship showing up. hovered it and saw it was tier 2 right away. also noticed some are battleships right away

One of my favorite moments of the playtest for sure. I remember fondly playing Voyage Century Online and seeing the high level ships sail past. When they are hostile you can really feel a sense of tension and when they are friendly you develop a player goal. "I want to have that ship someday." The fact that he could recognize the power difference in ships quickly through the ship models and UI tier badge was a great sign. I was quite surprised that he could quickly point out other battleships too. It's a possible sign that our silhouettes are stronger than I originally thought.

is trying to remember what his contract said and has no way to review it. didn't go for the tutorial - was more interested in his contract

Definitely need a way for him to view active contracts. I'm not entirely sure how this should surface, but it's significant.

is choosing to fight white sail ships instead of pirate ships - seems to have lost sight of the tutorial

Interesting moment for sure. I was hoping the white sail ships would read as friendly. But unfortunately they were the first thing he attacked, and he got roughed up pretty bad from it since it was a battleship and not a merchant. This might deserve immediate attention because a player whose not completely sold on the game yet might see this as their breaking point if they were to have lost that battle.

is now realizing the white sail ships are not pirate ships

We're happy to see he did make the connection though eventually.

repair at the dock is still a thing - but it was also kindof a good experience in this ship. intended to be removed but lets re-evaluate

This was a feature I was testing out and actually thought I removed. But it did fix a pretty gnarly gameplay experience. I am considering leaving this in, and maybe attaching a coin cost to it. Giving the player two ways to repair (repair kits and coins) might cater to different player types more. It also reduces how much harvesting people have to do if they really just want to be fighting.

is now looking to repair. anchored. started using kitsis now using all of his repair kits at once. over-repaired. didn't get full value of his kits. definitely wasted some

Repair kits shouldn't be overlappable. And they need a bit stronger feedback of when they are working and what they are doing.

is running away from them. but is now thinking they might not aggro so was going to go back and check. then hit terrain and got distracted by a tier 5 ship. got scared. couldn't figure out why he couldn't move

Two things to unpack here. I kindof liked that he was manually testing out aggro rules. That feels like an interesting moment of player experience. And he didn't feel like being attacked was so detrimental that he should completely avoid it. Seeing the tier five ship and getting scared was also really fun to watch. The power was definitely felt. Unfortunately, the reason he couldn't figure out why he couldn't move was because his ship anchored when he hit an island. The anchoring state just isn't clear right now and needs a UX pass.

but he did remember he put on ship armor that made him tanky. is just thinking tier 1 ships hit very low damage.

Really happy to see that ship armor is doing its job and that the player was able to attribute that to his advantage in combat. This was a core goal of the ship armor item.

thought it was his - realized it isn't - wants to mark it on his map. couldn't figure out how so he sailed on. i stopped him and asked him to find the dock - but he just docked onto the island to explorecharting is not obvious - but he also didn't do the charting tutorial. should still call more attention to uncharted islands

The explorer tutorial teaches about island charting, but it was really difficult to discover at this time. The idea of charting the island was interesting to see him come up with. It felt great to have a feature implemented that he wanted but just hadn't found yet. It does need to be easier to find. I'm thinking about doing a UX pass on island stand-ins to give some better information about them and make charting clearer. I don't know exactly what that looks like yet though.

he is often checking both anvil and crafting bench quite a bit to see where to make things - i'm realizing we should experiment with changing the background color or texture. some visual change. to help associate what you created with what panel it was in. and create a subconscious connection between stations and the items they make

Throughout the playtest he was bouncing back and forth between stations to figure out where to craft things he had already seen before. I think the primary reason for this is that the different stations have identical UIs. Some visual tweaks to create a stronger connection between what recipes you are viewing and what station you are at could go a long way here. I'm thinking about recoloring the anvil panel and changing the texture possibly.

saikling all the way back at low speed is a bad experience - could die or use the teleport but isn't seeing that

Sailing*. Like I said, this is unedited. This was significant though. He was moving REALLY slow when he was both out of provisions and low on health. He did attribute this to being out of provisions but overall the player needs more feedback about what is making them slow. We also probably need a stronger solution than simply "crawl your way back to town" if they are out of provisions and repair kits. Ideally, players develop stronger planning skills over time. But we do not want this initial experience to get hit with something so disruptive. For now, I'm thinking about starting the player with more provisions and reducing provision consumption. Basically, delay this issue until later into gameplay. I will also probably weaken the movement penalty for being low health.

The Follow Up Questions

I'm paraphrasing the exact question asked

What were your first impressions after completing the playtest?

The biggest takeaway here was that he mentioned the boat section slowed down quite a bit. The initial goal of killing 15 ships sounded daunting and when he actually experienced ship combat it was reaffirmed that this was going to take a while. There was a noticeable contrast in time between interesting discoveries and gameplay beats compared to the building tutorial. On a positive note, he mentioned that the tutorial put a lot of goals into the back of his mind for him to explore later.

What are some of the goals you've created for yourself? Try to separate what this playtest specifically asked of you and what you, as Luke, want to do in this world.

Knowing Luke's player type it was unsurprising that the battleship path itself wasn't very appealing. I was happy to hear that he was excited by the idea of finding elder wood (my tier 7 wood he briefly saw in the warehouse) and saffron (a tier 8 good visible in the shop). Of course, as a builder at heart, he was excited to find himself back into building as well. He mentioned finding himself into a position where he can harvest and build for people who want to go out and fight. They take care of some roles he's not interested in and he takes care of roles they are not interested in. This is absolutely a direction I want the game to go.

Were there any areas you felt lost, confused, or frustrated?

From memory there wasn't much he could point to, which was great to hear. He did mention being overwhelmed looking at some of the ship menus and in particular opening the ship cargo view (which he had discovered before the playtest anticipated). And of course, the slow down from running out of provisions and being low health was very jarring. Understandably, he said he would have been very frustrated if he had to sail all the way back at that speed. Overall, I think this was a success. I'm considering locking some of the menus until the tutorial presents them to you to avoid some of that confusion and reduce the control space for new players.

The Analytics

A couple weeks ago I added analytics to Atma. This was my first playtest with them enabled and I figured it was a good way to both test the system as well as take a look at the playtest from a more objective point of view. There are a ton of asterisks when looking at this data. But regardless, it's fun to look at and see if it does call attention to any interesting patterns. It's also a great way for us to test how we analyze a player's session when we aren't there to watch them. So before looking at this I'd ask a few questions:

• Are there any interesting patterns showing up already?
• Are there any questions we want to ask from future playtests that analytics could help with?
• Are any of these analytics clearly misleading?

Claude was used to generate this playtest report using my analytics data. The information should be accurate, but the text should be scrutinized. Any conclusions it draws are not necessarily true, but can be worth thinking about.

The Beats

The main things that catch my eye here are the first time they hit the high seas at 47:03. That's a significant amount of time before someone gets to play with a boat, which is one of the main things the game advertises. The first pirate was then sunk at 66:19. 20 minutes between hitting the high seas and sinking a ship. Yes, the playtest itself is a factor in slowing this down. When I play a fresh character I can sink a ship in 15 minutes. But I'm the developer! I'm not learning all of this as I go. This is definitely something I want to keep an eye on and look for a way to expedite.

Server Memory

This didn't seem relevant at first but actually was a bit concerning after looking into another odd behavior. I left the server running overnight and it eventually crashed. It turns out the current ship math can cause ships to, over time, spawn more frequently than they despawn. We had a runaway memory problem where eventually the server reached over 12,000 ships and crashed. This memory growth was an early indicator of that, but stayed close enough to reasonable memory usage that I didn't see it as a problem. We'll be keeping a closer eye on this in the future.

Crafted items

It's a bit misleading to see 195 crafted cannonballs. Analytics are currently counting total crafted outputs. This means one stack of cannonballs records as 15 cannonballs crafted. The amount of "recipes" crafted is a little more useful to the way my brain thinks about this stuff. Technically, we can calculate the total cannonball count from the amount of recipes crafted, or we can calculate the recipes crafted from the total cannonball count. Both work, but I think I'll be changing this analytic to track recipes crafted instead of total output count. This will also help clarify things if we ever add multiple recipes to produce the same output item in the future.

Events Ingested

Part of running analytics during playtests is to better understand how much analytics are going to be costing us once we scale up to a higher player count. 659 events over the course of a 83 minute playtest is extremely reasonable. With today's implementation we paid somewhere around $0.00005. This price is a bit misleading because we can pay a lot less when we batch more events together in a single call. Another player going through the same experience at the same time would have negligible increase in cost because the combined events would have all fit into the same batches.

The Server Crash

Some of you might have noticed a server crash mixed in there. It turns out I actually launched the wrong server build for this playtest. Thankfully it held up for all but one issue: a crash bug that happened when you tried firing a cannonball after being at sea for a while. Thankfully I already had the fix implemented and just needed to rebuild, reupload, and relaunch the server.

Impressions after reviewing

Honestly, reviewing this was a little exhausting. Part of me wants to take a break but part of me finds this to be a valuable part of playtesting to comment on. There was a TON of information here. From it, a ton of new tasks that I have to somehow organize into actionable plans. Overall I think the playtest went well. I was happy to see a lot of previous frictions were mitigated, new features working as intended, and combat in a workable place. We discovered some new areas that need to be smoothed out and plenty of UX issues that could simplify onboarding for future players. The tutorial and combat systems themselves seem to be making good progress and landed in a spot that I think lets me move onto the next area I want to playtest.

What's next?

The next playtest is going to be a group playtest. I can't keep doing solo playtests and maintain any confidence that the team experience is holding up. The game is meant to be a social game so we need to get back into group playtesting as soon as we can. We'll continue to balance it out with some focused individual playtests but neither should dominate the other at this stage. My hope is to have the next playtest as early as this upcoming Friday but a more realistic goal would be the following week. I want to clean up the main issues from this playtest and refine the merchant and explorer tutorials so I don't need to force everyone into the combat path. The plan right now is to take Monday to tackle a lot of the quick fixes. Regardless of priority, things like small text changes, UI tweaks, highlight adjustments, and simple bug fixes deserve a quick pass. When those are done we'll move onto some of the major fixes that might require redesigns or refactors.

Improving Future Playtests

I think it's important to reflect on how we conduct playtests. One thing that stood out to me as an area I can improve is how I presented the playtest to Luke. I gave him a little more information than I needed to. While there were some known issues he was going to run into, giving him the heads up that I was going to force him into the battleship didn't provide anything useful and potentially just polluted his initial impressions going into the playtest. He was already given a goal without the playtest driving him there. In the future I'm going to spend a little more time refining what information I give ahead of time and trust that course corrections mid-playtest are a better angle than trying to prepare the player for hiccups.

Another thing I should have done was prepare my follow up questions ahead of time. I've done this in the past and it works great. After this playtest I realized I had forgotten to do just that, and it caused me to stumble a bit looking for the right things to ask. This both comes off as a little unprofessional but also meant I may have missed an opportunity to structure my questions so they provide the most value to the playtest's goals.

This post was both my way of reviewing the playtest and my way of trying to demonstrate how I work through feedback. I can't say I'll be going this in depth for every play test but hopefully this shows where we are at in the process and a bit of how my brain works as I iterate through Atma.

I don't really want to start writing blogs if I can't be vulnerable. Art is the biggest insecurity I have about the project right now, so let's rip that band-aid off early.

Struggling with Art

I have confidence in my abilities to work through the technical problems in my project. Design is an area I certainly haven't vetted myself outside of a few game jams, but I do have confidence in my vision and that the building blocks that compose it will strengthen over time through playtests and iterations. I find myself setting up infrastructure, optimizations, test flows, and robust systems probably more than I should at this stage of the project. Well, certainly more than I should. These are the things I absolutely love to do. My brain gravitates toward these types of problems and accomplishing each one has a tangible impact on the project.

Art has never felt the same to me. I believe it's because the art of a project can't be carried by a small set of well made assets. Art needs consistency and quantity. I've spent time learning character animations, VFX, hard surface modelling, rigging, skinning, and a good chunk of time researching color theory and materials. After each of these stints I walk away with some valued skill development but the impact on the project has always felt minimal (except for color theory, that was surprisingly impactful for a surprisingly little amount of research). Of course, the learning phases of all of these are expected to take a while. No artist is going to say their craft should be learnable in a week. And once you learn it and develop familiarity with it you get faster, better, and more creative. But while I love learning these things, the cost has been a little too great for too little reward. Atma has an insane technical scope and it needs all the attention it can get.

So while early on in the project I had a goal of learning everything and doing everything myself, that goal has slowly transformed into a reality where Atma becomes a team project. I want to hire artists. I miss working with artists. I miss working on teams in general. One of the hardest parts about solo development is not being able to share the small wins with anyone. And I somewhat selfishly love helping artists with their workflows. I love bringing them performance reports, adding new tools, or hooking their new assets up and sending them gifs of their creation coming to life. When I was in college I would break out Unreal's sequencer and take cinematic shots of the assets my artists would create. There's something extremely fulfilling about that moment when engineering talent and artistic talent complete each other.

When I first started acknowledging the art struggles I recruited my friend John Khaw (check out his ArtStation here) to do some hard surface modelling for me. I loved these days on the project. John always produced incredible work and would get fascinated by underexplored (by us) technologies like tessellation and triplanar materials. A style was developing for Atma and it was one I was very excited by. But the technical and design side of the project couldn't keep up with how fast John worked. I simply didn't have answers for what assets we needed next. John's involvement in the project ebbed and flowed. It felt bad asking him to make things that I wasn't sure were going to stay around and it felt bad giving him only one task for the week.

I started looking for other solutions to get me through development. It was also important to recognize that there were a number of neglected art disciplines on the project that still needed attention. Animation, VFX, character modelling, UI, lighting, and sound were all things I knew the project needed but simply didn't have an answer for yet. I started trying to purchase some asset packs online to help out but try as I may, they always created noticeably disjoint art styles that I felt didn't really improve the project. They certainly didn't hold up over time when I needed a new element the packs didn't include. So after a few underwhelming purchases I got back to the drawing board.

Animation

Animation was probably the biggest windfall of the project so far. Character animation can be incredibly tricky. I spent a few days working with Unreal Engine 5's Control Rig and actually made a few animations I was pretty happy with. They weren't perfect, but for a learner they showed promise. They were polishable. However, they took a long time and the more time I spent tweaking keyframes and solving rotation issues, the more tired I grew of it. It's a skill I've visited a number of times in my career and have simply never been able to stick with. But a happy accident of the new direction of the game meant it didn't really require as much attention on characters. Ships have much more rigid and simple animations. A lean into a turn, a quick slingshot of a cannon firing, and the rising and falling of sails might be all the ships ever need. Of course we'll still have to figure things out for sea creatures and land animations, but a large class of high visibility animations was somewhat removed.

Then Unreal 5.8 came out. Unreal 5.8 introduced its new markerless mocap (motion capture) system. If you've ever seen people wearing the dark body suits with white balls on them to record game or movie animations, that's what mocap is. The white balls are the "markers" and serve as high contrast points for software to track motion between frames. Each frame the software compares the location of the white ball with the corresponding white ball in the previous frame and uses this to calculate animation data. It usually requires a decent amount of cleanup after the fact to correct issues and make it game ready, but it's been a popular industry tool for a long time now. It's also usually very expensive limiting its access to indie developers like myself. Unreal's markerless mocap gets rid of the need for fancy equipment and dressing up in ping pong balls. It leverages machine learning to produce animation data from a simple recorded video. Of course, when machine learning (AI) enters the conversation around games it should stir up some controversy and it did. This made me a bit hesitant to use it at first so I did some research. The general consensus online seems to be that this could have easily just been trained on videos of human motion more than hand crafted animations and thus didn't strike the same chord as things like generative 3D models or sprites. Do we really know though? It's hard to say. And there are still ethical and artistic concerns around replacing a trained animator's touch. I want to write a whole post about my opinions on AI and where I believe it belongs (and mostly doesn't belong) in games soon. So I'll save the tangent I'm heading down for when that time comes. For now, it's a fun tool to explore and it definitely solves the humanoid animation problem. I've tested it out and gotten some pretty great results. I haven't yet attached it to any gameplay logic though.

User Interface

User interface was one of the areas I tried purchasing packs online for. Unfortunately, I couldn't get something I enjoyed looking at for more than a week. There was also a glaring issue which is that no pack really had everything I needed. One pack might have my UI toggles and buttons and the other one might have the right button styles or progress bars. "Why not pick both?" was shut down by style concerns. It was extremely difficult to find multiple UI packs that matched in style outside of pixel art.

So I started looking at procedural UI. A while back I was inspired by Unreal's video on the UI Material Lab. This is a set of assets that uses math to create user interface materials. You can create rectangles with rounded borders, soft gradients, animated spinners, sheens, and a ton more with just math. The math isn't really simple, but I've always found math fascinating. The first time I tried to use it I found it quite confusing. And honestly, I still do. I often times know generally what I want but the math to get it done is quite complicated. Thankfully, Claude is really good at math. So this is an area where AI has touched art indirectly. I had Claude write my own set of material-lab-style functions to render my UI with rounded borders, dirt, wood grain texture, and simple animations. It exposes a set of parameters for me to tweak and find my style and the output isn't half bad. It's not generating the textures or assets being used, but it is writing the shader code that renders it all. It lacks embellishments and that hand-crafted feeling that we see in most user interfaces which makes it considerably less appealing.

Do I love it? Nope. But it's consistent and fast to iterate on. I've accepted that this is a great way for me to work through prototype UI. The dream is still to hire a UI artist. I've actually started looking around already but, like with most art, the project is still shifting too much to really leverage someone dedicated to UI art.

As a quick aside, I should mention item icons. Games like this have tons of items and each one needs its own icon. My temporary prototype solution has been to simply render the 3D models and use that as an icon. This has some challenges. The first is that it usually looks bad. Realistic lighting on models rendered on top of the simplistic UI panels I've created is a definite style clash. I alleviated this a little bit by applying a shader to the rendered output to tweak colors, flatten details, and add a gentle outline. This helped and for now works as my prototype workflow but it's not ideal long term. The second is that it only works if I have an actual model for the asset. With the ForgeScript tool I mention later on, this problem is mitigated slightly but in all honesty a lot of my UI icons are placeholder art at this stage.

VFX

Gotta be honest, I've hardly touched this. I did spend a day or two working through Niagara fundamentals and quite a bit of time discussing VFX with a good friend of mine Luke Mason (Senior VFX artist at Blizzard, check out his ArtStation here), but I've mostly set it aside for now. While I actually really enjoy VFX, it's another area where the time invested isn't paying off quite yet. In the meantime, check out this RuneScape inspired fireball thing I made:

Modelling

Modelling is a major area I'm still very shaky on. This is probably where I toed the line the closest to AI art on the project. Before the pitchforks come out though I just want to be very clear about my intentions. Not a single model or texture on Atma is generated by AI. A good chunk of them were hand modelled by John Khaw, but to expedite my prototyping phase I started experimenting with something I call ForgeScript. ForgeScript is a small Unreal module sitting on top of their mesh authoring tools. It leverages some existing tools and adds some of its own to push a concept of "art as code". The idea was that I could quickly have Claude write code scripts that deterministically create models with tweakable parameters that can be shared between assets to maintain consistency. Imagine creating a sword with something like this:

sword_blade = new cube()
                    sword_blade.set_scale(20, 5, 80)
                    sword_blade.pinch(0, 0, 80, 5)
                    sword_blade.attachment = new attachment("BladeBase", 0, 0, 0)
                    
                    sword_handle = new cylinder()
                    sword_handle.set_scale(15, 8, 20)
                    sword_handle.attachment = new attachment("HandleTop", 0, 0 0)
                    
                    attach(sword_blade, "BladeBase", sword_handle, "HandleTop")

This is super rough, but hopefully it illustrates the vision. Now, ForgeScript didn't come out quite like that. Here's an actual ForgeScript file in full for the arming sword.

"""A simple one-handed arming sword: straight double-edged blade with a central
                    fuller, plain bar crossguard, oval leather grip, crescent "cocked hat" pommel.
                    
                    Layout: +Z from pommel to tip, origin at the blade/guard junction.
                    Blade width runs along Y, thickness along X.
                    """
                    
                    import forge as f
                    
                    ASSET_NAME = "SM_Forge_ArmingSword"
                    ASSET_FOLDER = "Weapons"
                    MAX_TRIANGLES = 4000
                    
                    # Zoomed preview of the hilt (guard/grip/pommel) — whole-sword framing makes
                    # this region too small to review. center is normalized within the mesh bounds.
                    PREVIEW_CLOSEUPS = [
                        {"name": "hilt_closeup", "center": (0.5, 0.5, 0.09), "radius": 0.24},
                    ]
                    
                    BLADE_LENGTH = 78 * f.cm
                    BLADE_WIDTH = 5.4 * f.cm
                    BLADE_THICKNESS = 0.85 * f.cm
                    FULLER_DEPTH = 0.16 * f.cm
                    
                    GUARD_SPAN = 19 * f.cm
                    GRIP_LENGTH = 11 * f.cm
                    
                    
                    def blade_profile():
                        """Double-edged lens cross-section with a fuller groove on both faces.
                        Profile X = width, profile Y = thickness."""
                        w = BLADE_WIDTH * 0.5
                        t = BLADE_THICKNESS * 0.5
                        floor = t - FULLER_DEPTH
                        return [
                            (-w, 0.0),
                            (-0.42 * w, t), (-0.16 * w, t),
                            (-0.10 * w, floor), (0.10 * w, floor),
                            (0.16 * w, t), (0.42 * w, t),
                            (w, 0.0),
                            (0.42 * w, -t), (0.16 * w, -t),
                            (0.10 * w, -floor), (-0.10 * w, -floor),
                            (-0.16 * w, -t), (-0.42 * w, -t),
                        ]
                    
                    
                    def build() -> f.Part:
                        # Blade root starts just inside the guard (guard spans z -0.55..1.35);
                        # a deeper root pokes out visibly below the guard bar.
                        blade = f.sweep_profile(
                            profile=blade_profile(),
                            frames=f.linear_frames(
                                start=(0, 0, -0.4), end=(0, 0, BLADE_LENGTH),
                                scales=[
                                    (0.00, 1.00, 1.00),
                                    (0.15, 0.97, 1.00),
                                    (0.30, 0.93, 0.97),
                                    (0.45, 0.88, 0.93),
                                    (0.60, 0.84, 0.88),
                                    (0.72, 0.79, 0.82),
                                    (0.84, 0.70, 0.72),
                                    (0.93, 0.50, 0.55),
                                    (1.00, 0.06, 0.10),
                                ],
                            ),
                            material="Iron",
                        )
                    
                        guard = f.box(size=(1.5, GUARD_SPAN, 1.9), material="Iron", at=(0, 0, 0.4))
                        guard = f.bevel_all_edges(guard, distance=0.3)
                        # Quillons sweep gently toward the blade, like the reference.
                        guard = f.bend(guard, along="y", toward="+z", angle_deg=14)
                    
                        grip = f.cone(
                            base_radius=1.5, top_radius=1.75, height=GRIP_LENGTH,
                            material="Leather", radial_steps=12, at=(0, 0, -GRIP_LENGTH),
                        )
                        grip = f.scale(grip, (0.8, 1.0, 1.0))
                    
                        # "Cocked hat" pommel: a flattened mass bent into a clear crescent whose
                        # tips curl up toward the grip.
                        pommel = f.rounded_mass(half_extents=(0.95, 3.2, 1.7), material="Iron")
                        pommel = f.bend(pommel, along="y", toward="+z", angle_deg=85)
                        pommel = f.translate(pommel, (0, 0, -12.2))
                    
                        sword = f.combine([blade, guard, grip, pommel])
                        f.set_anchor(sword, "hand_grip", position=(0, 0, -5.5), forward=(0, 0, 1))
                        return sword

So you can see some of the spirit is there. It definitely needs a bit more work. But it actually worked as a proof of concept. You might also notice that it uses some helper functions to carry quite a bit of weight. By design, this allows other swords to reuse the same exact workflow when creating similar parts to help maintain style and reduce script complexity. Below is the output of that script.

Sound

Sound hasn't been touched yet in Atma. I did a bit of sound work on another project recently and quite enjoyed it. At the moment my plan is to use Soundly and Unreal's MetaSounds for the entire soundscape of Atma, but I'm not entirely confident that is going to hold up long term. We'll cross that bridge when we get there. But Soundly is an incredible program for anyone looking for high quality source sounds for a project. It can sometimes be tricky to get the exact sound you want but I'm not sure any source exists that doesn't have that problem. I'm planning on getting an initial sound pass done for the project within the next month or so. At this point the game is feeling a little dry from the lack of it.

Lighting

Lighting is another underexplored area of Atma. I'm currently using Lumen to light the scene which has been working pretty well so far. There are some artifacts but they are mostly noticeable around certain terrain textures which I've been phasing out. A bit of ghosting exists when characters move at low framerates too which does have me fairly concerned. Performance-wise things seem fine but my 3070 isn't exactly the min-spec video card. Thankfully no performance issues have really shown up in playtests.

In terms of style I've struggled quite a bit to get a lighting style that I really like. I added the Ultra Dynamic Sky plugin because I find its default lighting settings to be pretty appealing. The idea of adding weather to the game at some point is also interesting but it's not really a critical path at the moment and raises some design questions around syncing weather between islands and their seas. Simply adding Ultra Dynamic Sky didn't really get us somewhere I was happy with. Lately I've started researching color theory and how lighting can affect your color composition. Tweaks in material colors around the world have helped a lot but we still aren't where we would like to be. Many shadows are too dark and certain areas of the game still feel washed out, but I'm not entirely convinced it isn't a material or mesh problem yet. Overall we have a lot of work to do on lighting to get Atma looking nice and eye catching.

Looking forward

So right now a lot of Atma's art is in a prototype proof of concept phase. My dream is to be able to hire some artists to replace my temporary work and fill this world with something really beautiful. In the meantime, my goal is to make things functional and look decent enough to not detract from the experience. I've set aside a little money for when the time comes that I can provide artists with a real asset list, but I'm trying to be conscious about the current content and design churn and not commit to anything until things are in a stronger position. I have no intentions of ever using AI to generate art assets, but will definitely be leveraging it to create systems that support art. I like working with people too much. I want to be back on a team. I'm excited to someday compose that team of artists that can really bring life to Atma.

Atma has been in production for a little over two years. No, that's not going to be the official shipping title. I have a tendency of naming my personal projects after Diablo 2 characters. RIP to projects Flavie, Alkor, Anya, Fara, and Charsi. There is a lot here and I'll be following up on these different aspects of the game in the near future to give you some more in depth insight into where my head is at, where I want to take these systems, what playtests have shown me about them, and the technical details behind them as soon as I can. But here's a quick overview of where we are at today. For those who like labels, I consider this Early Alpha.

All art you see here is simply proof of concept and is almost certainly going to change before any public release.

The Vision

Atma has wanted to be a town builder from day one. I love games where I can build a house and even more so when I have a group of friends putting together a village around me. Inevitably, though, people start dropping off as they lose interest in whatever game it is. I'm sure many of us have had that experience of spending a week on a huge project only to be the last one active on the server. No one is there to appreciate it anymore.

My proposal: a living world that pulls active players and their creations toward the center while pushing inactive players toward the edge.

In its simplest form, we let players build their own creations in either an independent or a shared town. Every so often, we trigger the Shuffle which moves everyone's towns around. Your neighbor last week isn't your neighbor this week. Maybe we placed you next to your closest ally. Maybe I placed you next to your current rival. Maybe you won the weekly Guild Versus Guild battle so I rewarded you by placing you next to a high level raid, or maybe your guild had the most fishing experience this week so I placed you next to high level fishing spots. There's a ton of directions to explore here and this concept is the foundation of what is pushing Atma forward.

Gameplay Today

Today when you start Atma you'll find yourself placed on your own personal island.

Your personal island is where you can start learning the game and is the one place you will always have available to you. I want to drive social experiences as much as possible so I have a lot of interest in pushing guild islands heavily on players. But people leave guilds. So the personal island is somewhere you have that is always yours and no one can take that from you. It's small enough to be easy to explore while also encouraging you to get on the high seas to find more content.

Building

Atma has a simple building system implemented. The system focused on reducing the friction of lining things up perfectly while trying to provide a slight retro feel to the world. It works by being mostly tile-based. Most of the things you build cannot share the same tile, with some exceptions to allow for things like tables to stand on top of floors or for walls to exist between two tiles instead of occupying them. Right now players can build with simple wooden structures and some stone structures.

Everything you can place in the world is considered a Placement. Most placements are created through Blueprints which are simply construction recipes. But you can also place certain items like wall torches from your inventory. Some placements are considered "attachments" that need to be placed on the proper slot for that item type.

The High Seas

Today Atma is composed of a set of seas that meet each other at their edges. You can travel to the high seas once you have your first boat and sail around to the other islands. Player islands are connected by trade routes of attackable ships. Pirate islands exist and have trade routes as well, but no meaningful content on them yet. Defeating a ship drops loot which is usually some simple resources and rarely a valuable trinket that sells for a fair amount of coins. Sailing around the high seas you may find a message in a bottle, drifters, and wreckages for some quick loot and coins. You can also chart islands which adds them to your map.

Combat

A land combat system exists today. However, it simply wasn't providing much meaningful gameplay during playtests. My focus has entirely shifted toward naval combat for the time being which I think is a much stronger hook for the game. We are still in the early stages of balancing but ships fight back and chase you down. You need to craft canons and canonballs to be able to fire at ships, and can optionally craft hull armor to provide you some additional defenses. Combat is a major focus of development right now with its first playtest coming up this Friday. I'll definitely be doing a follow up to do a deeper dive into what challenges I'm currently facing with combat and what the playtest has taught me about its current state when we get there.

Other systems

A few other systems exist in Atma.

• A guild system allows you to group with your friends and you can teleport to the guild island to build together.
• A bug reporter system helps playtesters report issues quickly and includes diagnostics.
• Crafting is recipe based and works through a few stations like the crafting table, anvil, and smelter.
• Battleships, merchant ships, and explorer ships all exist as different types the player can choose to build.
• A trade good system allows you to purchase an item for cheap at one island and sell it for profit based on your travel distance.
• A contract system lets you accept mini-quests with coin rewards for defeating enough enemy ships, selling trade goods, or charting islands.
• Players have skill levels that gain experience as they perform actions and certain recipes are locked behind level requirements.

All of these things are in their early stages. They work, but they haven't been folded into meaningful gameplay yet.

Art

Most of the art you see in the screenshots on this post is a rough proof of concept. I've been trying a few different methods. I'm not an artist myself by any means. While I like to dip my feet into 3D modeling, texturing, animation, and VFX, it simply has taken too much time away from the game. So I've experimented and largely resorted to other methods. The main method has been recruiting the help of a close friend John Khaw (check out his ArtStation here). John is an incredible hard surface modeler whom I've worked with on a number of previous game jams and college projects. Unfortunately the technical and design parts of the project have not been able to keep up with how fast John can finish art tasks, so we haven't been able to keep John on the project full time.

To reduce art scope, I've wound up leaning heavily on procedural art methods.

Almost all of the UI in Atma is currently done with material math (based on ideas demonstrated by the Unreal Material Lab) for performance and simplicity reasons. I tried purchasing some packs on the fab marketplace but it became considerably limiting when I needed an element those packs didn't contain. I don't have the skillset to create new assets in their style. I feel the procedural UI looks a little bit flat but it did come out better than I originally expected. It's still on the chopping block with plans to replace it by bespoke art when I can.

Terrain is also being done procedurally. The materials were created in substance painter but the terrain itself is a dynamic mesh created based on my tile data. Originally I tried a method where I hand modeled each different corner shape and ledge but this proved extremely challenging to both look good and avoid holes where tiles meet. It turns out there are something like 680 or so tile shapes I would have needed to author to handle this naively (I didn't realize that at the time). So now it's generated at runtime as a procedural mesh, divided up into sections to allow for streaming.

I also tried some procedural methods for creating ships. I created a small system on top of Unreal's mesh scripting to help me keep style consistent and explored the idea of "art as code". Ships and a number of other structures exist as a script that says what shape to place where, how to cut holes, where to attach pieces, what material things are, how to bevel, and a number of other modeling operations. Honestly though, I strongly prefer the hand modeled stuff. So the plan right now is to continue using this method, which I call ForgeScript, for proof of concept assets but have them all recreated by artists when the asset list has settled a bit more.

AI and Art

A big topic these days is AI and it's definitely a delicate subject to cover. I believe in being fully transparent about how I use AI and my plans for it going forward.

In the early days of Atma I hand wrote everything but as time went on it seemed increasingly unlikely that the project would ever see the light of day if I didn't leverage AI. So I use AI a ton for coding. I still refuse to use AI for generated art assets, but I did have it create the ForgeScript system and my UI material code. You could argue this is a weak workaround and I would agree. But I'm a tech guy at heart and sometimes I need to explore these ideas to sate my own curiosity. Again, the goal is to just use these workarounds for the early days of Atma where I need to create prototypes quickly. I have some funds set aside to hire artists to recreate these assets before an actual launch of the game and hopefully before I even get to a public beta.

Backend

Before starting this project I didn't have a lot of backend experience. I'm still absolutely in the learning stages but I have poured a significant chunk of these last couple years into learning the AWS (Amazon Web Services) ecosystem and some backend best practices. A lot of people say vender lock-in can be a bad idea, but I needed to focus on reducing scope as much as possible. Using AWS gave me access to a large number of existing tools while not having to manage multiple accounts or coordinate services between different vendors. Everything in AWS plays nicely with everything else in AWS. It might not be the absolute cheapest route, but it keeps things simple and helps me develop a set of skills that should be relevant for years to come.

Is it an MMORPG yet? Not quite. A lot of the framework has been set up and the proof of concept has been tested with automated swarms of bots, but it would be a bit naive to assume I've hit the real challenges with MMO scaling at this stage. I really need to get a large group of playtesters playing the same servers for at least a week before I can say its an MMORPG with any level of confidence. Even then I'm assuming there are mountains of unknown unknowns yet to come.

Right now players can log in to the game using Steam authentication. The vast majority of my backend "control plane" exists through lambdas. Clients communicate with the backend strictly through a client WebSocket API, and servers leverage a mixture of a WebSocket API (which is being phased out slowly), lambdas, and direct DynamoDB access. Flows that currently exist and have been play tested include login, character creation, world joining, server travels, and save data. Last weekend I added some analytics using AWS Athena and S3 which have been locally tested, but I think will be really fun to check out after the next group playtest.

As with all these sections, the backend infrastructure and process deserves its own set of posts, so I'll show some restraint and stop here.

Playtests

Atma has gone through a handful of playtests so far. I've done a few group playtests as well as some individual playtests. Almost all of these have focused on the building and crafting systems. This Friday I will be having my first playtest that I hope gets to experience naval combat. Behind the scenes I've been slowly gearing up Atma for longer duration playtests. I really want to be in a spot where I can just leave the servers running for a week and let people jump in and out as they please. As it is right now, the playtests have simply been one or two hour focus sessions.

How are playtests going? Fine I would say. I definitely find a lot more bugs than I would like, but overall I'm getting the heart of the systems to come through. And in group playtests, people often continue playing a little past when I officially call time. So it's been reassuring that something enticing is here. It's important to remember there's a significant bias though: all the people playtesting are friends of mine who are invested in my journey as much as they are in the game. They'll always be a little more excited just because its something I made. It's still a great way for me to find serious problems and bugs before I start getting unfamiliar playtesters involved, but it certainly isn't an accurate representation of how the average player will experience the game.

What am I working on now?

Right now I'm working on the High Seas combat and overall balance. I'm experimenting with trade route behaviors, ship strengths, island positions, and distribution of island types. I've created some tutorials that help teach the game but have also encountered a few bugs that can lock you out of completing them effectively. I'm also entertaining early ideas around the economy of the game, and finding ways to make sure early level players can just play and not have to stress about resource scarcity or trading until higher levels. Again, the first playtest for this stuff is Friday and I'm really excited to see how this all looks through the eyes of a player.

I think that's a decent overview of where things stand today. I caught myself deep diving into a number of these topics as I was writing them and had to take chunks out and set them aside for future posts simply because of how long it has taken me to get this all down on paper. It's been a great way to do a little review for myself and I hope it sheds some light on the current state of the project.

Well here it goes: the first post.

I've been working on Atma for a little over two years now. During that time I've had to learn a LOT about every aspect of game development and I still have a lot more to learn. I'm lucky to have a strong support group around me that asks how the project is going frequently. They genuinely feel interested in my future plans for the project or if the playtest on Friday went well.

On the other hand, they aren't quite as interested in how increasing contrast can guide players toward the important buttons, or when I migrate my AWS infrastructure into CDK, or how I recouped 20 milliseconds on the game thread by changing a TMap to a TArray. They haven't had the same social experiences I did playing Voyage Century Online for hours a day and going to a 100 vs. 100 war to take over a city. They haven't felt that joy of level 40 attack and walking around with your first rune scimitar. They haven't lost a full set of tier 7 gear because they disconnected during a Hellgate. And they certainly haven't tried to recreate these experiences in Unreal Engine 5. When I was still working as a Technical Lead I was surrounded by people who had similar memories of games deeply ingrained in their history as a gamer.

I miss that.

So this blog is going to be my way of sharing my experiences with anyone who is willing to listen. I plan on talking about my development process from design theories to technical battles to production issues and timelines. I may even just share some of my favorite experiences growing up playing games that influenced what I want Atma to become. We'll see how it evolves over time. Hopefully this provides some valuable insight for people who love to play these types of games and people who want to make them. It might serve as a giant warning sign to anyone else considering tackling projects like this or might be the green light one of you has been waiting for. It might just be me writing a diary that only my brother reads once every few months.

Either way, I'm excited to put my thoughts on paper and share my experiences. We have a lot to catch up on.