argument to remove need for spec

[pheonixstorm]

Not every planet/station should have hundreds of craft flying to or from it. Some backwater systems should be very sparse when it comes into traffic. The most heavily trafficed areas will always be jump points and heavily populated planets or stations with a large amount of trade or systems that have a lot of inter system trade.

[klauss]

Well, i think it's not simple the amount of time that we need to get rid of. That's the big part. But that's not the only aspect of spec that ruins gameplay. The other aspect of it is the fact that we need something like it at all. Simulating a huge amount of space is something we take pride in. But we can't ever hope to simulate enough units to make that space ever seem anything but sparse and empty.

I can hope.

And I really hate time acceleration. Just the thought of it makes me cringe. If SPEC has logic holes in how it behaves in games then time acceleration is like just not caring at all about being cohesive. It's another bandaid to deal with a problem that can be solved by just avoiding the problem to begin with. The problem is that we want things to goto that are too far away to realistically have the player and NPC's go to ....so just STOP making them go there. Problem solved...no need to create magic ways to travel in additional to our magic way to travel.

Ok, now imagine. we have a game where SPEC and autopilot and time dialation aren't needed. You are actively doing things that aren't mundane time wasting busywork every time you launch from a dock. Sounds like a decently fun game. But, you have this huge universe you have at your disposal and it's a shame the player only experiences a fraction of it. Well, eventually a decent amount into the game the player can be given missions where they have to dock onto much larger ships. These ships are "spec" capable. They take them to goal oriented missions across the system. For now piggy backing onto these ships are the only way to complete those missions and see the rest of the system.

Now much later in the game with enough money and luck, the player could get a ship large enough to be spec capable itself. Leading to different and much more lucrative missions.

I like that direction. I do.

But I believe those hubs spaced a few kilometers apart, those, without SPEC, will be just like huge systems with SPEC. Travel between stations will be slow, too slow, without some form of time acceleration.

And that's why I said we needed it.

About the effect in multiplayer... well... multiplayer doesn't allow time acceleration. If travel is boring, suck it up. Don't stray from the jump points. Get a SPEC drive.

[safemode]

It isn't empty kilometers though like it is in game now. The area will be bustling with many dozens of ships of varying types. And you won't be simply traveling from station to station. Meeting up with individual ships will be important to scripted missions as well as free playing too.

[klauss]

It isn't empty kilometers though like it is in game now. The area will be bustling with many dozens of ships of varying types. And you won't be simply traveling from station to station. Meeting up with individual ships will be important to scripted missions as well as free playing too.

Well, deus's physics patch, believe it or not, makes ship encounters more likely and enjoyable

Trick is, I think, that ships now are slower, so you have more time to meet at choke points. So it's not only about the size of the universe, it seems unit speeds also matter. So you're doubly right.

I'm still trying to fix a particle system bug that got unbearable with his patch, somehow.

[safemode]

Ha! Try being near any ship with damage. Particle output makes game unplayable with my crappy graphics card.

[klauss]

Ha! Try being near any ship with damage. Particle output makes game unplayable with my crappy graphics card.

Here here... so hopefully I'll be committing a fix shortly.

[Hicks]

Are there many games out there that don't have something similar to SPEC? Eve has all its warping between planets and bases, it has 30k+ players on most the time. Everyone's favorite space game Freelancer had those little warp travel things between bases and planets. If we remove SPEC its not just changing the gameplay, it changing how people expect the game to work.

[safemode]

Don't fool yourself. Nobody plays vs in any meaningful numbers right now. There is no expectation except what is described on the site and in distro packages. Having all our eggs spread out over realistic space distances like we do now doesn't work. Spec or warping is merely a cheap programmer work around for that problem. You want to see what sparse action is to a user base? Look at our current activity for the last few years. The time it takes to get around is irrelevant. We simulate a lot but it is pointless to the player when they only come across ships one at a time. Things have to change.

[IansterGuy]

Don't fool yourself. Nobody plays vs in any meaningful numbers right now. There is no expectation except what is described on the site and in distro packages.

So it is a great time to make a change as you said.

Having all our eggs spread out over realistic space distances like we do now doesn't work.

Would work better to have a large main hub of activity in every system where the majority of the activity takes place. In this way the jump hub idea is great.

Spec or warping is merely a cheap programmer work around for that problem.

Cheap? Well maybe if it is the only think we do to solve the problem. Any of the simple solutions I have heard presented for the travel time issue would be by themselves cheap. Only when all of the solutions agree with each other to create a grand effect, would it not be cheap.

You want to see what sparse action is to a user base? Look at our current activity for the last few years.

Can't have all the ships in one big lump either. This has me thinking of how to regulate the spread of ships. If all traffic is moving directly from jump node to jump node and to main stations seems like there could be many collisions if they where allowed to SPEC and jump in the most concentrated space lanes. Could include a collision warning system, but a better solution would be dropping buoys along the lanes though not to mark the diction of travel necessarely. Those stations and buoys within the hub would all radiate a Drive inhibition field to disallow jumps in out and inhibit SPEC over the entire large area of the lane and surrounding space. This would protect almost all the ships in the hub without SPEC or nodeless jump drive, from the ships that do coming in and taking advantage of the fact. Instead they would have to move out of the areas to take full advantage of their abilities. Space lanes would also be paroled and would thenbe relatively safe to abiders of local law.

The time it takes to get around is irrelevant. We simulate a lot but it is pointless to the player when they only come across ships one at a time. Things have to change.

I agree things should change, but there is little need to throw out much of the old to get this working great. I'm still thinking of the details of how getting the best of both but I can't think of a reason that it could not, and is why I'm optimistic for this. Someone mentioned an idea like this a while ago before the forum crash I think, maybe it was you. Instantly I saw the potential.

I think it may be a good idea now to think about the progressive steps to accomplish this new jump system layout, so that the details can be worked out. It does not seem like it would be so difficult or foreign if done gradually without risk of being put into an unplayable state.

- Cluster all but a few of the Inter-system Jump nodes into Jump Hubs only a few kilometres from each other or less, and place them all somewhere scenic.

- Create a new type of smaller jump node called something like "Local System Jump Nodes" that leads to various places in the system. Some of the "Local nodes" would lead directly to the planet surfaces or hangers of the space ports which are made void of atmosphere to facilitate non-destructive jumps, otherwise difficult or impossible.

- Add or move in more space stations to the Jump Hub to begin creating a niche economy within it.

-Add inhibition fields and jammers to stations, buoys and ships, to prevent unfair tactics utilizing Jump drives and SPEC.

- Add non linear transport drive capabilities like Node-less Jump Drives for in system travel.

- Begin adding a campaign adapted for the new layout of the jump nodes.

- Place limitations on starting off travel technology, to begin to contain new player to the jump hubs.

- Create and tweak game play elements to differentiate game play outside the jump hub.

- Add new features required for complete complimentary balance between both inside and outside the Jump Hub. Things like, residual jump node openings, ferries buoys.

- Adjust the transport system's balance to be in complete harmony within the hub.

- Add additional functions to transportation Drives

-Adjust the transport systems balance to be in complete harmony outside the hub.

- In hindsight consider adding and planning some more complex features, like power management, planetary flight, gravity,

[safemode]

I would be highly against adding features when current features are in such great need of work and attention.

The idea of consolidating units doesn't add features in of itself. It actually removes them.

The only real change needed to implement things is changing how jump nodes behave. Since we dont want to make FTL in system necessary, we can't have jump nodes located all over the system in order to reach other system.

So, solution: We use canon logic and tweak things a bit. Canon states that jump nodes are phoned in and are maintained by massive distant machines. So, what if this phoning in doesn't simple initiate an activation, but the signal includes a simple stargate type code. The code isn't simple a code that can send you to any system's jump point though. Since the machines maintain the wormholes, their connectivity is not an accident or random. Certain systems are connected to certain other systems and the signal lets you connect to the varying number of systems your current wormhole can reach.
eg.
Wormhole A can reach wormhole B and C and D. So you goto D. Now, Wormhole D can reach A obviously, and E. Now go back to A and goto B. Wormhole B may be able to reach A and E and F. etc. etc. The system can be setup similarly to the way things are linked now, only instead of multiple wormholes needed to connect to multiple systems, it's done through 1.

Now, with little complication, we create a whole new area of strategy. codes to certain uncharted systems may need to be discovered in missions to shortcut in order to reach a system in time to save the day etc. Also, we can make the canon that jump codes need to be processed by quantum calculations and that's what the jump drive does. expensive jump drives equate to faster calculations... which is important when shields have to be down and weapons offline to send the jump signal burst. Not only is it for energy requirements, but those systems energy fields would interfere with the jump burst. So, jumping is extremely risky for newbies with cheap jump drives.

Ok, so we have the how, and we have the way but what about the traffic jam that is going to occur? The answer to that is a bit more complicated. We could work via a queue system but i dont think that is necessary. The way things work now is kind of wrong. if all a person does is initiate a signal that causes the wormhole to open, then I should be able to fly into someone else's wormhole that they opened and end up in the system they went to ... but that doesn't happen. So what exactly are wormholes in the current game? They are individual wormholes initiated for your particular ship only that just happens to have to be opened in the same exact location. I think we can do away with the idea that it has to all share the exact same location and can only open for 1 unit at a time. Instead we have a zone that is near to a central location that jumping is allowed. Instead of the wormhole opening up for each unit in the same place, it opens in front of each unit that initiates it. Dozens can be opened at once and they could all be going to various locations (since they work on codes for destination now). Conversely, they will open up in systems all over the zone and out will come ships ... Simple collision detection can be done upon loading a new system prior to rendering to determine safe locations to insert incoming ships.

This eliminates the need for a queue, and it eliminates the pileups of incoming units ending up coming out in the same exact location.

[IansterGuy]

I would be highly against adding features when current features are in such great need of work and attention.

The idea of consolidating units doesn't add features in of itself. It actually removes them.

I don't think that is accurate... it seems your hole idea requires new features to make it worth while, and you are even suggesting new features in your post to make it work better. I think it comes more down to how difficult any particular feature is to implement. If it is simple to program it would be worth the effort, since so much would be slated for change anyways.

The only real change needed to implement things is changing how jump nodes behave. Since we dont want to make FTL in system necessary, we can't have jump nodes located all over the system in order to reach other system.

This was the first step I thought necessary. The next step should probably be just to add transport Drive inhibition fields, emitted by the jump points and surrounding stations. This way sub light speeds are enforced within the hub, like a speed limit for safety in the space lanes. One could go a step farther to make this like other games and impose speed limits relative to the buoys. This would protect the space lane and everything in it from ultra high speed kinetic weapons from the outside. I suggested this technology before to make cannon slow close quarters battles, and now this is an even better example of it's use. How I explained it would work is, the faster something is moving relative to the field, the more the field gains energy to impose a counteractive force on the object. This would be like the exponentially increasing friction in water so that if someone decided to strap some rockets onto an almost light speed kamikaze asteroid, that asteroid would under it's own kinetic energy either be stopped or be destroyed by the sudden deceleration due to the field; Even before reaching the lane, and same thing for ships.

Everyone would only be able to effectively use sub light propulsion up to the speed that their engines can manage push to push the ship through the soupy space of the kinetic inhibition field.

So, solution: We use canon logic and tweak things a bit. Canon states that jump nodes are phoned in and are maintained by massive distant machines. So, what if this phoning in doesn't simple initiate an activation, but the signal includes a simple stargate type code. The code isn't simple a code that can send you to any system's jump point though. Since the machines maintain the wormholes, their connectivity is not an accident or random. Certain systems are connected to certain other systems and the signal lets you connect to the varying number of systems your current wormhole can reach.

This dialing feature sounds like an advanced way of doing it. It would require some way to select a destination. Currently jumps are conveniently activated with a single key press after targeting it. Perhaps choosing alternate destinations would be hot keyed the same way as if it was targeting distant invisible subsystems or subunits of the node.

The system can be setup similarly to the way things are linked now, only instead of multiple wormholes needed to connect to multiple systems, it's done through 1.

Well since these ancient maintained inter-system nodes only can go to particular systems according to the landscape of subspace, one would think that sometimes two inter-system nodes would be necessary. It would all create good variety and sense of place.

Now, with little complication, we create a whole new area of strategy. codes to certain uncharted systems may need to be discovered in missions to shortcut in order to reach a system in time to save the day etc.

Iééééé like it.

Also, we can make the canon that jump codes need to be processed by quantum calculations and that's what the jump drive does. expensive jump drives equate to faster calculations... which is important when shields have to be down and weapons offline to send the jump signal burst.

I hate it... Well, hate is a vague word, I think I see the purpose, but I dislike the cannon proposal. There are better ways to explain why things would be balanced a particular way. I don't see a reason yet to require energy to jump at nodes facilitated by ancient machines if they already have a long warm up time. If they did use energy though, the ships should simply be spending energy to help maintain the rift locally at it passes though.

Any calculations should be done by the ships quantum computer, which would be mainly for navigation. This would include all kinds of jumps. Jump drives would be for opening up local rifts to temporary wormholes through subspace, and keep them open as the ship passes through. Since the inter-system jump points are maintained by an ancient machine. No jump drive would be necessary at all. Same with recently constructed jump gates leading to places like ship hangers and planet surfaces and points of interest. Gates would not be effected by inhibition fields because of their proximity, and remote jump nodes maintained by the ancients would also not be effected for unknown reasons.

Ok, so we have the how, and we have the way but what about the traffic jam that is going to occur? [...] if all a person does is initiate a signal that causes the wormhole to open, then I should be able to fly into someone else's wormhole that they opened and end up in the system they went to ... but that doesn't happen. [...] Instead of the wormhole opening up for each unit in the same place, it opens in front of each unit that initiates it. Dozens can be opened at once and they could all be going to various locations (since they work on codes for destination now). Conversely, they will open up in systems all over the zone and out will come ships ... Simple collision detection can be done upon loading a new system prior to rendering to determine safe locations to insert incoming ships.

This eliminates the need for a queue, and it eliminates the pileups of incoming units ending up coming out in the same exact location.

Now this is a fantastic idea. An adaptive whirlpool opening with boundaries, or custom rift opening for each sized ship would suffice. This is a weird part of the game that I would be happy to see improved. Visually the giant unadaptive wormhole seems underdeveloped to any new player, who expects to be ripped apart by the outer rim of the graphic. If the wormhole would just open up so that you and others could fly into it, that would be one thing; but being sucked into the center individually from any angle wherever you may be while near the node, does not make it seem as if intelligently designed ancient machines where running the show. If the Whirling rift stayed open as long as ships are passing that would be better. Though any kind of adaptability for individual ships would make this seem more real.

Edit: Fixed my bad grammar now that I'm not in a hurry.

[log0]

Canon states that jump nodes are phoned in and are maintained by massive distant machines.

I usually don't really care, but this is so...

So, what if this phoning in doesn't simple initiate an activation, but the signal includes a simple stargate type code. The code isn't simple a code that can send you to any system's jump point though. Since the machines maintain the wormholes, their connectivity is not an accident or random.

Stargate VS?

Why not make replace SPEC with a jump drive that requires gigantic amounts of power and thus can only be installed on large vessels (jump ships) and let smaller units dock to them. There you have the restriction for smaller units which will cause clustering at points of interest and still allows for exploration without requiring some god like entities and mystic signals/codes. Some randomness of the destination point would deal with possible collisions (the engine would simply check if there is a unit at destination position and add a safe offset).

This would keep the amount of handwavium as low as possible imho.

[safemode]

Canon states that jump nodes are phoned in and are maintained by massive distant machines.

I usually don't really care, but this is so...

I didn't write the canon. That is what is written for vs already. If you don't like it then it will have to rewrite the back story of vs. Not against that but it is extremely hard to convince people to do drastic changes

So, what if this phoning in doesn't simple initiate an activation, but the signal includes a simple stargate type code. The code isn't simple a code that can send you to any system's jump point though. Since the machines maintain the wormholes, their connectivity is not an accident or random.

Stargate VS?

Why not make replace SPEC with a jump drive that requires gigantic amounts of power and thus can only be installed on large vessels (jump ships) and let smaller units dock to them. There you have the restriction for smaller units which will cause clustering at points of interest and still allows for exploration without requiring some god like entities and mystic signals/codes. Some randomness of the destination point would deal with possible collisions (the engine would simply check if there is a unit at destination position and add a safe offset).

This would keep the amount of handwavium as low as possible imho.

You are under the assumption I'm creating the God beings and signals and machines. Thats already there. I'm cool with jump ships but then it is like waiting for the train to go anywhere. That won't work.

[Deus Siddis]

I didn't write the canon. That is what is written for vs already. If you don't like it then it will have to rewrite the back story of vs. Not against that but it is extremely hard to convince people to do drastic changes

I think there's needs to be a more balanced approach to canon than that. On the one hand you don't want to change canon to whatever flavor of the year idea has been popularized by the latest space opera series on tv.

But if there is a much better game-play and story synergy that can be achieved by changes to canon, big or small, then that needs to be taken a lot more seriously. If jackS wrote the canon around the game play 'parameters' hellcatV outlined for VS, but those parameters aren't working and the game is not popular, then canon changes should certainly not be off the table.

[klauss]

I didn't write the canon. That is what is written for vs already. If you don't like it then it will have to rewrite the back story of vs. Not against that but it is extremely hard to convince people to do drastic changes

I think there's needs to be a more balanced approach to canon than that. On the one hand you don't want to change canon to whatever flavor of the year idea has been popularized by the latest space opera series on tv.

But if there is a much better game-play and story synergy that can be achieved by changes to canon, big or small, then that needs to be taken a lot more seriously. If jackS wrote the canon around the game play 'parameters' hellcatV outlined for VS, but those parameters aren't working and the game is not popular, then canon changes should certainly not be off the table.

Those parameters aren't working because of faulty development, not because the paradigm itself is wrong.

I don't mean faulty development as in bad code or stuff like that, I mean it as in, we haven't exploited its full potential, nor used those elements in a consistent fashion.

VS, as all games, needs consistency foremost.

Thought exercise: consider SPEC and jump points as unchangeable axioms. SPEC's nature as a directed speed multiplier and jump points' nature as a fixed dialable wormhole between two (and only two) endpoints as fixed, not the rest of the details about them. Now... can those elements be used to make a great game? (answer is most probably yes). They don't have to change.

[Brendan]

Hi,

Thought exercise: consider SPEC and jump points as unchangeable axioms. SPEC's nature as a directed speed multiplier and jump points' nature as a fixed dialable wormhole between two (and only two) endpoints as fixed, not the rest of the details about them. Now... can those elements be used to make a great game? (answer is most probably yes). They don't have to change.

As a thought exercise, I want to describe how I think it should be (without any consideration for how things currently are in VS).

First; to avoid a boring game you'd have to assume there are several different races. Let's split time into 4 eras:

• Before space flight:
  • Each race confined to their own home planet, developing their technology in isolation
• Local space flight:
  • Each race's technology reaches a stage where limited space flight becomes possible for them.
  • Because each race's technology was developed in isolation (without any means of sharing information between races) it's likely to be radically different. For example:
    • some races using rocket fuel propulsion
    • some races using some sort of "solar sail" (no fuel, max. acceleration depends on distance to star)
    • some races using some sort of manipulation of gravity to pull their ships forward
  • Each race colonises nearby planets (whatever they can reach without any inter-galactic travel) Note: For some races, this may include terraforming capabilities.
• Inter-galactic travel:
  • After a long long time; one or more races figure out way/s of doing intergalactic travel.
  • There may be multiple different technologies for inter-galactic travel. For example, one race might build permanent "worm hole generators" near their planets, while another race might have some kind of jump drive built into their ships, while a third race might use a combination of autopilot and cryogenics.
  • Note: I'd ignore the possibility of natural worm holes, as (for plausibility) any natural worm holes would be too far away from anything relevant, and travelling to/from these natural worm holes would lead to boring gameplay
• Universal colonisation:
  • Races that didn't manage to invent their own inter-galactic travel technology end up being discovered by a race that did, and (via. treaty or slavery or reverse engineering) end up with the same inter-galactic travel technology
  • The race/s explore; finding resources they need and setting up space stations to exploit those resources (then military to defend those space stations)

The end result of all this is that each solar system ends up with space station/s near important resources, with either a jump point (as ships equipped with jump drives would need to know where the destination is) or "worm hole generator" near the space station (or something else near the space station). Of course no sane person is going to transport raw resources to a processing plant billions of kilometres away in the middle of nowhere - they're going to build the processing plant into the space station itself to reduce transport costs. For example, you might have an asteroid belt with a space station, and that space station is going to be the centre of mining operations, plus an ore processing plant, plus a manufacturing plant, plus a transport hub, plus a trading post; and have a lot of citizens and everything that comes with that (living quarters, training/education, hospital/s, entertainment, etc).

Of course gravity sucks. For planets, you're going to end up with a facility on the planet's surface for extracting raw materials (ore, ice, gases, food/farming, whatever) with a space station (transport hub, trading post, etc) in geosynchronous orbit above it (I'm assuming some sort of space elevator here). Of course planets are large and you might have several of these "surface facility with orbiting space station" setups (possibly owned by different races/factions).

Stars are also a resource, and there'd be space station/s near them extracting energy (and/or gases and/or fuel).

I'd also expect that space stations (at least for most races) would be modular. For example, you might have a manufacturing plant (most likely near a mining/ore processing area) which produces "station modules" of various types (power plant, docks, living quarters, trade, ore processing, gas refinery, shipyard, etc), and these modules would be towed (special tug ships) to distant places and connected together. When a resource is depleted and the space station is no longer needed, it'd be dismantled and those modules could be reused (e.g. added to any other nearby space stations - that'd be a fun escort mission). Some (rare) space stations might even have "engine modules" - e.g. mobile fortresses for the military (power plant + living quarters + docks + engines).

Finally; a player should be able to buy space station modules and own space stations (and receive profits from resources gathered by their space stations). This opens up the possibility of whole new "end game", where a bored merchant (with lots of cash) can try their hand at world domination (e.g. acquire their own mining and manufacturing facilities, while using profits from existing space stations to hire the military forces needed to adequately defend their territory, and hopefully expand and conquer new systems). I think this is as important as fixing the "spending ages flying through empty space is boring" problem - the fun of trading and dog-fighting and upgrading your ship wears off after a while (about 4 days of playing for most people); and that's when the player hacks their save game, gets a cap ship and can't think of a reason to continue playing.


Cheers,

Brendan

[safemode]

Consistency is something that can't occur with SPEC. Not in canon, and not in keeping gameplay actually fun.

I'm not arguing spec should be changed, I dont think it should exist if the game (data side) is written correctly. I dont care how spec ramps up, or how it handles slowing down near objects. That's not what is wrong with SPEC in of itself (those are implementation details).. What's wrong with spec is that we need spec to play the game.

Thought exercise:
Consider how much simpler the canon can be by not having to try to explain how SPEC works or under what principles it works or how everyone got to using it and why ships dont just spec around system to adjacent system when they want to. Consider how much simpler the game can behave when we dont have to worry about SPEC around gravity wells or the physics implications of a unit in SPEC colliding with another unit. Consider how much simpler AI can be without having to deal with SPEC. Then consider how much more you'll be doing in the game because you dont have to use SPEC to reach every single thing and unit because they're too far away to travel by any other means in any decent amount of time.

Bring it all in close, solves many problems and doesn't introduce any magic handwaving or additional techs that we can't hope to explain why it behaves the way it does because it's not based on anything that _might_ work that way and it more importantly, has the potential to keep people interested in playing the game because the game is packed full of activity, instead of you having to go looking for the tiny pockets of activity spread all over.

[klauss]

This is going in circles...

[safemode]

indeed. in the end. both can be accomplished at the same time. They're not mutually exclusive ideas. Fixing spec and getting rid of it, while sounding like you have to choose one or the other, isn't. And accomplishing both goals benefits the game without taking away from either idea.

[klauss]

indeed. in the end. both can be accomplished at the same time. They're not mutually exclusive ideas. Fixing spec and getting rid of it, while sounding like you have to choose one or the other, isn't. And accomplishing both goals benefits the game without taking away from either idea.

So... lets do that?

[loki1950]

Good argument concluded for now I stayed out of it for a reason as I have no preference either way.So what if any thing will be the result remains for the future.

Choice the Choice

[log0]

Just for the sake of offering options. The waiting for the train issue can be dealt with quite easily by making sure there are always ships entering and leaving a zone at a decent rate, like 1ship/sec maybe. All you have to do is contact the closest one and dock to it before it has its jump drive ready. The whole process shouldn't take more than a few seconds.

What is the conclusion now? Multiple jump points or stargate style gates? Keeping SPEC as it is?

[IansterGuy]

Stargate VS? Why not make replace SPEC with a jump drive that requires gigantic amounts of power and thus can only be installed on large vessels (jump ships) and let smaller units dock to them. There you have the restriction for smaller units which will cause clustering at points of interest and still allows for exploration without requiring some god like entities and mystic signals/codes. [...] This would keep the amount of handwavium as low as possible imho.

Wound not drop SPEC for this, ferries would be a good game element on their own but I prefer not for normal travel around the system but rather for special things. Like campaign missions that need to committed to or hard to go to places. The Ferries job could even be in the mission computer.

Telling the player to believe in something they can't see indeed is like telling them to believe in an in game god, but I think it is necessary to support some mysticism behind the back story. This includes the nano plague and all the explanations that they allow, such as: Why AI don't rule the battle field; Why nanobots and or microbots are not common in warfar; Why manufacturing is not highly automated; And in general why things are so dismal, disorganized, and decentralized in the future.

I didn't write the canon. That is what is written for vs already. If you don't like it then it will have to rewrite the back story of vs. Not against that but it is extremely hard to convince people to do drastic changes

I think there's needs to be a more balanced approach to canon than that. On the one hand you don't want to change canon to whatever flavor of the year idea has been popularized by the latest space opera series on tv.

But if there is a much better game-play and story synergy that can be achieved by changes to canon, big or small, then that needs to be taken a lot more seriously. If jackS wrote the canon around the game play 'parameters' hellcatV outlined for VS, but those parameters aren't working and the game is not popular, then canon changes should certainly not be off the table.

I agree the games parameters need to adjust to better plans as they come, but not for the reason to avoid even thinking about the complexity of the current solutions. Should look at it first; determine why it does not work; then make an informed decision on a new plan while keeping everything good that works. Redoing work where benefits are not maximized I imagine dose not get as much done as being more selective.

Thought exercise: consider SPEC and jump points as unchangeable axioms. SPEC's nature as a directed speed multiplier and jump points' nature as a fixed dialable wormhole between two (and only two) endpoints as fixed, not the rest of the details about them. Now... can those elements be used to make a great game? (answer is most probably yes). They don't have to change.

I totally agree with this. Also none of that has to change to make a great game where traffic, Points Of Interests and combat, are all concentrated if they are only so within the hub. Well configured transportation inhibition fields would be the only dependency and have the same results without disallowing linear travel or altering the sizes and distances within the solar system.

[*]Inter-galactic travel:

• After a long long time; one or more races figure out way/s of doing intergalactic travel.

You would mean interstellar (between start) not intergalactic (between galaxies), that would be a long trip unless ships can travel the milky way in a few seconds, or one just jumps there somehow.

The end result of all this is that each solar system ends up with space station/s near important resources, with either a jump point (as ships equipped with jump drives would need to know where the destination is) or "worm hole generator" near the space station (or something else near the space station). Of course no sane person is going to transport raw resources to a processing plant billions of kilometres away in the middle of nowhere - they're going to build the processing plant into the space station itself to reduce transport costs. For example, you might have an asteroid belt with a space station, and that space station is going to be the centre of mining operations, plus an ore processing plant, plus a manufacturing plant, plus a transport hub, plus a trading post; and have a lot of citizens and everything that comes with that (living quarters, training/education, hospital/s, entertainment, etc).

Now this sounds like a nice cozy solar system that is really believable. One central hub at the most prominent location in the system, then a few other clusters of activity at interesting locations. I would have insystem jump nodes to get to some of these local system locations from the central hub, but others would need to be traveled to using a speedy transport drive either on the players ship or on giant space ferries.

Of course gravity sucks. For planets, you're going to end up with a facility on the planet's surface for extracting raw materials (ore, ice, gases, food/farming, whatever) with a space station (transport hub, trading post, etc) in geosynchronous orbit above it (I'm assuming some sort of space elevator here). Of course planets are large and you might have several of these "surface facility with orbiting space station" setups (possibly owned by different races/factions).

Space elevators, and low orbit transport stations. Now this is a nice way to sidestep the time it takes to land on every planet. Alternatively or additionally, insystem jump nodes or jump gates and or jump drives could take small ships right to surface hangers, vacuumed of atmosphere for the purpose. A fee would be charged per mass for landing using that method meaning that it would be mostly for passenger, express and military use, since fighters and couriers could be small. Cargo ships would dock with the stations and shuttle sized cargo ships would sometimes land to avoid the elevator fee if they must land for some reason anyway perhaps to get better deals or selection or to complete a mission on the surface.

...these modules would be towed (special tug ships) to distant places and connected together.

Towing missions would probably need a new take on how the tractor beam works. It would have to hold objects static and work from behind.

Finally; a player should be able to buy space station modules and own space stations (and receive profits from resources gathered by their space stations). This opens up the possibility of whole new "end game", where a bored merchant (with lots of cash) can try their hand at world domination[/quote]Including real time strategy elements in Vega Strike is very very low priority as I understand and for good reason. First and foremost Vega Strike is a Space shooter then Space Simulator then anything else. There are others that have similar Real Time Strategy ideas and and base ownership, it would work somehow, but this is so far away from being considered for development right now that it's just a passing thought. Though possibly some domination of the players environment could be worked into some sort of campaign story.

indeed. in the end. both can be accomplished at the same time. They're not mutually exclusive ideas. Fixing spec and getting rid of it, while sounding like you have to choose one or the other, isn't. And accomplishing both goals benefits the game without taking away from either idea.

So... lets do that?

If serious then idea can get it's boots on and start trenching through the snow now. The goal of being less sprawled and more clustered seems like it could be easily tested.

To start testing I would pick a system, probably the starting system "Cephid". Place the all the Jump Nodes and some stations to orbit planets in clusters together, so they don't move relative to others in the cluster. Then make new minor In-System Jump Nodes denoted by the color and size to link to other clusters and significant places like asteroid field stations, planetary docking bays, and anywhere else a player without SPEC would need to go. Most jumps in the hub should be close enough to each other that traveling in between them with thrusters is way faster than traveling witch SPEC currently. Since jump sweet spots would depend on the subspace landscape, distances in between should vary somewhat. For longer runs that go beyond the Stations inhibition field, start creating friendly space lanes by placing the odd buoy and virtual dual color coded markers where required to somehow clearly and possibly redundantly denote direction of traffic. Some of these buoy would be large enough to optionally act as also sentries and inhibition field emitters. They would scan ships, shoot at law breakers and hostiles to the systems faction. They would be rarely destroyed in which case they would be eventually replaced in time depending on how expensive it is for the faction. The inhibition fields that the buoys, sentries and stations emit would block SPEC the same as now; but also it would resist ships trying to move at ridiculous speeds through the hub at a rate either logarithmic or exponential to the the relative speed [I'm not sure which is the right way to say it].

Strength Placement, and direction of inhibition field emissions would be set so ships flying between them are protected, yet can accelerate to decent speeds in the near center of the path and faster in the middle of the run. At the ends of the run inhibition fields would be configured to slow ships down to decent speeds to avoid too much overshooting of the destination. In the middle of the run fields would be more spread out so to act almost as much on near ships as distant ones.

The inhibition field emitters could be arranged in many different ways according to the needs of the system, though in general there would be a sentry near each node for unwelcome visitors. Marker buoys would be in the center of the lanes simply marking the traffic flow direction with virtual double color coded markers. Then inhibition emitters would be either arranged in a sequences either surrounding the run to make a center hollow or just along it.

Good argument concluded for now I stayed out of it for a reason as I have no preference either way. So what if any thing will be the result remains for the future.

Hey let's not close this chapter yet, I'm still typing. Though it does seem near a conclusion as for possibilities. What about the details? Suggesting any dependencies or prerequisites and a priority? Also, I don't think we even know the difference between the pure form of what Safemode was originally suggesting, and how it would be if in game technology was used to create those inhibited jump hub safe zones for for concentrating various aspect of the game.

Just for the sake of offering options. The waiting for the train issue can be dealt with quite easily by making sure there are always ships entering and leaving a zone at a decent rate, like 1ship/sec maybe. All you have to do is contact the closest one and dock to it before it has its jump drive ready. The whole process shouldn't take more than a few seconds.

I can't tell if your joking or sarcastic or what "{Sarcasm goes here}:-P" One ship a second? That's hardly profitable. I think insystem jump nodes also known as interplanetary jump nodes would be the answer. Ferries would be reserved for missions or hard to get to places. Hence the wait for the time. Which makes me notice there is no clock in the game. Maybe there could be if everyone is counting the seconds or need to arrive on time for the ferries.

What is the conclusion now? Multiple jump points or stargate style gates? Keeping SPEC as it is?

Well I would support inproving SPEC as already suggested because it is still broken. Single destination jump points as is now with the option to change it later get my support. Modern made Transport 'Gates' could also be a future option. I'm opposed to general removing of content because that sounds like the residue from proprietary software propaganda, who only include polished and completed work. If having polished versions is desired, maybe plan clean polished versions in a predictable release pattern.

[log0]

I can't tell if your joking or sarcastic or what "{Sarcasm goes here}:-P" One ship a second? That's hardly profitable.

OK going otop, but good running airports have an arrival/departure rates of close to one minute. I bet they would aim for even much lower times if there weren't restrictions due to flight physics and runways. What does this tell about their profitability?

[klauss]

What is the conclusion now? Multiple jump points or stargate style gates? Keeping SPEC as it is?

Well, the more readily viable option is clustered layout but unchanged mechanics:

• Concentrate everything around a single POI at Cephid-17
• Keep SPEC as it is, but generally unneeded because everything would be closer
• Jump points still have 1-to-1 correspondance with destinations, but are closer together
• Make sure Cephid-17, like this, is nice on the eyes

That's for a first phase. To test the feasibility of such a layout. Then:

• Add secondary points of interest
• Alter ASAP to use SPEC only for really long hauls...
• ...or make interdiction around jump clusters high enough that SPEC is infeasible there
• Add other clustered systems near Cephid-17, test inter system travel

For a second phase. This is just a small step, because after this, the real work begins, and this is assuming everything goes as planned and no significant issues with the paradigm are encountered:

• Modify the system generator to generate clustered systems
• Modify mission scripts to adapt them to the clustered topology (label off-hub missions as well as off-system, for instance)
• Modify SPEC to be either an expensive upgrade or a difficult to maintain one
• Implement ferries for those not willing to equip a SPEC drive

And that's as far as I'd go with planning...