Was curious if anyone here used any form of ranged systems… ie… combat, spells, etc.

Most muds have a track command that makes use of a primitive breadth-first-search, and usually a scan command.

In a hobby project of mine, I was emulating the behavior of GroundZero, a ranged pk mud, and wrote a ranged search library that handles these and more.

Been talking with Samson about the possibility of porting it to SmaugFUSS… which would require C++ compilation. Wanted to hear other people's thoughts.

With our weapon attack system to be in soon, I plan on some ranged weapon attacks and maybe skills too at sometime. Maybe at first just a one target ranged attack, but in the future something that decimates entire rooms in a certain direction.

I'm hoping to eventually add "archer" like capabilities to the Assassin class eventually, and maybe to the "tech" class but as a bit more high-tech version.

I'm planning on implementing something a bit more half-assed, but more true to the genre of games I'm basing my code on. I'll just be using front, mid, and back ranks, with each weapon having a preset number of rows away that it can hit from. For instance, a weapon with a range of one can only hit the row right in front of them, while a weapon with a range of three can hit the enemy's front row from their middle row. It's not the most 'ranged' combat possible, but it's not really meant to be.

I'm working on a small side project right now in C++. Mostly to keep me sane from all this php :). My thoughts where to create a 'Distance' object to store length. This object would be used for things like, range on a weapon, distance between two objects. Probably use it for room dimentions, etc. Anything that involves a measurement would be a Distance object. I'm still not all to sure how I'd store the relative distance between two objects. Might just generate on the fly when needed. Though, in my eyes, something like this has to be built into the project from the ground up. It doesn't feel like a system you can just toss in and expect unity. So porting to smaugFUSS might be quite the challenge, but definitely port it to C++, more people should attempt to use this language. Making classes to mimic built-in types makes adding huge changes a simple task.

Davion

Just an update. Managed to get SmaugFUSS compiled with g++ and running alright (near as I can tell). My search code compiles in, but I gotta do a little testing/debugging before I feel ready to upload it.

So… a brief explaination…

The code consists of 3 major parts. A frame which represents the current state of the search, a callback which gets passed a single room (well frame) at a time. And the algorithms which handle the actual "ranged" search.

Currently support 3 algorithms… A breadth-first search, a line-of-sight search (send rays in all available directions), and a single direction search.

Anyway, will post more later as I work out the bugs.

Sounds like a pain in the ass to code. Hat's off to ya. Speaking of pains in the ass, I'm working on an OLC editor to create techniques (not skill entries, mind you, full techniques, with a sort of prog code to handle their effects). I may or may not release a new version of my combat engine when it's done… Haven't decided. Being able to flesh out the combat system through OLC might make things a bit TOO easy on those without original thought, after all.

It's uploaded and pending.

To be honest, the code wasn't that much of a pain to write. It's just that I wrote it for a from-scratch C++ mud I'm writing. Required a little bit of porting to make it SMAUG compatible. The biggest issue is my use of the c++ standard containers to implement parts of it.

SmaugFUSS compiles under g++ without any changes… just needed to de-mangle the function names for dlsym to pick up the commands. Luckily I found an easy way to do that or it'd only work with afkmud. (will do that port as time permits)

Oh yeah, btw, I included 2 examples with the snippet.

A simple scan command weighing in at 9 lines in the header file and 54 lines in the c file.
A simple minimap command weighting in at 9 lines in the header file and 73 lines in the c file.

Neither is setup for player use, but as a demonstrator for the snippet. Should be fairly easy to add features to make them player-ready though.

To be perfectly honest… I spent more time fiddling with the output of the minimap command than I did working on the rest of the snippet. The minimap gathered the data pretty easily… since I store a relative coordinate from the start room but had to do little things like… flip the y axis and some pointer arithmetic… not the prettiest solution but it works.

I give all attacks a 'reach' value, and ranged combat is simply an extension of that. Shoot someone with your longbow, and the 'shoot' attack has a base range of 600 feet. Bash them over the head, and the 'bash' attack has a base range of 0 feet (defined as a melee attack, which means it also adds your Size reach bonus, plus five feet for the length of the bow).

I've considered using a distance based system. But with experience I've found that the extra detail allowed doesn't have enough advantages to overcome the extra complexity.

The use of ranged systems however, is not limited to combat. I've had bots which used the BFS search to look in surrounding rooms for better equipment… or for a smarter wander AI.

The most amusing thing I've done using my ranged search code… was the application of sound to the mud. Whether room based or distance based, I think the use of ranged systems adds alot to a game.

I tryed to make a ranged system once err we dont talk of that around my house no more

Heh, well I've seen a "ranged system" around the house a time or two.

Being a man that's probably going the way of a distance system I'm wondering if you can go into more detail on this. Is this because you've been doing it in a base not build from the ground up. Ie. Trying to add something like this to a smaug codebase would probably be like pulling teeth. Also, got any resources for someone going into a job like this? I found a few things on the BFS search algorithm, but I couldn't find anything for LoS.

At the time, I was writing a codebase in Java. Since things were organized on a coordinate grid, I was using concepts from 3d graphics.

Required alot of heavy lifting to deal with things in a true 3d environ, but the major issue was representing your surroundings in text. To get decent descriptions that didn't feel canned required alot more effort than it was worth.

On a side note, I've seen muds which have modified rooms to have size, and… within a room supported distance. This worked because it was limited to specific things, and didn't require an awful lot of modification.

The LOS search isn't an algorithm, so it's not surprising you couldn't find any reference. In a 3d game, line of sight is normally determined using ray-casting. That is… casting a ray from one location to another. If it doesn't encounter any obstacles, then the two locations can be considered "line of sight".

You could say that both my LOS and DIR searches are using ray casting. On a side note… if you're representing your world in a true coordinate plane, you may want to look into the A* algorithm. With a bit of tweaking, it allows a great deal of adjustment in how a path is defined.

I once wrote a bot for a pk mud I used to play… ground zero (a version is up again, but I don't have time to play atm). Since the map is built on coordinates, I used an A* to generate fairly short random paths that preferred rooms it hadn't visited recently.

Wolfbot (as I called it) was able to scan surrounding rooms using a BFS for equipment that may be useful… and only used the A* for navigation. Both searches could scan the full 441 room top level in less than 10ms (minimum time resolution for java on windows).

I think I computed the average time for a path between 0,0 and 20,20 at around 3ms (averaging the time to execute 100k searches)

A text-based mud doesn't require anywhere near as much complexity as a 3D graphical game as far as things like line of sight are concerned, primarily because it doesn't need anything close to the same amount of accuracy.

The approach I use is pretty simple. I generate an 11x11 ASCII map of the viewers surroundings, then spiral outwards from the centre replacing hidden terrain with spaces. I then add mobs and objects to the map, and if they can't be displayed you can't see them. Those outside of the map range are automatically ignored, while those within one square are automatically visible (which means melee combat doesn't have to bother doing line of sight checks).

The system is still a little rough around the edges, but overall I'm rather pleased with the results - in particular it provides an excellent way of handling ranged combat, and a much more logical way of dealing with fleeing.



Davion, you might also find this link of interest:

"Line of Sight Algorithm for Tile Based Games"
http://www.gamedev.net/reference/article...

So you're basically treating rooms as tiles, and generating a 2d map? Not too difficult.

Granted my system was using 3d coordinates, and generating actual descriptions. Which was where most of the complexity was. English is not an easy language to generate and not sound… canned…

I glanced over that article. Gives a good synopsis of concepts involved. The algorithm description was a bit vague with details being glossed over.

I'm interested to hear how you handle ranged combat, and fleeing. Since you mention those. The ranged search code I've posted here was designed to support a post apocalyptic ranged combat mud. As I've mentioned elsewhere, I was emulating the behavior of Ground Zero. Which was fairly primitive in most areas.

Basically, each weapon had a range… and basically… if during the combat pulse an "enemy" character was within range, the weapon fired automatically. Ranged weapons had rate of fire, and a damage modified… ammo had the base damage. Armor absorbed damage… So you'd do (rate*((damage*mult)-absorb)) to calculate actual damage. Negative numbers of course were fixed to prevent combat healing.

Additionally there were explosives. Each explosive applied damage to the current room… then used what is essentially a LOS to send out shrapnel. Finally a BFS was used to generate the effect of "hearing" explosions.

A variety of other things were involved with the combat system (mines, vehicles, airstrikes), but that's the gist of it.

Eventually, I'd like to see some of these features available in more traditional muds.

Sort of - there are tiles, but no rooms.



Mine is currently 2d, although there's partially coded support for 3d (which I'll eventually get around to finishing). I have generated descriptions, too.



As I mentioned earlier, every fighting technique has its own range modifier. If I slash you with a sword, that's +0 melee range (meaning it also adds the length of the sword and a reach bonus based on my size). If I thrust with my sword, that's +1 melee range. If I pummel you with the hilt, that's -99 melee range (which means only my reach bonus for size applies, not the length of the sword).

A ranged attack such as a bow or thrown dagger works in exactly the same way, except that it doesn't apply the length of the weapon nor a reach bonus for your size. Ranged attacks also have the top attack strength, meaning they can only be blocked with shields or dodged.

So for example a longsword has a base range of 3 feet. Its basic 'slash' technique costs 100 action points, requires 3 seconds to execute, has a +5 damage modifier, and can be parried or blocked by any non-unarmed defence.

A longbow has a base range of five feet. Its basic 'bash' technique costs 100 action points, requires 3 seconds to execute, and can be blocked by any type of defence.

But assist the longbow with your other hand, and that other hand gets a 'fire' technique which costs 75 action points, requires 1 second to execute, has a 600 foot range, can only be blocked by shields or dodged, and provides +25% armour bypass. Of course you'll also have to use the 'load' technique between each shot, and that takes another 5 seconds (reduced to 2 seconds if you have the Fast Reload talent).



Fleeing isn't explicitly implemented, it's just something which is automatically handled on account of the movement system. If you wish to run away from someone, you literally target a location far away from them and start running - if you're faster than they are, you'll get away.

Hello All,
I'm not too familiar with ranged systems but I thought Thoric wrote something like this in Smaug 1.4. I saw ranged something in the codebase for the archer code I thought. There is someone who had a mud years ago, something set in the future with guns and stuff and there were a bunch of original snippets that had to do with a system like the ones you've mentioned here.

Anyway, Just my thoughts,
Chris

I had one on Top Secret for a regular ROM game. But that was modern day based, with only projectile weapons (ie non-beam etc), and thrown weapons.