22 Dec, 2009, Brinson wrote in the 1st comment:
Votes: 0
So, I'm building a combat system from scratch in MOO. I'm designing it right now. MOO by default, has zero combat systems, so its basically back to the drawing board. First thing I'm doing is eliminating the concept of ticks. Everything is real time. One game hour is one real hour. Healing will take a long time, and combat will consist of a few single blows, rather than dozens or hundreds like in some muds.

Rather than having any automated attacks, you simply have skills and spells that are usable. They lag you for X seconds, and then you are free to run or continue. In the system I'm designing, most classes will have spells. Melee fighters will similarily have commands such as powestrike, bash, uppercut, ect.

Take, for instance, uppercut. It has a chance of doing a bunch of random things. It uses your STR to calculate chance of breaking the enemy's jaw, has a slight chance of causing unconsciousness, causes damage, and lags the person hit for 3 seconds, and you for 4.

Bash, on the other hand, uses size like most ROM muds, and has a chance to lag you both evenly and to do some damage. If you never missed a bash, you would eventually win, unless the person you fight is a melee class with counter.

A common spell, flame arrow, would do damage, but would lag you for 5 seconds, and the enemy only for 1.

In the next few days/weeks I'm going to build 2 simple classes and the barebones of the system and test PK scenarios to see how it works. Has anyone done this before?
22 Dec, 2009, Kline wrote in the 2nd comment:
Votes: 0
Now when you say lag do you mean artificial "lag" where nothing will process for the player, like a Diku WAIT_STATE, or more of a cooldown of sorts where they are unable to perform more offensive actions for X seconds, but can still do other stuff?
22 Dec, 2009, Idealiad wrote in the 3rd comment:
Votes: 0
I'm guessing he's talking about the latter. This is a balance system, and I believe the type used by IRE, Simutronics muds (?), Maiden Desmodus, etcetera.
22 Dec, 2009, Brinson wrote in the 4th comment:
Votes: 0
Artificial lag, as used by a lot of ROM muds I've played. I'm trying to decide whether or not OOC commands should be prcessed during this wait state or not. Changes the feel to do so, but definitely some advantages.
22 Dec, 2009, Kline wrote in the 5th comment:
Votes: 0
Ah, see, I am much opposed to the Diku-based lag you are talking about, then, the same you experienced in ROM games. It makes it hard to discern if you are paused due to a command or actual game/connection lag, and can be difficult to keep track of how "long" you have queued up in actions, before you can freely act again.

I still use it, slightly, for momentary (<1s) delays between things like movement mostly to throttle the wall of text going to clients. Otherwise everything is on a cooldown system inspired by WoW's guardian/battle elixir concept. Commands are either on no cooldown (movement, info, chatting, etc), offensive or defense cooldown. Different skills have different lengths, and you simply lock yourself out of the offensive/defense schools for X seconds based on the skill you use, but are free to do other things in the mean time.
22 Dec, 2009, Twisol wrote in the 6th comment:
Votes: 0
Just to mention, don't the majority of (or all of) the IRE games also have fully real-time combat? Maybe you could look at what they're doing, because it sounds like you have very similar ideas.
22 Dec, 2009, Mabus wrote in the 7th comment:
Votes: 0
Brinson said:
Has anyone done this before?

Been coding a time-based, manual combat system for melee for a while.

Ours times down to the millisecond, but displays to the second. There is an absolute 2 second minimum for melee attacks. Uses weapon-types (axe, sword, etc.), two-handed/one-handed, player stats, affects (haste, slow, etc.) and other factors to generate the time to attack. No "You regain balance." messaging, so it has to be timed by the player.

I now have it checking hit locations and armor worn (at a "main" armor level, as we have layers) at the hit location, and modifying based on damage-type (bash, slash, etc.). The bare-bones for a critical system are also in (variables and such), but have yet to decide how many "levels" of criticals there will be, the complete list of critical hots, and the best way to seed them. I know I want to weigh them against NPC's, so that players can "feel the power" without being "wtf-pawned" while trying to level up (or so I was asked in one forum post by a player…).
22 Dec, 2009, quixadhal wrote in the 8th comment:
Votes: 0
Just my opinion, but commands that have to do with either communication or information should never have any kind of "wait state". It just annoys people. Consider looking at your inventory, that's not your character doing anything (he KNOWS what he has), that's YOU remembering what your character has. As such, there's no in-game effect, and no reason to ever not display the data instantly.

Likewise for chat channels, disconnecting, help screens… all of those are commands that deal with the player, not the character. There might be penalties to some (disconnecting in combat might get your character killed), but you aren't asking the character to do something inside the game mechanics.

I would probably try to break commands up into logical groups that share cooldowns. No player I have ever talked to has liked the way Diku did wait states, and there's no real reason to do so if you're designing your own system. But, it's your system. :)
22 Dec, 2009, KaVir wrote in the 9th comment:
Votes: 0
Brinson said:
In the next few days/weeks I'm going to build 2 simple classes and the barebones of the system and test PK scenarios to see how it works. Has anyone done this before?

Unless I've misunderstood what you're suggesting, it sounds like you could achieve the same result just by commenting out the section that performs automatic attacks in a Diku mud. If all you want to do is see what it plays like, that would be a far faster way of testing the concept.

I dislike the Diku WAIT_STATE as well, and I'm surprised that so many muds still use it. It shouldn't require much effort to replace it with a separate counter, and add a flag to the command table to indicate which commands can be performed while the counter is > 0.
23 Dec, 2009, Brinson wrote in the 10th comment:
Votes: 0
My intention to reinstitute ROM-style lag was basically becuase I saw it as standard. I dislike it, and it will be rather annoying to code into MOO, requiring me to limit myself in the future. However, I am now considering not using it. It would be eaiser for me to use a counter. The code I've written to simulate Diku wait_state is actually rather annoying. It adds all the commands you send during the wait_state to a list and executes them afterwards, but it requires me to add this to the code in every command because moo doesn't have ticks or anything else that occurs on a regular basis to "count" by and check for.

Alternate, I could use a cool down system as discussed above. I'd just have to have a player property store someone's "Status". I could use 0 for inactive, 1 for sleeping, 2 for combat, ect, and just have commands check for that. Any command that sets it to that would set it, suspend, and then change it back. It would be about a hundred times easier.

…If you haven't coded a moo what I said above likely makes little sense. In a moo every piece of code exists on an object that you can hold, like a mud object. You add verbs to these objects and program theme. The room has a verb called "look" which can be reprogrammed at a whim to change the look of that particular room, or edit the parent room to change all the children rooms.