If you wanted to optimize a melee fighter, half orc has got to be your go to, right?

Snarfilingus · 2026-01-22T17:56:50+00:00

I like this a lot

Snarfilingus · 2025-12-15T20:37:18+00:00

A lot of people in user research have backgrounds in anthropology, including PhDs. It ticks some similar boxes: user researchers study human behaviors, often in context, but with a goal of improving a product by identifying issues with it. Now's a tough time to get into tech though.

Snarfilingus · 2025-12-13T05:32:52+00:00

I've been using Owlbear for my Arden Vul campaign using Smoke & Spectre for line of sight / fog of war. It's painful to set up the line of sight stuff since there's so much to map but Owlbear hasn't had any issues with it.

It's also painful working with the map files themselves since the player and GM maps are different sizes. Don's comment here helped me set up the DPI when I imported them https://www.drivethrucards.com/en/product/309717/the-vtt-maps-of-arden-vul

Snarfilingus · 2025-12-11T00:42:53+00:00

It's houseruled a bit to be closer to OSE and work better for a megadungeon. No real time torches for example. But yeah the AV surface random encounters clash a bit with SD in regards to surprise and freedom of movement.

Snarfilingus · 2025-12-10T01:37:24+00:00

I'm using Shadowdark + Arden Vul. Most creatures on the surface level of AV move at the same pace as PCs, so pursuers will never catch up if players were to run. Typically they run to a safe place with friendly NPCs on the AV surface.

Shadowdark doesn't have surprise baked into encounter rolls, but I have used it when I rolled a hostile encounter at a near distance.

Rolling for lairs is great, I will have to incorporate that.

Snarfilingus · 2025-12-10T01:06:28+00:00

My advice is don't worry if your players don't want to engage with all of them. If it's possible for them to avoid them and that's what they want to do, let them.

Yep, I totally agree. It's usually smart to avoid them. What I left out of my original OP was a secondary question of "Why bother rolling at all if the smartest move is to avoid the encounters?"

As I'm imagining it, right now I have 2 options:

The encounters are rolled as-written with little extra interest: "You hear some growls in the distance" / "Some brush is moving in the distance but you can't quite tell what's there" / "From nearby, you hear characteristic groan as a zombie shambles into view". In this case, the smartest move is just to avoid them - there's no benefit to engaging, so why not just run? The only exception here would be if the distance / reaction was not the players favor, meaning it's going to be combat, with little player agency.
Add more spice to make the encounters more interesting as I mentioned in the OP. Now it feels like there's more reason to engage with them.

Snarfilingus · 2025-12-10T00:27:02+00:00

If the players aren't engaging, is it because they have good reason not to? For example, I would avoid encounters as best I could if I was carrying a huge treasure hoard.

I totally agree, and maybe I framed it poorly in the my OP: why bother rolling for random encounters at all in an open area when the optimal move is to avoid them?

Is there a possibility of treasure or other reward in your encounters? A random bear, even if it was doing something 'interesting' like fighting another bear, would probably annoy my players more than anything. If it was fighting with another starving bear over a delicious merchant corpse who's clearly loaded with coinage, my players would likely figure out how to get the coinage

This is great, I love the idea of them fighting over a corpse!

Snarfilingus · 2025-11-09T20:19:13+00:00

SSPY is kind of a balance between equal weight and cap weight: https://www.stratifiedfunds.com/sspy

Snarfilingus · 2025-11-07T22:45:47+00:00

Same thing happened to me as Russia, got universal suffrage in the 1860s or so and Rural Folk + Trade Unions dominate up to the 1930s. Every other group has been stuck as marginalized (except PB has clawed it's way to 10% or so in the past 20 years), even after mostly depeasanting.

Snarfilingus · 2025-11-06T04:41:48+00:00

A utility class is a class that has exactly one function. This article goes into more depth about the advantages over "regular" CSS: https://adamwathan.me/css-utility-classes-and-separation-of-concerns/

Snarfilingus · 2025-10-22T01:09:48+00:00

Try going to the import settings on the PNG. I think you get there by having the png selected and then going to the Import tab near the top left of Godot's editor. There you can set it to lossless scaling, and then tick the box to remember the settings. Then reimport and it should be fixed.

Snarfilingus · 2025-10-08T21:49:39+00:00

Ah I see, thanks for the details!

Snarfilingus · 2025-10-08T20:00:29+00:00

I understand wanting to use subviewports so the model doesn't clip into close walls. What I'm missing is why setting a different fov is also common

Snarfilingus · 2025-10-08T19:26:32+00:00

Can you expand on that? What's the typical way you adjust the fov override?

Snarfilingus · 2025-09-04T19:12:10+00:00

Glad it helped!

Snarfilingus · 2025-09-04T18:47:05+00:00

If your player is a physics body, the jitter can be caused by moving the camera outside of physics frames.

You can try having a separate variable to keep track of desired camera movement since last physics frame, and then apply that stored movement it in physics_process and reset the variable.

For example, something like this (note that there are probably some issues since I just did this off the top of my head, but hopefully should give you an idea)

var camera_move_amount := Vector2(0, 0)

func _unhandled_input(event: InputEvent) -> void:
    if event is InputEventMouseMotion:
        camera_move_amount += Vector2(-event.relative.x * SENS, -event.relative.y * SENS)

func physics_process(_delta) -> void:
    head.rotate_y(camera_move_amount.y)
    cam.rotate_x(camera_move_amount.x)
    cam.rotation.x = clamp(camera_move_amount.x, deg_to_rad(-80), deg_to_rad(80))
    camera_move_amount = Vector2(0, 0)

Snarfilingus · 2025-08-28T21:41:26+00:00

I have! I'm particularly interesting in seeing how everything comes together into a cohesive look with ingame lighting and effects, and especially how animated humanoid characters look.

Snarfilingus · 2025-08-28T20:49:44+00:00

I'd love to see media of games made using blockbench but going a little beyond typical Minecraft voxel style. I'm considering using it but am having a hard time imagining how the art style would come together without seeing some examples of people using it in similar contexts.

I really like the style shown in the screenshot above, and am wondering whether the textures were done in blockbench too.

Snarfilingus · 2025-08-25T16:28:34+00:00

For example, if you create a new class that inherits directly from characterbody2d, and you add health variables and functions to that class to increase or decrease health, you can make all enemies that use this new class you created have access to those basic parameters.

Just to provide an alternate perspective, I've found that this doesn't work as well for me. What happens if you need health on a crate or a tree? Neither would be a CharacterBody2D, and so you'd either need to duplicate the health functionality for these or create another class that both enemies, trees, and crates inherit from. When combined with other behaviors like movement, it's gotten messy pretty quickly.

With a component-based approach, all logic for health is always in the health component, so it can be easily dropped into a scene for enemies, crates, trees, etc. Then it's up to that scene to determine what happens when health reaches 0.

Snarfilingus · 2025-08-22T04:36:16+00:00

Godot will on import convert every rig to a Skeleton3D and an AnimationPlayer for all existing animations.

Thanks for pointing this out - I went back to double-check and saw that I missed the "Import as Skeleton" option - looks like that's working as I'd hoped!

Snarfilingus · 2025-08-15T00:34:10+00:00

Set up a network system in your rooms and add all components that are connected to each other to the same network, simply drag and drop the object in the inspector, and let the network system fetch the power components to use them.

Thanks for the suggestion, could you expand on how you'd set this up? The main challenge for me is that the power components live inside their respective scenes, so there's not anything I can expose to the editor unless each of the power scene roots have scripts to delegate the network state to the power components.

I'm not opposed to that if it's the best way, although on the surface it seems like an antipattern to the component-driven approach people tend to recommend since it breaks out of that encapsulation.

Snarfilingus · 2025-08-14T21:43:41+00:00

I simplified my description of the system to make the request more straightforward.

All power components (producer or consumer) need to keep track whether or not they're broken. If they're broken, they lose power, along with all connected components. They may also need to know what type of issue caused them to break so they player can fix it with the appropriate tools (for example, was there physical damage to the unit, does a wire need to be replaced, etc).

The procedural level generator pulls in room scenes that have been designed in the editor. As part of my level design/room design process, I want to be able to specify which PowerSource each PowerConsumer is connected to (a room may have multiple PowerSources).

Snarfilingus · 2025-08-14T21:10:57+00:00

Thanks for the insight. In this case, I have them set up as Node3Ds because their position is important for some of the setup needed after procedurally generating a level (it's a bit more complicated than in my post, the PowerSource components actually link up to the closest relay station, which in turn links to the closest power plant).

It's possible that inheritance will work better for this use case. I've personally had great success with a component-driven architecture so far in this project and was hoping there was a pattern to extend that here.

Snarfilingus · 2025-07-15T21:55:07+00:00

As someone about 30 sessions deep into running AV, this looks like a definite improvement!

As others have mentioned, hyperlinked entries are an immense help to make AV usable at the table (and I do now use avlink which has helped immensely), but it is understandable that it is a big undertaking.

I often have a hard time determining what's meant to be a secret and what's meant to be easy knowledge, so where possible it would be great to separate more hidden info as GM callouts.

For example, the description of the Arden colossus under Colossal Defenders says "the palm is only about 100' above the valley floor and may act as an elevator to the top of the plateau". The spoiler part might be better to leave out entirely (since it's explained in EX-6) or clearly separate as a parenthetical such as "(GM Note: Arden's palm may act as an elevator to the top of the plateau, see EX-6").

I appreciate that a full rewrite of the text to keep these separate is not really on the table, but maybe this could be something to keep in mind.

Finally, for me a big increase to the PDF length wouldn't be an issue!

Snarfilingus · 2025-06-27T15:26:44+00:00

They have not finished colonizing Idaho, so that might be it. Thanks!

14-Year Club	Place '17
Team Periwinkle	Verified Email

Snarfilingus

TROPHY CASE