MirceaKitsune

A simple and effective way to make better use of sound is to allow overriding and randomizing the pitch and speed of a noise. A constant or random pitch / tempo offset could be defined as a new sound shader parameter, which like others can be specified in the sound definition or overridden by the speaker entity individually. There are at least two use cases where I think this simple feature could make a notable difference: Random interaction sounds and AI voices. Random sounds: We already play a random audio for every footstep or movable collision. In my book that's already good enough. But if the engine supported customizing the pitch we could have even better results by also randomizing that by a slight +/- 10% per executions. AI voices: AI could make use of a special spawnarg that gives each character a permanent pitch / tempo offset, making that character talk at a higher or lower tone or speed. Obviously this should not be abused as we don't want people in TDM sounding like cartoon characters or demons from hell (except for undead), the offset should once more be something among the lines of 0.1 roughly. But this slight offset could make it easier to give more personality to characters, giving a buff thug a slightly deeper voice or a wimpy nobleman a slightly higher pitched one, all without having to store or load any extra data.

I think those look a bit better: They inflate / deflate the original mesh across its normals which is the best pattern. The only issue I see there is the deform is constant, vertices should be waving in order and out of sync with the order unique per instance. The other issue is you can't limit and scale the effect per vertex using some kind of mask, which would be necessary for pinning the roots of grass blades or clothes on AI so they don't come off and cause visible gaps in the mesh. If that can be fixed, just add deforming from the intensity of a speaker and do the same for pushing particles.

I had a question for an idea I'm thinking of but haven't yet created a map for. I presume it will require scripting a custom entity, I did it before so that's fine if that's the case, but I'd like confirmation that the functions I'm thinking of would work as expected and what you think the best script structure is; I'd basically like a reusable entity which when triggered, changes the visibility / model / skin on all entities it targets. The plan is to use this in a few exotic ideas for maps that mess with the player, allowing heavy modifications to rooms when the player isn't looking, without having to make copies of each area and teleport the player there which isn't seamless: I can use this as a workaround to our lack of warp zones in some situations to make places change heavily using smart trigger placement. The goal is to transform building modules and furniture including objects, such as switching a wall panel between the version with and without a door or a drawer between its covered and non-covered variant or a piece of furniture between the polished versus worn out version. Show / hide: I already know how to do this for mere func_static entities, you just set the initial visibility flag then trigger that entity. The problem is more complex entities, from movables to loot to AI. The later is especially important as I want AI and ragdolls appearing in and out of existence without having to teleport them each time: When turned off the AI should suspend all logical processing and become invisible / non-solid including all worn attachments, when made visible again the AI code and patrolling should resume from where it left off. Change model: I should mainly need this one for func_static entities, though I could use it on a few other things like doors... if the engine doesn't complain I may even switch the body and head model on AI to make characters subtly transform. I just need a way to set a new model on a static entity which also updates its collisions, ideally in a way that's precached so the engine doesn't hiccup during the change. Change skin: Should be the easiest one and should work on anything if changing the model does; I need the ability to change the skin on the selected entity to the given skin definition. I'll be heavily using this to change the colors or quality on building modules, changing paintings, possibly editing loot items to change vases between gold and bronze though in this case I'd also need a way to change the icon it displays after being picked up.

Ok, so our shaders already support vertex deform, it just wasn't used yet. This is a good start! Though the surfaces seem to disappear if they move too far away from the source, is that something that can be avoided? Can you make a video of that demo showing the two deform types mixed? I think neither looks realistic on its own, but combined they might look better. We need grass to look like it's wavering, the bottom fixed and the top more flexible. Also what does it look like on a cloth banner? Obviously use a patch instead of a brush so it has enough vertices to deform, bend it a little if necessary to give it enough initial geometry since I remember patches would self-optimize.

That's very interesting, thanks for laying out the current possibilities so well. It's better than nothing at all. But as can be easily seen, they are very limited in how far you can go. Engine changes would be needed but greater and more difficult things were achieved. The worst thing is like you said we can only deform texture coordinates not real vertice positions. Essentially TDM only lets you use fragment shaders but not vertex shaders, and it's the later we need to apply a sine deform to, although in other engines GLSL lets you use both as necessary. Vertex deforms need to be exposed in our shaders to allow any realism for banners swaying in the wind or the clothes and hair on AI as they walk through windy areas. Then there's the issue that the direction and intensity of the deform doesn't match that of the wind. This can be manually done to some extent, by adjusting the direction of the func_pendulum for each grass blade, but it's so tedious you'd need to use a complex script to set it especially if you want to spawn a lot of grass with a seed across complex terrain so it's not worth it. With the system I'm envisioning, the mapper places the same func_static flag model in multiple locations and each will be pushed away from the wind source automatically, also the flame particles on torches as well as candles the player is carrying will be automatically pushed away in the correct direction wherever they're located or moved. There's also no actual variation this way. My idea of using sound intensity like for flickering lights would allow making plants and particles pushed by the wind based on the volume of its sound at that moment, of course multiplied by attenuation based on the distance of the wind speaker and the distance of each vertice / particle from it. We can even apply a delay based on distance from the sound source, so whenever it gets louder you see the wave traveling across cloth and grass blades, once the base system is in place details like this should be far easier and look amazing

I forgot what technique that demo used but it was quite impressive. I'm away on my laptop and using mobile data so I can't watch too many videos just in case, but I remember seeing that a while ago though not exactly what it did and how. Particles are one component, the equally important part is GPU deforming vertices on any mesh in the direction of wind. In the meantime I need to patch up my idea as I realized there's an even simpler way of going about it. We shouldn't even need a new entity at all, wind can be done as a sound property on speakers: Just like s_shakes allows a sound to make the camera move for the earthquake effect, so too could we have an s_wind defining the magnitude by which vertices and particles move away from the source, similar to how lights flicker based on the lamp's electrical noise. The existing sound propagation system may be usable to make wind blow through open doors depending on how cheap that is, but having the wind noise itself do it definitely makes sense.

Bonus 1: The system can also be used to simulate simple soft body physics. Obviously collisions will not be affected and vertex deforms are done by shader and purely visual. But it can also be used to make movables with soft parts have those bits that lag behind when moved, for example a pillow can have its edges pushed behind slightly if you frob to pick it up then throw it or move the camera around to make it dance in the air. Bonus 2: Explosions such as mines or the fire arrow should also create a temporary wind source, in RE grenades do this and make all trees move away from the blast. Bonus 3: If portals connect rooms with different wind values, opening a door should make vertices and particles near it waver to simulate drafts through doors and windows.

I should start by saying the suggestion was inspired by this exact feature being successfully implemented in the FPS Red Eclipse (Cube / Tesseract engine) for a long time with very good looking results. I'm a developer or at least mapper for RE as well, if you need more information I'll ask its admin Quin for more technical data on how the system works. I can also find or create a video showing how the wind mechanism functions if anyone can use that. TheDarkMod currently lacks any real system for simulating wind: If you want to make a FM that takes place in a stormy environment that looks good, you're out of luck. All we have is a handful of animated props animated to appear as if swaying in the wind, namely a tree and banner that move slightly: You can't adjust the intensity nor the direction of the wind effect, at best you can maybe tweak the animation speed to match the wind strength you'd like to depict. There is a much better way using vertex shader deforms defined in the global shader. The first step is defining wind direction, this can be done as a property of the location info and / or using an entity for radial wind direction. When touched by a wind value above zero, models (static or animated) will play a sine wave animation on vertices, its direction and distance and frequency defined by the wind entity spawnargs and the entity's distance from its epicenter. Obviously models must specify which vertices should be wavy, the most common way is using vertex colors though an intensity texture also works if that's preferred, in any case models must include per-vertice information to specify which points should sway in the wind and by how much. Particles also need to be blown away by the wind but that should be very simple, further effects like affecting the direction of noise transmission are optional and can be done later at best. Existing assets will need to be modified to make use of this. This includes every tree and grass so branches and leaves are affected by wind the further they are from the trunk and the base of the tree, obviously this should also be done for all banners and even the clothes on AI so you can see the the sleeves of characters flutter in the wind. All particles should be affected including flames and smoke so torches blow to the side. Note that old maps would not be affected even after the assets are modified since they'd need to specify wind information for the effect to activate.

I sort of like the builtin difficulty settings... sort of: I agree that their number should be customizable, having to use 3 is a bit limiting. I imagine this could be solved in the future if desired, obviously without breaking old FM's so they're left at the existing Easy / Normal / Hard settings if one doesn't specify otherwise. I remember seeing FM's use the All / The / Same setting and can't say I approve of that even if I ultimately don't mind: If you have a difficulty setting, make use of it to offer as much variation and choice as possible. You can change some things in the map very slightly, at worst just tweak the count in the loot objective. I even thought of using them for heavier differences in some of my FM ideas, like changing seasons or daytime or the start location and thief character you play based on the difficulty.

Idea: Maybe add in a FM independent achievement system, similar to Minecraft's as a concept but of course for TDM stuff. So one for your first mantling, for putting out the first torch and candle, knocking out the first AI with the blackjack, knocking them out with a movable, one for killing your first AI with the sword, one with killing them with a broadhead and fire and gas arrow, blinding them with a flash bomb, beating a FM on every difficulty, finding all loot, getting 0 stealth score, etc. The list of all achievements should be visible from the menu, including ones you haven't beaten so you can click on them to see a description of what you're supposed to do. Players who want to know every aspect of TDM would seek to 100% the list and will do everything at least once.

Yeah, that's the thing: I wouldn't want it to be thought of as a penalty. Rather the FM wanting you to play the difficulty levels in order, if it has a good reason for it and promises to make it worth your time to play it 3 times for each.

That is a possible workaround for now I think. The idea is being able to use the same map, just filter different entities and events by a setting: Campaigns should be able to do this too using persistent data and loading the same level 3 times, only issue may be the briefing would repeat every occurrence. The FM Eye on the Prize by Amadeus is what inspired my suggestion. No big spoiler to say he used a different biome and weather system for each difficulty level: This got me wondering if I could do something similar and beyond, where each mode does affect difficulty as expected but also alters the environment and represents a different chunk of the story.

I'd suggest this too, there should probably be a simple sound flag to support it. Make it a feature for all looped sounds: I can see many situations where you'd have the same looped audio in multiple locations from which you hear it simultaneously, but because they all start playing at the same moment, you'll hear them in unison which will sound unrealistic.

It may or may not be a simple fix. Light flickering uses the ingenious method of making lights flicker based on the sound shader: The most logical way to get more realistic flickering is to look for a better electric sound, I believe you simply set it as the s_shader parameter of the light to replace the default one.

It's good to suggest a simple feature that if desired would be simple to implement, given the hardest difficulty beaten is already recorded in permanent mission storage so this should only require a mere GUI flag. I was thinking the FM should allow progressively unlocking difficulty levels, meaning you must first beat Easy before you can play Normal and / or beat Normal before picking Hard. The main reason is I've seen FM's use the difficulty in ingenious ways that relate to the story: Apart from just increasing the actual difficulty, FM's may change areas or story elements for each one... in this case you may want the player to play through them in order. Imagine a FM where there are 3 thieves and each difficulty level is playing one as they run into each other robbing the same mansion, each thief spawns in their own home with an unique set of tools while the other two will be AI in the other homes... for the full story to make sense you may have to first play the Easy thief followed by the Normal thief then the Hard thief. Otherwise this can be a great way to increase replayability, a complex FM can tempt you to play it 3 times rather than just once. But this should only be used under the condition that the FM has unique changes in each difficulty mode, it should always be done with the promise that you're bound to discover something new when playing on each setting.

I should mention that if portals were implemented, I already have a few FM ideas for using them in mind. Not to be taken as a promise since I'm working on over a dozen FM's for nearly 10 years and only released one so far. But if the feature got added, there's definitely one or two unique concepts I'd already attempt, which I could try either way but in a much poorer and more limited fashion using any of the possibilities currently available. For my ideas at least, only the player would need to travel through warp zones, objects and AI would be deliberately limited as they'd each be bound to their own world. Of course that too should be supported for maps that need to seamlessly stitch all aspects of the world, but things like AI navigation are among the parts that can be put on a TODO list and done later, with working use cases existing even before then.

I like the idea. As someone who plays TDM for 10 years now, so many things are obvious to me... yet it's easy to tell that for someone new they'll take a while to figure out many of those details, for which those tips would be pretty handy. More circumstances could be covered in the tutorial level too, I only played it when I first found TDM and it taught a few things like mantling though some of the fine details seem to have been missed.

Oh I so enjoyed this. It's officially one of the scariest TDM FM's ever made in my book, the ambience was phenomenal and I loved the premise just as much. No spoilers to say this much: The moment you set foot in the town let alone the home, you instantly know something is wrong and have a rough idea of what's coming, just not exactly what it will be and when. The more it stays silent the more uneasy it gets; I expected something to change as I turned around after interacting with each readable or loot, every corner to have a potential jumpscare, I was even confused whether a few sounds where triggered by me or random ambiance playing at just the right moment. Pretty terrifying and I loved it! Found almost all loot just a few hundred short.

That sounds similar to the existing X-ray, may already be doable with it to some extent. For such a system we could just make some entities only visible through a surface, then permanently visible when walking through that surface and entering the portal. But it's far more limited to having proper warp zones, you can't simulate inter-connected spaces which is what could make some FM's really interesting.

For the basics I think we do. The main difference between portals and cameras is the camera renders from a fixed angle, a warpzone is see-through and depends on the camera position... the skybox might thus be a better candidate to base them on, except not rendered in 360* but acting as a distant visportal. Other than that the details may get complicated. Datiswous just pointed out yet another one: AI being able to see and recognize the player through such portals is yet another thing that would need to be implemented manually, the view cone would need to travel through the warp zone too. I think rendering and basic player / entity travel would be most important to get first, then all those other TODO's can slowly be done over time, with mappers informed of the limitations in effect at that time.

Thanks: I used to play with Unreal Editor ages ago, brings back memories to see all that. I did remember that our visportal and location_info system is very similar to early UT's in how we define and separate rooms. As far as portals go, UT seems to be doing it via location info. Doing it per portal seems ideal, especially with func_portal already being there and easy to use for this purpose: I'd imagine that way you can still have a normal room, but only a particular door or window leading to an altered version. Also easier for mappers to understand, just link two func_portal entities together and that's it... rooms with multiple portals that don't match would have to throw errors otherwise.

It would definitely require engine changes. I think the basic building blocks should be there: We have custom render passes for stuff like the skybox or dynamic mirrors, the rest should be entity teleportation. But it would definitely take one of the devs with experience in the engine and renderer to decide if it's worth their time to look into this.

That sounds highly plausible. If disk performance is the bottleneck, the obvious solution would be to write the demo in memory and only save to the drive once you stop recording. Though with such large demo sizes that could cause some players memory to fill up: Dump it in steps instead like say every 100 MB or 1 GB, or do so every 1 minute if using a timer is better. Indeed it's not the scale of the map that matters but the number of entities, large maps tend to have more objects so usually one follows the other. The solution here would be to only record entities that changed: If a 7.5 MB demo was generated just from me moving around and picking up loot for 15 seconds, it was likely not recording just my movements but the state of every entity per frame which is extremely wasteful if that's the case.

Just got around to playing this and I enjoyed it! Always love a small FM with a silly premise yet a lot of heart put into it. One of the few times I found all secrets and all loot on my own, that almost never happens A little feedback and small issues I found:

Played the other difficulty levels and I must add: Fantastic work using them to create the seasons! I can't believe you managed to do all that on the same map just by filtering different entities. Love how everything is different in each one, the attention to detail in this was amazing.