Jump to content
The Dark Mod Forums

Leaderboard

Popular Content

Showing content with the highest reputation on 08/11/21 in all areas

  1. NoClip has put out a fantastic retrospective of the Thief games that interviews a lot of the creators on how the game was designed. Edit: New things I learned (or had forgotten & learned again)... - The whole magic system was geared around the 4 elements, which they later played down as such, but they also made up the original arrows, air/gas, water, earth/moss, fire... But noise & rope arrows were too useful to leave out. - A major design idea was "active stealth", one idea of which was creating distractions and negotiating "safe spaces", and a major inspiration was Ken Levine's experience with sub sims, where you can release noise makers and use thermal layers to slip past, both of which had natural extensions in Thief gameplay. - The other game LGS was making right at the same time as TDP was a Golf game. For that game, they had to fill a lot of dead space with commentator patter, which fed directly into using guard patter to fill time since the player was avoiding most things. - I also respected Randy's postmortem of TDS. It was pretty clear he was just as crushed by the design flaws that the rest of the community was (the body awareness supreme backfire, the heartbreaking necessity to break up the levels to meet the XBox memory limits, the render woes & being stuck with a wonky engine, etc.), and I think he did a good job of explained how and why they happened. More or less, he made design decisions before getting all the relevant information that affected what they could do, and some decisions (like body awareness) just didn't work in practice like they may have looked on paper. I can't be too upset. Some good levels and moments still came out of that game, I still love Randy's levels & design thinking (generally), I can understand and very much sympathize with his position and (ultimately mistaken) thinking and intuitions, which I might well have gone along with myself if I were a team member, and above all ... if TDS hadn't been what it was, we probably wouldn't have Darkmod now, and I'm really, really happy we have Darkmod.
    4 points
  2. We could probably at least swap out the menu option for the frob helper with one for the frob outline, since the outline is a much more substantial effect. Or have neither if we don't believe such options should be accessible in the main menu. There are probably quite a few cvar-only settings that'd be interesting to some people, such as texture resolution, that could go in a submenu as suggested by Mircea.
    1 point
  3. I'm in favor of keeping the menu clean and only having popular and necessary options: IMHO that's the softest approach especially for less technical users. As far as the obscure settings go... just a thought: Many games now have a menu that lists all vars and lets you edit them, as seen it in both Xonotic and Minetest. It's a list that dumps all cvars, their value, and their description... you can click on any and set the value manually, just from a GUI instead of having to search from the console. With some category grouping added to the mix this might make some users happier to have. To offer the actual example:
    1 point
  4. The modules are models and thus they are not actually sealing geometry. So a room made only with models - ie no world spawn brushes - will be exposed to the void and will leak. You will need to do what you proposed above which is create a sealed room with world spawn geometry and then use the modules to provide the detail within the sealed room.
    1 point
  5. Isn't it a question of order of operations? In modeling apps you can easily achieve both results, depending on what you need. The only difference is, that in the first example the modelling modifier would be placed before UV modifier, and in the second one it's vice versa.
    1 point
  6. I'm honestly not convinced this belongs in a menu option. You can always change or disable it via cvars as an advanced user, but menu entries should be limited primarily to those options that have the most use to the majority of players, otherwise the menus just get overloaded with a plethora of options nobody will fully understand. If we conclude that the majority of players actually has a use for turning the highlight off, it would be better to kill the feature.
    1 point
  7. Right, sorry. Perhaps this video might be useful. It's precisely about internal leaks, and the map is built using Springheel's modules.
    1 point
  8. I believe if you use the latest dev build, the map compiler will actually emit a warning for leaked visportals and write a pointfile which you can then load in DR. I don't know how much this helps with the situation where you already know where the missing portals are, but you just want to find out why they are leaking.
    1 point
  9. I believe this video by Springheel should answer all of these questions. I'd also recommend the whole series, very informative.
    1 point
  10. I figured most materials in TDM maps will be lit by sources that have a flame-like colour, so this resembles the final appearance best. But of course it doesn't offer a neutral view on the material which might be desirable too. I think remembering the value would be best, please feel free to open a tracker entry for that.
    1 point
  11. I checked out your branch. Everything built fine on Linux, and the basic functionality is good — seamlessly launching the game and going straight into the correct map is very convenient. There's a sizing issue with the dialog: widgets are cut off and the bottom buttons are not visible at all. The SetSizerAndFit() method is convenient for setting a window sizer and automatically setting the minimum size, otherwise you might need to explicitly set the minimum size based on contents as the Light Inspector does: SetMinSize(contents->GetEffectiveMinSize()); Probably I should find a way to refactor this into the TransientWindow base class, since we have a lot of problems with dialogs being shrinkable to nothing regardless of contents. Note that your branch is based on master from about a month ago; I recommend rebasing on the latest master (either mine or Greebo's) to get the latest changes and minimise possible merge issues. I will be interested to see how the hot reload functionality interacts with the 2.13.0 light brightness slider (hopefully it does not collapse under a flurry of tiny updates). Overall this is a massive improvement from the menu-based version, especially the autolaunch and dmap. I can definitely see myself using this as the main mechanism for testing map changes, rather than manually running the game from a terminal. Good job.
    1 point
  12. Our forum rules state that personal attacks and harrassment are off-limits. Coming from a specific country or culture doesn't give license to blatantly flout them, i.e. by alleging mental illness. I believe everything that needs to be said has been said for now, so this thread can be locked.
    1 point
  13. Well, we (speaking as TDM team members who are unfortunately forum mods too) could easily have pulled the trigger on the ban and lock buttons on several occasions already, but usually we prefer to handle this like adults (as you put it) and we talk it over, that's really the only reason this thread is still alive. Though we all can remember people being banned in the past (it must have been two members over the past 16 years, if I recall correctly), it will happen if people are really asking for it. I personally am pretty tired of seeing threads being bombed with that kind of bullshit. What hurts me the most is that this kind of thing is directly subtracted from the team's productivity. Devs as the only mods here have to deal with forum bullshit instead of developing source code or entityDefs. So I'd really, really appreciate if everybody pulled themselves together and make this a nice place to be around, discuss and work on TDM stealth gameplay.
    1 point
×
×
  • Create New...