reference material
http://dwarffortresswiki.org/index.php/DF2010:Combat#Mechanics

Quite surprising stuff. Also quite a bit... overkill.

My goal is something simple yet versatile. Though I guess that isn't saying much.

One thing that occurred to me yesterday: Are there any sort of combat mini-games out there that I could take a look at too? I feel like some elements from other genres like adventure games and dungeon crawlers can easily adapt to what I'm trying to achieve. In fact, some things I planned are very much like dungeon crawlers in a way, now that I notice it. But combat in DC's isn't usualy something I find too interesting. I like them, but I feel they're a bit lacking...

What kind of "dice rolls" are you trying to avoid?

I was refering mostly to the typical ones found in most RPGs such as the old Baldur's Gates and Arcanum/Fallout, and even on Bethesda games (mostly on thievery).

The type of dice roll that tells you you have X% chance to fail to pickpocket or hide in shadows or to miss a sword swing, which I always found a bit obnoxious. There are situations in which I don't really mind them, but... And I'm not entirely against them, they just detract me from immersion a bit in those games. If I can't avoid them, so be it. But I always found that, for example, I had more fun being a thief in the Thief series than on any RPGs.

I had more fun being a thief in the Thief series than on any RPGs.

That's a good one. I'll reuse it in a following example. Garrett is a master thief, nobody sees him if there's a single shadow in the room. It's the player that makes mistakes, and whatever enchantment Garrett uses to distort perception is easily broken.

But Thief wasn't about combat, although it's a great game.

It helps me if you can describe what experience you hope for the game to deliver to the player thoroughly. You don't need to give a working example. Just imagine it, and if it's hard to make sense of write it down and revise it for yourself, or for someone else to read.

Example from a different game:

The player is a thief (easy reference, we know what a thief is), the thief can steal, he shouldn't fail to steal too much, and he takes double damage or instantly dies. He has some items but the usefulness is very situational.

The player searches for treasure, and occasionally pickpockets, his goal is to earn money and be a successful thief. The game's difficulty will scale by the user's choice (always a great feature).

I'm obviously replicating Garrett, although not entirely. From this I can tell.

1. The character is a thief.
2. The thief can become wealthy, and make other characters poor at the same time ( a good Robin Hood plug ).
3. Throw out the annoyance of failure right here, he's a master and never fails to steal.
4. The thief will die too easily, and he has no special attack skills ( this is clearly imbalanced ).
5. The thief has an arsenal of not yet described situational items.

The rules of the world need to be adjusted or the thief is underpowered, but there's no way to be sure yet.

It may seem logical now that he should be able to hide in the shadows and sneak around unseen, but this is the point where the initial game mechanics are missing. We can figure out what works by taking this as a starting point and then making guesses, trial and error.

I am also making a text rpg and is perplexed with designing combat. The main problem for me is implementing ranged combat.

How do you let players fire a ranged weapon when all you have is text? Text based RPGs are usually made like Multi-User Dungeons (MUDs) that only allow you to see what is in the same room as you. Even if there is an overview (e.g. Urban Dead, browser game), how do you select/target and shoot someone two rooms away in an efficient manner? Especially when your graphical system is limited. E.g. only text.

I am also making a text rpg and is perplexed with designing combat. The main problem for me is implementing ranged combat.

How do you let players fire a ranged weapon when all you have is text? Text based RPGs are usually made like Multi-User Dungeons (MUDs) that only allow you to see what is in the same room as you. Even if there is an overview (e.g. Urban Dead, browser game), how do you select/target and shoot someone two rooms away in an efficient manner? Especially when your graphical system is limited. E.g. only text.

The Star Wars MUD I mentioned previously handles ranged combat with a low-level skill called snipe.

The syntax for the skill is:

snipe <direction> <target>

Let's say that there is a jawa 5 rooms to the east, and the player is holding a rifle, they would type:

snipe east jawa

The code would first look at the contents of the room directly to the east of this one if there is one. If there are no targets named jawa, it continues by searching any room directly east of the one it just checked until it reaches a certain distance (in number of rooms), finds the target, or there are no more rooms to the east.

The source code for SWR is publicly available if you want to refer to how they handled it. It's written in C. It was developed for Linux, so you'll need something that can work with *.tgz and *.tar files. I'd share snippets of the code if I had it readily available, but I don't have it available right now.

Let's say that there is a jawa 5 rooms to the east, and the player is holding a rifle, they would type:

snipe east jawa

The code would first look at the contents of the room directly to the east of this one if there is one. If there are no targets named jawa, it continues by searching any room directly east of the one it just checked until it reaches a certain distance (in number of rooms), finds the target, or there are no more rooms to the east.

Thanks for the explanation! I am more perplexed by the design of range combat, rather than the programming.

E.g. how does the player know there is a jawa 5 rooms to the east, without moving there to look? I could implement a "look east" feature that displays the names of all mobs and players 1 to 5 rooms to the east. But players and mobs move around, which means by the time you type "look east" and "snipe east jawa", the jawa could already have moved away.

In fact, in PvP, players would surely move around a lot, making it hard to find and shoot them. Unlike games with graphics, I can't see how to let players "scan" the area and shoot moving targets fast enough. For 2D tile based games, they can click on the target, which selects it, and initial combat. For 3D games, its just typical FPS mechanics.

@Legendre

I actually have zero experience playing MUDs. But usually a text game makes "look" take 0 time to complete, in a real time game any action takes time to complete except for looking around. Communication between users takes real time. The player may have looked with a command or received a communication informing him to take action. If snipe takes 3 seconds, and movement takes 15 the jawa may have successfully hidden on time if the player was too slow.

If it is something like that then... yay me.

@Legendre

I actually have zero experience playing MUDs. But usually a text game makes "look" take 0 time to complete, in a real time game any action takes time to complete except for looking around. Communication between users takes real time. The player may have looked with a command or received a communication informing him to take action. If snipe takes 3 seconds, and movement takes 15 the jawa may have successfully hidden on time if the player was too slow.

If it is something like that then... yay me.

Well, basically a MUD is exactly the same as "text adventure". If you're using only text, there is usually no way to display objects not in the same room. Since you're using only text to describe the room you're in and the content (players, monsters, objects) of the room.

Movement takes place in real time. When someone types "west", he instantly moves 1 room to the west. Are you suggesting making movement take time to complete, essentially slowing things down so people can be shot with ranged weapons? I don't think that will work out very well. Even if movement takes 2-3 seconds to complete, moving around can be pretty frustrating.

(...)
how does the player know there is a jawa 5 rooms to the east, without moving there to look? I could implement a "look east" feature that displays the names of all mobs and players 1 to 5 rooms to the east. But players and mobs move around, which means by the time you type "look east" and "snipe east jawa", the jawa could already have moved away.

For my part (my project is outdoors heavy) I'm thinking of having perhaps an array that stores a sort of visibility value for each room in each direction. For example, a street may take up 3 rooms, and if I'm in one of its extremities I can see the other two rooms from there. If I'm in the middle room I can only see one at a time (I'm also planning on implementing direction I'm facing). The visibility factor may be also affected by obstacles(a dirty glass window, fog, etc) or distance.

And as you enter the room you may be given a description that includes other visible rooms. And probably there should be a range the character's vision can reach.

I'd love to know if there's any more efficient ways though. As this is only what I have planned and I'm still very inexperienced.

EDIT: I don't know how to solve the NPC movement issue though. I'm debating whether it would be a good approach to use rogue-like mechanics where the world is static while you're not doing anything. That might solve that issue, as the NPC would wait for your actions, and if, for example you missed the shoot, he would be somewhere else after that, perhaps even not visible any more, and on alert. And probably, observation skills might not take any time to complete, or at least much less time than anything else.

The source code for SWR is publicly available if you want to refer to how they handled it. It's written in C. It was developed for Linux, so you'll need something that can work with *.tgz and *.tar files. I'd share snippets of the code if I had it readily available, but I don't have it available right now.

Thanks for this.

Well, basically a MUD is exactly the same as "text adventure". If you're using only text, there is usually no way to display objects not in the same room. Since you're using only text to describe the room you're in and the content (players, monsters, objects) of the room.

Movement takes place in real time. When someone types "west", he instantly moves 1 room to the west. Are you suggesting making movement take time to complete, essentially slowing things down so people can be shot with ranged weapons? I don't think that will work out very well. Even if movement takes 2-3 seconds to complete, moving around can be pretty frustrating.

Oh, the rooms I imagined were not very granular, I was thinking it could be an instance of any size based on the location's rules. Because a jawa was involved, I expected the scene was a desert where one room could be an entire valley. In outer space each room would be a planet, because you'd want to travel faster, etc.

I don't know how this compares to the player experience you'd expect, so it probably sounds really strange.

And as you enter the room you may be given a description that includes other visible rooms. And probably there should be a range the character's vision can reach.

How can we display this information without creating huge text spam? From my experience playing with text adventures/RPGs, displaying the content of one single room generates quite a bit of spam already.

E.g. if your vision is just 2 rooms. North, south, east and west, no diagonals. There are 9 rooms of content to display. I don't think it is feasible. Imagine the amount of text spam just to display a line for each of those 9 room telling the player there is no one in any of them.

Imagine if you're in a heavily populated area.