peter_spy

Actually, quite the contrary. With manual saves, you quick save/load your way through the map without ever facing the consequences of your actions, if the route or plan you choose goes wrong, or in the way you didn't expect. With limited or no saves you have to go with the flow and think on your feet – and that's when you really see the emergent systems at work, to full extent. With infinite saves players typically choose the safest option and they're done with the mission, instead of choosing a different approach in another playthrough. And then they can boast of the forums that they finished the mission in 30 minutes on expert and it was a little too easy for their taste Edit: and while I like to use cheats in FMs, e.g. to give myself a sightseeing tour and admire the views/ambience, I'd never edit anyone's map. IMO it's a sign of disrespect. They did what they could at the time, with the knowledge and resources that was available to them. It's a finished work unless they'll have another go at it, it's not up to me to mess with anything they created.

Yup, and at this point it's not even a console feature, as these games are on PC too. In general, in last ten years or so, game designers got really good at making the checkpoint systems almost invisible to the player, who doesn't have to think much about saving their progress. At the same time, there are devs experimenting with both im-sim genre and e.g. rogue-lite features. Prey: Mooncrash did that really well, ditching manual saves, but carrying some of the things throughout your progression. To me it was one of the most fresh experiences back then, and I've heard Deathloop is going further down that road as well (can't wait to play it!).

I brought that up because there is no polar opposition here or contradiction. I thought it's obvious and not worth discussing over and over again that there is an authorial intent, even in sandbox or im-sim games. It's just that the author is giving players toys in a controlled sandbox environment, and they're just not authoring the experience in a linear way, minute per minute, as in other games. But authoring the experience is still there, just in much broader sense. Again, obvious things for im-sims and sandboxes. And I was opposing the cvar for overriding the save system, because it can be more much more influential than just level design tools; as in both Kingsal's mission and other games using different approaches saves (or lack thereof), you can see that there is a potential to create basically a new gameplay type, or at least adding some fresh elements. Roguelike/time trial levels for speedrunners, adding old Resident Evil kind of pacing and resource management to the mix, etc. Adding a cvar to override this is like adding a save system to Quake deatchmatch, or a fighting game.

Can we skip sunday school for im-sim level designers? I believe everyone here knows that, and that we're talking about saving system, which is higher in the game systems hierarchy than level design tools, while obviously influencing everything down the line.

It's not about my enjoyment, it's about author's intent. If someone wants to create an FM with different saving methods and resulting gameplay, they should be able to do it. They don't always have to cater to everyone. Save scumming is a term decades old and it's commonly used; "compulsive saving", if you need to be so formal.

That would be a huge and firm no. If you want to cheat, you already have god mode, noclip, notarget, etc. Limiting or removing saves in FMs is not only a new way to prevent save scumming and letting the emergent systems work, but it can also allow to create missions that are more akin to roguelike games: focused on short runs and replays. Overriding that with a cvar is taking control away from mission authors just to satisfy players who don't want to change their habits or can't be bothered to understand gameplay concepts other than classic Thief gameplay.

I wouldn't say that the dark outline is the best solution. According to these screenshots it looks more like toon shader, like in Borderlands: Adding fresnel won't help either; it works great for curved surfaces like spheres or models with bevelled edges, but will never do anything substantial for simple box shapes like doors.

In practical terms it's not that simple though. When you use omni lights to to fake light reflecting off surfaces across the room, their radii can overlap somewhere "in the air" without hitting any visible surface, and be large enough to hit the player light detection cone or whatever is used for lightgem calculation. It can look weird and erratic ingame. And having such tool isn't uncommon practice either. Even Thief Deadly Shadows had a LightWeight parameter, which was a multiplier IIRC, so you could decide how much it affects the lightgem.

When you set r_newFrob to 0, the frob outline preset is still there, so you can have your custom frob set in material file, but it will always be with an outline Perhaps there should be something like r_frobOutlinePreset 0 (no outline) as well?

Nice work! Ray quality looks much better than the last time we've worked on this.

To be honest, I've been thinking about resuming my modeling and map work, but this is a total showstopper for me I like neither the idea of my hard work being modified by anyone, but selling it is much much worse. Technically, I could release my stuff with low quality textures e.g. 512px to deter asset flippers, but it kinda undermines the whole effort of making high quality environments. Until there is some kind of asset package protection, a or way to binarize assets a la RBDoom3BFG, I don't see the point in continuing work that can't be safely released

In other engines, static mesh class itself already has attributes like material path, skins, LOD settings, etc., but the model has to be imported first. So instead of having a separate "LOD entity", it would be better to have these attributes either moved to func_static class already, or, requiring models to be assigned to an entity with all the proper spawnargs.

I'm not sure if that's a best example, but I was trying to stress the physics system a bit. I'm using moveable ball models, all having that 16-polygon CM above. Just for fun I gave them friction 0 and bouncyness 1, to make physics work harder than usual. And I was able to get to 150 balls without going below 60fps: Given that this is a synthetic test, and in typical situations you won't need more than, let's say, 10 objects interacting with each other simultaneously, it seems to me that those limits could be raised like ten times, and it shouldn't hurt the performance.

That makes sense, but going from that to 16 polygon limit seems really extreme to me. In practical terms, you can't create a shape more complex than this: Since physics is done on CPU, it should be pretty scalable too. I doubt that mappers or content creators will want to go beyond something like a bowling mini-game So perhaps it would be worth trying to set it at, I dunno, 1024 polygons per CM, testing it on a few objects, and going down until the game works in a stable manner? Btw. I was trying to find any info on any hard CM polygon limits for engines like Source or UE3, but couldn't find anything.

Not DR but engine-related question: is there a reason for idMoveables collision model to have such low polygon limit? I know the game can be wonky, but it's impossible to make even a really basic round shape with such low limits.

As for the LOD confusion, it kinda seems like you created the problem yourself, moving stuff to very different folders. Typically, you don't have time for making more than one good (LOD1) version of your model, so the clutter in the model folder is usually minimal. What I've seen in TDM stock assets though, is that models can have unnecessary LOD stages, where e.g. LOD1 is 1500 tris and LOD2 is 1200 tris, for example. That makes little sense. The rule of thumb is to have around 50% vertex difference between each stage, so changing between models gives tangible performance boost.

Hmm, upon closer investigation, it's not like AAA titles handle it in a 100% consistent way either. For example, Dishonored 2 dropped the outline for doors altogether: And for windows, it's often visible only after you open them: Edit: I guess the reason for not having super tight outline system is that they might have been relying on an interaction prompts more (which I turned off and forgot about it):

I wonder why this is such a huge issue. Such outline is being used in tons of both AAA and indie games nowadays, and it works correctly. I bet it's something you can either find for free, or buy in a Unity or Unreal Marketplace for a few bucks.

That bloom and fog reminds me of Deadly Shadows a bit, good old mapping times

Outer Wilds is definitely on my list, it's been receiving nothing but praise and I've seen gameplay videos too, it's very intriguing

Nope, Parvati. Currently I'm on Monarch and I wonder if there's going to be anything interesting here.

I've been playing The Outer Worlds a bit, but apart from a one companion that's well-written and voiceovered, the whole game is flat and lifeless. I really hoped it would be more like FNV in space.

That^ seems like overthinking. If water arrow + torch = light off, players will expect it to work every time, whether it's moveable or not. I'd expect that just hitting a guard with it should make him drop the torch and start investigating. IIRC Thief 3 did that with both water and moss arrows.

At least when it comes to objects inside containers, it was always easier for me to just set them to hide 0 and use target links from openable element. Since the problem is with ignoring geometry when tracing frob entities, adding more geometry doesn't seem like a solution to me. Making objects invisible until container is open works every time.

There was a Splinter Cell installment where Sam could whistle to attract guards to a spot and then evade them. The sound range of this whistle was pretty small, so often it felt awkward that it isn't heard in larger distance, but IMO that wasn't the main problem. As we all know, stealth games like SC or TDM these are about scanning the environment, assuming a strategy and trying to execute it. The finite aspect of player resources is important and makes for different setups mappers can create. Whether it's a whistle or a mic-based sound, you're giving the player an infinite resource to cheese through your map, and it makes the gameplay awfully boring. I bet that the number of mappers that would want that is excatly 0. Exactly. Not to mention implementing the whole idea, which can easily get complicated, like guards reacting differently to different sound levels your mic produces, etc. Good luck making predictable player tool out of that, and then teaching the player to use it effectively (long story short, that's a hell no from me ).