18 Oct, 2013, Chris Bailey wrote in the 1st comment:
Votes: 0
I'm working on yet another design for space travel and combat and I thought I'd get some advice from the community. My goal is to keep the system complex enough to be interesting but not so much so that it creates an entry barrier for casual players. I know that many of us enjoy depth and realism but I also realize that sacrifices will have to be made in both of those areas. Here is a brief description of the implementation as currently planned.

The "space" itself will encompass a single galaxy and an arbitrary amount of star systems within it. The design does of course allow for additional galaxies in the event that gameplay or evolution of the story somehow require it. Each star system will house a variety of planets, moons, and large ships with dockable areas that players may navigate to. Navigation between docks, which is intentionally simplified, will be handled by choosing a target with the navigate command ie: navigate earth. Additionally, manual travel is possible by specifying an x and y coordinate on a two dimensional plane with the same command ie: navigate -76 42.

Control of the spaceship is limited to choosing a destination and adjusting the speed of the craft. In combat situations energy can be diverted to shields, used to power a variety of weaponry, or dedicated to engines to assist in escape attempts. In order to allow less than stellar typists to be competitive, all combat and movement actions are resolved per tick with delay periods related to the equipment used, the action taken, and the in-game skill level of the operator. Large amounts of energy can be diverted to any particular system to greatly enhance their effectiveness but only at a cost to the other systems. Additionally, maximum available energy and the rate at which it recharges is dependent on the hardware and equipment of the ship. Captains must be wary of when and how much energy is depleted during combat (and travel) or they might find themselves in a rough situation.

In-game movement, as traditionally accepted, is limited to space travel. When landing on planets, moon bases, or other ships, the players action is limited to selecting from options available at that location, such as shopping at the market, accepting quests from the government or bar, or repairing ships. There is no need to "walk" between these places as the player is simply presented with a list of available activities.

What I hope to gain with this post is advice on which areas could use more depth and which would benefit from simplification. I'm more than happy to answer any questions about specific mechanics as far as the in-game commands go. Thanks in advance! =)
18 Oct, 2013, Kelvin wrote in the 2nd comment:
Votes: 0
I've been working on something very similar to this here: https://github.com/gtaylor/dott. It's still very early goings, but you can fly around solar systems, jump between them with gates, land on planets/ships/stations, scan for other nearby ships, and a handful of other things. It's not the easiest codebase to set up (since it's 100% for my own project), but perhaps some of the code would give you ideas.

Systems are best thought of as "areas", whereas the "rooms" end up being important points within the solar system. These could be asteroid belts, space stations, planets, moons, instances, whatever. I thought about going coordinate-based for a while, but I think that's probably not worth the added complexity, for what I'm trying to do. I ran some games on the incredibly complex 3D real-time movement..., and it was always a battle getting newer players to stick around long enough to become proficient.

My combat system will be a lot like FTL (energy and repair management), and will encourage boarding/fighting on each others' ships. I'm going against rounds/ticks in favor of real-time, per-weapon firing cycles. Movement won't be tied to a global tick (each ship will operate independently), as I feel like that causes some silly things to happen. We'll be a lot more like EVE Online in this regard.
18 Oct, 2013, Chris Bailey wrote in the 3rd comment:
Votes: 0
Very interesting, I will check it out for sure! When I say per tick, and you might have already understood properly, what I mean is that each player is given the time between each tick for actions to be chosen and entered although they are still subject to delays and cooldowns dependent on the action. For instance, Bob and Larry have engaged in combat and only Larry has a weapon capable of reaching Bob. Larry orders a long range weapon to be fired, and requests power to be directed to his ships shields. Bob requests power to his shields, and advances toward Larry to close the distance. Regardless of when within the tick those commands were entered the timers to execute the command and cooldown so it may be used again all start at the same time..at the end of the current tick. So Bob and Larry both have the same ship with the only differences being their various skills and the long range capabilities that Larry has installed. Because of Larrys expert reaction speed and training in weaponry, his attack hits before Bobs relatively green crew has time to raise the shields…even though Bob might have entered the command before Larry did.
18 Oct, 2013, Kelvin wrote in the 4th comment:
Votes: 0
What you are describing sounds like a global tick system. My codebase has no global ticks that dictate the pace of combat. Each action that requires a delay is on its own separate timer (a Deferred, in Twisted terminology). For example, if a weapon has a cool-down time of 2.2 seconds, it will be ready to fire in 2.2 seconds. If a ship starts attempting to jump out and their loadout dictates that it takes 20 seconds, the jump will happen (if not interrupted) in 20 seconds "exactly", not 19.4 seconds if you entered the command late in a tick.

If I want to make the game less "twitchy", I can bump action times up to the point where you have a little longer to make decisions. One of the other positives is that you don't end up with clumps of events finishing up at the end of ticks (if your action timers are low). That always lead to clumps of messages assaulting the player in short intervals, especially if your ticks are longer than a second.

None of these are super big deals, in the grand scheme of things. Just figured I'd share. Global ticks aren't a clear disadvantage, I just didn't want them.
18 Oct, 2013, Chris Bailey wrote in the 5th comment:
Votes: 0
Oh okay I understand. I might end up having similar issues with ticks as well, I won't know until I can get some serious play testing underway. Please share all you like, that's what this thread is for! I haven't done much work on anything similar before so this is a learning experience for me.
19 Oct, 2013, quixadhal wrote in the 6th comment:
Votes: 0
Chris, it sounds like you're actually describing turn-based combat with a timeout. If you think of these global "ticks" as turns, I think you'll find it fits the same profile as any turn based strategy game, which is a good thing IMHO. :)

What Kelvin is describing is currently known as real-time strategy, in that every player simply acts on their own timer regardless of what anyone else is doing.

The reason I said turn-based is a good thing (beyond having a preference for such games), is that in a game where the map is represented by a connected graph of nodes, rather than an attempt at a spatial system, players who are familiar with the map gain a distinct advantage over newcomers without a turn based system.

In RTS style, a new player will have to at least skim the description and read the list of exits that are usable to determine where to go. If combat has tactical movement (IE: you can choose to go straight at the enemy, or pick the exit that ducks around a moon, or pick the other exit that heads towards the sun), that means a player familiar with the map gets an advantage in reaction time. The veteran will simply type 3;fire laser;4;fire missile, knowing exit 4 will provide cover while the missile is readied.

However, when you move to a turn based system, that difference goes away. You can type as fast as you want but your actions just get queued up and only execute one per turn.

It all depends on the feel you want. I like games that emphasize strategy and tactics over reaction and memory, but YMMV. :)
19 Oct, 2013, Chris Bailey wrote in the 7th comment:
Votes: 0
I see where you are coming from there Quix. Personally I've mostly played MUDS that favored reaction time and memory but the end-game became rather dull with two equally quick typists. My plan was to keep any differences limited to skill progression and hardware advancement. Of course there is always going to be some player knowledge that will give an edge of sorts but I hope to minimize the learning curve. The other idea is to present an environment where scripting and botting are effectively useless rather than creating rules against them. I'd like the game to be mostly self moderating with little need for staff…in a niche where 10 online players is great I don't need 6 of them to be admins.
19 Oct, 2013, Kelvin wrote in the 8th comment:
Votes: 0
I think you may be associating a lot more with a global vs a local tick than we were talking, Quix. Using a global vs a local tick in no way changes your movement choices, your map choices, your spatial choices, or in many cases your "twitchyness". It's important not to get sucked into that line of thinking, as I think it's missing the point entirely. A movement system based on a graph of nodes has nothing to do with global vs local ticks.

While I can see why you'd be confused about this in the case of fast local tick intervals, if your intervals are longer, being a few seconds slower here and there won't make a big difference. You don't have neat "turns", but you're not at much of a disadvantage if you waste an extra 5 seconds deciding which weapon to fire when you won't be able to fire again for another 40 seconds. The twitch factor can be easily negated (which I feel I have to do to lessen the advantage of scripters).

quixadhal said:
Chris, it sounds like you're actually describing turn-based combat with a timeout. If you think of these global "ticks" as turns, I think you'll find it fits the same profile as any turn based strategy game, which is a good thing IMHO. :)

What Kelvin is describing is currently known as real-time strategy, in that every player simply acts on their own timer regardless of what anyone else is doing.

The reason I said turn-based is a good thing (beyond having a preference for such games), is that in a game where the map is represented by a connected graph of nodes, rather than an attempt at a spatial system, players who are familiar with the map gain a distinct advantage over newcomers without a turn based system.

In RTS style, a new player will have to at least skim the description and read the list of exits that are usable to determine where to go. If combat has tactical movement (IE: you can choose to go straight at the enemy, or pick the exit that ducks around a moon, or pick the other exit that heads towards the sun), that means a player familiar with the map gets an advantage in reaction time. The veteran will simply type 3;fire laser;4;fire missile, knowing exit 4 will provide cover while the missile is readied.

However, when you move to a turn based system, that difference goes away. You can type as fast as you want but your actions just get queued up and only execute one per turn.

It all depends on the feel you want. I like games that emphasize strategy and tactics over reaction and memory, but YMMV. :)
19 Oct, 2013, quixadhal wrote in the 9th comment:
Votes: 0
If I know my local ticks are indeed local, I can game the system by playing to that advantage. For example, most games have movement on a relatively fast tick, while weapons might be considerably slower. So, if I can move 1 space every 1/2 second, and my weapons fire 1 per 3 seconds and 1 per 4 seconds, I can take advantage of the faster movement speed by writing macros that do things like:

north; fire laser; fire missile; south; east; north; west; fire laser; west; east; fire missile.

Replace the cardinal directions with known map locations, and now have that player competing against someone who has to read the map/exits because they don't know them.

Note that even without a macro, if you know the map by heart you can just type all that in sequence, knowing that the timing will work out.

It has nothing to do with the map layout. It has everything do with how easy it is for players to learn and memorize the map layout. That was my point. A turn based system reduces the advantage players have from knowing the map, regardless of it being spatial or node based.
20 Oct, 2013, Kelvin wrote in the 10th comment:
Votes: 0
What you described is a really terrible way to do a space combat system. What are we using cardinal directions for? Why are we moving like that?

I think you're assuming way too much. Global vs local ticks is one thing, you're creating a mythical movement/combat system to base your "gaming" on. Movement is much slower on my game, and it's not room/coordinate based. There is no real advantage to being a second or two faster typing commands…
20 Oct, 2013, quixadhal wrote in the 11th comment:
Votes: 0
Quote
Replace the cardinal directions with known map locations, and now have that player competing against someone who has to read the map/exits because they don't know them.


I guess you didn't read that part, huh?


As to it not being room/coordinate based, that's not possible. :) As in, it has to be one, the other, or possibly both. A "room" is nothing more than a location which may be connected to other locations, it in no way implies directions.

So, unless your entire game takes place with every player occupying the same location at all times, yes… it IS room based.

I think there was a discussion elsewhere about this, and nobody could come up with any situation which didn't boil down to either a coordinate system or connected graph (room system).
20 Oct, 2013, Nathan wrote in the 12th comment:
Votes: 0
You might look at this page: https://en.wikipedia.org/wiki/Space_syst... as it mentions the names at least of past space systems used in text games.

Personally I looked at HSpace ( http://hspace.org/, wiki – https://www.hsdev.org/trac/ ), which is a space system for use with PennMUSH, back when there was a test game up at some point. There used to be a better website (something happened in between then and now that the site disappeared), but eh. The descriptions on the wiki (probably not complete) may be of some use. They have a download link for PennMUSH with it installed somehow and there is also a googlecode project with an older version ( https://code.google.com/p/hspace-old/ ). The ship system is fairly sophisticated with fuel and interchangeable ship parts. It tracks distance from places, has some kind of warp gate like things, among other features. It had planets and systems and docking/landing too I think
20 Oct, 2013, Kelvin wrote in the 13th comment:
Votes: 0
I think you've completely missed the point of the original thing being discussed (global tick vs local tick). What are we doing talking about a theoretical movement system?

One is not more twitchy than the other automatically, it only is if you design that way. If the pace of your local ticks are slow enough, your game won't be any more twitchy than the equivalent global tick system. The big difference is that actions won't all happen at the same time (at the end of each global tick).
quixadhal said:
Quote
Replace the cardinal directions with known map locations, and now have that player competing against someone who has to read the map/exits because they don't know them.


I guess you didn't read that part, huh?


As to it not being room/coordinate based, that's not possible. :) As in, it has to be one, the other, or possibly both. A "room" is nothing more than a location which may be connected to other locations, it in no way implies directions.

So, unless your entire game takes place with every player occupying the same location at all times, yes… it IS room based.

I think there was a discussion elsewhere about this, and nobody could come up with any situation which didn't boil down to either a coordinate system or connected graph (room system).
20 Oct, 2013, quixadhal wrote in the 14th comment:
Votes: 0
I might download that Nathan, just because it's been years since I've even thought about MUSH code. It would be kindof fun to see how that side of the MUD universe has evolved.
20 Oct, 2013, Idealiad wrote in the 15th comment:
Votes: 0
Don't bother, it hasn't ;D…

Seriously though and somewhat OT, a space-themed mush recently released their Pennmush/Ruby hybrid codebase. It's quite interesting and they had a simple but well-designed IMO space system.

http://tkrajcar.github.io/wcnh/
20 Oct, 2013, quixadhal wrote in the 16th comment:
Votes: 0
Kelvin said:
I think you've completely missed the point of the original thing being discussed (global tick vs local tick).


Ok, one last try.

Let's take everything off the table except players, and weapons. Basic scenario: I'm at some location, and get ambushed by a hunting group of 4 other players. The fight starts.

Let's see what reaction times are like for both scenarios, global (turn based) ticks, and local (real-time) ticks. In each case, let's set the tick speed to be 30 seconds for simplicity's sake.

Global:

I type raise shields and fire lasers at enemy 1
Enemy 1 types raise shields and fire lasers at me
Enemy 2 types raise shields and fire lasers at me
Enemy 3 types raise shields and fire lasers at me
Enemy 4 types raise shields and fire lasers at me

Some time between 1 and 30 seconds later, the tick happens and all our shields go up, and all our weapons fire. The first round time is unknown, since movment may (or may not) be linked to the combat rounds. Every subsequent round will happen exactly 30 seconds later (not considering lag).

So, after the first volley, I have 30 seconds to decide if I want to try to escape, redirect power to the shields and shoot back next round, shoot back NOW and hope I can take the damage, or whatever other options there are.

Now, let's look at local tick timers (which I call real-time):

Same scenario, but in this case, it takes me 10 seconds to realize I've been ambushed, which now matters.

Enemy 1 raises shields and fires lasers immediately
Enemy 2 raises shields and fires lasers immediately
Enemy 3 raises shields and fires lasers 5 seconds later
I raise shields and fire lasers at Enemy 1 10 seconds later
Enemy 4 raises shields and fires lasers 20 seconds later

So, the first 3 lasers hit me for FULL damage to the hull, because my shields were not up.

In the next round, Enemy 1 and 2 both get to shoot at the 30 second mark,
Enemy 3 can shoot at the 35 second mark.
Enemy 4 can shoot at the 50 second mark.

Since my own action happend at 10 seconds, my next will happen at the 40 second mark. That means I have 20 seconds before the next damage hits, and I have either 20 or 30 seconds to decide if I want to flee, or continue the fight. If movement is linked into combat, I get 30 seconds.. if not, I only have 20 seconds.

If you jury rig the numbers a bit more, you can pressure me further by ensuring I have less time to react, since if those 4 players coordinated their attacks to be evenly staggered, I'd be down to what… being hit every 8 seconds?

THAT is why I'm saying local timers are more twitch based. Because you have less knowledge and control over the situtation, as soon as you get into something other than a 1 vs 1 fight, you're forced to react faster and faster.

Imagine if you were playing with a couple friends, and your group of 3 encountered an NPC fleet of 8 ships. Of course it's a tough fight, but now the timing is even worse when those 8 ships are all acting independantly. If that's what you want, then by all means, go for it! But realize that it WILL make a difference in how quickly the players need to react to things.
20 Oct, 2013, quixadhal wrote in the 17th comment:
Votes: 0
Idealiad said:
Don't bother, it hasn't ;D…

Seriously though and somewhat OT, a space-themed mush recently released their Pennmush/Ruby hybrid codebase. It's quite interesting and they had a simple but well-designed IMO space system.

http://tkrajcar.github.io/wcnh/


Hmmm, interesting. If I read that right, it sounds like you could code NPC's and other entities in ruby using the JSON API, and thus have a much more diverse coding system than keeping it all sandboxed.
21 Oct, 2013, Kelvin wrote in the 18th comment:
Votes: 0
quixadhal said:
Enemy 1 raises shields and fires lasers immediately
Enemy 2 raises shields and fires lasers immediately
Enemy 3 raises shields and fires lasers 5 seconds later
I raise shields and fire lasers at Enemy 1 10 seconds later
Enemy 4 raises shields and fires lasers 20 seconds later

I'm not trying to be petty, but why weren't your shields up? You're an EVE player, do you go roaming around lowsec or nullsec without being at full attention? Is this a problem in that the combat system makes players run around with shields down? What benefit does this provide as far as game experience goes? I'm of the opinion that this is more a case of the captain's own carelessness, or a badly designed system if you can get a huge benefit from running triggers. You don't go running around lawless space without shields, and if you do, you deserve every point of that damage you took.

Let's go with a more reasonable example:

Ship 1 warps in with shields up
Ships 2-3 notice, and fire immediately.
Ship 1 fires a few seconds after. No big deal.
The weapon recycle times are balanced to the point where missing one volley or being a few seconds early/late won't be a huge determiner in the battle (they are only one small component of what will determine the end result of the engagement). Management of subsystems, repairs, and energy will be just as important (and probably require additional humans to manage for the larger ships). Repelling boarders, fabricating components for repairs, and managing drones will also be crucial (and require additional people on the larger scale).

A central principle in my design process has been to minimize the benefit of triggers and reflexes, without resorting to the sluggish feeling that a slow global tick brings about. I want to allow faster people or larger crews to operate more efficiently, within reason. However, they'll also be managing quite a few other things. The ship combat will be a bit slower paced, and the damage done with each cycle won't be back breaking.

It really is all how you design it. Particularly if your tick intervals are pretty high and your damage per cycle isn't ridiculous, a few entirely missed rounds here and there won't drastically impact the battle.
21 Oct, 2013, Kelvin wrote in the 19th comment:
Votes: 0
Weird, I've never seen this before. Will have to check it out.
Idealiad said:
Don't bother, it hasn't ;D…

Seriously though and somewhat OT, a space-themed mush recently released their Pennmush/Ruby hybrid codebase. It's quite interesting and they had a simple but well-designed IMO space system.

http://tkrajcar.github.io/wcnh/
21 Oct, 2013, Chris Bailey wrote in the 20th comment:
Votes: 0
My system typically requires shields to be down (or at low power) outside of combat. Leaving them up while traveling puts a lot of drain on the rechargeable energy system.
0.0/40