Antorum Online | News

Patch: Combat Polish and Quality of Life

Fri, 19 Jun 2026 12:00:00 +0000

Damage numbers and health bars now update on the same tick, so hitsplats and your HP finally stay in sync.
Attack timing is now driven per-weapon, so weapons land their hits at their own pace instead of a fixed delay.
Fixed hits occasionally landing after you had already stopped attacking.
Salvaging low-value junk now awards Tinkering experience, so nothing is a total waste.
Broken machinery is no longer soulbound, so you can move it around or hand it off.
The dev blog and news have fully moved to their new home here on antorum.online. Old ratwizard.dev dev-log links now redirect here.
Added an RSS feed for the news page, and the downloads page now shows the current asset build along with per-artifact download counts.
We are also working behind the scenes on a big rework to The Heap.

Patch: New Enemy, Crafting Additions, and Quality of Life

Tue, 09 Jun 2026 12:00:00 +0000

New Enemy: Defective Utility Bot. Killing them is a reliable method of getting items which can be salvaged into Scrap Metal.
New crafting recipes: M. C. Antidote Soda can now be crafted, and iron ingots can be used to craft a pot and a pan.
Melting a Vespex Resin Chunk now requires a pot and actually works (it didn't before).
Junk items no longer roll a quality tier (no more Driftwood +1).
Sitting now satisfies rest zones, so you can rest while seated.
Emotes are now canceled when you move, and cannot be started while in motion (No more butt scooting).
The client now only warns about updates when the remote version is actually newer than yours.
Bank window layout improved to prevent overlap with other UI.
Vespex enemies now have a death sound.
News pages now show a per-article view counter, and patch notes can be updated without restarting the website. Neat.
Editor: Fixed up the Runtime Transform Gizmos stuff that broke during the URP migration, and added a global zone overlay toggle which is very handy when editing terrains.

Patch: Dialog Improvements and Bug Fixes

Tue, 26 May 2026 12:00:00 +0000

Improved the dialog window UI and streamlined the dialog protocol between client and server.
Simplified dialog scripting internals for more reliable NPC conversations.
Fixed a bug where aggressive NPCs would never engage players.
New consumable: Antidote Soda - cures poison. Available at Merri Crate's shop.
Bag capacity is now shown in item tooltips.
Interaction outlines now use color based on the primary interaction type.
The game client now checks the release manifest on login and shows a clear error if outdated.

Bags

Mon, 27 Apr 2026 12:00:00 +0000

You can now expand your inventory by equipping bags! Every character starts with a base inventory of 16 slots, and bags let you carry even more. There are two dedicated bag slots for now. You can also equip items like the Backpack in the back slot to get even more space.

New Items

Patchleather Sack - A crude sack providing 2 extra slots. Craft it with 3 Patchleather (Smithing 3).
Patchleather Bag - A sturdy bag providing 4 extra slots. Craft it with 6 Patchleather and a Scrap Ingot (Smithing 10).
Patchleather Bag Mk2 - An upgraded bag providing 6 extra slots. Upgrade a Patchleather Bag with Patchleather and an Iron Ingot (Smithing 20).
Backpack - Provides 4 extra slots. Available from the Armor Merchant.
Storage Case - A premium case providing 10 extra slots. Available from the Armor Merchant.

Minor Tutorial and World Updates

Sun, 19 Apr 2026 12:00:00 +0000

Minor changes to Intake Facility 45: trainers now reclaim loaned gear, tutorial nodes cap at level 3, and the exit terminal clears your inventory and hands out a starter kit.
Training dummies grant combat experience on hit (again), scaling with your equipped weapon. But they have a level cap.
New tutorial-only fishing pool and ore vein with faster respawn times.
Crafting tutorial uses a new "Broken Machinery" item instead of a weapon.
Added a Shrine with a "Pray" interaction that grants a buff. I dunno man I haven't put it anywhere yet.
New NPCs: Peacekeeper Galbard and Hildegaard. They don't do much.
Ghouls now have a chance to drop Sunglasses. Also Ghouls exist now, be careful at night.
Improved treasure chest loot tables.
Fixed the Emote window close button.
Ad columns now scroll their billboard textures.

BIRP to URP

Thu, 16 Apr 2026 18:48:00 +0000

This one was a damn pain.

Antorum has been running on Unity's built-in render pipeline (BIRP) for most of its life. BIRP is the old default, the one that shipped with Unity for over a decade. It's battle-tested and honestly looks fine, but it's showing its age, and Unity is actually going to deprecate it soon. Since I'm already on the latest Unity version, it felt like the right time to drag Antorum into the modern age and move to the Universal Render Pipeline (URP).

Look and Feel

The game feels a lot snappier and looks much better. We get emissive materials, nicer LOD fading, and real-time lights that actually look like lights. I took the opportunity to place a lot more of them around the world.

Forward+ and Lighting

We switched the rendering path to Forward+, which lets us have many more real-time lights in a scene without the old per-object light-count limits. Shadows are still expensive, so we're now pickier about which lights are allowed to cast them.

Materials and Shaders

Migrating all of the materials was tedious. Unity's built-in upgrade tool did most of the work, but for a chunk of materials it failed to carry over textures, so those had to be fixed up by hand. Our custom terrain, editor, and character shaders all had to be rewritten for URP, and lighting values needed tweaking across the board. Honestly a lot of this stuff is showing its age in general, since I wrote it so long ago. It's still not perfect, but I'll keep chipping away at it.

Water and Weather

I had to ditch LuxWater for Stylized Water 3, since LuxWater doesn't support URP. Stylized Water 3 is easier to configure, and I had fewer issues getting it to play nicely with Enviro 3. It also comes with some really cool river tools I'm excited to dig into. Enviro 3 itself is still great, and upgrading to the URP-compatible version was painless. Fog interacts with water much better now.

Addressables

The biggest surprise pain point was the Addressables build pipeline. Our asset content is built from a separate Unity project, and once we were on URP the shipped Addressables bundles started throwing missing shader errors in the actual game. Unity was overzealous about stripping shader variants it thought weren't being used, leaving only "invalid" shaders with erratic lighting behavior. Strange.

The fix was twofold. First, I centralized the URP renderer, pipeline asset, and global settings into our shared engine package, so the game, editor, and assets projects all resolve to the exact same rendering configuration. Second, I added a custom shader stripper to the assets project to preserve the variants we actually need at runtime. Needing to do that at all seems wrong, but Unity is full of annoying quirks like this and from what I could see it's a known issue. With both fixes in place, the Addressables bundles now build with the same shader variants the game and editor use, and everything renders correctly in the shipped game.

Other Updates

On a related note, I got the macOS build up and running again. The downloads page is now gated behind a login, and we serve a proper releases manifest with a version archive for all the relevant Antorum software. Good progress on the devops front.

With all that being said, the game is online! Make an account, download the client, and help test it out if you're interested.

Thanks for reading.

- Declan (@dooskington)

Minor Site Update

Mon, 13 Apr 2026 12:00:00 +0000

We improved the site layout across the board.

There is now an email verification flow. Not required to play the game, but it's nice to know if a user has a real email we can reach them at.

Also, we set up this neat little news system, so this is a test for that!

Update 1

Sun, 12 Apr 2026 12:00:00 +0000

Hello world. This is where patch notes are going to go. The first update is that Antorum is now live! Create an account and download the game to participate in the alpha playtest.

Motion and Emotion

Mon, 09 Mar 2026 23:35:00 +0000

Players can now express themselves with a variety of emotes, like dancing, waving, flirting, etc. It's an MMO staple, so we had to have it. Emotes are triggered via chat commands like /wave, /dance, and /cheer, but there's also a little window for browsing them.

(video unsupported)

A character performing an iconic dance.

There are currently eight emotes: Wave, Cheer, Flex, Cry, Flirt, and three Dance variants. Each emote has one of two lifecycle types: one-shot or loop. One-shot emotes like Wave or Flex play once and then automatically stop after a set duration. Looping emotes like the dances keep playing until the player moves or performs another action.

Emotes are data-driven on the server side, defined in TOML just like everything else:

id = 3

name = "Wave" command = "wave" lifecycle = "one_shot" duration_ticks = 180

Adding new emotes is straightforward, aside from the animation issue I'll get to later. The client can request a list of all available emotes from the server, so the UI stays in sync automatically.

The whole thing is built on top of the activity system, which is the same bit of code that powers sitting, crafting, mining, and fishing. When an emote is triggered, the server sets the player's activity state and broadcasts the change. For one-shot emotes, it also schedules an automatic stop:

let state = ActivityState::Emote(EmoteActivityState { emote_id: emote.id });
activity_performer.set_state(state.clone());

if matches!(&emote.lifecycle, EmoteLifecycle::OneShot) { let duration_ticks = emote .duration_ticks .unwrap_or(DEFAULT_ONE_SHOT_EMOTE_DURATION_TICKS); pending_one_shot_stops .entries .insert(ent, current_tick + duration_ticks as u128); }

Looping emotes are instead cleared when the player's current interaction is cancelled, like by moving or starting a new action.

On the client side, when the activity state update arrives, the emote ID gets passed into the Unity Animator as a float parameter:

EmoteActivityState emoteActivityState = (EmoteActivityState)activity;
animationId = "IsEmoting";
emptyHandsForActivity = true;
emoteId = ConvertResourceIdToAnimatorFloat(emoteActivityState.EmoteId);

This works, but it's not ideal. The animation controller is fairly static, so each emote clip has to be wired up manually through blend tree states keyed on that float value. There's no way to look up and play a clip by ID at runtime yet, so every new emote means another manual entry in the animator controller. I'd like to rework the character animation system to support that, but it hasn't happened yet.

Emotes also don't have any sound effects yet. When they do, the audio will most likely be driven by animation events on the clips themselves, so it shouldn't require any server-side changes.

(video unsupported)

The Cry emote in action.

In the future there will be plenty more emotes. Some cool ones will even be unlockable via quests.

Thanks for reading.

- Declan (@dooskington)

I Love to Sit

Sun, 22 Feb 2026 15:46:00 +0000

Characters in Antorum have been freed from the curse of standing up for their entire lives. They can now sit!

(video unsupported)

Just put a SeatComponent on an entity and it will become, well, a seat. If the model has a seat-anchor socket, the client will use that as a hint for butt positioning. All in all, this was a pretty simple feature to implement. It works using the activity system, which is the same bit of code that powers animations/poses and syncing for crafting, mining, gathering, and fishing. I'll keep extending it with other functions, such as allowing players to lie down on beds and sofas, but for now, it's just chairs.

Antorum is dangerous. Have a seat and relax.

- Declan (@dooskington)

Status Update

Tue, 10 Feb 2026 19:30:00 +0000

Howdy. This is just a quick status update on the project since I've been a bit quiet recently, but development is going well! The antorum.online website is back online in a limited state, and you can download the client and play. The test server is up periodically as I work on things.

Combat Improvements

Instead of being client driven, we now properly sync ticks with the server and try to match impact timings in a latency-aware way. We also have new combat sounds. You can attach an SFXContainerComponent to an NPC to give it custom hurt, death, and attack sounds. Weapons can also have their sound effects defined in their item definition, so each weapon sounds different when you swing it.

The CombatSfxResolver figures out which sounds to play for any given attack. It checks a priority chain: first, if the attacker has a weapon equipped, it pulls SFX ids from the weapon's item definition. If not, it checks for an SFXContainerComponent on the entity (this is how monsters get their custom sounds). And if neither of those exist, it falls back to default unarmed sounds. The resolver also handles finding the right socket to play the sound from (the muzzle socket for ranged weapons, the hand socket for melee, etc.)


CombatSfxResolver.cs
public CombatSfxData Resolve(NetworkEntityComponent entity)
{
    // Priority 1: Check for equipped weapon sounds
    EquipmentComponent equipment = entity.Equipment;
    if (equipment != null)
    {
        var weaponSfx = ResolveFromEquipment(equipment);
        if (weaponSfx != null) return weaponSfx;
    }
// Priority 2: Check for monster/NPC SFX container
SFXContainerComponent sfxContainer = entity.GetComponent&lt;SFXContainerComponent&gt;();
if (sfxContainer != null &amp;&amp; sfxContainer.State != null)
{
    return ResolveFromSfxContainer(sfxContainer);
}

// Priority 3: Unarmed/default fallback
return CreateDefaultSfxData();

}

Dynamic Footstep Sounds

After years of hearing the same footstep sounds, I finally made it so the sound depends on the surface you are walking on. Not difficult, I don't know why it took so long. But it is very satisfying.

We keep a mapping of material/tile ID to AudioEvents. At runtime, we sample the surface the player is walking on, grab the material id, and resolve it to the right footstep sound. There's a default fallback for any unmapped surface. Simple, but makes a huge difference. Grass, stone, wood, and sand all feel distinct now. It does a lot for spatial awareness and just making the world feel more grounded.

DevOps Changes and Workflow Improvements

I had some issues with my server provider, and had no help from support, so I changed providers and rebuilt my server infrastructure. I also made some workflow improvements to make it easier to deploy and manage things from anywhere.

I created GitHub workflows to automate building and deployment of the client, editor, server docker images, and game content (addressables). The workflows also upload the latest client and editor executables to the website, so the most recent build is always available for download. antorum.online is back up, but still very much a work in progress. For now it is just a place to download the client and get some basic information about the game.

Entity Inheritance

Entities can now extend one another, making similar entities easier to maintain and reducing duplication. So we have a base npc-chonkrat, and then npc-chonkrat-runt, npc-chonkrat-papa, etc. Entity definitions are TOML files. A derived entity specifies extends = "npc-chonkrat" and only overrides the components it needs to change. Everything else is inherited from the base. The server merges component tables at load time with deep merging for nested properties, and validates that there are no circular inheritance chains. This matters a lot long-term: adding a new variant is just a small file with a few overrides instead of a full copy-paste, which means less duplication and fewer bugs when the base definition changes. Here's the base chonkrat and its two variants:


npc-chonkrat.toml
id = 98

[networked] [info] name = "Chonkrat" description = "An abnormally large and menacing variant of rat." model_id = 54 [transform] [animator] animation_controller_id = 3 [npc] wander_radius = 20.0 sayings = ["eep"] combat_sayings = ["SCREE!"] [interactable] interactions = ["attack", "walk-to", "examine"] [movement] speed = 1.25 [health] [combat] [stats] max_hp = 12 attack = 2 armor = 1 [rest] requires_rest_zone = false [drop_table] drops = [ ["any", "1, 100.0", "330, 90.0", "96, 90.0", "414, 30.0" ], ]


npc-chonkrat-runt.toml
id = 81
extends = "npc-chonkrat"

[info] name = "Chonkrat Runt" description = "Slightly less menacing than its larger counterpart." [transform] scale = 0.75 [stats] max_hp = 10 attack = 1 armor = 0


npc-chonkrat-papa.toml
id = 21
extends = "npc-chonkrat"

[info] name = "Chonkrat Papa" description = "Don't mess with his ratlings." [transform] scale = 1.5 [stats] max_hp = 20 attack = 4 armor = 4

Dialog Editor

I vibe coded a dialog editor to help me work on more complex conversations. It's built with Dioxus, largely with the help of ChatGPT and Claude. Dioxus is great for building quick UIs and it is nice to stay in the Rust ecosystem, since I have been extracting server code into a shared module which tooling can use. The editor still needs a lot of work though. Node edges and connections are especially difficult to get right. Very basic feature set right now, but it is already helpful for visualizing conversation flow.

As for the vibe coding workflow itself, it is very nice and becoming very important, but of course that is bittersweet. Working with AI tools exhausts me more than anything. It is great for quickly iterating and learning something new, but in the days of agentic tools I think we are just going to find ourselves prompting them and running "teams" of them. I don't know how this is all going to turn out.

I guess there is a reason I've been building an MMORPG for years as a sort of escapism.

Thanks for reading. More news soon!

- Declan (@dooskington)

Summer Progress and Fall Foundations

Wed, 27 Aug 2025 18:45:00 +0000

I'm still getting a lot of Antorum work done this summer, but it's been slow going as I try to avoid burnout and enjoy some time away from the screen. Here's a look at some of the recent progress across gameplay systems, scripting, art, and world-building.

Monorepo

The project originally started with five separate Git repositories: server, client, editor, engine, and assets. At the time, I thought this might make things cleaner. I leaned on submodules for the engine and assets, but that just offered more friction than benefit. It also made it annoying to keep versions in line with each other and work on larger features that spanned multiple projects.

Now that Unity's tooling is better, and with my recent push to support external asset bundles (see dev log 51), I went ahead and merged everything into a single repo. All commit history and authorship was preserved, and I also transferred all issues to the new repo. The result is cleaner, easier to work with, and now sits at 1,774 commits. Not bad.

Improved Lua Scripting and Interactions

Scripting in Antorum has always been pretty experimental. But I spent some time improving the Lua integration, and now it's a bit more robust. Notable changes:

Lua modules can now be defined in a shared include folder and reused across scripts.
A player-init.lua script runs when players log in, which I’m using to manage tutorial flags and state.
Player spawn points can now trigger attached scripts when a player spawns there. This helps with one-time intro sequences or scripted encounters.
Entities can now have a ScriptComponent that responds to item usage. This powers things like inserting a keycard into a scanner to trigger logic.
A TagComponent was added to help identify or group entities from within scripts.

These allow for fine-grained behavior control, defined entirely through external Lua scripts, without modifying core engine code. For example:

An Orientation Pass Scanner in the tutorial checks your completion state and opens a door only when conditions are met.
Item-on-entity interactions now support things like spawning monsters, unlocking doors, or triggering dialogue.
Because it’s data-driven, developers and modders can define their own interactions without writing any Rust, or shipping a new client & server build.

It’s still early, but this moves us closer to an Antorum where the world feels responsive and fun to interact with.

Improved Character Creator

I revisited the character creator and gave it a few overdue improvements:

Added several new hairstyles and facial hair options.
Improved the lighting and layout of the scene.
You can now click and drag to rotate your character preview.
A new developer mode lets you build characters and export them as entity `.toml` definitions.
You can mess with the character creator without being connected to a server.

It's significantly more usable now.

Intake Facility 45

Intake Facility 45 is the starting location for newly arrived players. It serves as a tutorial and orientation center, perched on a rain-soaked, fog-shrouded coastal cliffside clearing surrounded by jagged sea rock. Isolated from the mainland, the facility processes Offworlder immigrants arriving from the Triglav via orbital shuttle.

This is effectively version 2 of the tutorial. Players learn the basics of movement and interaction, then head into training and orientation halls for specific mechanics. It’s been fun to build and test, and there’s still plenty to flesh out.

Deer

This came from a community poll in the Discord! Deer now roam the Foreston area. There are doe and stag variants, and they make the world feel a little more alive.

Other

Upgraded to Unity 6. It went surprisingly well.
Fixed the water shader so it interacts properly with fog.
The Editor remembers the last file you saved and opens it on launch.
Fixed character combat stances and transitions.
Added an admin command to `die`.
Improved the `tp` admin command to support x, y coordinates in addition to predefined points.
Added support for varying roof heights (useful for tiered structures).
Improved the Tile Paint tool for better usability.
Navmesh and tile walkability now support a “no vehicles” flag.
Vastly improved the world map UI.
Only the roof of the structure you are in obfuscates; others remain visible.
Added an eyedropper tool to the editor to speed up terrain tile painting.
And a bunch of tiny fixes I didn’t write descriptive commit messages for.

RustConf 2025

As a side note, I'll be floating around RustConf this year. Say hi if you want to meet and chat.

Thanks for reading.

- Declan (@dooskington)

Asset Bundles and Content Delivery

Sun, 20 Jul 2025 22:37:00 +0000

Among many other goals, I want Antorum to be easy to build content for. A significant part of that is streamlining the pipelines with which new content gets created, made accessible to designers, and shipped to players. To that end, I've finally taken the time to refactor the entire resource loading system of the client and editor.

In Antorum, all items, entities, map data like zones, dialog trees, scripts, etc., are entirely data-driven and controlled by the server. While this approach works well for most things, client-side assets such as Models, AudioClips, Textures, and Materials still need to be managed and compiled through Unity. This means the server only references an asset by a numeric ID (like model ID 123), expecting the client to have the corresponding asset prepared.

Unity, by default, does not expose game assets at runtime. You can't easily query existing assets or dynamically load new ones. The proper solution for this issue is Unity's Asset Bundles. But seven years ago, Asset Bundles seemed intimidating, so I opted for the simpler Resources system. Unity's documentation outlines the drawbacks clearly:

Unity typically doesn't use path names to access assets; instead, you declare a member variable and assign it via the inspector. Unity then calculates which assets to include when building a player. This radically minimizes the build size. When you use the Resources folder, all assets within are included in the build, significantly increasing the size and impacting performance. Additionally, using path names creates less reusable and maintainable code.

The Resources folder solved the problem of dynamic asset access but created new issues. Assets became permanently baked into builds, making modifications cumbersome, and each new asset added increased the game's boot time. Once the game started occasionally crashing on startup due to excessive loading, addressing this became essential.

The solution involved refactoring our existing ResourceStorage system to integrate seamlessly with Unity’s Addressable Asset system and Asset Bundles. The ResourceStorage class manages assets by asynchronously loading them at runtime, caching them for efficiency, and associating each asset with numeric IDs corresponding directly to server-side definitions. This design simplifies synchronization between client and server and significantly streamlines content management.

In order to actually bake these bundles, the new setup has a sort of dedicated "asset builder project". Developers place new assets into the project, click a button to bake the bundle, and the bundle is then placed in the server files and synchronized with clients.

This system significantly improves the content creation pipeline. What previously took an hour or more can now be accomplished in minutes.

Looking ahead, individual servers could theoretically serve their own data files and asset bundles to create entirely unique game experiences. While this is far in the future, the groundwork is now in place.

There's still room to improve, and we're currently limited to Unity's ecosystem for player-facing assets. However, the long-term goal remains clear: to make Antorum as data-driven and modular as possible.

Thanks for your continued support. Also, come play Glorbio.

- Declan (@dooskington)

Patrols And Paths

Tue, 10 Jun 2025 21:29:00 +0000

Lately I've been putting more work into NPCs and their interactions with the world and player. One cool thing you can do now is create and assign paths - perfect for patrolling guards, wildlife, cutscene choreography, and other fun stuff. It all works through the new PatrolPathComponent.

The new Component is pretty straightforward: it manages a list of waypoint positions/nodes. NPCs can reference this Component on a target Entity (via a UUID) and then follow that path. Initially, I thought about creating a more atomic node Component, and then implementing paths such that each node is another Entity with that Component, referencing the next like a sort of linked list. In the end, though, I kept it simple and took the monolithic approach. Gotta keep moving.

Aside from defining the path itself, there are three path types to choose from:

Loop: Travel to each node in order, then go back to the beginning. Repeat.
Ping Pong: Travel to the end of the path, then reverse direction. Repeat.
Random: Travel to a random Node. Repeat.

The tooling for this was a bit of a grind. I ended up using a similar pattern that Unity does, creating an interface for custom inspectors based on Component types, then using that to create new UI as well as override the wireframe rendering of certain Component types entirely. This means Entities like the Player Spawner can have a specific visual representation in the editor (a wireframe character model), and others like Patrol Paths can render each Node as a wire sphere, along with a custom inspector for adding, removing, and jumping to Nodes. I also added brand new transformation gizmos using the super cool Runtime Transform Gizmos package. Moving things around the game world is very intuitive now.

Another neat thing I finally did was upgrade to Unity 6, as well as update our dependencies and convert over to the new input system. It is nice to be back on a stable release. This fixed some annoying issues — particularly one where the engine was keeping some gamepad polling thread active, keeping the game executable from ever actually closing. Hopefully it will be a while before I have to do this again.

In other news... there is a wiki now! It will be a technical hub for scripting guides, specs, documentation, tutorials, etc. I hope it will help keep things clear and accessible for anyone interested in modding Antorum. It isn't public yet, but it will be available soon, with the first new playable build of the game in years.

Lastly, somewhat unrelated to Antorum, Rat Wizard has launched a new game called Glorbio. We are awaiting word from the Chamber of Commerce on the exchange rate between Glorp and Antorum Standard Credits. Praise Glorath.

More updates to come. Thanks for reading.

- Declan (@dooskington)

Vehicles

Sun, 11 May 2025 11:49:00 +0000

The game has vehicles now! This is a feature I've wanted to experiment with for a while, and after a lot of groundwork, the first iteration is complete.

Your browser does not support the video tag.

This feature pretty much entirely works around the newly introduced VehicleComponent and RiderComponent. A VehicleSystem handles mounting and dismounting, ticking vehicles and their riders, and handling other vehicle related logic. The system isn't too flexible yet, supporting only small single rider vehicles, with a limited animation set. But, it's already a lot of fun to zip around the map.


ents/motorcycle.toml
id = 84
[networked]
[transform]
scale = 1.0
[info]
name = "Old Motorcycle"
description = "A slick motorcycle. It's a bit rusty, but it still runs."
model_id = 378
[vehicle]
is_locked = false
idle_audio_clip_id = 19
move_audio_clip_id = 20
start_audio_clip_id = 21
stop_audio_clip_id = 22
is_headlight_enabled = false

[interactable] interactions = ["drive", "walk-to", "examine"] additional_client_interactions = ["exit-vehicle", "headlights"]

You can even turn on and off the headlights. It's a small touch, but it really helps with immersion and makes nighttime travel feel special. I should add a horn. Not sure why I didn't do that already.

Fun technical fact - when an entity is riding a vehicle, the vehicle actually just follows the riders position and not the other way around. Then, we make you go really fast by giving you an invisible spell effect. Neato.


spell-effects/riding.toml
id = 20
name = "Riding"
description = ""
icon_id = 0
is_db_save_disabled = true
is_net_sync_disabled = true
[[status_effects]]
type = "modify_stat"
stat = "vehicle_speed_bonus"
val = 160

[[status_effects]] type = "set_flag" flag = "is_in_vehicle" val = true

I threw together a simple riding pose for now. I'll need to add support for different vehicle animations later.

Aside from that, there are still a lot of things to polish: better models, controls, some way to purchase a vehicle, and more interesting interactions with the vehicles themselves. The foundation is there though, and I'm excited to see where it goes next.

- Declan (@dooskington)

New Character Models

Tue, 17 Dec 2024 19:44:00 +0000

NOTE (2/12/2025)
NOTE! This post was originally written about a fork of Antorum that has since been merged back into the main project.

Over this past year I was able to invest in something I have wanted to do for a long time: new character models.

Not only was this a major lift from an art perspective (Thanks Gustaw!), but it also required a lot of work on the technical side.

To make it easier to add new equipment and clothing, the game now supports the concept of "skinned" equipment. This means that equipment can be added without needing to create a new mesh for each piece of equipment. This is a huge time saver as all you need to do is paint a texture which will get applied to the character model. Not all equipment will be skinned, but it is a nice option to have for simple stuff.


items/shirt-tee.toml
id = 14
name = "Tee Shirt"
description = "A basic tee."
...

[model] male_skinned_texture_id = 32 female_skinned_texture_id = 33

The implementation is pretty simple. All the layers of a character are combined together at runtime and cached. Then, that final texture is applied to the character.

These layers are described as style items and are data-driven just like actual items. I still need to create more at some point.


style-items/hair-male-mohawk.toml
id = 11

name = "Mohawk" type = "hair" body_type = "male" skinned_texture_id = 14 model_id = 329

I've also been making some animation improvements, replacing the janky animations with new ones that are a bit more fluid and natural. Additionally, in-combat and out-of-combat stances are now separated, which is nice.

(video unsupported)

I'll miss the old character models, but this had to be done. I'm excited to see the fun characters that players can create now.

Thanks for reading. Onto 2025 - year 7 of development!

- Declan (@dooskington)

Improved Crafting Skills

Mon, 04 Nov 2024 23:08:00 +0000

NOTE (2/12/2025)
NOTE! This post was originally written about a fork of Antorum that has since been merged back into the main project.

Now that gathering skills are in a better place, I turned my attention to the core crafting skills. I want them to be familiar and consistent, but unique in their own ways. For example, Cooking is more focused on experimentation and recipe discovery, while Smithing focuses more on creating items from concrete schematics, then upgrading those items into new ones.

Cooking

Cooking is mostly the same, but I simplified the process a bit by cutting the concept of differently sized cookware items affecting the number of ingredient slots available. You still need either a Pot or a Pan, but either will give you 4 ingredient slots to work with. The quality of the used ingredients affects the quality of the final dish, which affects the amount of health restored by eating it. Better ingredients equals better food.

Smithing

Smithing (previously called Gearcrafting) required a good bit of bugfixes and UI improvements. You can now queue up more than one of an item, just like you can with Cooking. There is also a new recipe panel so the interface is more consistent with that of Cooking. Of course, material quality now affects the quality of the final product - which affects its maximum durability.

Ore still needs to be processed into Ingots at a Furnace before they can be used for Smithing. Not too much has changed there.

Next Steps

There are more crafting skills to be added in the future, but to keep things simple for now I won't add them until there is more gameplay for them to actually support. You may have also noticed that the character model looks a bit different now. I hope to write more about that soon!

Thanks for reading.

- Declan (@dooskington)

Improved Gathering Skills

Mon, 24 Jun 2024 17:45:00 +0000

NOTE (2/12/2025)
NOTE! This post was originally written about a fork of Antorum that has since been merged back into the main project.

For the past few months, I've been making a lot of bug fixes and changes to the item system to support improvements to the three main gathering skills: Fishing, Foraging, and Mining.

The core thing to support were the concepts of item quality and derived stats. When gathering items, they now have a chance to be of improved quality, based on the level of the respective gathering skill. Item quality itself affects the stats of the item. For equipment, higher quality means better damage, armor, maximum durability, etc. For materials and ingredients, quality can carry over to the final product.

Individual item instances already had support for properties, but stats are a bit different. They change often, don't need to be persisted to the database, and are derived from said properties (like quality, durability, and enchantments). To achieve this, each item instance can now have a block of stats associated with it that gets calculated by the server and synced to clients when needed. Instead of just using the static base stats from the item definition, the stats of each item instance are derived when the item is created in the game world or when the item is modified (e.g. if the quality or durability is changed). This was a big refactor, but it was necessary to support the new item quality system and a few other things I have in mind for the future.

As for the skills themselves, they now each have unique animations. Additionally, skills which require tools don't expect you to have the tool equipped anymore, which is a nice quality of life change. It can just be in your inventory. That was kind of a pain to get working correctly as there were a lot of edge cases to handle - dropping the tool while gathering, changing your equipment, etc.

I created an Activity system to handle the various animations and actions that can be performed in the game. An Activity is basically a visual action that the client needs to replicate. It may consist of an animation, sound, or other metadata. For example, the Fishing activity contains data about the fishing bobber position and the type of fishing rod being used. This allows the client to properly override the players equipment and animation state. It also allowed me to remove a bunch of fishing specific packets and code, as all that is now just driven through this more generic system.

Fishing

Fishing was frustrating to get working with the new water system. Since water is more dynamic now and actually moves, I had to make sure that fishing nodes and bobbers floated properly. Aside from that, the aforementioned item quality changes, and bug fixes, there is not a ton of new stuff here - I was already pretty happy with how the skill worked.

Foraging

Foraging is in a similar place. The core was already solid, but I spent a lot of time refactoring it under the hood and fixing bugs. Now it actually takes some time to forage something, instead of just being an instant item pickup.

Mining

Mining was the most busted of all the skills. I didn't even realize how broken its been for the past few years. Apparently, I just never implemented mining speed / the mining bonus stat properly. No matter what tool you used, or what your Mining level was, you would always take the same amount of time to mine some ore. Not great, but I got that fixed up. Smelting also got some work, but I'll talk more about that in the future. I'm just happy to have an actual animation here now.

Next Steps

There's still a lot of work to be done across the board. Now that I've gotten a chance to revisit gathering, I'll revisit crafting. Thanks for reading.

- Declan (@dooskington)

Time

Tue, 09 Jan 2024 23:47:00 +0000

NOTE (2/12/2025)
NOTE! This post was originally written about a fork of Antorum that has since been merged back into the main project.

Happy New Year! The most recent addition to the game is one of the biggest yet - Time.

(video unsupported)

(time scaled up x1000 in this clip)

Time will now pass in the world, creating distinct morning, afternoon, evening, and night phases. I took the opportunity to upgrade the water on the game client as well. The old shader had a few issues and also didn't interact well with a dynamic sky. I used some assets for this: Enviro 3 and Lux Water. No reason to reinvent the wheel for this stuff, at least not right now.

The current time ratio is 4:1, so a full day in the game takes 6 real-world hours. Time affects a few things in the game world: At night, dangerous beasts will come out and hunt down unsuspecting players. Certain bosses or quests may be only available at certain times. And when fishing, your success at catching certain fish will depend on the time (more on that in a later update).

Serverside, I've been experimenting with scripting again to take advantage of this new feature. Here's an example for an NPC spawner that is only active at night:


npc-spawner-night.toml
...
[transform]
[npc_spawner]
    min_spawn_delay = 50
    max_spawn_delay = 250
    max_spawned_ents = 3
[time_based]
    on_time_of_day_changed_lua = """
        local ent_id = Context:ent_id()
        local time_of_day = time_of_day()
    local is_night = (time_of_day:value() == 3)
    set_entity_active(ent_id, is_night)
    print("[Lua] npc-spawner-night is_active = " .. tostring(is_night))
"""

...

You could also use a TimeBasedComponent for an NPC that despawns when the sun comes up:


[time_based]
    on_time_of_day_changed_lua = """
        local ent_id = Context:ent_id()
        local time_of_day = time_of_day()
        local despawn_effect_id = 25 -- corresponds to some "poof" effect on client
    -- despawn this NPC if it is dawn or day
    local needs_despawn = (time_of_day:value() == 0) or (time_of_day:value() == 1)
    if needs_despawn then
        print("[Lua] Day is here, despawning")
        spawn_effect_on_entity(ent_id, despawn_effect_id)
        delete_entity(ent_id)
    end
"""

The scripting API is still pretty rough. As time goes on I'll continue making improvements there. But it's nice to be able to data-drive some simple behaviors.

Time is synced to clients using a new packet:


101 - 0x65 - Time Initialize 
struct TimeInitializePacket {
    world_time: String,
    world_time_scale: i32, 
}

Clients will receive this packet on connection and at infrequent intervals after that, unless time changes in some dramatic way (like through an admin command), upon which it will also be sent. Aside from that, there's not much attempt here to sync a tick count or stay super accurate with the server. Since both clocks advance independently in real time I'm expecting them to stay in sync at least well enough to support the day/night cycle, as time on the client is purely visual and there are no game mechanics that require precise timing (yet). An improvement that could be made here though is to take the latency between client and server into account when syncing the initial time. With this current system, if the time scale and ping are high enough, the times could diverge by several in-game minutes.

Now that it can get dark at night (in the wilderness at least), you probably want to carry a light around. If you find yourself without one, you can use the new Lighter item to ignite a Stick and get a Torch.

Over the holidays I also did a lot of boring terrain fixes. Most notably, terrain normals don't break down at certain chunk boundaries anymore. I need to investigate just pre-calculating these or even setting up some sort of static map, because they really are simple, and my current method of normals generation is getting expensive for no reason.

Before. Yuck.

After. Normals on the chunk boundary now take those boundary tiles into account.

I'm glad to have finally gotten all this stuff done. Lots more to do, though. Thanks for reading.

- Declan (@dooskington)

Character Progression and Stats Rework

Fri, 22 Dec 2023 17:00:00 +0000

NOTE (2/12/2025)
NOTE! This post was originally written about a fork of Antorum that has since been merged back into the main project.

I've been spending some time figuring out how to improve the feeling of progression in the game. Player Characters should have the freedom to experiment with different combat styles, skills, and items, as well as have access to lots of content relating to all aspects of the game. However, I also want to reward specialization and create interesting paths for Player Characters to take, with some paths even closing off others.

In this regard, one of the new features I've been prototyping a bit is Cyberware. Cyberware chips can be installed in your characters brain to give them "focus points" towards a particular skill, or set of skills. Once installed they can be tough (or impossible) to get removed. Focus points increase the amount of experience points recieved in a skill, along with increasing the level cap of that skill. The idea is that by becoming a cyborg you can specialize further and become more powerful than typically possible. You just need to sacrifice a piece of your humanity to do so. If this feature sticks around and gets another iteration, I'll write a more in-depth post about it.

I made health bars a bit easier to visually parse. Now they are separated into sections, each one representing 5 health points. This makes it possible to quickly gauge your relative strength against other characters and monsters. It's also satisfying to see your character's health pool grow in a tangible way.

Each Skill level up now increases your Max Health and Stamina. Combat skills have more influence on this growth, but even if you play a pacifist character, you'll still become a bit more tough and fit over time.

Additionally, I made some adjustments to combat calculations with the goal of better rewarding Player Characters for training Skills in addition to simply acquiring better equipment.

Characters and Monsters now have attack/defense ratings that are used to determine hit chance in combat. Monsters generally just derive these ratings from their static damage and armor values. Entities with equipment though, like Player Characters, derive them from the damage and armor of each item equipped, as well as their mastery of those items and relevant skills. Of course, modifiers from things like status effects and enchantments are also taken to account in both of these scenarios. I also changed the max hit calculation, so now instead of being purely damage-based, it is based on the damage, combat style, and mastery of your main weapon (or if you have none - your fists). This creates a scenario where items that you may normally out-level will implicitly improve for you in a minor way if you continue to spend time training your weapon skills.

At this point I've iterated on this stuff at least five times, and I'll probably do so again. But I think for the moment this creates a much more interesting difficulty and progression curve. Hope to make another post soon.

- Declan (@dooskington)

Tile Blending

Mon, 20 Nov 2023 23:48:00 +0000

NOTE (2/12/2025)
NOTE! This post was originally written about a fork of Antorum that has since been merged back into the main project.

One of the new features I worked on this year is Tile Blending. It's now possible to have smooth transitions between two different tile types, which is really nice for stuff like pathways and finer terrain details.

Each tile now has background, foreground, and mask layers. The mask layer determines how much influence the foreground and background has on the final texture of the tile. I generated the masks and arranged them into a blob tileset:

Then the terrain shader does some basic blending:


...
float3 backgroundUv;
backgroundUv.xy = uv.xy;
backgroundUv.z = IN.customColor.x;
fixed4 backgroundColor = UNITY_SAMPLE_TEX2DARRAY(_MainTexArray, backgroundUv);
float3 foregroundUv;
foregroundUv.xy = uv.xy;
foregroundUv.z = IN.customColor.y;
fixed4 foregroundColor = UNITY_SAMPLE_TEX2DARRAY(_MainTexArray, foregroundUv);
float3 maskUv;
maskUv.xy = uv.xy;
maskUv.z = IN.customColor.z; // Using custom vertex data for third set of UVs
fixed4 maskColor = UNITY_SAMPLE_TEX2DARRAY(_MaskTexArray, maskUv);
fixed4 c = lerp(backgroundColor, foregroundColor, maskColor.a) * _Color;

...

It's not perfect (There's probably more efficient ways to do this without 3 sets of UVs) but it's a good first step and a lot better than having sharp tile transitions everywhere.

You can paint tile masks manually, but the real star is the auto-blend option that decides which mask to use based on neighboring tiles of the same type:

(video unsupported)

Planning to make more improvements soon.

- Declan (@dooskington)

Doors

Mon, 15 May 2023 17:15:00 -0700

NOTE (2/12/2025)
NOTE! This post was originally written about a fork of Antorum that has since been merged back into the main project.

Been a while since I made a post. Got a few things in progress over here, but a cool thing I just got done is Doors.

(video unsupported)

Doors are just entities with a server-side DoorComponent. They can be locked, but I haven't implemented keys or any way to unlock them yet. I had to modify a bit of interaction code to get them working. Doors are unique in that their interactions (Open, Close, Lock, Unlock, etc) are dependent on the state of the entity itself, and therefore can change. Anyway, now interactables are a bit more dynamic.

Another unique property about doors is that they modify the walkability of whatever tile they are on. This required a new system to handle mutation of the map data at runtime, which will be nice to have in the future for other stuff too.


ents/door.toml
[networked]
[info]
    name = "Door"
    description = "A door - the nexus between two rooms."
    model_id = 70
[transform]
[interactable]
    interactions = ["open", "close", "walk-to", "examine"]
[animator]
    animation_controller_id = 6
[door]
    is_open = false
    is_locked = false

Doors themselves are entities, but the frame has to be carved out of a wall.

(video unsupported) (video unsupported)

- Declan (@dooskington)

Character and Combat Work

Sun, 13 Nov 2022 19:53:00 -0700

NOTE (2/12/2025)
NOTE! This post was originally written about a fork of Antorum that has since been merged back into the main project.

I made some minor improvements to the character creator, making it look nicer and also adding the ability to rotate your character. Here's a peek at how it's looking so far.

(video unsupported)

You may notice it's a bit more simplified compared to the character creator in Antorum. I don't want to make players mess around with numbers or choose stats before they are even in the game. Stats and your character build should happen based on how you play, not how you assign your starting numbers - that's the goal at least. Additionally, I'll note that there's still a lack of variation in hair and starter clothing. I'll have to make new ones soon.

Past that, I've been focusing on combat again. There are now damage types which can be put on Items or NPCs, as well as resistances. This is the first step of many that will hopefully make combat a bit more interesting and give players some more choices in the gear set that they are building. For now, the types are Slashing, Piercing, Crushing, Fire Ice, Electric, Psionic, and Poison.


items/shock-stick.toml
name = "Shock Stick"
types = ["weapon"]
model_id = 175
...

[attributes] damage = 25 equipment_slot = "mainhand" damage_types = ["crushing", "electric"]


items/trash-can-lid.toml
name = "Trash Can Lid"
types = ["armor"]
model_id = 26
...

[attributes] armor = 2 equipment_slot = "offhand" resistances = [ # 2.5% resistance to physical types { damage_type = "piercing", percentage = 0.025 }, { damage_type = "slashing", percentage = 0.025 }, { damage_type = "crushing", percentage = 0.025 } ]

Along with this, I went ahead and changed how hit chance and max hit damage work. Your ability to hit an enemy is now less dependent on your skill level and more on your Attack stat, which is modified by your equipment/weapon. This means that more focus is put on your gear, (hopefully) pushing players to maintain and build it up in order to gain power. Additionally, I removed unnecessary complications like dodging and blocking. They might get added back in some form, but they weren't really adding anything to the core experience of combat. Of course, you can still have a shield equipped to maximize your Armor and gain some resistances.

Since I had new damage types to deal with and felt like doing some art, I worked on a few new equipment models and props. I even added some Brass Knuckles, which are pretty cool.

Not sure what's next, probably more combat stuff. But the holidays are coming up and that will certainly slow things down. Thanks for reading!

- Declan (@dooskington)

Fences and Walls

Fri, 14 Oct 2022 18:06:00 -0700

NOTE (2/12/2025)
NOTE! This post was originally written about a fork of Antorum that has since been merged back into the main project.

Something Antorum was missing was structures. Seems like that would be pretty important for a game in an urban setting, so I've started experimenting with some new editor features. I started with walls, to keep things simple. You can paint them onto the terrain with a new tool.

(video unsupported)

A wall mesh is built out of a few different individual pieces. The game uses these and creates mesh resources for all their possible orientations. Then, they are stitched together at runtime. To decide which piece to use, I sum up the neighboring walls that exist to get a sort of "neighbor score". Then, each potential score is mapped to the proper piece. It's a technique I learned from this cool Blob Tileset article on cr31.co.uk.

There are a few improvements I gotta make, mostly performance related. Every time you place a wall, the entire terrain chunk is rebuilt. So you definitely notice the slowdown when placing a ton of them. The other annoying thing is that transparent walls (like fences) have to be in a separate mesh from the opaque ones, due to sort order, materials, etc. Not sure I can really do anything about that, but I can at least make the two wall mega-meshes as lightweight as possible.

As far as structures go, roofs are the next important feature. I'll get to that soon enough, but will probably take a break and work on something else next.

- Declan (@dooskington)

2021 End-Of-Year Update

Wed, 08 Dec 2021 18:24:00 -0700

Another year has passed! It probably wasn't as productive for the game as it could have been, but honestly that is a sign that it's time to move on. So not to disappoint anybody, but that is kinda the main theme of this post - I think the game is done.

I've achieved just about every goal I set out for myself with this project, and learned so much in the process. I wanted to make a tiny mmo based on the games that inspired me as a kid, not for any commercial reasons (after all, making money in the indie mmo space is very tough and I work on this as a hobby), but for the fun of it. And it was fun! But now it's time to have some real fun, and apply the foundation I've built to a more interesting setting, supported by more unique game mechanics. I chose the extremely generic fantasy setting (Which I am not passionate about) because this was a prototype project where I wanted to focus and experiment with technology that I had only read about in textbooks and random articles. So the idea of working on a new world is pretty exciting to me.

There isn't a ton of content, but there is enough to keep players occupied for several hours (way longer, if you're into gathering, crafting, and fighting difficult bosses). All the main ideas of the game are expressed, and I think there is only one area of the game that is blatantly unfinished (the eastern isle). I could spend time adding more quests, monsters, items, etc. But like I said, I'm not passionate about this setting. It was never meant to be the game I spend years making content for.

I want to do a more in-depth retrospective at some point, but for now I'll just chill and collect those thoughts. Just know that I'm working on a new game, built off most of the same tech that I have been building and discussing here for several years now. There'll be a new development log page for it soon enough.

On Writing These Posts

I'm glad I started writing these posts. Crazy that I somehow managed to write 40 of them, although it's a shame I couldn't do it with a more consistent schedule.

I don't really know who reads them (some ~250 people a month according to analytics) and I don't get much traction or comments, but I don't boost the game or post about it much. Although, it was great to be featured a lot on the "This Month in Rust Gamedev" newsletters. These posts were always meant for my own accountability and records rather than for marketing, but maybe I'll take steps to change this for the next project. Multiplayer games aren't very fun if there isn't a community to play with. So, to those that have been reading, and to those who have joined the discord, thanks!

Minor Name Change

I changed the name of the game a tiny bit. It's now Antorum Isles (instead of Antorum Online). Yes it is an online game, but the scale of the game is small and I want the name to reflect that. The ideal scenario for the game in the future is to live on a small server that doesn't cost me much money. Players who don't want to join the official server can host their own servers for themselves and friends.

Editor and Dedicated Server

On that note, I'm going to publicly release the editor and the server software executables soon. It feels like a big step, and also kind of like a personal vulnerability. I didn't design it for others to use, and most things are not documented well. However, it will be good to do just in case somebody comes along and wants to tinker on it. I also don't want the game to permanently disappear with no chance of coming back if I ever decide to turn off the official server. It has always been a core tenet of the project to allow self-hosting and basic modding, even if I didn't end up making that a great experience.

Treasure Chests

I added treasure chests to the game to inspire and encourage players to explore more. There are a limited number that spawn every day, and once a player opens one, it can't be opened again by anybody else. These chests contain rare rewards that aren't available anywhere else in the game, along with vast riches. Hunt for these chests to claim the rewards!

Highscores

I finally got around to adding leaderboards to the Antorum website. I look forward to seeing them grow as more people try out the game. Not much else to say about that.

Other Stuff

Here's some other stuff that is worth mentioning.

Made game client downloads available on the Antorum website
Added player count and official server info to Antorum website
Added moving cloud shadows to make lighting and the world look a bit less static
Added two new quests
Added snowy peaks to the mountains in the world
Fixed bug where chat input was resizing while you typed
Fixed skill guide formatting
Fixed broken Steel Bar item texture
Fixed ritual window exp bar display
Fixed clientside item duplication glitch when equipping certain items
Modified fish node drop tables to be less unfair
Added a ritual that allows you to offer extra bones to gain Ritual exp
Added a new species of Crab to the world
Added a new species of Slime to the world
Improved discoverability of item durability
Pickaxes can no longer mine ore that is of a higher tier than the pickaxe itself

What Now?

The game isn't going anywhere! It just isn't going to get any more major new features or updates. I might add more content or modify things, but most of my attention will be on a new project.

Like I said I will try to keep it online always, because I love it, I'm proud of it, and I honestly think it is a fun (although quite generic) game. Even though I am not passionate about the fantasy setting, I really put my heart into the world of Antorum and I believe it's worth exploring - if not just to see my rough programmer art come to life.

Come on the Discord and chat with me! I'll be logging onto the game to play regularly, and I'll keep trying to gather others to do the same. It may be "done" but I still want as much feedback as possible so I can make the next game even better.

Play Antorum Isles

Antorum Isles is free to play and the server is now running! Check out the game homepage for info on how to download the game client and connect.

- Declan (@dooskington)

NOTE (2/12/2025)
At this point back in 2021, I forked Antorum. That fork, however, has since been merged back into Antorum somehow. With that in mind, know that the next few dev log entries were originally written about that fork. They are included here for posterity.

Mining

Sat, 25 Sep 2021 11:12:00 -0700

I avoided adding Mining to Antorum for a long time. I kinda wanted to expand the Salvaging skill instead, making a gathering profession around breaking down old machines and equipment as the only way to get metals. However I decided that didn't really fit the game setting, and traditional mining made more sense instead. I don't deny that Antorum is a pretty standard fantasy world, but that was kind of the point when I started this project out. Maybe I'll try something a bit spicier for the next game.

Mining works similarly to Fishing, and actually shares a lot of code which is nice. It was a good opportunity to refactor some resource node stuff in general and remove a bit of code duplication. I was also able to reuse the Cooking code for the furnace and ore smelting mechanics, which saved me a ton of time. Unfortunately I didn't get to implement any sort of mining animation just yet. I need to make some other fixes first before I can support something like that with the current character model.

Raw ore isn't too useful on its own, and you'll need to smelt it into bars first. I added a furnace to Belmart for that.

There's also a new Pickaxe shop in Belmart. So get out there and strike the earth!

Bacon + Bears

At the start of the week I made some polls in the Discord channel asking "Which food item should be added to the game next?" and "Which type of wildlife NPC should be added to the game next?". The winners of these polls were Bacon and Bears! I spent a bit time adding that stuff, and the bonus of adding Bacon is that the game now has Pigs.

Watch out for the bears next time you are out and about! I was killed mid-screenshot there.

Other Stuff

Playing the game with others this past week has been really fun but has also turned up a lot of issues, as expected. Here's a list of the fixes I made.

The `/all` command for global chat has been changed to `/shout`
Crafting and Ritual casting no longer require you have a Hammer or Scepter equipped. The tool can just be in your inventory
The player blip on the world map has been made more visible, and the map centers itself on it when opened
Item tooltips will refresh if the item changes while the tooltip is open (like after being repaired)
Crabs will now drop useful materials more often
Cultists will now drop useful materials more often
Skill guides have been tweaked
Some typos have been fixed
Maximum durability is now included on item tooltips
Durability is now colored on tooltips when low to make it more clear when equipment is broken
Improved the chat box, adding distinct tabs to help filter chat messages
Driftwood can no longer be equipped as a weapon
Added a small shortcut in Belmart and made other tiny changes
Added a level 10 fishing node in Belmart
Slimes are no longer aggressive
There should be less Chonkrat Alphas terrorizing the road at Lordling Lake

Play Antorum Online

Antorum Online is free to play and the server is now running! Check out the game homepage for info on how to download the game client and connect.

- Declan (@dooskington)

Audio Sources and Other Stuff

Mon, 20 Sep 2021 18:47:00 -0700

Something that's finally been implemented is audio sources. Now I'm able to place ambient sounds throughout the world, and the atmosphere has really improved because of it.

The server doesn't care about the audio sources, but they are synced to players as part of the clientside map data. The details are not super interesting.

Other Stuff

Back when I implemented rest as a health regeneration mechanic (see dev log 33), I didn't actually include a concept of rest zones. So, characters could rest anywhere in the world just by staying out of combat for a bit. It was convenient but really removed any tension the game had, so I fixed it. Now, zones for places like settlements can be marked as rest zones and the rest status effect will only occur in such a zone.

I've also just been polishing up the game client a lot. UI elements should look a little cleaner and more consistent, there are more sound effects and bits of feedback in various parts of the game, and some frustrating control issues have been resolved. I'm gonna keep tinkering on these small fixes as time goes on, and as player feedback comes in.

I merged the Armorcrafting and Weaponcrafting skills into one Gearcrafting skill. There was no real reason to keep them separated, and it just meant you had to grind two skills to get a whole set of good gear. I don't think anybody will miss the separation and this will streamline things a little bit. Related to this, you no longer need to have a hammer in your hands to begin crafting. It just needs to be in your inventory.

I did a small dev stream at twitch.tv/dooskington yesterday. I'm not much of a streamer but I'm looking to get the word out on the game a little more and try to grow a community for it. When I was younger I enjoyed watching game development streams and was inspired by them, so maybe somebody will find inspiration in seeing Antorum behind the scenes. Anyway, if you're interested in that sort of stuff, follow me so you get alerted next time I go live.

Play Antorum Online

Antorum Online is free to play and the server is now running! Check out the game homepage for info on how to download the game client and connect.

- Declan (@dooskington)

Item Enchantments

Tue, 07 Sep 2021 02:23:00 -0700

The Ritual skill has been a bit lackluster for a while now, and not as useful as it could be. So, I added item enchantments as a way to augment your gear in the mid to late game. They aren't accessible until the higher levels of the Ritual skill, and are expensive, but skilled casters can create enchantment scrolls for themselves or others to use on equipment.

Enchantments can modify stats or add flags just like spell effects. The particle effect is optional, and each enchantment can be specialized for weapons, armor, or both. The whole system relies heavily on the item property bag work I mentioned in the last dev log, as applying an enchantment to a weapon makes it unique from its base form.


rituals/fire-enchantment-scroll.toml
id = 11
name = "Scroll of Fire Enchantment"
description = "Imbue a blank scroll with a Fire Enchantment, to be applied to a weapon later."
input_item_res_names = ["fire-slime-glob", "flux-flower", "blank-scroll"]
input_item_quantities = [3, 1, 1]
req_skill_level = 40
icon_id = 30
skill_exp_reward = 200

[spell] type = "conjure_item" item_res_name = "fire-enchantment-scroll"


items/fire-enchantment-scroll.toml
id = 171
name = "Scroll of Fire Enchantment"
description = "A scroll imbued with the Fire enchantment. It can be applied to a weapon."
model_id = 299
is_stackable = false
value = 15

[[combos]] type = "event" event = { type = "apply_enchantment", enchantment_id = 0 } tgt_item_types = ["weapon"] consume_src_item = true


enchantments/fire.toml
id = 0
name = "Fire"
effect_id = 2
types = ["weapon"]

[[status_effects]] type = "modify_stat" stat = "damage" val = 5

For replication purposes, the client needs to know about the enchantment resources themselves. I tried to get away without doing this, but then I'd need to include way more data in the item property bag (enchantment name, description, effects, etc) instead of just one single enchantment id. So, they are included in the data cache now, and the client will download them when outdated. It's kind of annoying, but at least they can be updated quickly for all players.

I still need to design and add more enchantments, but the implementation is done and seems to be working well. I'm excited to get the update out to players. Speaking of which...

Play Antorum Online

The game needs more alpha testers! The servers are offline currently, but I'm planning on releasing a big update and opening them back up sometime this month. Click here to join the Discord server, where you'll be the first to know when and how you can connect. It would be great to get some more players involved to help shape the game.

Other

A random fun thing I did recently was add a waterfall to the map! There's actually two, if you know where to look. It needs particle effects but it's nice to see some water in the game that isn't just endless ocean. I've also been tinkering on new quests, but that's been a slow process due to the amount of writing required.

I'm hoping to get another dev log out soon. Thanks for reading.

- Declan (@dooskington)

Item Durability

Mon, 30 Aug 2021 20:06:00 -0700

I've been taking a pretty big break from Antorum this summer. I'm just trying to get some fresh air and sun and all that.

However, I did spend a bunch of time making modifications to the item system. An individual item can now have a "property bag", which is a JSON object thats persisted in the database and modifiable by any system in the game. This is extremely useful for any data that is specific to the instance of a single item, and not exactly relevant to the item resource itself. The first important use of this feature is in the new item durability system.

All equipment items now have a durability, and degrade as they are used in combat. The overall effectiveness of an item is affected by this durability value, so equipment that is broken will be basically useless. You can repair items with Repair Kits, available at any general goods trader. They are kind of the opposite of Salvage Kits. I also added tooltips to inventory items to make info like damage, armor, durability, etc, more visible.

Aside from that, there are a few aspects of the game experience that have improved a bit. The user interface works better, a few bugs have been fixed, and the world map is now accessible anywhere at any time. Previously, you needed the Map item to view it. I realized though that this just hides important info and discourages exploration for new players. I'll be making more improvements in this space as time goes on - maybe some fog of war or treasure maps that can augment the main map.

- Declan (@dooskington)

Lua Scripting

Mon, 31 May 2021 22:09:00 -0700

There's a bunch of new stuff in the works for Antorum. The biggest thing is probably Lua Scripting.

To test and prove out the scripting system, I built the tutorial for the game, or at least the first iteration of it. It's been helpful to feel out any requirements for the scripting system, as well as get a bunch of basic script endpoints set up so that other quests down the line can take advantage of them for interesting scenarios.

I used the rlua crate for the Lua implementation. I don't love Lua as a scripting language, but I wanted to integrate something that was simple to write, and well-known. I'll probably switch it up next time I do something like this for a game.

Dialog Scripts

Dialog trees now support Script nodes, allowing the execution of scripts based on dialog option choice (or just by talking to an NPC). This is how quests are started - dialog nodes trigger scripts which mutate the players quest stages or flags.


asmabius.toml
// ... other dialog nodes ...
[[nodes]]
type = "Script"
id = 140
script = """
player_ent_id = Context:player_ent_id()
quest_res_id = 0
    -- Clear player inventory and equipment but give them a map
    inventory_clear(player_ent_id)
    equipment_clear(player_ent_id)
    add_item(player_ent_id, "map-of-antorum", 1)

    set_quest_stage(player_ent_id, quest_res_id, 30)
"""
next_node_id = 123

Information about the game world is passed to these scripts via context objects. Different contexts (Like Dialog, Entity Spawn, Entity Killed by another entity, etc) contain different information about each event and the Entities involved in it. The lua scripts are essentially just callback functions, with the arguments being passed in this context object.

Entity Scripts

Scripts can also be directly embedded on an Entity, allowing execution based on various events. Here's an example of a script on the Tutorial Chonkrat NPC, which executes when a player tries to interact with it. In this case, it's meant to keep players from attacking the NPC before they have begun the Combat portion of the tutorial.


npc-tutorial-chonkrat.toml
on_interaction_requested_lua = """
if OnInteractionRequestedContext:interaction_type() ~= "attack" then
return
end
player_ent_id = OnInteractionRequestedContext:player_ent_id()

if not get_quest_flag(player_ent_id, "tutorial-lesson-combat-started") then
    send_chat_message(player_ent_id, "You haven't started the Combat lesson yet. Speak to Asmabius first.")
    cancel_interaction(player_ent_id)
    return
end

tutorial_quest_res_id = 0
tutorial_quest_stage = get_quest_stage(player_ent_id, tutorial_quest_res_id)

if get_quest_flag(player_ent_id, "tutorial-lesson-combat-finished") or tutorial_quest_stage == 14 then
    send_chat_message(player_ent_id, "You already killed a Chonkrat for Galus. Best leave them alone.")
    cancel_interaction(player_ent_id)
    return
end

if tutorial_quest_stage ~= 13 then
    send_chat_message(player_ent_id, "You should speak with Galus before trying to fight a Chonkrat.")
    cancel_interaction(player_ent_id)
    return
end

"""

Music

There are three new music tracks in the game, by Electric Dad! He also made all the other tracks that have been added so far. Check out his Soundcloud and Spotify.

Other

Here's some of the other stuff that's been done recently. The changes are mostly based on alpha player feedback. This month has been kind of slow though, so there's not a lot else to report.

Added a second chat box, for "system" messages
Added a global chat channel (/all )
Added more combat messages for things like blocks and dodges
Logging into an account that is already logged in will now kick the already logged in client

- Declan (@dooskington)

Poison and Resting

Tue, 27 Apr 2021 23:15:00 -0700

I've been chipping away at more content and bugfixes for the game. Not a lot of screenshots to share, so this will be a quick update.

Poison

In the codebase, the functionality is called "Poison", but it basically just refers to any spell effect that deals damage over time.

Spiders now have a venomous bite, and being inflicted will "poison" you, dealing damage over time. You can fix this by consuming some form of Antidote. I also tweaked a few other monsters on the Isle to inflict various debuffs.

Hopefully this makes combat a bit more interesting. The mechanics behind it have stayed the same for a long time now. Tip: You can make Antidote Buns yourself by cooking Deadcap mushrooms and Dough together.

Resting

Resting is the opposite of Poison. Players that are now out of combat for a little while will gain the Resting effect, and slowly start regenerating health. I added this because it was annoying to have to go cook food to heal after every little combat encounter.

After initial player feedback though, it is a little overpowered in the current form. I need to do another pass on the feature, so I'll be writing about that some time soon.

New Belmart

I revamped Belmart, it's pretty spacious and has a bit more going on now. I'll be adding even more stuff to it soon.

This has actually been in progress for 2 months, but I just recently wrapped up the work.

Metrics

This was a really fun thing to work on. Instead of doing LD48 this past weekend, I did a little rat wizard dev-ops jam.

This is a Grafana dashboard, reading game server metrics collected by Prometheus. I spent a ton of time figuring out docker to get these set up locally, but after some initial frustrations it was surprisingly straight-forward to get the entire thing working. I've never worked with a time-series database before, so my dashboard is lacking, and I'm still figuring out the best metrics to display and the best ways to display them. All of my past experience is with event databases and more SQL-like query languages, so learning PromQL has been interesting.

I'm using the prometheus crate, which is really cool. It makes it pretty simple to collect metrics, such as the timing of certain game systems:


// Database Sync
let metric_timer = metrics::METRIC_DB_SYNC_HISTOGRAM.start_timer();
db_sync_dispatcher.dispatch(&world);
metric_timer.observe_duration();

// Network Sync let metric_timer = metrics::METRIC_NET_SYNC_HISTOGRAM.start_timer(); network_sync_dispatcher.dispatch(&world); metric_timer.observe_duration();

I'll keep working on these as time goes on and as I collect more useful metrics. I'm just glad to finally have the infrastructure taken care of, and so far it's been working well, even on the official (and remotely hosted) game server. Speaking of which...

Play Antorum Online

I'm sneaking this in here. You can actually join the discord, download, and play the game now! I've been running another alpha test with a limited number of players, and it would be cool to add some more. Click here to join the Discord server, where you'll find download links. If you have been reading these dev logs, now is your chance to get involved as a player and help shape the game.

As a quick disclaimer though, the game is still far from done. There is no tutorial to help you out, so be aware that you will probably be a bit clueless. That's what the discord is for though, I guess.

Other

Implemented an '/add-effect' admin command for testing spell effects
Implemented support for consumables clearing a specified spell effect
Added some new NPCs to fight around Antorum
The Ritual skill guide now displays a list of Rituals that can be performed
All scroll bars in the user interface should scroll much faster now
Added a new gear set and weapon, craftable from spider parts
Changed the combat, defense, and HP of all NPCs in an effort to re-balance the game
Implemented option for certain spell effects to not persist on player logout
Added experience bars to crafting, ritual, and cooking windows (instead of only being visible in the skill guide window)
Signposts can now actually be read
All NPCs now have more complete and interesting dialog trees

- Declan (@dooskington)

World Map and More Content

Tue, 13 Apr 2021 02:47:00 -0700

I'm still working on new additions and fixes to support the next alpha test, which I am hoping to start up in May.

Map of Antorum

I added a map item to the game. Each new character is given one for free.

It is pretty basic, and doesn't even show where the player is. You'll need to use your surroundings, compass, and map to get your bearings. As part of this work, I added the ability to render blips for services in the world - so things like the vault, a trader, or even a cooking station should not be as difficult to find. I added a new tool to the editor to help with the placement of such blips.

Robes and other new items

I added a bunch of robes, in various colors. Some of them require a specific Ritual level to be equipped. Here is a small subset of them.

There are also a bunch of other new items, like pizza. Yeah, you can cook pizza now. I'm pretty happy about it.

Support for Move Speed Bonuses

It used to be dubious to modify the movement speed of an entity at runtime, because all the clients would fall out of sync and use the old movement speed until they got a fresh state update. I finally got around to fixing this by requesting a movement state sync whenever a MovementComponent gets an updated speed. To take advantage of this fix, I added a new Ritual that gives a 10% move speed bonus for 30 minutes.

Bulky & Tall Characters

To help add some visual variety, I added support for "bulk" and "height" in player and non-player characters.

Your browser does not support the video tag.

Like with other customization options, NPCs can be set up to get a randomized bulk and height when they spawn. As a player you'll be able to tweak these values during character creation.

Other

Entity selection should no longer happen through the terrain
Teleporting while moving should now properly cancel the movement
Players will no longer get full experience points for performing an activity which they have out-leveled
Pathfinding should properly respect and handle diagonal tiles once again
Skells will now drop iron gear much less often, and will drop ruined gear instead
Added a new tier of salvage kit which has a lower chance of breaking
Added some danger signs around the isle to warn players of... danger, I guess
Refined some more terrain textures to eliminate the "tiled" terrain look used throughout development
Corpsefish can now be cooked
Examining an item with zero attributes will no longer send an empty chat message
All other players will now see the particle effect that occurs when you level a skill up
Added a particle effect that occurs when you cast a ritual
Bones now drop when a player dies, as they already did with NPCs

- Declan (@dooskington)

Status Update

Wed, 31 Mar 2021 18:30:00 -0700

There's so much new stuff in the game, I'm starting to lose track of it all. So, I guess it's time to make another dev log. This one will be pretty speedy. These days I'd rather use the writing time to just work on the game itself. Thanks for reading.

An important thing that happened recently was a tiny friends and family alpha test! There were around 10 players, and the server was running for about a week or so. The peak number of concurrent players was 8, which was awesome until the server crashed due to a code defect in the bartering system... Luckily that was the only serious issue, and I got a ton of valuable feedback. The development focus now is just to address all of it.

Rituals

The coolest new addition is the Ritual skill.

Players can now use monster parts and other reagents to cast rituals on themselves or other players. These are mostly for support, doing things like increasing damage and armor, or giving a bonus for another skill. In my opinion though, the best rituals are the ones that teleport you to other places.

To cast a ritual, players must use a Ritual Altar, of which there are a few around the map. They'll also need a Scepter. The idea is that players will cast some rituals (or pay for the services of a more experienced caster) before venturing out to more dangerous areas.

The Grove

All the art for this zone took a while to get done, but I think the result is the most visually unique place in the game. I was playing Dark Souls while working on it earlier this year, so it's pretty inspired by Darkroot Garden.

The Derelict Weald

This is a zone that I threw together pretty quickly. It's mostly a big rework of the existing spider zone, and includes some ruins, dead trees, and a bunch of webs.

Improved Interaction Menu

It was annoying and difficult to interact with objects that were in close proximity to each other. That should hopefully be fixed up a bit now.

Your browser does not support the video tag.

Other

Implemented ability to zoom the camera
A few experience points are now awarded even if you burn a dish while cooking
The cooking interface has been improved and now supports queuing up a recipe many times
There is now a "Deposit All" button in the bank
Added an "/announce" admin command
Implemented an AFK timer for players
Implemented a periodic world save on the server
Implemented spell/status effects
Refactored some client/server world syncing to support in-game teleportation
Implemented ability to move items in inventory/bank
Implemented ability to click on minimap to move
Your class is now visible to other players
Added some basic fishing sound effects
Implemented map blips for services like traders, banks, etc.

- Declan (@dooskington)

Crafting and Salvaging

Sun, 21 Feb 2021 13:51:00 -0700

I've been working hard to add new skills and activities for players in Antorum Online. There have been three new skills added to the game: Armorcrafting, Weaponcrafting, and Salvaging.

Armorcrafting

Armorcrafting is pretty self explanatory - it's a skill that allows players to craft armor!

Your browser does not support the video tag.

First equip a Hammer (purchased from a trader), then interact with an Armorcrafting Anvil. There are only a few armor sets at the moment (including the new Crab Shell set) but I'll be adding more soon.

Weaponcrafting

Players can also craft weapons with the Weaponcrafting skill! I added a few new weapons for this, one of them requiring a rare monster part from a certain beast in Antorum. I hope to add more items like this soon.

Your browser does not support the video tag.

I separated armor and weapon crafting so that players could specialize in one or the other and get certain rewards down the line. This is kind of the direction I want to take the game - when I play an RPG, I don't really like it when your character can be an expert at everything. I'll be making changes to the skill and stat system in the future to emphasize this, and encourage specialization.

Salvaging

Salvaging is another new skill. It allows you to use Salvage Kits to break other items down into raw materials for crafting. A higher Salvaging level allows players to use better kits, as well as the ability to break down more powerful weapons and armor. Pick up some Salvage Kits from your local trader and get scrapping!

Your browser does not support the video tag.

I added some more hostile NPCs around the map so players can actually loot items to salvage. Beware the tiny blue men!

Other

I got a bunch of other random stuff done too, including some critical bug fixes. The game feels a bit more solid these days.

Added an in-game bug report / feedback tool for players
Added a "Latest News" box to the main menu which is populated by the server
Players will no longer aggro NPCs if the NPC has no path to them, or would have too complex of a path
NPCs will no longer chose a wander destination that would require too complex of a path
NPCs in combat will no longer get stuck after being dragged away from their designated wander area
Added a few Roving Traders around the map
Added a few more campfires around the map
Tweaked some existing terrain, added more trees, etc
Added a clientside particle effect that triggers when you level up a skill
Combat will now choose the closest tile position for the attacker to stand in, instead of a random one
Tweaked some NPC drop tables and stats for balance purposes
Reduced the range at which you can see chat messages from other players
Fixed bug in entity region system that sometimes resulted in duplicated or missing network entities
Fixed bug with clientside movement interpolation that sometimes teleported players back to an old position
Fixed bug that allowed players to walk onto non-walkable tiles with certain slopes and get stuck there
Fixed bug with clientside connection retry where the socket was not properly closed, resulting in an extra connect call to the server
Modified skill guide to show recipes and other helpful tips for each skill
Changed shading of a few meshes from flat to smooth
Implemented basic admin permissions and commands (/add-item, /add-exp, etc)
Added particle effect and light to campfire model

This was a fun update to work on. Now that these new skills are "done" I'll eventually revisit the (pretty old now) Cooking skill to make it work similarly to Armorcrafting/Weaponcrafting, since they are less buggy, more usable systems. Aside from that, I'll be releasing another content-centric dev log before the end of this month, showing off my new favorite area in the game.

- Declan (@dooskington)

Item Combinations

Sun, 31 Jan 2021 13:28:00 -0700

This month, I finally got around to implementing item combinations. It wasn't that large of an addition, but was required for some crafting stuff I have planned. Down the line, it will also be useful for quests.

To define a combination between two items, you add an entry to combos in an items definition file. Here is an example of a combo for the egg item:


[[combos]]
type = "combine"
tgt_item_res_name = "bowl"
output_item_res_name = "raw-scrambled-eggs"
output_message = "You crack the egg into the bowl and stir it up."

The type parameter isn't important now, but you can use "event" to configure a combination that triggers a game event in the case that something special needs to happen (other than just making a new item). I'll talk about that more in a future post.

I had fun adding some new items (mostly cooking ingredients) to take advantage of that system. Here's a video of my character making dough with water + flour, then baking some bread:

Your browser does not support the video tag.

There are still some issues. For example, why is the bowl consumed when you pour water out of it? Also, I'm not sure it makes sense to be able to bake a loaf of bread over an open fire.

New Packets


/// 72 - 0x48 - Inventory Item Combine Request
/// Client
InventoryItemCombineRequestPacket {
    source_item_slot: u8,
    target_item_slot: u8,
}

Skill Requirements for Equipment

You can now specify skill_requirements on any equipment item:


name = "Chef's Toque"
description = "The official hat of a Chef."
types = ["armor"]
model_id = 78
is_stackable = false
value = 80

[attributes] armor = 0 equipment_slot = "head" skill_requirements = [{ skill = "cooking", lvl = 20}]

It's pretty self-explanatory. If you don't have the required levels in the required skills, you won't be able to equip the item. Not much else to talk about now. Next month, I hope to finish up more crafting related stuff.

- Declan (@dooskington)

Banking

Tue, 12 Jan 2021 22:22:00 -0700

I've been working on banking for about a month now. It was supposed to be a simple feature, but as I got started I realized that the inventory required a few fixes to support it. I mentioned some of those fixes a bit in the last dev log, so I won't really cover them here.

The Vaults

The Vaults of Antorum have been opened, allowing players to bank their materials, equipment, and coins in a safe place!

Each vault connects to the others via a complex arcane network, which can be accessed and manipulated by a Vaultmage NPC. They can be found in every settlement on the Isle.

Your browser does not support the video tag.

At the moment, you can hold 100 item stacks in the vault, and the maximum stack size of banked items is in the thousands. Even non-stackable items will stack inside the vault. Hopefully this makes things like fishing trips less painful, as you can store your combat gear somewhere safe and make use of your entire inventory for fish.

New Packets


/// 65 - 0x41 - Bank Inventory Open
/// Server
BankInventoryOpenPacket {
    // (slot, resource_id, quantity)
    items: Vec<(u8, i64, u16)>,
    bank_size: u8,
}
/// 66 - 0x42 - Bank Inventory Close
/// Server
BankInventoryClosePacket {};
/// 67 - 0x43 - Bank Inventory Deposit Request
/// Client
BankInventoryDepositRequestPacket {
src_inventory_slot: u8,
quantity: u16,
}
/// 68 - 0x44 - Bank Inventory Deposit
/// Server
BankInventoryDepositPacket {
// (src_inventory_slot, dest_bank_slot, quantity)
deposited: Vec<(u8, u8, u16)>,
}
/// 69 - 0x45 - Bank Inventory Withdraw Request
/// Client
BankInventoryWithdrawRequestPacket {
src_bank_slot: u8,
quantity: u16,
}
/// 70 - 0x46 - Bank Inventory Withdraw
/// Server
BankInventoryWithdrawPacket {
src_bank_slot: u8,
quantity: u16,
}

/// 71 - 0x47 - Bank Inventory Close Request /// Client BankInventoryCloseRequestPacket {}

Side note, it was a big mistake choosing to use 16 bit fields for all item quantities at the start of this project. I have no idea why I did that - right now the maximum amount of an item you can hold is 65,535. That means you can't stockpile many coins, which sucks. I'll get around to changing the types to something more sane, but it is a pain to go and update it everywhere in both the client and server codebases (and I'm procrastinating).

Player Item Drops

Since you can store your items now, it's only fair that I get to turn up the difficulty in some way. Upon death, players will now drop all of their items and equipment.

Your browser does not support the video tag.

This might force me to re-balance some areas and equipment, but it's alright.

Other

Decreased inventory size to 16 slots
Added Shopkeeper's Apron item
Added Chef's Apron item
Quantity input menu should now do it's best to stay on-screen when opened
Moved inventory code out of the item module and into it's own module
Entities now inherit rotation and scale from their spawners

Not much else to report. The next thing I do will probably be bug fixes. I'm also (very slowly) building another new area, with new enemies, items, etc.

- Declan (@dooskington)

The Big 2020 End-of-Year Update

Wed, 30 Dec 2020 22:51:00 -0700

This month has been super productive for the game, just because of the holidays. It's not like I'm traveling anywhere this year during my time off work. I finally managed to implement a client-side item cache (same idea as the world cache), as well as make the biggest content update that the game has seen so far. I also dusted off some unannounced stuff that I'm ready to talk about. Overall, I feel like this is a big update to end the year with. Here's an overview of what I got done.

Dialog

The main attraction of this update is Dialog. Players can now talk to NPCs!

Your browser does not support the video tag.

Turns out, writing dialog lines is a lot of work and the month didn't have too much time left once I was done with all the code. I'll be adding more as time goes on, but for now there are only a handful of NPCs to talk to. The system is fairly simple, in that dialog cannot effect anything else. Ideally, I'd like to be able to script tiny sequences so that dialog can do things like grant the player items, open user interface windows, and eventually, mutate quest state.

Dialogs are defined in .toml files. Here is a segment of one:


entry_node_id = 0
[[nodes]]
type = "Lines"
id = 0
text = ["Hail, Traveller. Keeping your nose out of trouble?"]
next_node_id = 1
[[nodes]]
type = "Responses"
id = 1
[[nodes.options]]
text = "Where am I?"
next_node_id = 2
[[nodes.options]]
text = "Where can I purchase supplies?"
next_node_id = 4
[[nodes.options]]
text = "Goodbye."
next_node_id = -1
[[nodes]]
type = "Lines"
id = 2
text = ["You are in Belmart. It's a fishing town and trade hub."]
next_node_id = 3

...more nodes

This whole system is networked via three tiny packets. After all, it's just text being sent one direction, and response selections being sent the other.


/// 58 - 0x3A - Dialog
/// Server
DialogPacket {
    pub ent_net_id: u64,
    pub lines: Vec,
    pub response_options: Vec,
}


/// 59 - 0x3B - Dialog Option Request
/// Client
DialogOptionRequestPacket {
    pub option_idx: u8,
}


/// 60 - 0x3C - End Dialog
/// Server
DialogEndPacket;

NPCs that are in a conversation won't "squak" random sayings, and they won't wander around. They also cannot be attacked. I figured it would be annoying to have NPCs get killed by other players while you were talking to them. To compliment this, players also can't start a conversation with an NPC that is in combat.

I like how NPCs actually move and turn to face you when you talk to them. That is a pretty concise bit of code from the DialogSystem, so I can share it here:


// ... handle dialog and determine 'lines' and 'response_options'
let packet = DialogPacket {
ent_net_id: tgt_ent_net_id,
lines,
response_options,
};
pckt_events.send(PacketPlayerRecipient::Player(player.id), packet);
// Make the target entity move to the center of their occupied tile, as well as face the player.
let (target_conversation_position, target_conversation_rotation) = {
let src_transform = transforms.get(*src_ent).unwrap();
let tgt_transform = transforms.get(*tgt_ent).unwrap();
let tgt_tile = map::world_coords_to_tile_coords(&tgt_transform.position);

let tgt_tile_center_pos = map::tile_coords_to_world_coords(&tgt_tile)
        + Vector2f::new(TILE_SIZE / 2.0, TILE_SIZE / 2.0);

let dir = (src_transform.position - tgt_tile_center_pos).normalize();
let rot = Point3f::new(0.0, f32::atan2(dir[0], dir[1]).to_degrees(), 0.0);

(tgt_tile_center_pos, rot)

};

move_events.single_write(MoveEvent { src_ent: *tgt_ent, destination: target_conversation_position, final_rotation: Some(target_conversation_rotation), start_tick: ticks.0, should_end_combat: true, })

Client-side Item Cache

So far, each time I added an item, I also needed to update a file on the client so there was some client-side knowledge of it. This was a massive pain, and kept me from adding new items regularly. I'm happy to say this is no longer the case, and I finally got around to giving items the same treatment that the world/terrain got. They are now downloaded by the client when outdated, so any changes to the item database are propagated to all players automatically.

The coolest bit about this is the item icons. Now, after being downloaded, the item cache has all item icons automatically generated. This all works pretty much the same way as the minimap tile rendering does.

There is plenty of room for improvement. I'd like to add some outlines to the items (or maybe drop shadows, like items had in Morrowind?), and the render camera needs to adjust its size based on the bounds of the item model. You can probably see that item 21 (Cooked Blue Skipper) is looking a bit too tiny in its item icon.

Better Inventory

The inventory is feeling much better these days. Now you can actually drop more than one item at a time, through the use of the handy dandy new right-click menu. You can also left click to quickly equip/unequip, eat, or interact with items.

Your browser does not support the video tag.

I don't love working on user interface elements. This particular one was a gauntlet of bug fixes and edge cases, and then all the interactions had to be properly sent to the server. I'm glad to be done with this, I spent a lot of time making sure it was actually usable and I hope I don't have to touch it for a while.

Better Dropped Items

This is a simple but cool fix. When dropped on the ground, equipment items didn't really look right, because their models were meant to be placed on a characters body. However, it is now possible to specify an model id override for when an item is dropped on the ground.

Along with this, all item hitboxes were improved. No more pixel-hunting to pick up items!

Better Bartering

A lot of the inventory improvements that I just talked about also applied to the barter window. However, an added bonus here is that you can now sell all of a certain item in bulk, even if that item isn't stackable. This makes shop trips much less tedious.

This whole menu still needs work to look nicer, but that's low on my priority list.

Better Minimap Quality

I mentioned the blurry minimap in the last dev log. Turns out, I was accidentally saving the minimap tiles at a much lower resolution than they were originally rendered. So, they looked great on the first run of the game, but subsequent runs were loading up the low quality versions of each tile. I fixed that up pretty quickly, and we are back in business:

Better Main Menu and Options Menu

The main menu has gotten some love, and I also added an options menu!

You may have already noticed all the cool new post-processing effects in the game - I got a little carried away. Then I realized that if the effects were in the game, you needed to be able to turn them off. So, I got sidetracked for a while ironing out this menu. It is also accessible in-game.

Not pictured here is the resource download screen, which also shows a view of any in-progress item/minimap rendering.

More Fish, More Plants

I added a few new fish, junk fishing items, and plants to the world. Here are some of them:

Along with the new fish are a few new cooking recipes.

More Equipment

I also added some new armor sets and weapons. Here's a small preview of some of those items:

Some can be purchased at shops, while others are only dropped from certain NPCs.

The Graveyard

This is the part I am most excited about. I spent a long time designing and building this zone, and it is the most challenging one in the game yet. Actually, I'm not even sure it can even be explored very easily (alone, at least) with any currently accessible gear. My bad, I have a lot of balance work to do in general.

Here, players will find new plants to forage, monsters to fight, and loot to acquire. There may even be a new hidden and rare fishing spot...

My favorite part of this zone is the new boss:

The scythe is a rare drop, and currently the best weapon in the game. If you are one of the very few people who are playing the game, and are looking for a challenge, head out of Belmart via the North road. Follow the road past the woodlands, then at the fork, go left. You'll probably want to try and purchase some iron armor, and stock up on food, before you make the quest.

Music and Audio

Some things are stirring in this area. Hope to have more updates soon.

Other

Fixed server crash when a player tried to chat on the same tick that they respawned
Fixed many bugs with inventory item dragging
Added more messages from server to alert player when they have done something unsupported or wrong (such as trying to move to an incorrect destination)
Added more colors to chat user interface to make it more clear when players are chatting
Added over ten new entities
Added over twenty new items
Added two new undisclosed bosses to the world

I know I said I would announce a playable alpha before the end of the year, but the game still isn't ready. I've shared it with a few friends though, and I'm trying to incorporate as much feedback as I can while still completing new game features.

In total, all this content required that I make over 60 new 3D models, so I really have been getting a lot of art practice in. I also realized an early mistake I had made in my pipeline over the year, and had to go back and update 90 models by hand to be compatible again. Despite my best efforts, it is still hard to keep track of every little thing I change in the game. So, I probably haven't captured everything here. I really wanted to finish up Banking this month, but it didn't make the cut - I think that will be the first thing I post about in 2021. Thanks for reading this year. Here's to another one!

- Declan (@dooskington)

Various Improvements

Sat, 12 Dec 2020 22:13:00 -0700

Here's an overview of some of the random improvements I've been working on recently. This stuff didn't really add any new gameplay, but a few features were polished and improved.

Minimap Blips

A long time ago I probably mentioned that the minimap was unfinished, missing blips for players and other entities. I finally took some steps to correct that. Check out this blurry image:

The white dots are players, yellow dots are NPCs, and red dots are items.

I haven't figured out how to fix the weird artifacts on chunk boundaries yet. The minimap tile sprites are not properly snapping to each other, and leave behind those visible seams. Maybe it's some texture filtering issue. I can render the tiles out at a much higher resolution, but I'm avoiding it right now just to keep the game booting up quickly.

As far as I can tell, there is only one task left for the complete minimap implementation, and that would be blips for points of interest (shops, bank, quests, etc). I'll get to it in the future, it doesn't seem too important right now.

Aggro & Combat Indicators

Another cool new thing in the game is aggressive NPCs. I added an AggroComponent which, when added to a combat capable entity, will cause that entity to attack players that wander too close. The entire aggro.rs file itself is less than 100 lines, which is cool. To contrast that, cooking.rs is over 1000 lines. Here's an abridged version of what the meat of the AggroSystem looks like:


for (ent, aggro, combat) in (&ents, &mut aggros, &combats).join() {
    // Only check this stuff on an interval
    if aggro.range_check_tick_counter < aggro.range_check_tick_counter_target {
        aggro.range_check_tick_counter += 1;
        continue;
    }
aggro.range_check_tick_counter = 0;

if combat.is_in_combat() {
    continue;
}

let (position, chunk_coords) = {
    // ...
};

let set: BitSet = entities_in_region(chunk_coords);
for (_, tgt_ent, tgt_transform) in (&set, &ents, &transforms).join()
{
    let distance = distance(&tgt_transform.position, &position);
    if distance < aggro.range {
        println!(
            "[AggroSystem] Ent {} entered the aggro range of ent {}",
            tgt_ent.id(),
            ent.id()
        );

        attack_events.single_write(AttackEvent {
            src_ent: tgt_ent,
            target_ent: ent,
        });
    }
}

}

I kind of expected this to cause performance issues, simply due to all the distance checking between NPCs and Players. However, the range checking is staggered and not performed every tick. Also, entities are split into regions and only a single region is checked, so it all seems to be working well. As with everything else in this project, I'll worry about it if it ever actually becomes an issue.

The next thing I added is red circles around NPCs that you are in combat with. This makes it a bit easier to see what is going on, considering there are no real combat animations or other indicators.

Your browser does not support the video tag.

Movement, Rotation

Since the beginning, server-side entities in Antorum have had no concept of rotation. I managed to make this work on the client by just predicting everyones look rotation based on their movement. It was never perfect, and then it started failing entirely once I started adding interactable entities like forage nodes (since I wanted to make players face them while interacting). Then, there was the problem of desync across clients. So I quit messing around and just added entity rotations to the protocol and database schema. Now, if you turn one direction and log out, your character will still be looking that direction when you log in. Clients should also stay synced now in terms of which direction a player is facing.

Other

Tweaked the UI to look a bit nicer (drop shadows, better font sizing)
While open, the skill guide window now keeps skill levels and exp properly updated
UI windows no longer block the mouse when dragging to rotate the player camera
Fishing lines no longer become detached from their poles when the player moves
Fishing rod item now has a hitbox again
Tweaked interaction position calcs to avoid players standing on top of NPC shopkeepers
All starter weapons and armor items have been made more valuable
All starter resource items have been made less valuable
Added more client-side error messages for things like an invalid movement or interaction
Added a comment section to these dev logs

Gonna take a little break and then get back to work. I've got something more interesting in progress for the end of this month.

- Declan (@dooskington)

Zones

Thu, 26 Nov 2020 15:28:00 -0700

Something new this month is Zones! The map can be split up into distinct named areas, like in pretty much every open world game I have ever played. Here is a (2x speed) video of me crossing into a zone, and then into a sub-zone.

Your browser does not support the video tag.

The Dead Valley is a mountain pass that I felt like decorating with dead trees and other forest detritus. It is still in early stages and doesn't look dreary enough, but I'll come back later and improve it when the time is right. I tucked a brigand camp in there to hamper players from taking the pass if they are unprepared but since I haven't implemented aggressive NPCs, it doesn't matter much right now.

Zone Tool

Zones are defined in the editor with a new tool, which features an interface window to add, delete, and edit zones. Zones can have a parent, making them a sub-zone, which slightly modifies the zone change notification for players, as shown in the above video. The "color" of a zone means nothing in gameplay terms - it is just available so you can tweak the zone overlay color.

For now, zones just serve as some flavor while exploring, as well as to help players navigate the growing world. In the far future, zones will be responsible for things such as ambient and background music, color grading, and maybe other visual features like fog.

Minimap Tile Stitching

Another cool thing I finally got around to doing was writing the code to stitch together minimap tiles into a single map image. I waited a while to do this because it just wasn't important, but now it's super helpful to see the entire island from above. It will be useful for content planning, zone layout, and terrain design.

Most of the east side of the map is unfinished, and the "finished" areas lack distinction from one another. I've got a lot of work ahead to add variety and interesting stuff to the world. On top of that, I need to add new NPCs (both friendly and hostile), plants, fish, cooking recipes, and other unanncounced bits and bobs.

It's awesome to finally be able to name areas, and really makes me reflect on how far this project has come. What started as a technical experiment & Rust learning project has grown into some sort of an actual game, and now I'm too attached to move on to anything else. I still don't know when it is going to be playable by others, but I'm thankful to the few readers and project followers who share support, so I'm working hard to let folks play. Thanks again for reading.

- Declan (@dooskington)

Fishing

Wed, 25 Nov 2020 17:48:00 -0700

The Fishing skill brings a new foraging opportunity to the Isle, allowing players to kick back and cast a line out into Antorum's vast waters. The lakes, streams, and surrounding oceans are now home to a variety of fish, just waiting to be caught, thrown on a skillet, and made into a fine meal.

"Fish Nodes" are essentially just forage nodes that have a drop table instead of just a single output item, so there isn't much to talk about on the technical side. They also have some unique spawn rules to prevent too many nodes from existing in an area, but I'm still unsure if that functionality is final. In the future I need to do another pass over this stuff to consolidate the forage node spawning logic and get rid of some duplicated code.

Unlike when harvesting forage nodes with the Herbology skill, a Fishing Rod is required to fish. You can pick one up at any general store on the Isle. Speaking of forage nodes, I needed an art break, so I also added a few new things to be harvested in the world.

I'm on vacation and don't want to write much, so that's all I'm gonna say for now. I'm looking forward to adding more fish and fishing gear in the future. For now, I've got to move on to other features.

- Declan (@dooskington)

Herbology

Mon, 02 Nov 2020 23:10:00 -0700

The Herbology skill allows players to take advantage of the wide array of fauna growing on the island. Ingredients can now be harvested and used for things like potions, cooking, or just to be sold for a quick coin or two.

"Forage Nodes" pretty much work identically to how item spawners work. An forage node spawner entity is placed in the editor, and the desired forage node entity is specified as an option. Here's an example of the lettuce-forage-node entity definition:


id = 25

[networked] [transform] [info] name = "Lettuce" model_id = 65 description = "There is some Lettuce growing there." [interactable] interactions = ["forage", "walk-to", "examine"] [forage_node] item_res_name = "lettuce" skill_exp_award = 3

Once a forage node is harvested, it will respawn after some random delay (which can also be tweaked). For now I've added a handful of improved variants of recipes requiring the use of harvested herbs/plants, as well as some new recipes (like scrambled eggs). I'm looking forward to adding more, but items are time consuming to work on. Most of the time spent on this stuff was just in the new art assets alone.

There isn't a ton else to talk about - after procrastinating for a month on implementing this skill, it turned out to be pretty easy to get "done". Some other boring stuff I did was improve hitboxes on entities (so mouse selection is less frustrating), tinker with always-visible nameplates on NPCs (I didn't like this and reverted it), add Chickens, and modify some NPC drop tables.

The next thing I work on will be the Fishing skill, but I've got a long list of random junk to finish during this month so I'll probably be taking detours.

- Declan (@dooskington)

Character Creation and Customization

Thu, 29 Oct 2020 19:27:00 -0700

Something I have been sitting on for a while is character creation and customization. This feature took a good bit of time, as it required changes to the database schema, login flow, and clientside player replication. I also had to make a bunch of 3d models for hair styles, beards, etc. Everything is still pretty rough, but at least now there is some variety in characters on the island.

Included in these changes are a slight rework to character stats, and the introduction of classes. In Antorum, players select a class by allocating class points into four areas: Artisan, Explorer, Warrior, and Ascetic. These points determine the name/title of the class and experience bonuses in the various skill categories, so you can tailor your character to be a bit better in the areas that suit your playstyle. I'll see how this all feels as work on the game continues.

Additionally, I finally got around to reworking the gross character window. The new one shows way more information about your character, and even has a little preview window. Nice.

Just like players, NPCs can now be customized, as well as have gear equipped. Just specify some options on an EquipmentComponent:


[equipment]
    hair = [0, 255]
    hair_color = [0, 6]
    skin_color = [0, 36]
    shirt_color = [2, 4]
    pants_color = [5, 7]
    [equipment.spawn_equipment_set]
        main_hand = "iron-longsword"
        off_hand = "wooden-board"
        head = "rusty-helmet"

As seen above, customization options for stuff like hair can be specified as a range instead of just a single value. If you do this, the final value will be randomly selected from within the given range when the entity is spawned. I added this because it just makes it easier to have randomized NPCs that look different, without requiring a ton of separate entity definitions.

I'm pretty pleased with the network protocol changes for this feature. It's a set of 6 tidy packets:


Client - 0x30 - Character Creation Request
name:               string (? bytes)
class_artisan:      u8 (1 byte)
class_explorer:     u8 (1 byte)
class_warrior:      u8 (1 byte)
class_ascetic:      u8 (1 byte)
stat_stamina:       u8 (1 byte)
stat_strength:      u8 (1 byte)
stat_smarts:        u8 (1 byte)
stat_speed:         u8 (1 byte)
hair:               u8 (1 byte)
hair_color:         u8 (1 byte)
facial_hair:        u8 (1 byte)
facial_hair_color:  u8 (1 byte)
skin_color:         u8 (1 byte)
shirt_color:        u8 (1 byte)
pants_color:        u8 (1 byte)


Server - 0x31 - Character Creation Response
status:             u8 (1 byte)


Client - 0x32 - Character Creation Class Info Request
class_artisan:      u8 (1 byte)
class_explorer:     u8 (1 byte)
class_warrior:      u8 (1 byte)
class_ascetic:      u8 (1 byte)


Server - 0x33 - Character Creation Class Info Response
class_title:        string (? bytes)
class_bonuses:      string (? bytes)


Client - 0x34 - Character Creation Stat Info Request
stat_stamina:       u8 (1 byte)
stat_strength:      u8 (1 byte)
stat_smarts:        u8 (1 byte)
stat_speed:         u8 (1 byte)


Server - 0x35 - Character Creation Stat Info Response
stat_bonuses:      string (? bytes)

The next thing I plan to finish and write about is the herbology skill and foraging nodes.

- Declan (@dooskington)

Belmart, Shops, and Bartering

Tue, 27 Oct 2020 19:10:00 -0700

Antorum has shops now! This feature was done a couple months ago, but I was too busy to write a new dev log, so here it is now. I also needed a place to actually put merchants/shopkeepers, so I started building the first town on the island: Belmart.

There are plenty of art assets that need to be finished and work to be done on that front, but I'm pretty happy with the town layout and the small marketplace area. There's a few merchants here for players to purchase primitive gear and weapons, as well as useful items such as cookware and ingredients. The idea is that players can get well enough equipped here to allow safe travel to the more difficult areas.

Any entity can be made into a shop by adding a ShopComponent to them, and making sure they have an InteractableComponent which supports bartering. Here is the entity definition for a fish merchant:


id = 13

[networked] [info] name = "Fishmonger" description = "A fish trader." model_id = 1 [transform] [npc] sayings = ["Fish here! Getcha fish here!", "Fine fish!", "Get your fresh catch 'ere!", "Selling fish over 'ere!"] should_wander = false [interactable] interactions = ["barter", "walk-to", "examine"] [movement] [shop] items = ["groofish", "blue-skipper"] buys_items = true sells_items = true

You can't barter with other players yet, but I'll add that eventually. It's just not a very fun feature to work on when I'm the only person wandering around.

The bartering system was a complex bit of work. I don't know why I decided to make such a complicated interface for it, but I guess I was feeling inspired by Fallout and other RPGs with similar interfaces. Five new packets were added to support all this, and existing entity sync packets were updated to support the new component.


Server - 0x2B - Barter Open
inv_values_len:  ulong  (8 bytes)
inv_values:      list   (? bytes)
    bag_slot:    u8     (1 byte)
    item_value:  i32    (4 bytes)
shop_items_len:  ulong  (8 bytes)
shop_items:      list   (? bytes)
    resource_id: i64    (8 bytes)
    quantity:    u16    (2 bytes)
    value:       i32    (4 bytes)
shop_name:       string (? bytes)


Client - 0x2C - Barter Close Request
status: u8 (1 byte)


Server - 0x2D - Barter Close
status: u8 (1 byte)


Client - 0x2E - Barter Move Item Request
src_area: u8  (1 byte)
src_slot: u8  (1 byte)
quantity: u16 (2 bytes)


Server - 0x2F - Barter Move Item
new_shopper_coin_offer: i32 (4 bytes)
new_shop_coin_offer:    i32 (4 bytes)
src_area:               u8  (1 byte)
src_slot:               u8  (1 byte)
dest_slot:              u8  (1 byte)
quantity:               u16 (2 bytes)

I also added some giant crabs to the beach areas. After all, the game is (mostly) written in Rust. Gotta pay respect to Ferris.

- Declan (@dooskington)

Milestone

Sat, 18 Jul 2020 19:04:00 -0700

Lately I've been tinkering on some stuff that is either related to the recent world engine changes or was blocked on those changes. I have been waiting a long time to add some concept of "entity regions" into the game, and having that done basically means that the entire game world is no longer regarded as one large room with all players within it. As entities move around the island, they are discretely sorted and swapped between regions, syncing themselves (or the removal of themselves) to any players that need it. Players that are in an entirely different region than some other entity are no longer required to keep track of it, and will no longer be sent any packets it may generate. Only the entities relevant to a client are streamed to that client.

I think I consider this a major milestone for the game. Systems are starting to come together more and I think the editor is even capable of creating some interesting scenes, regardless of the fact that I only have a handful of props and textures. Antorum is starting to feel like a place that is worth exploring. I also realized that this is dev log 20! Antorum has come a long way since I first started working on it over a year ago. I am not bored of it yet, so I guess I'll keep chipping away.

Something else I finally did was finally replace the garbage main menu that I have been tolerating since the start of this project. Not pictured here is the screen allowing the client to specify a game server hostname, and the world download screen which makes the process of connecting, downloading resources, and logging in a bit nicer.

I also ripped out the minimap rendering code and replaced it with a much cooler solution that renders a nicer looking map, in tiles. You can patch together the tiles to get the full world map - here is a small portion of it:

The shadows look a little messed up because I have smooth normal calculations for the terrain turned off. It's an expensive bit of processing which I haven't had time to optimize yet.

Changelog

Implemented the EntityRegionSystem to spatialize entities a bit more
Refactored client/server world sync to support entity regions
Refactored packet sending to support entity regions
Fixed bug that allowed stacking of non-stackable items
Fixed bug causing movement desync (especially during combat)
Added 4 new props
Added 2 new items
Tweaked drop tables for various NPCs
Refactored in-game user interface to be window-based and less obtrusive
Refactored main menu to be a bit more robust and nice to look at
Fixed some scary race conditions in the async networking bits
Tweaked in-game lighting settings & turned on fog
Increased default shadow draw distance
Refactored minimap rendering to be camera based
Fixed an editor bug where props and entities would duplicate themselves
Added hop animation to moving characters
Added drop animation to dropped items

The next thing that I work on will be NPC shopkeepers and the bartering system. Should be fun.

World Engine Improvements and Props

Tue, 30 Jun 2020 19:28:00 -0700

Antorum is a small island right now, but I've been planning on making it larger for a while now. I didn't spend time optimizing the terrain for this in the early days of the project, so I had to do a bunch of work to get the code in order. Terrain data should be easier to stream on the client now, and objects such as trees and entities will no longer be processed if they aren't in sight.

As usual when messing with the world engine, I had to update the Editor. Mostly it was boring refactors, but I did end up adding some goodies like entity scaling, rotating, and randomizers for those to help make more "natural" looking arrangements. Additionally, I used to store trees as their own type of data to save some minimal amount of space, but decided to stop doing that because it was needlessly complex. Antorum now just has the concept of "props", which can be any 3d model. I've already taken advantage of this by adding props for a new type of tree (palm tree) and a boulder. I'll get around to adding more interesting stuff soon.

Changelog

Removed Tree tool and replaced "Trees" with more generalized "Props"
Refactored props and entities to be more closely associated with regions
Refactored world file serialization/deserialization
Implemented Prop Placement Tool
Implemented Prop Edit tool
Updated Entity Placement and Edit tools to support rotation and scale
Made a new test world that is much larger
Removed support for variable tile sizes
Fixed bug causing all regions to be reconstructed for any small terrain change
Fixed bug with map serialization that prevented map files from being larger than 1 mb
Fixed walkmap overlay rendering on large terrains
Added Tree (Palm) prop
Added Boulder (Small) prop

Cooking

Sun, 09 Feb 2020 21:05:00 -0700

Recently, I've been working on adding the cooking skill to the game. The core implementation is done, but I left a lot of room for improvements and polish while I iterate on it. Consumable items were already implemented, so along with this addition it's now possible for players to cook various foods and eat them for healing and other benefits.

Recipes and Cookware

To cook, players need to be at a campfire, stove, or some other cooking "appliance". They also need some cookware like a pot or pan. Pots can be used for soups and stews, while pans can be used for fried fish, meat, and other stuff. I've only added a handful of recipes to the game so far. Recipes are written as part of an item definition. Here's the item definition for Chonkrat Stew, which can be made by cooking some Raw Chonkrat Meat inside any Pot. The player also needs to have at least level 2 in cooking - cooking a recipe that your character is not skilled enough for will most likely result in some Ruined Food.


chonkrat-stew.toml
id = 25
[item]
name = "Chonkrat Stew"
description = "It's got stuff floating in it!"
type = "consumable"
model_id = 0
is_stackable = false
[attributes]
heal_amount = 7

[recipe] req_crafting_station = "cooking" req_crafting_equipment = "pot" input_item_res_names = ["raw-chonkrat-meat"] req_skill_lvl = 2 skill_exp_award = 20

I haven't really figured out how players are meant to "discover" recipes yet. I am going to have a skill guide available in the game, to give players an idea of what they can do and what they are working towards. Along with this, I'm kicking around the idea of having individual recipes be items that have to be purchased at a shop, found in the world, or read in a book. I'll see how it feels once I add more recipes and flesh out all the effects of cooked food.

Interactions

To support all this, I had to do a little refactor to the interaction system, and also added a right-click menu on the client so there was somewhere to tuck away the new interactions. One of those new interactions is examine, so you can examine entities similarly to how you can already examine items in your inventory.

It's easy to specify various interactions on an entity. Here's how the entity definition for the chonkrat looks these days, including the (one line) interaction list.


chonkrat.toml
id = 1

[networked] [info] name = "Chonkrat" model_id = 2 description = "A bit on the heavy side." [transform] [npc] sayings = ["squeak!"] combat_sayings = ["eek!", "scree!"] wander_radius = 40.0 [interactable] interactions = ["attack", "walk-to", "examine"] [movement] [health] max_hp = 8 [combat] [stats] stamina = 2 strength = 3 smarts = 1 speed = 3 [drop_table] drops = [ ["any", "0, 10.0, 2-6", "1, 100.0", "2, 100.0", "10, 20.0, 1-2", "11, 15.0", ], ["one", "!rusty-weapons", ], ]

New Packets

This feature brought a ton of new packets along with it. I'm probably going to end up refactoring and reusing a lot of these for other crafting skills. I'm already starting to notice that I have a lot of empty "event packets" in the protocol these days, which really should just be wrapped up into some common RPC (remote procedure call) type packet. I'll get to it some day.


Server - 0x1E (30) - Cooking Open
station_net_ent_id: u64    (4 bytes)
Client - 0x1F (31) - Cooking Close Request
cooking_slot_type: u8    (1 byte)
slot: u8                 (1 byte)
Server - 0x20 (32) - Cooking Close
(0 byte body, event packet)
Client - 0x21 (33) - Cooking Add Item Request
cooking_slot_type: u8    (1 byte)
dest_slot: u8            (1 byte)
src_bag_slot: u8         (1 byte)
Client - 0x22 (34) - Cooking Remove Item Request
cooking_slot_type: u8    (1 byte)
slot: u8                 (1 byte)
Server - 0x23 (35) - Cooking Add Item
cooking_slot_type: u8    (1 byte)
src_bag_slot: u8         (1 byte)
dest_slot: u8            (1 byte)
Server - 0x24 (36) - Cooking Remove Item
cooking_slot_type: u8    (1 byte)
src_slot: u8             (1 byte)
dest_bag_slot: u8        (1 byte)
Client - 0x25 (37) - Cooking Begin Request
(0 byte body, event packet)
Server - 0x26 (38) - Cooking Begin
Unused for now

Server - 0x27 (39) - Cooking Finish (0 byte body, event packet)

Art

On the art side of things, my texturing skills have "improved". After all this time, at least I have figured out how to unwrap objects more complex than a cube.

With cooking implemented, the game is feeling a lot more interesting. Since monsters can drop ingredients, and players can cook food for combat and recovery, game systems are starting to feed into each other. When I add things like shops and trading, cooking will also be able to contribute to some minor economy. The new interaction stuff was a big blocker for friendly NPCs, shopkeepers, and banks, so I will be tackling those sometime soon.

Data Driven Entity Updates

Wed, 29 Jan 2020 21:41:00 -0700

I've been making improvements to entities, to make them more data-driven. Previously, if you placed an entity in the game world and wanted to customize some property on it, you would have to create a new and unique entity file. Obviously I can't build a whole game like that so I decided it was time to go back and work on this stuff.

Entities can now be given a property bag in the editor, by typing in some basic TOML. Here's an example of a tiny property bag that I gave to one of the new NPC spawners, to lower the default spawn count:


ent_res_name = "arachna-broodling"
max_spawned_ents = 4

What happens is the base entity will be constructed (the NPC spawner), then each component that belongs to that entity will have its fields overridden by any that are specified in the property bag. Not every field is overridable though! Those that are get specified by the developer when they are implementing the OverridableComponent trait for their component.

With that said, it's now trivial to place unique NPC and item spawners around the world. So, we got some new NPCs! It's all pretty rough right now.

shoutout to Cevvin for the giant spider model

Since there are more than one species inhabiting Antorum now, I also added the ability to define a maximum wander distance for an NPC. This way, packs of them wander around where they were placed, instead of wandering off to the far reaches of the world, never to be seen again. In the future, I'm also planning on making it possible to specify a "home tile type" for NPCs, which they would use as a guide for terrain to stay on when wandering. This would be useful for keeping NPCs like crabs localized to beaches, or even getting friendly NPCs to stick to paths and roads.

As much as I want to be writing more about the game and less about the editor, it's a necessary stage of development that I have to finish up. I'm sure I will continue to add features in the future if the game grows, but I am close to having everything needed to build the initial version of the world. For the next dev log, I have an important feature cooking up...

Terrain + Minimap Update

Sat, 18 Jan 2020 15:36:00 -0700

The game has seen some major improvements since the last post! I'm not ready to talk about all of it yet (Entity updates, NPC updates, new NPCs, new items), so I will save that for next time.

Tile Paint Tool

I finally got around to implementing the tile paint tool. As usual when adding some new data to the map, I had to update the world format on both the client and server. The world format now includes a paintmap, which stores the id of each tile. In the near future, I want to expand this so that each paint tile contains a foreground, background, and mask. This will allow interesting effects such as rounded paths and other irregular shapes. Right now each tile is just a boring square that does not blend with it's neighbors.

Maps are getting to be way more fun to build. With tile painting, you can make more detailed little mountain bits, bridges, and docks. The map generator will also take care of painting sand on beach areas and underwater (thanks sir!).

Basic Minimap

There's a little minimap now. I still have to implement blips (for NPCs, other players, items, etc). Also, trees are a little messed up due to some transparency stuff, I'll have to fix that too. The minimap is my favorite new feature - it really makes the world feel solid, and now that the world is larger it is useful for navigating.

Each client generates the base map image once they load into the server and acquire the world data. Then I just display it in a UI box (with a mask to keep it within the box) and do some rotation math so the minimap and compass face where they should. After months of thinking about this particular feature, I'm surprised I was able to get it in just a couple days.

I did lose some time because I attempted a different style of minimap. In this alternative style, an orthographic camera would be move across each chunk of the map, capturing an image of the terrain. All these chunk images would be stitched together for the final map. This was working well, but the big issue was that I could not get the water shader to play nicely with an orthographic camera. In addition, I felt this might limit me in the future, if one day I decide I don't like how a certain tile looks from the perspective of the minimap camera. They are textured with the purpose of being viewed a little closer, after all. Here's an image of that experiment, except with a perspective camera. It looks awesome, but won't work well when stitching multiple chunk images together.

Trees

Mon, 13 Jan 2020 09:10:00 -0700

Antorum has trees now! This post is mostly going to be a quick photo overview of those changes, as there isn't much technical stuff to discuss. The editor now has a tree tool, which can be used to quickly place trees (randomizing scale + rotation).

Placing trees also updates the walkmap, so characters cannot walk through trees.

Here's a bonus screenshot, it's a closer view of the first armor set, as well as the model for the Groofish item and it's cooked variant. Obviously I am not an artist by trade but I am having a lot of fun getting some modelling/texturing practice in.

Equipment

Thu, 02 Jan 2020 22:41:00 -0700

Equipment was a pain. The inventory was already a complex piece of state, and equipment just added more stuff to keep track of. I also had to rework the UI on the client to accomodate this. Now there's a little tabbed menu, with 3 pages: Character, Gear, and Settings. I haven't gotten to make many new models or textures for the equipment yet.

Item Types & Attributes

Item resources now support an an item type, and slot (if the item is equippable). You can also specify a simple attributes table, which allows items to have configurable attributes such as damage, armor, and a healing amount (for consumables). Here's what the item file for the rusty axe looks like:


rusty-axe.toml
id = 8
[item]
name = "Rusty Axe"
description = "Dull, but will chop stuff."
type = "weapon"
slot = "mainhand"
model_id = 0
is_stackable = false

[attributes] damage = 1

Most of the code was tiny refactors and packet additions, so here's a changelist to sum it up quickly.

Server: Updated item database schema
Server: Added weapon and armor item types
Server: Added 'slot' field to item definitions (for weapons and armor)
Server: Added item attribute table to item definitions
Server: Added EntityState::Inventory
Server: Updated combat to take equipment damage and armor into account
Server: Updated block mechanic to only work if you have a shield equipped
Client: Added button to equip items in inventory
Client: Added tab menu UI, with character, gear, and settings tab
Common: Added a few new items including a shield
Common: Updated InventoryPacket to include equipment stats
Common: Added InventoryUseRequestPacket, InventoryEquipPacket, InventoryUnequipRequestPacket, InventoryUnequipPacket

New Packets


Client - 0x19 (25) - Inventory Use Request
bag_slot: u8    (1 byte)


Server - 0x19 (25) - Inventory Equip
bag_slot: u8               (1 byte)
dest_equipment_slot: u8    (1 byte)
new_damage: u32            (4 bytes)
new_armor: u32             (4 bytes)


Client - 0x1A (26) - Inventory Unequip Request
equipment_slot: u8    (1 byte)


Server - 0x1A (26) - Inventory Unequip
equipment_slot: u8     (1 byte)
dest_bag_slot: u8      (1 byte)
new_damage: u32        (4 bytes)
new_armor: u32         (4 bytes)

Having a full gear set makes it pretty easy to take on the King Chonkrat, the main threat in this test world. Although, I did hack in a better weapon for extra damage. I need to add some more NPCs that drop loot.

Was having fun with the world editor and made this little island. I want to get back to the terrain code soon and start making the world much larger.

Pathfinding

Mon, 30 Dec 2019 16:55:00 -0700

It was a surprisingly productive morning. I got up a few hours early, and instead of going back to sleep I just hopped on the computer and did what I could to bang out this pathfinding stuff. I fixed a frustrating combat positioning bug that was caused by a badly designed equation and some floating point precision errors. After that, I was able to finish up the pathfinding code and spend some time testing it. Seems to be working well, and I want a break for the evening, so here's the update.

Editor - Tile Walkability Tool

The first thing I did was add a new tool to the editor - the Tile Walkability Tool. I wanted to make it simple for designers to be able to mark tiles as walkable / non-walkable. It's pretty self explanatory, and works like the other tile tools. The editor automatically marks underwater tiles as non-walkable, and I have no plans to add swimming to the game.

When the server starts, the heightmap and walkmap (created with the tile walkability tool) are processed together to generate a final "walkable neighbors" map. This map is then queried during pathfinding - A tile must be walkable as well as have a slope leading to it in order to be traversable. When there are no terrain features in the way, flat tiles can be traversed diagonally.

Pathing

For the actual pathfinding, I'm using the awesome astar crate. And, upon writing this post I realize that this crate is deprecated now. I guess I'll spend some time upgrading it soon.

Getting it working was quick, but optimizing it was a little frustrating. A* pathfinding returns a list of every node along the path, which is fine and makes sense, but I didn't want all that data. I ended up writing a little bit of code to "collapse" the path, essentially giving me the list of nodes that are directly before a direction change. This way, we have the smallest number of nodes that represents the same path, and we have to send way less data over the wire. It also helps to avoid thrashing the movement system, as characters will follow a few large paths between nodes, instead of many tiny paths.

Networking Updates

Today I greatly decreased the number of movement packets that the server sends out per tick, by updating the MovePacket to contain all destinations that an entity has in it's path, instead of just sending the current destination. Now, clients can smoothly move an entity along it's path without needing to stop and wait for a new destination from the server. There is an occasional de-sync, but that is to be expected as I have not implemented any form of reconcilation yet.


Server - 0x04 - MovePacket
network_entity_id: u64   (8 bytes)
dests_len:         u64   (8 bytes)
dests:             list  (? bytes)
    x:             f32   (4 bytes)
    y:             f32   (4 bytes)

I also had to update the Movement EntityState. EntityStates are just small bags of data that are sent across the network when an Entity is spawned. Since entities now follow large paths, I had to update this state to include the list of destinations that the entity has yet to reach. Note that in the scenario where a player joins and an entity is halfway through it's path, this entity state will only contain the second half of the path - the newly joined player will see the entity continue it's movement just as the already-connected players would be seeing it.


EntityState::Movement
dests_len:         u64   (8 bytes)
dests:             list  (? bytes)
    x:             f32   (4 bytes)
    y:             f32   (4 bytes)
is_moving:         bool  (1 byte)

That's all for today. Tomorrow, I'll work on equipment and equippable items.

Project Status

Sat, 28 Dec 2019 18:38:00 -0700

Well, my last update was about 2 months ago. I was distracted by the holidays, and also the weird idea I got in my head to make a (small) new Asteroid Quest game.

It's more of a spin-off, based on the original prototype I first made a few years ago. I started entirely from scratch, slowly porting parts of the game over, modifying them as I needed. I was just curious what the game would be like if I didn't make certain design decisions early on.

It was a fun distraction, and allowed me to really clean up a ton of old code, which was theraputic in a way. I modernized the game a bit, adding controller support and fixing a bunch of bugs. I even updated some of the graphics and visual effects. Anyway, I think I'll stash this project away for now.

The other news I have to share is that I am moving to a new team at Microsoft - starting in the new year, I'll be working at the game studios on Minecraft! I think it's gonna be pretty awesome. When I was young, that game played an important role in stoking my passion for game development.

Back to Antorum. I don't have a ton of news to share, as I just said I was distracted. However, despite the distractions, I have been working on pathfinding. The implementation isn't ready yet, and has exposed some other codebase deficiencies. I just need to sit down and focus on it and I could probably get it done.

So, with all that in mind, I'm going to try and put some serious work in over the next week, before I start up the new job. Here's what I'm looking at:

Monday: Pathfinding
Tuesday: Equipment
Wednesday: Art & Sound Updates
Thursday: Trees
Friday: Minimap

Hopefully, I'll be able to stick to this plan and post an update every day. The two things I think will take the most work are Equipment and the Minimap.

Drop Tables

Sun, 03 Nov 2019 16:55:00 -0700

This weekend I implemented a drop table system to handle monster loot. I wanted something that was easy to tweak and allowed a little more flexibility than a simple list of random drops would. I thought the item drop system I implemented for Asteroid Quest was okay, but it was hard to tune and did not feel very data-driven or scalable. So, I went back to the drawing board for this project.

The drop system now works based on something called "drop scripts". A drop script is defined inside an entity's .toml file, and then is parsed into a drop table component at runtime. I would say it's a sort of DSL, but toml is doing most of the parsing so I guess this is more of a "souped up" config entry. To make an NPC drop items upon death, all you have to do is tack a drop table onto the entity:


ents/chonkrat.toml
...
[drop_table]
    drops = [
        ["any",
            "0, 10.0, 2-6",
            "1, 100.0",
            "2, 100.0",
            "10, 20.0, 1-2",
            "11, 15.0"
        ]
    ]

"any" indicates that when a loot roll happens, multiple items from the list can be dropped. The entries themselves are in the form "item_id, drop_chance, min_quantity-max_quantity". The quantity fields are optional, and drop_chance must be between 0.0 and 100.0.

I got a lot of inspiration from Bob Nystrom's answer to this stackoverflow question from 9 years ago. The book he wrote, Game Programming Patterns, is awesome. When I was starting to learn more about game development and writing my own game engines, it was a invaluable resource. So, it's cool that here in the future I'm still getting educated by stuff he has written.

Anyway, similarly to the DSL proposed in that stackoverflow question, my drop scripts also have a macro system, but it is a bit simpler. It isn't powerful enough to do nested drop tables, as I originally wanted, but since this is just a first pass I may still implement that when I need it. For now, macros essentially just reference item drop lists that are written in their own .toml files. When an entry in the form of "!name" is present within a drop script, it is expanded, bringing in the drop list saved under name.toml.


drops/gems.toml
id = 1

drops = [ "4, 3.0", "5, 1.5", "6, 0.5" ]

Now I can reference the gems drop list in an entity file:


ents/king-chonkrat.toml
...
[drop_table]
    drops = [
        ["any",
            "0, 50.0, 25-40",
            "1, 100.0",
            "2, 100.0",
            "10, 20.0, 1-2",
            "11, 15.0"
        ],
        ["one",
            "!gems"
        ]
    ]

"one" indicates that when a loot roll happens, only one item from the list can be dropped. So now, the King Chonkrat drops any of the items in the first list, but then will pick a maximum of one gem to drop.

Since I was working on item drop sets, I had to add some new (boring) items to the game:

Sapphire (id: 4)
Ruby (id: 5)
Emerald (id: 6)
Rusty Shortsword (id: 7)
Rusty Axe (id: 8)
Iron Longsword (id: 9)
Wooden Shield (id: 10)
Chonkrat Claws (id: 11)
Chonkrat Tail (id: 12)

The client didn't change much, so there isn't really anything new to see. Here's a screenshot of the battlefield after I had slain some chonkrats. Those purple cubes you are seeing are just items that I haven't had time to make 3D models for, yet.

Terrain Sync

Mon, 28 Oct 2019 21:04:00 -0700

In the previous post, I talked about the world editor, and how it can export usable world files now. In this post, I'll talk about work that was done to get the Server loading up those world files and sending terrain data to Clients.

First, here's a quick overview of what's been done:

Client: Integrated terrain library
Client: Refactored movement code to allow traversal of sloped surfaces
Server: Renamed Giant Rat NPC to Chonkrat
Server: Implemented world file loading
Server: Implemented actual ctrl-c handling for a graceful shutdown
Server: Bugfix: Fixed crash when two players picked up an item on the same tick
Client & Server: Implemented terrain syncing

I added two new Server packets to the game protocol: The WorldInfoPacket, and WorldTerrainDataPacket.


Server - 0x16 - WorldInfoPacket
size:       u32 (4 bytes)
chunk_size: u32 (4 bytes)

The WorldInfoPacket is sent after a client connects, and informs the client about the terrain data they are about to start receiving. This is so that the client can get the world ready, essentially creating a properly sized terrain with "empty" chunks that are waiting for heightmap data. For now, the only important information is the world size (in chunks) and the chunk size (in tiles). I'll add more to this packet as time goes on, such as a value for sea level, lighting values, or maybe info about the time of day.


Server - 0x17 - WorldTerrainDataPacket
chunks_len:    ulong (8 bytes)
chunks:        list  (? bytes)
    chunk_x:   u32   (4 bytes)
    chunk_y:   u32   (4 bytes)
    tiles_len: ulong (8 bytes)
    tiles:     list  (? bytes)
        bl:    byte  (1 byte)
        br:    byte  (1 byte)
        tl:    byte  (1 byte)
        tr:    byte  (1 byte)

For now, the WorldTerrainDataPacket is sent directly after the WorldInfoPacket. Since the world is so tiny at the moment, all chunks are sent. Tiles are still just defined by the heights of their four corners. When I add new tile types and other stuff I outlined in the previous post, this will change a bit. Eventually, the server will only send these whenever a player crosses chunk borders, and a new area of the world needs to be streamed. Although, lately I have been thinking about it, and I may end up going with a more front-loaded approach. The server would send all terrain data when a client connects, expecting them to cache it. A Server-side world version would be maintained, and when a client with a null or outdated world version joins, they would be sent the latest data. Of course, all of this could just be shipped with the client itself, but then I lose the ability to modify the game world instantly for all players of the game - and I think that's really cool.

Above is a screenshot from the editor, where I'm placing a few coin spawners.

I'm rich!

Note that the only thing clients care about from the world is the terrain. Entities spawned at runtime are still synced in the usual way. The entity placements within the world file are just read when the Server starts, and the referenced entities are instantiated. I haven't implemented pathfinding or "walkable" tiles yet, so NPCs still wander out into the sea and will continue wandering until they reach the void.

This post concludes my work for October. It was a productive month! I am thrilled that I actually hit my stretch goal, which was to get the terrain system implemented (in some form) on both the Client and Server. I'm guessing the next two months won't be as exciting, due to the holidays. As I continue development, I think I'll be focusing on these areas:

Better item drop functionality
Better skill exp gain and level ups
Minimap
Bugfixes

Thanks for reading.

The Editor, Pt. 2

Sun, 27 Oct 2019 18:17:00 -0700

This week, I put a ton of work into all three aspects of Antorum: The Server, the Client, and the World Editor (introduced in my last post). Because of that, I'm going to post two blog posts detailing the work. I'll release this one quietly on Sunday night, as usual, then release the next one in a couple days.

Here's a list of the major Editor tasks that I finished:

New water shader
Terrain smooth tool
Entity placement tool
Entity edit tool
Native file dialog for saving/loading world files
Refactored terrain library into a unity package

With this work, the editor is finally shaping up into something that can be used for the game. It's lacking a few important things, such as varying tile types, tile masks, and trees. I'll add those features as the game evolves and starts to require them. The core of the editor, however, is in place. Designers can create new islands, modify the terrain, place entities, and easily bring it all into the game. I'll discuss more about how the Server handles this in my next post.

Compared to my previous post, you'll probably notice that the island pictured here is flatter. That's because I realized that this style of terrain handles gentle slopes way better than it handles big hills and mountains. Since the game operates entirely on a 2D plane, and is seen from a top-down viewpoint anyway, keeping elevation low will keep things simpler. However, there will be a few areas in the final game that have a higher elevation.

The entity tools are primitive right now. As I mentioned back in dev-log 4, entities are defined Server-side in .toml files. This system has basically stayed the same, with a few additions for new component types. I decided the quickest way to get entity placement working was to continue leveraging this. Designers working in the editor just input the resource name of a specific entity, then click to place them. Obviously this isn't too flexible because it doesn't allow fine-tuned customizations (like the Unity inspector does), but the route forward will be simple: More .toml! When the game is getting complex enough that we need to tweak values per-entity from within the editor, I'll modify this system so that designers can directly modify the .toml for a specific entity instance. I'm sure it won't be as clear-cut as that, but I've got to move onto other features so I'll circle back around on this.

Here's what the layout of an Antorum .wrld file looks like:


size:          u32   (4 bytes)
chunk_size:    u32   (4 bytes)
chunks_len:    ulong (8 bytes)
chunks:        list  (? bytes)
chunk_x:   u32   (4 bytes)
chunk_y:   u32   (4 bytes)
tiles_len: ulong (8 bytes)
tiles:     list  (? bytes)
bl:    byte  (1 byte)
br:    byte  (1 byte)
tl:    byte  (1 byte)
tr:    byte  (1 byte)

ents_len: ulong (8 bytes) ents: list (? bytes) x: f32 (4 bytes) y: f32 (4 bytes) name_len: ulong (8 bytes) name: str (? bytes)

The format will evolve as time goes on, and it has some issues now. For one, the terrain is chunk based, but it all get saved in one monolithic file. That's fine, but it eliminates the possibility of having more than one person working on a world file at the same time. It also means that the entire world has to be loaded into memory on the Server. That's also fine, since the world is not that large. Even at the size I am predicting the full game world to be, it will still be manageable. For the next game, I'll work on a more flexible world/chunking format.

I may have already shouted it out, but I'm using bincode for all my serialization needs, on the Server-side at least. I have written my own C# bincode implementation for the Client & World Editor - Maybe I'll publish it to GitHub at some point.

As a bonus, here's a screenshot of one of the first iterations of the terrain engine, circa May 2018. I've probably rewritten it twice since then, but it's really cool to finally get to use it, and the concepts I've learned, for a real project.

The Editor

Sun, 20 Oct 2019 11:27:00 -0700

This weekend I worked on the world editor.

It's an application built in Unity, which will be useful when I share the terrain library with the game client. If Unity native plugins weren't such a hassle to work with, maybe I would have written the terrain engine in Rust so I could also share it with the server. However, the way it's looking now means the server will not need to maintain the terrain mesh, so it wouldn't be necessary. The game server only needs to load the world file to get info it cares about, like walkable tiles and entity placement.

When starting a new terrain, a small primitive island is generated. Eventually, a much larger island would become the base for Antorum. I've tested it on larger sizes and it still runs well, but my current dev machine is a macbook with a very loud fan so I've been keeping the scale down for better performance. I haven't added trees yet.

My main focus has been the shovel tool, and tool system in general. You can drag tile corners to modify them, or you can drag on the center of a tile to raise/lower the whole tile, just like the original RollerCoaster Tycoon. That game was my main inspiration for using this style of terrain.

There's also support for larger brushes, and a tile smoothing tool that is still in a rough state.

I thought I was going to implement world loading on the game client today, but I decided to take the rest of the day off. I'll plan my time more accordingly this week, and hopefully conclude the entire months work with a large update.

Eventually, you'll be able to place trees/fauna, NPCs, and various other entity types. You'll also be able to mark walkable tiles, which the game server will use for pathfinding. The goal is to get the editor to a point where I can build a simple enough world to pilot new features in, as well as give players something to explore when I open up the server for testing.

Other Contributions

This week there's some contributions to share from somebody other than me!

Mike has jumped into the project and started to do some refactors and cleanup on the backend. Here's some of the stuff he got done:

Bugfix: Clients can no longer log into an account that is already logged in elsewhere.
Players now log in with a username instead of email address.
All SQL code and database schema are now in a separate crate, to be used by the game server and web server.

Grubbnet

Sun, 13 Oct 2019 16:57:00 -0700

This week I worked on bug fixes, refactors, and finally put some new art in the game. Since there are no new features, there isn't a ton to talk about. I'm not sure if this art style will be final, but it's within my artistic abilities, so it will stick around for now.

I fixed a couple smaller bugs, such as players being able to attack themselves, and players not being able to carry more than 16 coins. I also did some work on client disconnects, implementing a timer so that players don't disappear from the world instantly when they logout. This prevents players from just logging out to save themselves when combat isn't going so well for them. This also indirectly fixed some bugs that were preventing the player respawn system from kicking in for players who logged out just after they died.

The rest of my time was spent working on and quietly publishing the Grubbnet crate, which is the same networking crate that the Antorum game server uses under the hood. It is only an initial version, so I need to work on documentation, improved examples, and cleaning up the API a bit. For now, though, it's available for use by other Rust game developers.

There's more bugs to fix, and some more refactoring I need to do before I add any new features (I'm trying to avoid broken windows in the codebase). If I finish that stuff up, then a stretch goal for this month is to get some actual terrain into the game, and fix up the movement system so characters can properly traverse it. I'm sick of fighting giant rats in this tiny pit.

As a final note I'll mention that I have been slowly moving towards hosting an Antorum server for the general public (whoever happens to be following these posts). Part of the fun of this task is that I got to set up a VM and test the game with some real latency, and it seems to hold up well! I've been a Digital Ocean customer for about 4 years, but now I'm moving everything over to Azure, mostly because it's more cost efficient for me, but I guess also because I work at Microsoft. I use Azure and various Azure resources every day, but this is the first time I have set up a VM in the Azure portal, and it was very pleasant.

Items and Inventory

Sun, 06 Oct 2019 22:19:00 -0700

This week I worked on adding items and the inventory to the game. It's not perfect, so I'll probably spend a bit more time tweaking it while I figure out what the next feature is going to be. You can pickup, drop, and examine items. There's no way to trade with other players yet, but one player can drop items for others to pick up. As with the rest of the player data, inventories are stored in the database, and getting that working was one of the most interesting challenges so far. Of all the state in the game, the inventory has the most complex, so it really tested the database and network syncing code. So far it seems to be holding up, but I am getting a lot of insight as to how I plan on designing the codebase for the next multiplayer game I work on. With this update, there are now 24 packets in the game protocol.

In adddition, NPCs drop items when they die now (just some coins). I plan on adding a more robust item drop system this week. I'll probably write a very tiny DSL to make it easy to define interesting drop tables. Like entities, items are defined in .toml files like so:


id = 2

[item] name = "Raw Rat Meat" description = "I should cook this." type = "ingredient" model_id = 0 is_stackable = false

The inventory UI on the client needs some more work, as I threw it together quickly just to get moving. Ideally, I'd like players to be able to drag items to rearrange them, as well as drop items in quantities greater than one at a time. There's also no item icons, because I don't have any. When I find some time to pry myself away from the code, I'll do some minor touch ups and add new art. I already got sick of looking out into space and put some rock walls up.

I did some more tweaking for combat formulas as well. This is totally new territory for me, so I'm not sure how balanced it will feel as time goes on. I've been using a nifty spreadsheet to work on this stuff, and it isn't too hard to try out new values.

That's all this week. September is over now, so check out This Month in Rust GameDev #2! I'm moving quickly to try and get an official server hosted and a demo out so people can check out the game.

Stats and Skills

Sat, 28 Sep 2019 20:54:00 -0700

This past week I've been working on a more concrete implementation of stats and skills.

There are four stats: Strength, Stamina, Smarts, and Speed. They range from 1-10, and start at 5. At character creation, players are give 5 extra stat points, and allowed to allocate their points however they want. I'm still working on the equations for combat (like hit chance and attack damage) and how stats effect them.

With this change I also had to do some work on the client, so I added the character panel and skills panel. There are three skills in the game right now: Combat, Defense, and Athletics. Obviously, combat is useful for killing stuff. Defense makes you tougher and lets you wear better gear. Athletics effects your movement speed in the world, as well as your dodge change. The other three skills I have planned are Foraging, Fishing, and Cooking. I'll get to work on those soon, hopefully.

Skills work differently than stats. They range from 1-50 and start at 1. However, each individual skill has it's own level cap. Completing quests and leveling up as an adventurer allows the player to allocate points towards increasing the level cap of any particular skill. I'm hoping that this ends up making characters feel more specialized as they progress through the game.

The next thing I plan on working on is items and the inventory.

Combat and NPCs!

Fri, 19 Jul 2019 21:36:00 -0700

Combat took way longer than I expected.

I quickly began to run into issues with the way I was handling combat positioning. I thought I could rely on the character follow functionality that I talked about in the last post, but it was far too unreliable. Sometimes characters would dance around each other, unable to agree on stationary positions for themselves, because their target (the other character) was also doing the same, just delayed by 1 tick. This behavior was also seen in Runescape, when two players followed each other. In hindsight, since I'm modeling the character movement in a similar style, I should have anticipated it.

I pivoted into a new solution that seems to work well. When two characters begin combat, I create a lightweight combat handler entity. Every tick, it processes combat messages between the combatants and also determines where each one should be standing. Now that the combat positions are calculated on the same tick, the "follow dancing" problem is fixed. You will also notice that I also added a few more prototype cubes and NPCs to spice up combat testing.

There isn't much to say about NPCs yet. They can die and respawn (so can players now, too). The most interesting addition is a refactor I did to allow entities to be defined externally, in a .toml file:


[entity]
    name = "Giant Rat"
    model_id = 2
[transform]
[npc]
[movement]
[health]
    max_hp = 6
[combat]
[skills]
    combat = 1
    strength = 1
    dexterity = 1
    endurance = 1

As you can see from the above entity file, entities can now have skills. There are four skills, and they are combat related:

Combat - Determines your hit chance.
Strength - Determines the maximum damage your attacks can deal.
Dexterity - Determines your dodge chance.
Endurance - Determines your block chance and block amount.

These are probably all going to change. I just needed some basic skills so I could work on stuff like dodging, blocking, and critical hits.

Movement and Follow Refactor

Thu, 20 Jun 2019 16:02:00 -0700

Not much to report today, because I have been refactoring.

I modifed the server-side movement code (as I mentioned in the last dev log) so that movement packets are sent a bit more frequently in order to allow characters to follow other characters (for combat) or even follow a totally different type of entity (that's the power of ECS, baby). That stuff worked well, until I ran into another issue I had anticipated, but was waiting to see in action.

My original method of handling movement was to add some velocity to a Character's position every tick, and when the destination was very close (within 0.25 units) the character would snap to the destination, and end movement. This works well for most games, but most games run at an actual speed (like 60 frames per second). This game loop runs at 2. Even with a delta time, it resulted in situations where characters were overshooting their destinations, then overshooting again when they tried to correct themselves, resulting in them getting stuck in a twitchy loop. Movement was not deterministic enough.

To fix it, I just reworked the movement system to work based on a move start tick and a move end tick. Since I know when a Character's movement started, and when it should end (because the tick rate is constant and I know the movement speed), a progress percentage can be calculated, and then the characters current position can be calculated with some vector math. Voila.

Now that these refactors are out of the way, This evening I'll spend some time getting back to the combat implementation. Every time I test combat, I need to restart the server to reset the NPCs. I want to fix that and get some primitive death/respawn mechanics in. For now, when a character dies, they should just respawn immediately at their initial spawn point.

Mr. Grubba, Combat Progress

Wed, 19 Jun 2019 10:03:00 -0700

As much as I wanted to dedicate this entire week to dev, I ended up getting a cat. His name is Mr. Grubba and I love him.

But, I have somehow managed to get a bit done on the game. Health is now synced between clients, and attacks actually do damage. When a character reaches 0 HP, they just kinda glitch out and walk around like a zombie. Fun!

Now that characters can trade basic hits, The goal now is to tie combat and movement together so that characters attempt to stay within attack range of their target. This is a little tricky because this is a coupling between the two systems, but I have been trying to avoid such dependencies. Luckily, as I mentioned in the last post, I have a cool EventChannel implementation that is working working well enough. So, when a character begins combat, the combat system sends a FollowEvent to the movement system, telling that character to start "following" the target. Typically, characters just move to a static "destination", mark themselves as arrived, and stop. When following, however, characters need to get in range of another character, and continue to stay in range even if the target has moved since the follow started. When the character is following, I can probably achieve this behavior by updating the characters destination every tick and never "arriving". If the character is within range, they will stand still and combat can proceed.

The big takeaway from this design is that my current way of syncing movement across clients doesn't quite work. When characters simply move from A to B with a set speed, I can send one MovePacket to each client, they can perform the movement on their end, and everyone will stay pretty much synced up. Of course, I'm not accounting for lag, but prematurely optimizing away issues that don't exist yet is an non-goal of this project. Anyway, since character destinations can change on the fly now due to their follow target being able to move, I need a more consistent way to sync movement state.

For now, I'm gonna make a modification to the movement system so that if a character is following another one (and thus has a more volatile movement state), MovePackets will be sent once per second (at the moment, every other tick), containing the most up-to-date state info. In the end, the actual update frequency I roll with is gonna be dependent on how it feels and what level of network activity the game ends up supporting. My next post will contain the results of this experiment.

Starting to implement combat

Sat, 15 Jun 2019 17:12:00 -0700

I've been slowly starting to roll on the combat implementation. It's complex enough of a feature that other blocking issues in the codebase are starting to manifest. For example, my packet routing code (from the game world to the network) only allows entities to send packets to all connected clients. I need to make a small modification to allow targeted packets, so that the server can send combat text (in the form of chat messages) and other state info to individual clients when they attack or get attacked.

Players can now initiate combat with the giant rats in Antorum, and they will trade hits for 1 damage each. This is the first code going in here where two entities interact, so it's taking a bit of experimentation. I ended up finding shrev, a cool little event channel crate, particularly handy in this cross-entity interaction. When combat begins between entity A and B, an AttackEvent is sent to both of them, updating their combat state. I handle "turns" by simply pre-calculating the next "attack tick" when an attack should occur. When the CombatSystem sees that it is time for an attack, it performs the attack and adds a tick offset for the next attack tick. Since each tick is guaranteed to happen in sequence, I think this should work just fine.

Another new thing to consider, is that entities in combat need to make some attempt to stay within range of each other. If a player decides to run away from a monster, or gets ones attention, the monster should run after them. Right now the solution I have is a modification to the entity movement code so that I can specify a "target entity" that will be simply be followed (up to a specified minimum distance) instead of the usual method of moving to a set destination. This, in conjunction with the combat system doing range checks, should result in the simple persue effect I'm looking for.

Hello World

Wed, 12 Jun 2019 15:31:00 -0700

Right now I'm working on a multiplayer RPG called Antorum. I started tinkering with it a while ago, but I have only recently started to feel comfortable enough with the networking aspects to make visible progress. The server is written in Rust, and the client in Unity/C#. It's been a lot of fun so far figuring out how to make this arrangement work, with the server being fully authoritative and simulating the game world. Basically, Unity only serves as the front-end for the game. So far, I'm pleased with how it's working. There's 13 packets in the game protocol as of now, to handle things like spawning/despawning characters, chat messages, logging in, and the version negotiation/handshake. I'll probably talk more about the game protocol once there is more to say.

Currently, players can connect (and verify their client with the server), choose a username, spawn in the world, walk around, and chat with other players. There's some very primitive NPCs (Giant rats of course) that wander around the map and "squeak" every once in a while. So, the next thing I work on will probably be some form of combat. There's not much here, but it's taken me weeks to get the foundation required to progress this far. Hopefully I can finish a few more fun features before I start working a full-time job at the end of June.