Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
tintin++ ogg sound player script for linux
Author: Robert Smith
Submitted by: Vladaar
6Dragons ogg Soundpack
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.4
Author: Vladaar
Submitted by: Vladaar
LoP 1.46
Author: Remcon
Submitted by: Remcon
LOP 1.45
Author: Remcon
Submitted by: Remcon
Users Online
CommonCrawl, DotBot

Members: 0
Guests: 10
Stats
Files
Topics
Posts
Members
Newest Member
481
3,734
19,366
618
Micheal64X
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » General » Coding » Changing the stock pulse-base...
Forum Rules | Mark all | Recent Posts

Changing the stock pulse-based autocombat system (SmaugFUSS)
< Newer Topic :: Older Topic >

Pages:<< prev 1 next >>
Post is unread #1 May 14, 2009, 10:09 am
Go to the top of the page
Go to the bottom of the page

Trevlyn13
Apprentice
GroupMembers
Posts64
JoinedNov 30, 2007

I'm looking for any input on how I could begin to approach this change....right now I'm starting at move, fight, and update and not really sure where to begin.

I want to get rid of the auto-combat system that is stock in SmaugFUSS and replace it with an "active" combat system. I want attacks/defenses to be singular and not tied to an arbitrary continuance of combat. For example, a player could type, "shoot bob", and they should be able to fire one shot at Bob. This should not engage any fight system or force Bob to react in any way. Likewise with defenses, if Bob knew that combat was eminent, he could type, "defense dodge", and it would boost his chance to dodge the next hostile action that comes his way. After that single dodge, he would be back to normal.

Based on this general idea, I see two problems. Handling (or maybe ignoring) the pulse_violence stuff. It is everywhere, and I'm not sure how to either remove or work around it. Second, I somehow want to factor in a player's speed/reaction; meaning, some players will have their attacks/defenses execute more quickly than others. The only way I can think of doing this is having some kind of stat that is inversely related to a delay that is tacked on to each command. Not sure how to begin with that either.

Any input would be greatly appreciated.
       
Post is unread #2 May 14, 2009, 3:58 pm
Go to the top of the page
Go to the bottom of the page

Keberus
Conjurer
GroupFUSS Project Team
Posts341
JoinedJun 4, 2005

For the delay, you could set wait states for the players you need to delay, or set higher wait states, but that would interrupt all input flow. Also, you need to consider how you would want mobs to react to players attacking them, because they need to have some sort of semi-intelligent way to seemingly defend themselves.
       
Post is unread #3 May 14, 2009, 7:25 pm   Last edited May 14, 2009, 7:27 pm by kiro_san
Go to the top of the page
Go to the bottom of the page

kiro_san
Fledgling
GroupMembers
Posts23
JoinedJan 27, 2007

I did something every similar recently. In pulse_violence I changed the multi_hit to one_hit and made it so that it would only affect NPCs by placing it in a if( IS_NPC( ch ) ) check. That way players won't automatically attack other players/npcs etc etc.

I achieved the speed variable kind of strangely. First I added a variable to char_data fspeed (for fight speed). I then I added a small function to handler.c that would find each n/pc's ability modifier,(I based it off of D&D because SMAUG is based off of that and it was rather simple) for example if they had a Dex of say 25 then their Dex mod would be 7.

I then subtracted whatever that number turned out to be from 10 while I changed the definition of pulse_violence in act_wis.c to 1 and had pulse_violence subtract from the char's fspeed each time it ran until it reached zero. It would do one_hit then reset that char's fspeed to their dex ab mod.

Most of that was for NPC's, I thought to put a check in interpret to see if the command the char was using was a skill/racial ability and check if they had a wait left in their fspeed, (that way it would only affect their fighting commands) but I haven't quite gotten that far yet.


       
Post is unread #4 May 14, 2009, 7:37 pm
Go to the top of the page
Go to the bottom of the page

Kline
Fledgling
GroupMembers
Posts1
JoinedMay 14, 2009

Hi there, this topic caught my attention on IMC. I'm not a Smaug guy, but have replaced a "pulse" combat system, sorta. I suppose in the end it's still pulses, but doesn't seem like it :P.

It's active battle, like in MMOs, where weapons/attacks have swing speeds, etc, in 1/100th second increments. So your two hands may "swing" at different times based on the weapons you're holding. Casting is also delayed, and can suffer "knockback" up to 50% of the spell's cast time. You cast, wait (this could be expanded on, adding random chanting echos, etc), then the spell fires. No more static "lag" after spells or skills. All melee skills were placed on a cooldown system of offensive/defense.
       
Post is unread #5 May 14, 2009, 9:28 pm
Go to the top of the page
Go to the bottom of the page

Trevlyn13
Apprentice
GroupMembers
Posts64
JoinedNov 30, 2007

Mobs: I'd probably give them two stats to handle their autocombat....a combat speed stat and an offense vs. defense stat. They would still be on a pulse system, the combat speed would affect how often they took an action. The offense/defense stat could be on a scale from 0 to 100, with the value being the % chance the mob will use an attack; roll it each attack and if it misses, they defend instead. The whole mob side I'm not too concerned about at the time being, making them react intelligently will depend on how the player system works out.

As for waits, I think that may be what I'd like to do. If someone is attacking with a melee weapon and it causes a wait, they shouldn't be able to throw other commands in there. Actually, the more I think about it, it may be beneficial to do something like in a typical crafting system. You would engage your attack, it would throw out a message, and you would have to wait with no input before it hits shortly after. If basic defenses were immediate, this would make combat a lot more reactive.

Any potential problems with throwing around a ton of wait (pun intended) on players/mobs?

       
Post is unread #6 May 15, 2009, 11:09 am
Go to the top of the page
Go to the bottom of the page

Conner
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005

Trevlyn13 said:

Any potential problems with throwing around a ton of wait (pun intended) on players/mobs?

Ultimately, only the potential for players to complain constantly (particularly the ones who refuse to read help entries or who otherwise fail to understand that the waits are intentional to simulate weapon speeds and such) of the perceived terrible lag on your mud.
       
Post is unread #7 May 15, 2009, 11:37 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

The problem with wait states is that everything gets delayed. Let's say I type in this:

swing sword
swing sword
swing sword

But then during the first swing, I change my mind about the other two swings. Now, ok, sure, I can't do anything about the swing in progress. But I should be able to cancel the queue of actions -- I haven't actually really committed to them yet. But if you use wait states, as soon as I type anything in, I get committed to it and cannot get out of that commitment.

For this reason I would separate commands that take game time from commands that are "out of game", as it were. Commands like swinging swords should be queued separately, but the commands that manipulate that queue (e.g., clearing all queued commands) should always be processed immediately, so that players can change their mind about future actions that have not yet started.
       
Post is unread #8 May 15, 2009, 1:12 pm
Go to the top of the page
Go to the bottom of the page

Conner
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005

Actually, David, that's why I said what I did. While I'm sure plenty of us would choose not to use wait states like this in our own muds for whatever reasons we choose, and several here would advise against it for various reasons, ultimately it's Trevlyn13's game and his/her decision about what a player is going to be allowed to change their mind about once committed to it. Perhaps he plans his game to be turn-based and allow the players to stack several attacks at the start of their turn then sit back and watch them unfold like the older Fallout series did. Is that wrong? It's his game, and it worked for the Fallout franchise as well as Dungeons & Dragons.. maybe it's not so wrong... as I said, ultimately it's up to him, the only real problem with his doing that would be that players who don't "get it" would complain about the perceived lag, typically rather verbosely and repeatedly long after he tried to explain to them how it worked and that it wasn't actually lag.
       
Post is unread #9 May 15, 2009, 1:54 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Of course it's up to him. But he did ask if there were problems with using wait states, which is why I tried to give him an actual, useful example of a problem, not just a warning that players will complain. :tongue: Given his previous posts, his intention seems to be lock players into one move at a time, which is not what wait states will do. (Well, really, they'll do that, but more than intended as well...)
       
Post is unread #10 May 15, 2009, 5:07 pm
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

This has a lot to do with where the wait actually happens. Diku implementations typically back-load the wait, as in you type "cast 'foo' bar", and it casts the spell and THEN imposes a wait state so you can't do anything else for N ticks. LP implementations tend to front-load their wait states, so you type "cast 'foo' bar", and it prints a message saying that you've started casting, but the spell doesn't actually go off until N ticks later. Attempting to cast it again, either results it an error telling you you're already casting a spell, or stacks the command up to run after the current one(s) complete.

If you were going to rewrite the system entirely, I'd be tempted to suggest a priority queue, where you assign different levels of blocking (concentration) to different classes of commands. casting a spell might block any other game action due to the concentration involved, but a shield block might still allow a kick or jab to be done during the setup time.

Non-combat (OOC) commands should always be allowed unless there's a good in-game reason to block them. Players hate being told they can't check their inventory until their 30-second recall spell finishes.
       
Post is unread #11 May 16, 2009, 9:32 am
Go to the top of the page
Go to the bottom of the page

Trevlyn13
Apprentice
GroupMembers
Posts64
JoinedNov 30, 2007

The queuing that you guys have brought up is an interesting point. I had considered this already, and I think it actually works to benefit what I am trying to achieve. I don't want people to being queuing up actions. With an active battle system, the most obvious idea to a lot of people will be simply spamming their best attack. That's fine, if that is what they want to do, but I plan on having enough checks on the defensive side that it shouldn't be too hard to stop someone who is doing that. I want to eliminate the equivalent of button mashing and make them aware of what they are doing.
       
Post is unread #12 May 16, 2009, 1:41 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

It's not that you're explicitly allowing command queuing when you use wait states, it's that you are creating an implicit, unbreakable queue. If somebody happens to hit enter twice by mistake, they'll be penalized for it by being locked in to something. You can achieve all the goals of avoiding "button mashing" and encouraging people to pay attention without creating what can end up being a pretty annoying problem.
       
Post is unread #13 May 16, 2009, 10:56 pm
Go to the top of the page
Go to the bottom of the page

Trevlyn13
Apprentice
GroupMembers
Posts64
JoinedNov 30, 2007

After considering this a bit more, I think there may be another solution. What about slowing combat down by using a timer delay ala the SWR crafting system, be it on a very short timer? Any thoughts/opinions on this?
       
Post is unread #14 May 17, 2009, 1:01 am
Go to the top of the page
Go to the bottom of the page

6Dragons
Fledgling
GroupMembers
Posts48
JoinedNov 23, 2008

think you pretty much need to replace smaug combat system, if you don't
like the pulse system.

Midboss has an alternative.
http://www.mudbytes.net/index.php?a=files&s=viewfile&fid=493
       
Pages:<< prev 1 next >>