Project Atma · A player-built high-seas MMO · devlog by Baista

Ramblings from the shipyard.

My experiences working on a player driven MMORPG exploring social gameplay, economies, user created towns, and islands that move. A criminally ambitious project, but those have always been my favorite projects.

For players and developers who enjoyed Voyage Century Online, Runescape, Albion Online, or Valheim

The log

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.

A house one of my playtesters made, showcasing some of our building assets
A house from a recent playtest.

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.

One of my hand authored wood cutting animations.

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.

User Interface panels for the character, inventory, ship, and building views laid out together
A few of Atma's panels laid out side by side.

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:

A fireball effect I made in two different colors.

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.

A simple sword model
The model output of the arming sword 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.

Read on its own page →

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.

A fresh character standing in their spawn location on a small island. A dock visible below them, some trees above them.
My test character in their spawn location.

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 player hovers to place a new wall which shows the preview in blue. A house in progress stands with a few walls, floor pieces, a table, and a book shelf.
A player lining up a new wall to place.
The player previews a wall torch, an attachment type item, being placed onto a wall with the proper slot
The player previews a wall torch being placed onto a wall fixture slot

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.

The player sails away from their island. A few trade ships follow their routes nearby and the player hovers over a Tier 3 Merchant Ship.
A player hovering over a Tier 3 Merchant Ship on a trade route

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.

A stone, concrete, and wood house built by a player using assets created by John.
A house created during a playtest using mostly assets created by John

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.

A temporary analytics dashboard showing player count, items purchased, new player events, and some other stats.
A proof of concept analytics dashboard with some test data.

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.

Read on its own page →

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.

Read on its own page →

About me

I'm Baista. In 2024 I left my previous position as a Technical Lead to start my passion project Atma. I grew up on games like Runescape, Voyage Century Online, World of Warcraft, and Albion Online. As I dove deeper into game development I couldn't fight the feeling that I had to put my own creative vision out in the world. It's been incredibly difficult but I've loved every step of it.

I've always been fascinated with performance, networking, and game architecture which has given me the skills I need to create a small indie MMORPG, but I want to prove it to myself. There's no guarantee Atma will become a commercial success (and the odds are certainly against me), but it's already been a massive win in my own journey through game development and I hope it can become something others will enjoy being a part of as well.

This blog is where I think out loud. I have tons of thoughts on game development. Many of them I will inevitably prove to be flawed but some will hopefully be the heart of what makes Atma unique. I hope this blog will give people interested in game development some insight into what one person's process looks like. Rise or fall, there is always something to be learned in someone else's journey and ambition.