I'm about to start coding traps in my game My Life as a Spy. Just wanted to run a possible implementation by you folks, to see if anyone can see anything wrong with the idea, or if you have perhaps done something like what I'm trying, but have taken another approach.
A player can plant a trap at their own location, and it becomes hidden. Someone walking over the trap will fire the trap's effects.
What I'm thinking of doing is setting the trap under the turf level, then defining a new area on the fly for where the trap is. Then I can use Enter() to call the effects proc of any traps in the area.
I'd also like to have a function where people can search for traps in their current view. Here I guess I would need to have the code look for all trap areas in View(), and call some "digging up" proc, passing in the user's perception skill. The digging up proc would move the traps drawing level back to the top if the player is successful.
So what do you think? Am I up against something difficult here? I don't need any code from anyone, just wondering if it sounds reasonable. Is defining areas on the fly going to be a bear?
cheers,
/mob/skysaw
ID:154540
 Jun 11 2001, 4:44 am
|
|
The only problem is that I can see turf.Entered() slowing down the game considerably as turfs are entered every time anything moves. Each turf would have to look through its contents every time anything entered it. Any idea what lag may or may not be created with 15 people running around? I'm concerned about stuff like this because I have a lot more to add, and I want it all to be as fast and smooth as possible.
Thanks for your thoughts, .s On 6/11/01 7:47 am LexyBitch wrote: I don't know about defining areas on the fly, whether it'd be hard or not, but it strikes me as unnecessary. I'd just put something in turf.Entered(O) that does: | |
I'm concerned about stuff like this because I have a lot more to add, and I want it all to be as fast and smooth as possible. Your concern is praiseworthy, but unless you're putting 100 things in each turf, I'd say don't sweat it for now. The overhead will probably be negligible. | |
Hmmm -
Well I do remain a bit skeptical. I cringe if I have to add any proc that is called every time something moves. I'm not expecting 100 things in a turf, but I am expecting a lot of other small things in the game that begin to add up. If I can shave a millisecond here and there, I might just put forth the effort to do so. On 6/11/01 8:11 am Gughunter wrote: I'm concerned about stuff like this because I have a lot more to add, and I want it all to be as fast and smooth as possible. | |
On 6/11/01 8:01 am Skysaw wrote:
The only problem is that I can see turf.Entered() slowing down the game considerably as turfs are entered every time anything moves. Each turf would have to look through its contents every time anything entered it. Any idea what lag may or may not be created with 15 people running around? I'm concerned about stuff like this because I have a lot more to add, and I want it all to be as fast and smooth as possible. Lexy's obj based idea is like the traps I use in Darke Dungeon. (I even called the trigger proc spring() ;) though it is called from my mob move code.) I ran a test last night with around a dozen players and it didn't seem to cause appreciable server lag. (The lag came from my slow internet connection.) In addition to looking for traps in the turf, my code even goes through the status list of each obj to see if you step on something that is on fire or other effects. I was very disappointed with turf style traps, which I tried first, but I hadn't considered area traps. If you go with it, let me know how it works out. :) | |
I ran a test last night with around a dozen players and it didn't seem to cause appreciable server lag.[snip] I was very disappointed with turf style traps, which I tried first, but I hadn't considered area traps. If you go with it, let me know how it works out. :) Just out of curiosity--what was disappointing about them? | |
On 6/11/01 8:46 am Gughunter wrote:
I ran a test last night with around a dozen players and it didn't seem to cause appreciable server lag.[snip] Players in Darke Dungeon will be able to set traps. Creating turfs introduced problems I hadn't expected when I began, since they would overwrite the old turf. I suppose I could have stored a reference to the original turf type, but it seemed easier to use them as objs. I was already examining the contents of turfs with each move to see if they contained flaming items anyway, so it only added one line of code. The Enter and Exit procs were handy, but I changed the Enter() procs to spring() and called it in a way similar to what Lexy posted earlier in this thread. No further changes had to be made to my Enter/spring procs. Only the beartrap did something special on Exit() (which I still need to fix, but it's not a high priority.) | |
So what do you think? Am I up against something difficult here? I don't need any code from anyone, just wondering if it sounds reasonable. Is defining areas on the fly going to be a bear? Rather than creating a new area per turf, just add the turf to the area... var/area/A = locate(/area/blah) src.loc:loc = blah //move my turf into that area At least, according to the Book, that should work. That would make things much easier. Not to mention that it takes off tons of overhead (because there are way less areas than there are turfs). But, the overhead is negligible in the first place. ;-) | |
On 6/11/01 12:09 pm Spuzzum wrote:
So what do you think? Am I up against something difficult here? I don't need any code from anyone, just wondering if it sounds reasonable. Is defining areas on the fly going to be a bear? Worth considering, thanks. | |
In addition to looking for traps in the turf, my code even goes through the status list of each obj to see if you step on something that is on fire or other effects. You could save yourself some lines of code, by making one proc called EnteredIn() or something, for all objs/effects that need it... then, when you move into a turf, instead of checking for traps and triggering their Spring(), checking for burning oil and calling Burn(), then checking for burning dog doo bags and triggering StompOutFireThenReceiveARudeSurprise(), you could just call o.EnteredIn() for each object that has it. | |
Having procs named Spring() and Burn() could be coincidence, but how did you know about StompOutFireThenReceiveARudeSurprise()?
| |
Cultural universals, m'boy, cultural universals.
On 6/11/01 1:17 pm Shadowdarke wrote: Having procs named Spring() and Burn() could be coincidence, but how did you know about StompOutFireThenReceiveARudeSurprise()? | |
Well I finished my traps coding, and am quite pleased with myself. For the curious, I used turf-based traps with great success. I have a feature to have the traps only visible to the person who set them, and I believe I have introduced minimal overhead.
So without further ado, I announce Skysaw's very first library! Please applaud or throw money. /mob/skysaw | |
Looks good! A lot more polished than Darke Dungeon traps. (Gimme a break, this is my learning project after all.) It even protects you from your own traps. :)
You might want to call ..() somewhere in your Entered() proc. That way games that use Entered() for other things can add your trap library easily. | |
Thanks for the comments :-)
Good point on Entered. This is my first library, so I'm not used to thinking about things like that. It's just cut in snippets from my main game. (Which by the way is my "learning project" as well ;-)) .s [EDIT - fixed it too!] On 6/11/01 7:45 pm Shadowdarke wrote: Looks good! A lot more polished than Darke Dungeon traps. (Gimme a break, this is my learning project after all.) It even protects you from your own traps. :) | |
if (ismob(O))
for (var/obj/trap/t in src)
t.Spring(O)
The rest sounds good, though.
Where spring is whatever
On 6/11/01 7:44 am Skysaw wrote: