Special Fm Feature Requests

[SneaksieDave]

Okay, since it hasn't been done yet, I'll kick it off. First let me say, I assume this thread is to contain requests out of the ordinary, as stated by sparhawk at the TTLG forums:

 

 

QUOTE

I'm not talking of the standard features like buttons, switches, or similar stuff. Rather I'm thinking of things you might have wanted to implement in an FM but you couldn't because of limitations in the engine or in DromEd

 

 

 

as opposed to the obvious, like rope arrows, swimming, etc.

 

So here's a few ideas just to get things going.

 

-random treasure spawns. An author would place a piece of optional treasure, and set a percentage chance that it will appear or not.

 

-optional path nodes (although I think this might already be possible with Dromed). The AI can choose to ignore a node or go on a different, separate path altogether.

 

-AI actions similar to NOLF2. I never played the game myself, but I'd heard they do things that are unexpected, at unexpected times. Many times I've played Thief and thought to myself, "why is that cook just pacing back and forth?" Clearly for gameplay, NOT realism. "Why would a guy just be standing here in a dark room, facing the wall, then turn to the fireplace, back to the wall, back to fireplace, etc?" Again, gameplay, not realism. I'd heard that in NOLF2, AI will often kick a can around, or fidget (already in Thief), or even leave patrol to go to the restroom. That sounds like a fantastic addition that might really lend some tension to the overall experience.

 

-AI ladder climbing. Touchy subject, that, as it eliminates some safety and comfort in the game, but probably a good addition.

 

Okay, there's a few for now. What ideas would you suggest?

[Guest Ottoj55]

intelligent ai behaviors, such as in far cry, ai rush to an injured friend, draw weapons, then start searching, you hear them shout commands to each other as they move. the entire search is systematic.

 

convincing keepers assasains, come on, silentsleep did better in equilibrium with the dark engine then ion storm could do in their fancy engine.

 

a wider variety of weapons, i made gas bombs in dark, i almost made moss arrows choke ai like in deadly shadows in dark, the motions were wrong. it would be interesting to see the player pick up a mechanist mace and smash in a door instead of just throwing it at the door until it opens.

 

a simple scripting language for scripted events. there are many times in dark where i could write a script to create an effect but have no idea how to. so resort to a rube goldberg system of buttons, emitters and s/r in a blue room to do it. yet if i used the simple construction language of a TI-85 calculator i could do all the same things in a flash. a shame really that the most powerful tool in dark is still the least accesible to the common dromed user.

[Fingernail]

Thanks for dropping in, guys. And thanks for the suggestions. We'll respond to the best of our ability.

[sparhawk]

a simple scripting language for scripted events. there are many times in dark where i could write a script to create an effect but have no idea how to. so resort to a rube goldberg system of buttons, emitters and s/r in a blue room to do it. yet if i used the simple construction language of a TI-85 calculator i could do all the same things in a flash. a shame really that the most powerful tool in dark is still the least accesible to the common dromed user.

That should already be taken care of by the D3 scripting engine, which is syntatically very similar to C and even supports objects. Or did you have something specific in mind that is not covered by that?

[Fingernail]

Most of your stuff, Sneaksie, such as the optional loot and AI behaviours are done through the scripting language which sparhawk referenced.

[Guest Ottoj55]

i haven't seen a sample of the scripting language yet, the programing used in dark its beyond me. the languages i refer to are construction, so you set a group of variables and can make complicated if/then/or statements that trigger outputs, set up randomized events by generating numbers and using </> statements to determine effects that this event causes, set up timers all of these very basic things in a script environment.

 

statements are typically written straight forward, so if an item is x a statement could be written so that the user easily defines what happens, if x is present then do this or this, where the or is the action if x is not present.

 

an example can be taken from the soulforge machines in the metal age, if the right ingredients are present the script produces the product, if not then nothing happens. its simple if/then/or but buried under something too difficult to understand by the average user.

[Fingernail]

Luckily, we're going to be providing tutorials featuring everything required to make fully functional, detailed FMs.

[Guest R Soul]

I haven't played T3, but from my Dromed 2 experiences:

One thing that I find frustrating is the AI not being able to differentiate between a mansion and the streets of the City.

 

In T2, I've often heard a guard say "I think there's someone in the building", despite not even being in the grounds of a building.

The ability to only allow certain schemas to play if there is a certain property on the AI (which is added/removed depending on evironment) would be useful, and would make the AI seem more intelligent.

 

Another thing that bugs me is that the AI know the intruder's a Thief even if the only evidence they've come across has been a dead body.

 

And if you KO/kill an AI, it should be possible to put it onto a bed and so if it's seen by another AI, it assumes it's just asleep.

 

An AI should not be able to patrol past a sleeping AI without waking it up.

 

If a sleeping AI wakes up and eventually decides there was nothing bad there, it should go back to sleep.

[sparhawk]

In T2, I've often heard a guard say "I think there's someone in the building", despite not even being in the grounds of a building.

 

That's a bit of a problem because there can be all kind of missions. Since DromEd allows you to create arbitrary missions the only thing you can do to avoid this is either have more general bakrs, or you must record voices suiting your environment.

 

Another thing that bugs me is that the AI know the intruder's a Thief even if the only evidence they've come across has been a dead body.

 

That depends on the environment. I guess if you come across a dead body of a guard in a museum you are set to guard you should expect it to be a Thief (or something not belonging here anyway).

 

An AI should not be able to patrol past a sleeping AI without waking it up.

 

Why?

 

If a sleeping AI wakes up and eventually decides there was nothing bad there, it should go back to sleep.

 

That's a nice idea.

[Guest Guest]

Why?

Because they make a hell of a racket.

 

I'll redo that suggestion

When an AI approaches/sees a sleeping AI, it should make an effort to be quiet (e.g. softer [perhaps slower] footsteps, don't slam the door, no whistling, humming, muttering etc...)

 

The player should aslo have the option to open doors quietly if they suspect there is a sleeping AI nearby, with the penalty being that it's much slower. If the player was in a hurry (e.g. being chased ), they wouldn't have the time to open the door quietly...

 

 

As for environment specific barks, it would be great if there was an 'Environment' property that could be added to RoomBrushes and the possible flags were things like City Streets, Mansion Garden , Mansion Inside etc, then we could add a line in the schema files that defined which Environments a particular schema would be appropriate in. E.g. (env City Streets) or (env Mansion Inside) etc.

Then a bark would only play if an 'env' string matched an Environment flag of the Room.

[Guest R Soul]

Guess who made the above post

[SneaksieDave]

Another occasionally-mentioned suggestion, in fact one that was supposed to be in T3 if I remember correctly: guard hearing being affected by environmental noise. So a Hammer standing next to (or walking past?) a big old loud machine wouldn't be able to hear as well.

 

As for the closely related "a guard can't tell who made the footstep sounds" suggestion often mentioned, I don't think it's a good idea, as it would add near ridiculous complexity and perhaps make things a bit too easy for the player.

[Springheel]

Actually we were planning on implementing both of those ideas...certain environments, as designated by the author, would limit an AIs ability to hear. This could include rooms with machinery or crowded streets.

[Domarius]

I haven't played T3, but from my Dromed 2 experiences:

One thing that I find frustrating is the AI not being able to differentiate between a mansion and the streets of the City.

 

In T2, I've often heard a guard say "I think there's someone in the building", despite not even being in the grounds of a building.

The ability to only allow certain schemas to play if there is a certain property on the AI (which is added/removed depending on evironment) would be useful, and would make the AI seem more intelligent.

This happens in T3 - sparhawk, don't you remember? I had a guard say "Hey, we've got a Thief on the stairs!" when I was running down the stairs, and in another instance "What's that? Better go and check the door..." when I was seen in a doorway.

 

It can be done, just have to provide a way of letting the mission author create zones that have one of a finite list of "places" associated with it. Eg. stairs, street, garden, etc. Then the AI can play one of the appropriate recordings if the player is seen in that zone.

It's possible, just a lot of work.

[Domarius]

My limitation was objects. I needed so many bloody torches to light up my palace, that there weren't enough objects left to make the rest of the city, forest, etc.

 

Another thing is, the main reason I felt I needed so many torches is because you couldn't carry them around with you like you could in real life back in those times. Cellars etc. would have removable torches in the doorway (in the same way we have our light switches at the doorways of a room) so that you could light the torch (if nessecary) and carry it down with you, and put it back on your way out.

 

Another limitation was that all guards would hate you. For that, I had to make up some crummy curfew into the storyline (like so many other fan missions have done).

Unless they had the frontgateguard property on. But even then, if anything got them mad (eg. zombie), they would hate you when they next saw you, wether or not you were the cause of the problem. I tried to explain it by adding a "you're the stranger and if anything goes wrong, you'll be the first suspect" thing into the plot, but it was even more crummier than the curfew idea, so I went with the curfew idea...

 

Also, I wanted to have text come up instead of recordings, when someone spoke, because of the fact that I couldn't find any decent voice actors, and it's a lot of trouble. I'd just like to release it with text-only dialogue, and then put voices in when I can find the time. You could do this in DromEd, but it was really fiddly. I'd like it to be easier.

[Guest Guest]

How about some sort of a smoke bomb, creates a temp area of darkness, could throw one down and run by some guards. While it mite alert them they wouldnt see where you went.

[Guest Ombrenuit]

One thing that bothered me somewhat is that in Thief is that you would be searched for in odd circumstances. In Cragscleft, I released the prisoners, but made a racket in the process. The prisoners who should be running for their lives try looking for me, and when they find me they run to a hammer who kills them. Allow for some room for AI so that not every mission has to be about breaking and entering. There could be downtime missions where you are just exploring the City streets in mid-day with a throng of other citizens. These would help make storytelling more flexable.

 

I must say I'm very impressed! Please keep up the diligent work

[oDDity]

Hehe, as chief character modeler I don't like the sound of that word 'throng' ...of other citizens...

[Guest R Soul]

What about thong?

[oDDity]

Let's just say we're going for quality, not quantity.

[Springheel]

Yes, all our noblewomen will have quality thongs.

[Ishtvan]

Sorry to resurrect a relatively old thread, but I have a question about the 'impaired hearing' property of rooms that Springheel mentioned, and some possible suggestions.

 

Is the hearing impairment in an environment going to be a 'dynamic' variable that can be turned off and on (or ramped up if it's an analog scale), by scripts during gameplay? Or is it a map property that's set upon loading and stays at that value?

 

I think you could do some interesting things with that if it were dynamic, for example:

 

If ambient sounds were scripted to start and stop periodically, the hearing impairment could be linked to that, so you could time your movement to when the generator turns on or something.

 

In a social gathering environment with multiple rooms, one could have a script that counts noisy party guests entering/leaving the room and adjusts the hearing impairment based on that. So if you KO all the guests or they leave the room, guards will be able to hear you better.

 

If a character makes a lot of noise while moving (like the combat bots), that could also increase hearing impairment.

 

If you wanted to get really fancy, you could build it into the audio system, so that guards close enough to hear your noises (the 'signal') would do some sort of signal to noise test comparing your signal to the other non-suspicious sounds they can hear.

 

That might eat too many CPU cycles though, since you'd have to propagate both the Thief's 'suspicious' sounds and all nearby ambient sounds to all nearby guards, then run the signal to noise test on each guard (some might be better at picking out noises than others.. combat bot vs drunk Benny ). Maybe that would be feasible if you're already propagating all the sounds to the guards, and the signal/noise test is fast CPU-wise. I'm guessing that right now (and in previous Thiefs), only suspicious sounds are propagated to the guards?

 

Anyway, just some suggestions. Good luck with the Mod!

Edited January 8, 2005 by Ishtvan

[Springheel]

Thanks Ishtvan...we're discussing these very issues on the dev forums at the moment.

[Domarius]

That might eat too many CPU cycles though, since you'd have to propagate both the Thief's 'suspicious' sounds and all nearby ambient sounds to all nearby guards, then run the signal to noise test on each guard (some might be better at picking out noises than others.. combat bot vs drunk Benny ). Maybe that would be feasible if you're already propagating all the sounds to the guards, and the signal/noise test is fast CPU-wise. I'm guessing that right now (and in previous Thiefs), only suspicious sounds are propagated to the guards?

So true. That is why I feel that a per-area method is better (a way of giving an area a "noisyness" value). No extra propagation to do, just lower the "loudness" of the player sounds.

 

I'm glad you mentioned something about having it dynamic, such as all the party guests leaving. It shouldn't be hard to modify the "noisyness" value of the area in real time.

[Ishtvan]

Yeah, a per-area noisyness method seems like it would be the most efficient, CPU-wise.

 

You might be able to take it a step further and 'fake' propagation of ambient sounds to AI with the noisyness values if they're dynamic. The most simple way I can think to do this is: Say you've got a room with a noisy thing in it (room A), connected by 2 doors to 2 hallways (rooms B and C). (I have no idea how large the typical 'area' is, large rooms could have more than one sound zone i guess). Suppose the noisy thing in room A is initially off, and the FM author writes a script to turn it on.

 

When the noise starts in room A, the script changes the 'noisyness' variable in that room, then checks the state of the doors to B and C, and changes 'noisyness' var in rooms B and C based on whether the doors are open.

 

Then you'd have to attach a script to the doors so that when opened or closed, they would check the state of noise A, and adjust noise B and C appropriately. Doors or doorways could have a variable for how well they transmit sound (maybe they already have that variable for use with sound propagation to the player)

 

So to summarize, thru brute force scripting, each 'noise on or off' script would go thru and adjust the noise in adjacent rooms, checking the state of all the doors, and each door when opened or closed would have to change the 'noise' variable of adjacent rooms too, checking the state of 'noise generators' nearby. This could be done entirely by the FM author if each zone just has a dynamic 'noisyness' variable.

 

I've got another idea for a more complicated system that could be built in to the mod itself, but I'd rather not make (another) huge forum post. Is there someone I can email or PM some psuedo code to? Domarius, are you working on the sound propagation system, and could I message you some psuedo code as a suggestion?