Hello!

I'm very happy to announce that Warlock, originally released in 2024 on itch.io, has had a massive update in the works for over a year!

This Steam version, compared to the itch.io release will have:

• Sound effects and music.
• Enhanced visual effects for spells.
• A worship system with three unique gods.
• A brand new final boss.
• A gorgeous fullscreen rework that maintains the fidelity of the pixel art.
• Altars that transform or augment items scattered throughout the dungeon.
• Aiming previews, crowd-control markers, and colorblind options.
• Many new enemies, new perks, and new spells.
• A new help screen with vastly more information and a better layout.
• Records of every run from the main menu.

The itch.io version (0.4.4a) will continue to be free, but I highly recommend old fans of the game to try out the Steam version and experience all the new stuff when the game launches at 10:00 am PDT on October 27th!

If this game seems interesting to you, please give it a wishlist; it really helps me out! See you on release!

Warlock: Age of Entropy on Steam

This is the third informal playtest, showcasing the new Quick Step system, the ambient sounds, and some additions to the Western Forest.

https://youtu.be/nC2MX0xYTts

I'm dropping the weekly format for a while because I feel like it was pressuring me to report on all the little details of my progress. I'd rather just do a blogpost when I feel like something is interesting enough to share. I was making a lot of posts at the start because everything was new, but I'm moving more into the routine work of just fleshing out zones; so making blog posts at this point is just spoilers for the game.

I'm trying to come up with systems that will encourage players to interact with the world instead of just trying to get XP. I like to have this because, on repeat playthroughs, I'll want players to target certain things that require them to complete quests. When you force players to do quests to get build-essential items, it adds something to the repeat playlist checklist besides just speedrunning the campaign and grinding XP. I think Grim Dawn does a nice job of this with the constellation system forcing players to map out specific routes through the campaign to grab constellation points from shrines - but I think it would be nice to take a replayability element like that and provide a little more freedom for the player to make their own route. To that end, I'm introducing a slot on the player's equipment called a "Charm". A charm is just a little trinket that can only be acquired from completing a world quest (optional content), and has some sort of bespoke effect.

In this example, the charm provides some cooldown reduction to the dash, and some flat damage when passing through enemies. I think this is not only nice as utility, but could potentially enable certain builds using some of the existing designed skills (more flat cooldown reduction on dodge from Footwork, more damage on the dash from Razor Dash).

I've been working on fleshing out the Western Forest zone, and that's probably where my attention will remain for a long while. This first zone is really important for grabbing the player's attention while they're early on in the game.

See you next time!

This time we're demoing two new weapon types. Sorry for the lack of upload last week, I was too busy playing Path of Exile 2 to make a significant update to the game!

https://youtu.be/iHoocUmoYbw

This time I'm going to be showing the start of the Lowlands zone - which was talked about as part of the initial loop of the game since the beginning. This zone is intended to be the second zone players visit after clearing the Western Forest. They player should be around level 5.

Overlooking the lowlands (just the terrain, no trees or props yet)

I like the idea of a branching path. You can see there are three forks in the road. I'll probably have the questgiver for the zone specify that the quest objective is down the middle path, and the other two will be optional (likely involving world quests).

I also implemented backdrops for the forest and lowlands zones. Something I've had to think about is how the borders for each zone will work. The northern border of the playable area is mountains, but we'll need all the borders eventually. I think invisible walls makes the most sense (even if its kind of lame) because it lets me define a playable area where you can clearly see how the game would continue if you were to run in one direction. I may come up with some way to not use an invisible wall (trees too thick to pass, a palisade wall too high to jump over) but until then, it'll be an invisible wall. Here's the trees continuing on into the fog as seen from the top of the hill in the Western Forest.

Finally, here's a view from above the entire playable area with the fog turned off - unfortunately the LoD is killing the town in the Western Forest, but you get the idea.

I had to turn the fade distance on trees way up because even from the top of the large hill in the forest, the trees back in the hub area were disappearing.

I wanted to get the Lowlands into the game so I wouldn't have to stare into the void every time I got near the southern border of the Western Forest. Now I'll go back to completing that zone - I still need to create the second half of the forest area, and the entire goblin village on top of the hill.

This week's informal playtest is mostly going to be about the new content in the Western Forest zone and the affix system rework.

Previously, an item was yellow if it had 1 affix, and green if it had 2. This is still generally true, but I gave every affix a 10% chance to be a rare affix, which will have more stats than a normal one. This means that green items have a 1% chance to have two rare affixes. This is basically the same as the "double rare" system used in games like Grim Dawn. Rare affixes in Project Alder are indicated by a purple asterisk next to the item name.

I also increased the movespeed of both the player and enemies to compensate for the fact that the zones are quite large - I was looking for how this felt in the playtest.

The noise suppression filter is messed up in this video, so there's some pretty heavy background noise from my end. Sorry about this! I'll have this fixed for the next playtest. Thats the reason I called it 1.5 instead of 2 - I'm keeping it unlisted for now.

https://youtu.be/gSMFPYYah2E

This is the first of a series of informal playtests that I'm planning to publish about Project Alder.

Like I mentioned in the previous post, I'm going to try to upload something at least once a week - sometimes that will be a playtest video like this.

https://www.youtube.com/watch?v=ei39A9-r9GI

I haven't updated this blog in a month - that's not because I haven't been working on the game, it's the opposite. I've been working on the game a lot and haven't had the drive to update the blog. I'm going to start posting in a weekly format to try and ensure that I keep interested people informed about the development. Some of these weekly uploads might just be a playtest or a video - others will be blog posts.

First off, I've decided to change the working title of the project. I started with Project BN2 because it was a no-effort name based on a friends initials with the 2 representing that this is the second time I've worked on a project in Unity. My brother Jake told me that the name was not super memorable, and if I was going to advertise this game before I had a proper title, I should get a better working title. So from now on, this project will be referred to as "Project Alder". I like this name because nothing comes up on google when you search for Project Alder, and Alder Town is the name of the Act 1 hub that a lot of the game will be based around. Without further ado, I'll dive into the details of the damage pipeline.

Damage is divided into two broad categories, each having three subcategories. There's Physical damage with Bludgeoning, Cutting, and Piercing as subcategories, and there's Magical damage with Fire, Ice, and Energy. The player has two damage stats: a physical damage stat and a magical damage stat. These stats are summed up from your primary attributes (Strength, Dexterity, Intellect, and Vitality), your equipment bonuses, and your skills (more on this later).

Each subcategory then has an additive multiplier (for example, +30% damage to piercing). Active skills (like sunder or the fireball, from the last blog post) have a multiplier attached to them which just indicates the damage of the skill (single target will do more than AoE for example). Finally, there are certain other multipliers or bonuses you can gain from investing in passive skills.

The final, pre-mitigation damage formula then looks like this (piercing damage example): Physical Damage * Piercing Additive Multiplier * Skill Damage Multiplier * Bonus Multipliers.

Mitigation is similar. You have two broad mitigation stats, and then fine-grained resists for the subcategories. The mitigation stats per type are Armor and Magic Armor. Subtype resistances go up to 70% linearly; this means that if you get a piece of equipment that says 10% fire resist, its just 10% fire resist. Armors on the other hand are based on attacker level - you'll need more armor to achieve 10% mitigation against a level 15 attacker than a level 10 attacker. Armors then, have a linear soft cap at 50% with an 80% hard cap that scales logarithmically after the soft cap is reached. The full 80% hardcap requires about 6x the armor as the soft cap. I'm designing this with the expectation that most players in the end game will try to reach the soft cap, but dedicated builds can show class fantasy through substantial mitigation.

Now to the mitigation formula. Damage taken is reduced by the subcategory resistance first, then the remaining is passed to the armor. So if my opponent attacks me for 100 piercing damage, and I have 70% piercing resist and 50% armor: I will take 100 * 0.3 * 0.5 = 15 damage. You can see from this that the mitigation cap is 94%.

Pic - some semi-complex combat logging (and the training dummy).

Now we come to the topic of hybrid damage. There is one skill I've added to the game called "Vicious Mana". This is a Rogue skill in the Dark Arts tree (I'll follow up at some point with descriptions of the skill trees I've decided on). This skill makes it so that your energy damage will do an additional 10/20/30% piercing damage. How is this piercing damage actually calculated - what does 30% additional piercing damage mean? Whenever we say an ability will do some percent or multiplier on a type of damage, we will calculate based off of the root damage type: for piercing that means physical. This means that this skill has you using your magic damage stat to deal energy damage, then your physical damage stat to deal the piercing damage. Think about this for a minute - I think that this enables the greatest build variety. It rewards players who (as a shallow tier 1 dip) have high physical/piercing damage but occasionally do energy damage (from a weapon proc or something) because that 30% piercing damage will actually end up being a lot. At the same time, it doesn't make sense as a pick for pure magic damage builds, so people won't just multiclass into the Dark Arts tree to pick up what would otherwise be a "free 30% damage".

I'll follow up this post in the next few days with a playtest video featuring the new Rogue class.

I've been working on trying to get some abilities into the game, and I also wanted to start immediately working on my second class, the Wizard. The reason is simply because I want to start playing this game with my friends soon and I need some variety. I've tentatively called the melee class "Warrior", but I'll probably rename it to "Soldier" because "Fighter" sounds too much like DnD and "Warrior" takes up the W for Wizard. Since I discussed about the build system a bit, which involves taking trees from other classes, I'm guessing people will abbreviate their builds with the letter of the main class + acronyms for the extra trees. Example might be "WTaAc" - "Wizard with Tactics and Acrobatics". I want to get out of the way of having an abbrevation conflict, so I'll probably rename it.

Anyways, here's a quick demo of the character creation screen (which extremely rough for fast prototyping, don't take any of this to be a final product) and also the Wizard's basic attack, which I think is very cool.

https://youtu.be/iBDLy3EmDuI

I'm leveraging an awesome VFX pack that I got on sale to create this and the other effects. I opted for playing the cast vfx and spawning the projectile disjointed from the player position because I think its cool; as a benefit, I don't have to try to align the cast vfx with a swinging staff animation. It's lazy and it looks good; I did the same thing with the fireball ability:

https://youtu.be/-XYXxRp2kA4

In this video, you can see I'm using Unity's spacial blend feature with sound effects to make further away sounds quieter. It's really nice that Unity has these kinds of utilities out of the box - I'm used to trying to build my own engine where all these details are super tricky. I also like having the confidence that these kinds of systems will 'just work' in multiplayer.

Finally, I updated the warrior's ability with some VFX too. This does NOT look as good as the wizard abilities - I need more work on refining the animation and vfx here, but its ok for a playable prototype.

https://youtu.be/jKq4l8F-8kM

I created a whole projectile system in the game for the Wizard - I want to work on some goblin archers sometime soon. Archers are going to be key enemies in this game because the ranged pressure is going to push the combat forward instead of letting the player kite melee with ease. I also think it's nearly time to start implementing my skill trees and level up system.

This is primarly an ability based game. You're going to build abilities that seem fun to play and then use them to kill enemies. I wanted to make the UI very intuitive and enjoyable to use. For ability slots I think the World of Warcraft system is basically perfect and needs no further refinement. You just drag abilities into the slots you want with hotkeys assigned to them, and you can source ability icons from a spellbook that has everything.

I also made some improvements (marginally) to the hitboxes (player and enemy) and the goblin animations. It still looks janky and requires more layers of refinement, but for now I think it's acceptable for a demo.

https://youtu.be/7evHtOq7i4s

After this I'll probably start trying to implement some abilities and continue to work on the game feel. I've been thinking a lot about the stagger system recently. My current design is to assign each ability a seperate stagger value (tied to damage in some respect, but with an extra layer for tuning). The purpose of decoupling damage and stagger value is to provide classes like my wizard, that may have a very different damage profile (more AoE heavy) than other classes, the ability to stagger and knockdown with playing solo. Consider an ice bolt spell for instance that has mediocre damage but very high knockdown potential - I'd like the option to tune variables like this. I also think I'll have a two-tiered system where a monster taking a certain accumulated stagger value will be staggered (animation interrupted), and if it is dealt in a swift timeframe it will cause a knockdown (long stun).

This is an area that's just going to take some polish. I added goblin animations to the game (just reusing some of the free placeholder ones I already have). Them walking around hunched over looks cool, but the attacks look pretty terrible. First of all, all of the attacks I have them use seem to have some sort of angle baked into them that makes the targetting off when the player is standing still. Second, I have to tune the distance they choose to attack at very precisely (otherwise they miss even harder). I'll probably try to get some snappier animations for the enemy NPCs - or if I do use wide swings like these, I'll tune the angle and distance precisely for each attack and probably let them cheat with bigger hitboxes. I'm trying to find a nice balance between an action game and an ARPG.

Here's today's video:

https://youtu.be/SJk7NoB3YLA

You might notice the debug mode I implemented. This was a really nice idea I had to make it a lot easier to tune the hitboxes. I figure I'm going to be doing a lot of this in the future so I might as well set up some tools now. I also added an xp bar and a health bar - these function exactly how you'd expect.

Next I'll probably work on tuning this group of goblins further and maybe adding an active skill for the player.

I'm going to keep it really short today. I added some goblin models (with slight randomization applied to them) into the game as enemies. I then worked on hitboxes and hurtboxes for the player character - and finished with some damage flash and damage numbers. This is all super rough but I just wanted to get the broad concepts in place and refine over time.

https://youtu.be/TYWJ9Ht29BY

Next I'll let him fight back.

I want to clarify the purpose of this blog is mostly for progress updates on the new game. It will include a bit of technical details but I'm not planning to make it a technical blog. We'll mainly just cover what's going on in the latest build and talk about some of my design philosophy.

This post will just be an update about what I worked on today. First of all, I added a crosshair - this is going to be important because there will be many abilities that are targetted, and most abilities will be at least somewhat directional. When I added the crosshair, I realized that the player character was too centered in the screen, so I moved the player character to the bottom 1/3rd of the screen instead. This is the approach used by most over the shoulder games (I mean it's called over the shoulder for a reason, right?), I just didn't realize until I loaded up the game with the crosshair stuck directly in the character's back.

This is how the crosshair looks after I fixed that.

Next I started thinking about attack animations. For our first class, which will be a warrior archetype, I started by implementing a two swing combo used by holding the left mouse button. I used two masks to seperate the upper half and lower half of the body's animations, so that I could have the legs walking while the torso was swinging. This doesn't look perfect but it looks pretty good (and I'm still essentially using placeholder animations here - just throwing it together for speed and prototyping). I'm actually pretty happy with how they turned out. I also added a shader to the player character so the shadows don't affect him so much.

My brother Jake doing a jump attack while I look at the sun (showing the new shader).

Finally, I worked a lot on the camera. It still needs some work, I need a better strategy for handling the camera getting stuck on walls, but I have a nice system in place. Hard walls (like houses, terrain) block the camera, and it moves along the surface of the wall (closer to the player). Everything else gets a dither shader applied to it to give it partial transparency and to signal to the player "you're looking through a solid object". This is the approach games like Genshin Impact use and it works perfect here too. I'm super happy how it turned out.

Here you can see a tree faded out by the dithering shader.

Finally, I spent some time thinking about the character building systems. My current idea is that every weapon will have an active ability tied to it (think a thrust attack for a rapier or a wide swing for a greatsword). The attacks will have different physical animations as well as different interactions with the stat system. For example, you might be able to do extra piercing damage with your build, and you'd want a rapier with a piercing active ability. I'd also allow for the player to extract abilities and put them into other weapons using the crafting system (within reason, no piercing attacks on a mace for example).

The nice thing about this idea is it gives the player an active skill to work with right out of the gate, without any research into the character progression system. I'd even have something like a blacksmith in town with a variety of level 1 weapons - I'd give the player just enough gold to buy whichever they liked to ensure that skilled players can play with the active skills they like immediately.

The character progression system itself I'm thinking will give each class 3 skill trees. Think kind of like World of Warcraft's talent trees (at least in Vanilla WoW through Cata). These would be shorter than WoW's talent trees, and they'd have a mix of active and passive abilities. The warrior might have a tactics and a berserker tree; the rogue might have an assassination and an acrobatics tree, and so on. I'm thinking the level cap of this game will be around 30, so I'd want each tier of the talent trees to unlock after 3 points of investment (at levels 4, 7, 10, so on). The cool idea I had though, would be at level 10 and level 20 you can pick a talent tree from any other class. This would mean a warrior could take the acrobatics tree from rogue at level 10. I'll play with this idea but I'm pretty excited about the potential.

Blending two scenes together in Unity is kind of a pain. There's not really a good way to match two terrain objects up perfectly at the seam (that I've found). The benefits of using scenes and loading / unloading them in a smart manner are too good to ignore, so I have to figure out a good way to manage these transitions. For this game I've decided I can afford to be a little liberal in how I load scenes (given that we're low poly). I'll probably stick to loading scenes obstructed by terrain and assets (like hallways) well in advance of when they're needed, just to prioritize a seamless feeling.

Speaking of seams

I had to come up with a way to make sure there weren't seams at the edges of the scenes. My first idea was to just match the terrain y-level as nicely as possible - but no matter how I did it, there was always a bit of seam. Next I tried a much more successful idea of having the two terrain objects overlap by 10 units.

This works ok when the scene is pretty busy, but not so well when you're looking at a well defined texture on the floor, like road:

I felt like this approach had to be the right way to do it, but there was too much "fighting" for the texture that would appear on top between two nearly-even terrain surfaces. I ended up elevating the terrain of the forest level by 0.04 units to try and reduce this effect and it was pretty successful. All I had to do after that was to hide the 'crease' by spamming more objects around it (ideally on top of it so you don't see it at all). Here's what the transition looks like now that I've filled the forest with some trees and foliage and dropped some assets on the crease.

That's looking directly at the crease. You can still see that there's a bit of an artifact there if you stare at it. Normally, however, you'll see it more like this:

That should be good enough.

Unity Netcode for Game Objects (NGO) is amazing. I can see why so many people create asset-flip slop games for some goofy multiplayer concept like "X simulator" or some parkour game with a mess of props to climb up. I built a copy for my friend to test multiplayer with and it just worked pretty much out of the box. I had to iterate a few times on broken animations, crashing, etc. but the physics and the netcode are solid.

One key detail that I've been thinking about is how I'm going to synchronize players who are in different scenes. I've already decided on a P2P, client-authoritative model (i.e. the host doesn't validate or reconcile the client's network data). I don't really care about people using cheated characters or hacking down the line - I'm going to rely on lobby hosts to decide what they will and will not put up with in their lobbies (I'm assuming based on the structure of the game, 90% or more of the players will want to play in private lobbies anyway). I decided that for the purposes of zone synchronization, I'm just going to store critical information in a ZoneInfo class (stuff like which enemies have been killed, is there loot on the ground, etc). This is a lightweight file that the host can use to sync up other players after a scene has been altered without having to keep the scene loaded for the host all the time. I also am going to use a "Zone Leader" system where a client temporarily acts as a host for a specific zone's enemies.

The first player to enter a zone where the host isn't present becomes a Zone Leader for that zone. If the Zone Leader leaves, leadership passes to the next client in the zone (lowest ClientId or similar metric). Finally, if the host enters the zone, the zone leader transfers to the host. I'll give an example to show why a system like this is useful.

Host: killing goblins in the forest

Player A and B: killing skeletons in the lowlands

In the regular host-client model, if Player A hits a skeleton, that data has to get sent to the host, then the host needs to send that data to Player B's client. If Player A is instead a zone leader, then this eliminates a redundant network call. In the case of many players in many zones, we would reduce the burden on the host significantly (imagine a scenario with 16 players across 8 zones). This is all probably unnecessary premature optimization, but I'd rather have a tight optimization plan which I can slowly loosen as permissable then have a sloppy optimization plan and worry about it years from now. I boxed myself into a corner when I developed Warlock: Age of Entropy by relying on libtcod for python as the basis of the engine; I want to have flexibility down the line in this project.

Anyways here's a picture of me and my friend in the game together:

Next I might work on adding a new scene to the game (and also polishing the starting hub - the shadows are too dark and the town is too small imo). A lot of logic for my premature optimization is based on scene loading/unloading, and it might be time to start getting those systems set up. I also need an automated testing strategy.

I'm making a new game. I spent most of the last year making improvements to Warlock: Age of Entropy for a steam release, but I've been really inspired by my new game idea so I've put that on the back-burner for now. I apologize to any Warlock fans who have been languishing without an update on the itch.io page for over a year now; I'm still planning on doing a Steam version at some point (with a price point ~$5), but if you email me at strafespey@gmail.com and you want to play the new version, I'll just send you a copy for free. There really are a ton of improvements to Warlock that I have just been working on in secret - a religion system, sound and visual effects, a new boss, many new spells, etc.

I decided I wanted to make an ARPG that controls from an over-the-shoulder perspective with WASD to move. There's a lot of awesome indie games that fill a similar niche (for example, Risk of Rain 2), but I have yet to see a fully-realized ARPG with a character building system and multiple acts done in this way. I've thought a lot about worldbuilding in some of my prototype ideas that never saw fruition, so I've been really excited to flex my worldbuilding muscle through a 3D game. The idea of making a 3D game was really daunting to me, since I thought it would require exponentially more work than creating a 2D game. Honestly, though, Unity is so great for 3D, and I'm making progress very quickly.

It's pretty daunting to start a new project in Unity. I started by just adding some terrain and coloring it. Since I'm going with a low-poly style, I think the simple monocolor textures on terrain work fine.

I envision Act 1 to start in a central quest hub (in a coniferous forest), where the player will be asked to travel west into the Forest to do some quests (maybe killing an alpha wolf that has been terrorizing the villagers, I haven't decided yet). The second zone will be a lowlands swamp. Both of these will branch off of the hub and the player will return to the hub in-between. Eventually, the player will head east into another forest, with some higher level enemies (some goblin packs and bandit scouts). This forest, instead of leading back into the hub, will progress continuously toward the finale of the act.

We'll go from this second forest into a bandit village built on the side of a cliff (lots of verticality to play with). From there, we'll be up on the cliff in the highlands, which will be a more liminal zone to break the pace of the intense bandit village. Finally we'll end in some sort of castle. I'll polish up these ideas with sidequests and maybe some auxillary zones, but I think this is a pretty decent idea for an Act 1. I'll also have a cave with multiple entrances connecting the 3 starting zones. It will look something like this:

                      ┌───────────────┐
              ┌──────►│    Forest     │ (warm-up, tutorial)
              │       │   w/ Cave     │
              │       └───────┬───────┘
              │               │ (cave system loops back
              │               │  to hub + branches to lowlands)
              │               ▼
       ┌──────┴──────┐      cave
       │  ALDER TOWN │◄────entrance ──────────────────┐
       └──┬───────┬──┘                                │
          │       │   ┌───────────────┐    cave       │
          │       └──►│  The Lowlands │◄──entrance────┘
          │           └───────────────┘
          │
          │   ┌──────────────────┐   ┌──────────────────┐   ┌────────────────┐   ┌──────────┐
          └──►│ Sophomore Forest ├──►│  Bandit Village  ├──►│ The Highlands  ├──►│  Castle  │
              │   (transition)   │   │   TURNING POINT  │   │   (breather)   │   │ (finale) │
              └──────────────────┘   └──────────────────┘   └────────────────┘   └──────────┘

For now though, I am just working on the hub zone - I added a few houses and trees to the terrain and it doesn't look too bad, even with a pretty low amount of effort.

I ran some C# scripts to mass place trees and foliage in a circle around the village + added a few more houses, and suddenly, the hub started to take shape.

The next thing for me to think about is how to occlude the loading of new scenes. I decided to create a winding S-path to the west so I can trigger the forest zone load while the player is navigating through the trees. We'll rely on a ridge and some fog to trigger the lowlands zone loading. I've also put a lot of legwork into planning multiplayer. I think this kind of game is perfect for playing with friends, so I've kept the idea of how these loading triggers will function in a P2P network architecture as well. The awesome part of making a low-poly game is that the load on the client is pretty low even with a lot of stuff loaded in. I drew up some back-of-the-envelope calculations to anticipate the demand on the client.

The math for a larger combat zone with 60-80 enemies is as follows:

Estimated peak memory (three-scene case):

Planning for a 4GB memory budget, we're doing really well. I started adding some fog originating from the south to signal the transition into the lowlands biome - now the scene is starting to look pretty good.

Keep an eye on this blog for updates on Warlock: Age of Entropy and my new project.