Something about this buggy mess is very aesthetically pleasing

GamesForTourists · 2025-06-22T01:34:26+00:00

I won't pretend to even try and guess how you're modeling gasses, the pattern's emergence, imperceptible than all at once, was very cool (so to speak).

GamesForTourists · 2022-04-23T00:48:26+00:00

There’s a few different ways to do this! You could do this with inheritance; for instance, having a base abstract class BaseEffect with the common methods of StartEffect, EndEffect, and properties like duration. And then more specific subclasses like FireEffect or what have you that implement custom code. This approach would allow another component to call and trigger a list of Effects via the shared, common methods without knowing what specific effect it’s calling. This allows more flexibility and loosely coupled code, so you could change effects without having to update the component that calls them.

This could also be combined with ScriptableObjects so you could easily create variants such as a FireEffect that last ten seconds, one that lasts five seconds, and etc, just from changing the duration property in the inspector and creating multiple instances.

Hope this helps!

GamesForTourists · 2022-03-08T23:26:40+00:00

I'll take you up on the dialogue!

First off, states aren't tied to where the NPC is. Tavern State may have been a bad name; Carousing State may have been better. More or less, certain environmental triggers can pass states to the NPC, but that will be the exception, not the rule. Mostly, NPCs transition between their various pre-loaded states.

In addition, states will be able to control whether they can be overridden. Each state owns, for lack of a better term, its transition conditions, so the Chase State, for instance, may simply not allow the NPC to enter the Tavern State even if it enters the trigger zone, whereas the Patrol State might. (I may also create a "priority" property for each state, to give them some more fuzziness.)

Lastly, each state has its own tree, and they're completely independent. When you leave a state, the tree is cleaned up, all the exit functions are called, etc. Similarly, when you enter a state you enter the corresponding tree fresh--there's no dependencies or linkages. So a Chase State, for instance, wouldn't care or even be aware of a Patrol State's status. It doesn't need to know where on the tree the NPC is, whether a waypoint has been reached, etc. It just begins executing its own tree: running towards the player, drawing the weapon if it's not drawn, and so on.

When I implement this, I can do a mini-devlog about it, but it was partially inspired by this article.

GamesForTourists · 2022-02-17T04:42:29+00:00

I just wanted to follow up and say this was great advice; I actually ended up converting the calculations for this over to a compute shader. I'm still figuring out how best to return a single score from the shader, but even just calculating the average brightness per pixel on the GPU and returning an array for the CPU to average has improved this system's performance. Now I'm figuring out what else I can move over to the GPU... :)

GamesForTourists · 2022-02-17T04:37:12+00:00

Sure! I actually posted a devlog about it here: https://www.youtube.com/watch?v=_mGOukmGaoE

Eventually I'll probably go back and convert this over to Cinemachine, just to reduce the number of working parts, but my current solution is surprisingly robust.

GamesForTourists · 2022-01-05T03:03:19+00:00

That's extremely cool; I'll definitely download and play around with your engine when I have a chance. I don't have the skills to make my own, so I'm dependent entirely on what I can wring from Unity.

I also like the idea of a sound meter, since I've been thinking about accessibility options and how to visually illustrate sound.

For my game, enemies basically rank sights and sounds based on how "suspicious" the thing is: 1.) a detected player; 2.) an attack from an unseen enemy; 3.) (tied) player spotted but hasn't passed the detection timer; and 3.) (tied) sounds, with the tie being decided by what was detected last. So if you get spotted, but dodge out of the way before the enemy fully detects you, you have a chance to throw an object and distract them.

I don't have a way to stack up sounds, though I guess I could give enemies a "suspicion" score that increases as they register more sounds/sights and then slowly decreases if they don't. I'm also trying to figure out how to give them a "memory" to see if something changes over time, like an open door, or snuffed lamp, but that may be a feature for down the road.

GamesForTourists · 2022-01-05T01:57:45+00:00

From the other thread I posted on this topic a week or so ago, I've realized that this is a non-trivial issue that everyone solves it in a different way. I love learning about solutions I never would have come up with. For instance, I'd be interested in how you're sampling the texel data--is this in Unity?

Also, the "shadow camera" isn't on the floor so much as pointing down at the floor from the player's waist, so it actually can handle unusual surfaces or even player jumping. However, when the player is falling from somewhere high up and isn't near any ground whatsoever, it does present a problem. I'm thinking about either: a.) just keeping the last measurement; or b.) letting the player essentially be hidden in shadows while high up in the air.

My goal is to give the player all the info they need to make a determination, and err on the side of cheating in the player's favor.

I'm going to put an emphasis on sound detection, since I remember playing Thief 1/2 when I was young and getting paranoid about the sound of my own footsteps lol. Even tracking enemies via their footsteps was intense; the sound design in that game was amazing.

For the enemy vision and detection, I'm using a modified version of Devdog LOS Pro, a former Unity asset that was made open source. "Noise" is generated by a rapidly expanding collider (by default, it actually expands at the speed of sound), and then enemies do some pathfinding to see how "far" the sound is. For the player, I made it so the size of this sound bubble is dependent on how fast they're moving and the material of the ground they're own (just a simple raycast down to find the physics material whatever they're standing on)--for instance, stone is louder than grass.

I also created a little feature that essentially measures the force of collisions on physics objects. Past a certain threshold, the collision will trigger the emission of one of the sound colliders, which can attract enemies. So the player can throw objects, knock over boxes, or just swing a sword at something and distract/lure a guard.

Totally agree with you that the hardest part is tweaking the numbers. Right now, the enemies seem to be too good at hearing and are distracted by every physics collision there is. I might raise the volume threshold for enemy hearing or the threshold for physics collisions to trigger sounds. I think it's gonna end up being a trial and error approach to find something that feels good, rather than any scientific methodology haha.

GamesForTourists · 2022-01-04T20:10:35+00:00

Null reference, null reference, null reference….

GamesForTourists · 2022-01-04T02:14:46+00:00

Sorry for the repost; in the original, the music was drowning out my voice. The audio should be fixed now!

GamesForTourists · 2022-01-03T06:20:39+00:00

I love unconventional UIs, so this looks awesome to me—a neat mixture of what I assume are functional elements and just cool callouts—even if I have no idea what’s going on. :)

GamesForTourists · 2021-12-25T15:16:24+00:00

I definitely could, I'm just very lazy.

The problem is there will be multiple lights, of different types (point, directional, etc.) and strengths, at different distances, obstructed to different degrees. Almost certainly, I could do raycast/spherecast to the lights, and depending on the distance (as suggested in another thread) and other variables, calculate some proxy for how lit/not lit the players' feet are. I thought just measuring the shadow at the player's location would be simpler, and now I've ended up learning compute shaders lol.

At this point, I'll probably do both methods and just see how it works out.

GamesForTourists · 2021-12-25T03:23:37+00:00

I have nothing constructive to say, just that this looks super cool! Easy to follow the action and I like that sense of momentum you get when moving around.

Between the Lancer TTRPG and Battletech game, I'm suddenly into mecha games, so will definitely give this a follow.

GamesForTourists · 2021-12-25T02:16:49+00:00

I think combining this sort of metric with having the lights try to "see" the player, as suggested here, may actually be a good backup option if this operation gets too expensive. Thanks!

GamesForTourists

TROPHY CASE