Return to “Suggestions”

Post

Re: Jumpdrives, Jumpgates and Wormholes

#241
outlander4 wrote:A mixture of official channels and illegal ways can be used - e.g. cargo can be transported through high-security border system via a backdoor using small transports to avoid attracting attention, and left there at certain secure location; player will have to pick it up, load it into cargo hold, hack the manifesto and proceed to more relaxed core systems.
[...]
Spying in LT can be made really simple - when one faction needs to spy on the other, starts searching for a man who can do the job - i.e. one who's neutral with the enemy faction and can go deep inside their territory. It can be player, it can be NPC. He must be trusted by the faction to do the job; faction may provide some technology. The goal is to enter enemy territory and take scans of certain objects or gather other information. Of course, some activities would require stealth and using backdoors but again the whole system doesn't have to rely on complicated wormhole mechanics.
Sounds good. :thumbup:
Post

Re: Jumpdrives, Jumpgates and Wormholes

#242
Cha0zz wrote:
Cornflakes_91 wrote:Im more in favour of both ends need charge and charge slowly permeates between all connected ends.
So if in Cha0zz' case the ship wants to fly from a to b it would only need to pump charge into A, and the both ends equalise after a time, making travel possible
But that would mean that investing money to reinforce 1 endpoint would give you a free upgrade for all the connected ones (which could be more than 1 in thymineC's proposal), thus spending money to improve 1 endpoints gives you a lot of 2-way routes that can be used.
While in my idea the costs of improving wormholes is linear with the amount of jumps you want to execute (and the direction of them).
Is that actually a problem? Refer to my idea of modelling wormholes like shelves:
Image If you have a support that's helping to hold up many shelves concurrently, then a clever thing to do to improve the stability of many of them at once would be to strengthen that support. I don't see this as being a problem so much as an interesting consequence of the proposal.

What would be a lot more interesting, though, is Cornflakes' idea of charge permeation. I don't really see any immediate gameplay benefits of it but I've thought about it and it strikes me as a really elegant idea all the same. What exactly is "charge"? It's the potential energy that a wormhole endpoint has to cause matter to transit along it, sure, but what is responsible for that potential? In capacitors, "charge" is a potential caused by a buildup of electrons at one end and "electron deficits" (or "holes") at the other. In batteries, "charge" is the potential for two electrodes made of materials with different electron affinities that are immersed in an electrolytic solution to undergo oxidation and reduction reactions that causes charged particles to flow across the solution and through the rest of a circuit.

In wormholes, charge may be based on wormholes being made up of some exotic kind of particle - let's call these "nuons" for now, because why not? Now endpoints could be "charged" by converting electricity into nuonic matter, and nuons are capable of facilitating transits, decaying into photons when this happens. But if nuons are matter, what stops nuons occassionally causing other nuons to transit across the wormhole?

If this is the case, then each nuon can be imagined to have X% probability of being transited at each moment in time, and it stands to reason that an endpoint with higher charge - that is, with more nuons - will transit more nuons than an endpoint with lower charge (and fewer nuons) at each moment in time, just due to the law of large numbers. If we have two wormholes that are paired to each other and therefore transit matter to each other, what we then see is a diffusion process in which there is a net transfer of nuons - and therefore of charge - from the higher-charged endpoint to the lower-charged one.

This would also explain why wormholes decay naturally in the first place - because nuons are constantly being expended to transit other nuons between the two endpoints of a wormhole. If we imagine it this way, then permeation rate would correlate with decay rate, such that charge permeates fast from a high-decay-rate J endpoint, slower from a mid-decay-rate S1 endpoint, and slower still from a U-type endpoint. And of course, this all ties in perfectly with the equilibrium charge level as well! The more charge you put into an endpoint, the more nuons it contains, the more nuons get transited, the higher the permeation rate and therefore the higher the decay rate, all in a way that perfectly and naturally establishes a dynamic equilibrium level between charge and decay rates! :D This is working out so elegantly that I don't even. :clap:

This diffusion will only work along the directions that wormholes "point" in. Consider the example below:
Image The two S1-type endpoints (the green ones) that are paired with each other sustain a bidirectional wormhole with each other. Therefore, diffusion will occur between them. In the case of the unidirectional J-S1 wormhole, however, charge will only be transferred from the J-endpoint to the S1-endpoint, even if the J-endpoint has less charge. Charge can simply not flow in the opposite direction because the S1 endpoint does not point to the J endpoint.

This mechanic will not necessarily mean that all bidirectionally-connected endpoints will equalise over time, as we're not considering a closed system and endpoints will still decay and be charged externally at different rates. It would however cause interesting dynamics to appear between wormholes if charge could permeate between them in this way.

Contrary to what I stated earlier, U-type endpoints can be charged, but due to their nature that charge instantly decays i.e. their decay rate always rises to match the increase in charge rate - hence their equilibrium charge level remains constant. This still makes trying to charge them pointless and therefore avoids the gameplay issues that would arise if U-type endpoints could be charged, but I feel this is more elegant than saying that they strictly cannot be charged. This also means that charge can permeate across wormholes even to U-type endpoints, but all this accomplishes is increasing their decay rate and makes them more easily detected.

Edit: To be more clear, it won't necessarily always be the case that a net positive diffusion exists between a higher-charged endpoint and a lower-charged endpoint even if both point to each other; what actually matters is their decay rates. Decay rates tend to increase with charge levels, but different types of endpoints naturally decay at different rates even for the same level of charge, so it's possible for a net positive charge transfer to exist between a naturally-high-decay-rate J endpoint and a naturally-lower-decay-rate S1 endpoint, even if the S1 endpoint has more charge.
Post

Re: Jumpdrives, Jumpgates and Wormholes

#243
There's been a few days with no activity on this thread; can I assume that we reached some sort of consensus, or is everyone just punch drunk and taking a breather?

I'm going to outline an alternative set of options for the sake of getting everything on the table. The general concept I'm working from is Freelancer + FTL drives for capital ships and fleets (with a few tweaks to capture the good ideas that have been thoroughly bounced around in this thread). My goal is simple-but-deep, the holy grail of game design. I probably won't get anywhere near it, but with a system that we know works for single-player exploration and trade type gameplay as a base, we may be a tad more confident than creating something from scratch.

So, unto the breach...

There are three different ways in which a ship or group of ships can move from system to system:
  • Naturally occuring wormholes
  • Artificially constructed jump gates
  • FTL drives equipped to capital ships
Needless to say, each method results in instantaneous travel from one system to another. The names of each are deliberately differentiated, rather than re-using "jump" or wormhole too much. They essentially map to three different different gameplay styles or events: (a) exploration/trade; (b) empire building; (c) large-scale factional war.

The mechanics of each are as follows:

Naturally occuring wormholes
Wormholes connect two specific points in space and allow the passage of a certain mass of objects at a certain frequency. These points are called Apertures. It's actually better to think of a wormhole as a "group" which consists of a bunch of apertures which join together according to some form of periodicity.

Detecting a wormhole is done by scanning and finding one of the apertures. The scan will reveal:
  • The unique wormhole signature
  • The number of apertures in the wormhole group
  • The current state of the aperture
  • Time until the wormhole can be opened again
The current state of a wormhole aperture is either Active or Dormant. The time until the wormhole can be opened again depends on when it was last opened, and the combined mass of the objects that went through (up to a certain maximum value). This is essentially the charge mechanic distilled into the simplest form I can think of.

The scanner does not tell you the location of the other apertures in the wormhole group. To figure that out you have to scan them individually and match the signature in your database, or simply go through the wormhole when it's active.

I thought about having a system whereby there was a "key" to each wormhole, which would be a particular particle beam or other physics hand-waving that opens the aperture. I am still torn on whether that's a good idea or not. Different beam combinations could then open the different locations, rather than having some form of natural periodicity to the connections (or you could combine the two). It strikes me that it would be a nice mini-game, but sitting out in space firing different beam combos... nah.

Constructed jump gates
These are much simpler in terms of their connectivity. They can be constructed anywhere and they allow passage between two locations - end of story. They are also owned however, in a way that natural wormholes can't be, and therefore you will need permission to use them from the owning faction.

Jump gates also have a maximum mass that can pass, and a time-to-open mechanic, but this will depend on the technology used to build them.

FTL drives
These things allow a capital ship and associated fleet to jump into a different system. They have some interesting characteristics, however:
  • They require a "buoy" at the receiving end of the jump to mark the location
  • They require fuel
The length of the jump that the drive can make and the mass it can transport will depend on the capability of the drive (i.e. its tech level), how long the buoy and capital ship have been stationary, and the remaining fuel. In other words, to make a jump, you need to position and protect a buoy for a certain period (notionally to make the FTL calculations - "ain't like dusting crops, boy") and have the right amount of fuel on board. There would have to be some way to associate the ships you wish to jump along with the FTL drive ship - this would be part of the UI.

The goal of the FTL drive mechanic is to allow fleet jumps, but to avoid sudden arrivals of overwhelming numbers. To make a jump would require a scouting wing of fighters and the buoy ship travelling to the destination, which should make for some interesting protection missions.

And that's it. With the right presentation of information, a new player should pick this up pretty quickly without having to read through reams of lore, but it should also enable pretty deep and complex gameplay.

TL;DR: moving between "systems" is Freelancer + FTL drives for fleets.
Post

Re: Jumpdrives, Jumpgates and Wormholes

#244
mcsven:

how is this simpler than the charge mechanic?

instead of 1 easily understandable formula you now have a maximum value for transits and a time between transits which are independent variables.
with charge you have 1 formula from which you get both in a simple and transparent way.

also you have split wormholes, jumpdrives and jumpgates in 3 completely independent mechanics, which were nicely unified with charge.

this "key" mechanics also makes exploration something between very hard and impossible.
as when you dont know the key of an unknown system, how do you travel there?


your FTL drive also increases complexity as you have to select every single ship to travel with you,
whereas with the charge-based jumpdrives you create a wormhole which everyone can pass who wants/needs to use
which would also be no different in any way than a natural wormhole besides recharge.
the charge based approach also limits the amount of simultaneous ships to transfer, as you have to supply the charge to the wormhole you need for the mass to transfer


thymine and everyone in favour of one-way wormholes:

i found a problem with one way connections to random wormhole ends

if you connect your jumpgate to an already existing, enemy controlled wormhole you can send ships through without fear of immediate retaliation, as there is no direct way of travelling to the source of the ships.
effectively unlimited attack without possibility of counter attack? sounds like dangerous terrain for balance...
Post

Re: Jumpdrives, Jumpgates and Wormholes

#245
mcsven wrote:There's been a few days with no activity on this thread; can I assume that we reached some sort of consensus, or is everyone just punch drunk and taking a breather?
There are several consensi. This one is mine.
It works and doesn't need any more complexity because it already does all the important things with a smaller feature set.
(as opposed to 16 types of alphabet soup wormhole connections =)

Cornflakes_91 wrote:i found a problem with one way connections to random wormhole ends

if you connect your jumpgate to an already existing, enemy controlled wormhole you can send ships through without fear of immediate retaliation, as there is no direct way of travelling to the source of the ships.
effectively unlimited attack without possibility of counter attack? sounds like dangerous terrain for balance...
I've been repeating this so often I'm starting to feel like a broken record. =P
Any means of travel that lets you pick a destination in another sector does that. It doesn't matter if your destination is a wormhole or any old point in space.

However, there needs to be a way to counter fortification of jumpgates or turtling in general.
That's the temporary wormholes I outlined. If you send a major fleet through, you are certain to cut off your way back home so you better make it count. Or you slowly trickle in some guerrilla forces to scout, sabotage, harass and disrupt.
What it doesn't allow is to take your killer stack and jump it into one enemy system after another because those temporary WH are random and you're not going to always have the perfect set of backdoors to anywhere.
That gives your enemy time to react on a strategic scale. Fortify, counterattack, find a way to deal with a specific weapon system you used...

However however... turtling (after a fashion) is still a possibility if you come across a pocket of sectors that are connected by temporary wormholes only.
Sure, conquering that area of space would be a challenge but hey... if you must have your secret base on the remote island...
There is no "I" in Tea. That would be gross.
Post

Re: Jumpdrives, Jumpgates and Wormholes

#246
Gazz wrote:
mcsven wrote:There's been a few days with no activity on this thread; can I assume that we reached some sort of consensus, or is everyone just punch drunk and taking a breather?
There are several consensi. This one is mine.
It works and doesn't need any more complexity because it already does all the important things with a smaller feature set. (as opposed to 16 types of wormhole connections =)
well, mine does the same while providing an easily understandable math framework around it for building Jumpgates and jumpdrives
:P
Post

Re: Jumpdrives, Jumpgates and Wormholes

#247
Cornflakes_91 wrote:thymine and everyone in favour of one-way wormholes:

i found a problem with one way connections to random wormhole ends

if you connect your jumpgate to an already existing, enemy controlled wormhole you can send ships through without fear of immediate retaliation, as there is no direct way of travelling to the source of the ships.
effectively unlimited attack without possibility of counter attack? sounds like dangerous terrain for balance...
You and Cha0zz just gave me an idea that I'm really interested in. :thumbup:

Cha0zz expanded on the idea he presented earlier by imagining that the scanner data you obtain from an endpoint is affected by any connections it forms with other endpoints:
Spoiler:      SHOW
Image
You see in the diagram above how connected endpoints appear as small bumps along the frequency spectrum. However, what if those bumps were smaller versions of the profiles of the connected endpoints themselves? In this way, frequency profiles work in a kind of fractal manner, where the profile of one endpoint contains smaller versions of the profiles of other endpoints one jump away, each of which contain the profiles of other endpoints two jumps away, and so on.

I'll be using the following terms for the sake of clarity:
  • Frequency profile refers to the pattern of emissions - the amplitude of emissions at each frequency - for an endpoint in its entirety. This is the pattern you will see on your frequency scanner if you direct it at an endpoint.
  • Receive zone refers to the part of the frequency profile over the lower frequency ranges which is where you will see smaller versions of the frequency profiles of other endpoints that the endpoint we're considering receives from.
  • Transmit zone refers to the part of the frequency profile over the higher frequency ranges which is where you will see a smaller version of the frequency profile of the endpoint that the one we're considering "points" (transmits) to. There is always exactly one of these. If an endpoint transmits and receives from the same endpoint (as a bidirectional connection), its profile will appear in both the receive and transmit zone.
  • Identification zone or ID zone refers to the part of the frequency profile over the middle frequency ranges, which is the part of the profile that uniquely identifies the endpoint we're considering and remains fixed regardless of what connection it forms. This allows wormhole endpoints to be distinguished from one another and information on them to be stored in a database for future reference, as mcsven proposes.
A sketch of roughly what a profile might look like for an endpoint that receives from one endpoint and transmits to another is given below.
Image For a bidirectional wormhole in which two endpoints are paired together and form no other connections with other endpoints (the most commonly occurring variety), a frequency profile would look like this:
Image In both these graphs, I simplify the level of detail considerably, because I only show the ID zones of the two profiles within the receive zone and transmit zone, and not their own receive and transmit zones in turn.

It's interesting to note that in the case of a bidirectional connection - or any other series of connections that form a cycle, for that matter - the frequency profile will be infinitely complex, because each endpoint's profile will be based on the profile of its pair, but its pair's endpoint will be based on its own profile in turn. Therefore the profile that emerges in this case would be a true fractal. I only point this out as an interesting side-effect of the proposal - an algorithm used to generate a frequency profile of an endpoint would only be limited to a certain depth of, say, 4 or 5 levels before the contributions of profiles generated at that level become inconsequential, and to avoid generating unnecessary CPU overhead.

How does this tie into gameplay? The idea is that scanners can have different levels of resolution, and you and other agents in LT can research scanners with higher resolution as you progress through the game. Now, the higher the resolution of the scanner, the smaller the details of a given frequency profile the scanner can glean, correct? In the case of wormholes, the finer a scanner can resolve a pattern of emissions from an endpoint, the better able it is to also resolve the smaller fractal-like profiles of the connected endpoints one jump away. And if it's got really high resolution, it could potentially even glean the yet-smaller profiles of connected endpoints that are two jumps away, and so on.

Imagine a ship approached a wormhole endpoint. A basic scanner would only provide information about that one endpoint, such as its charge level and ID:
Image An intermediate scanner with higher resolution could resolve the profiles of any endpoints directly connected to the one it's scanning, giving information about them as well:
Image An advanced, high-tech scanner with very high resolution could resolve the profiles of endpoints that are two jumps away, giving them still more information:
Image How does this resolve the original issue about unidirectional endpoints favouring attackers?
Cornflakes wrote:if you connect your jumpgate to an already existing, enemy controlled wormhole you can send ships through without fear of immediate retaliation, as there is no direct way of travelling to the source of the ships.
Imagine an attacker intends to attack a system belonging to another faction. He has a big fleet with him, and among that fleet is a large, expensive WHM-equipped vessel. Based on previous exploration of the system or the use of a stealthed scout, the attacker obtains the ID of one of the S1 or S2 endpoints in his enemy's system. The fleet admiral orders the WHM-equipped vessel to establish a jump-bridge with that endpoint, which it begins doing.

Now, one thing to bear in mind is that it takes a considerable amount of time to establish a jump-bridge capable of ferrying a whole fleet, and the attacker has just formed a connection with one of the stationary, stable and therefore probably well-monitored or secured endpoints in the enemy system. If the enemy faction is on its guard, it won't be long before they notice what's happening - if they are monitoring the profile of their endpoints and notice an unexpected and unrecognised profile appear in the receive zone of one of them, they'll know something's up. Now, they may not be able to prevent that jump-bridge from forming short of destroying a potentially quite-valuable connection between their system and another, but what they can do, if they have a high enough level of technology, is perform a high-resolution scan of their endpoint as the attacker is establishing a jump-bridge to it. That jump-bridge means that the receive zone of the endpoint would have changed and now includes a smaller version of the frequency profile of the endpoint being maintained at the attacker's fleet location by the WHM-equipped vessel, and a powerful enough scanner could resolve that profile and therefore get a lock on it. The defender can then attempt to establish their own jump-bridge to the attacker's endpoint at the same time as the attacker is establishing their own.

As stated in a previous post and in agreement with what Gazz said, closing an already-formed J-type endpoint is a complex procedure that takes time, and the higher the level of charge it's at, the longer it takes to close. Therefore, when the attacker notices the defender forming their own jump-bridge to its location, it has a few choices:
  • They can continue to try and charge their endpoint, hoping to get their jump-bridge stable enough to transport the fleet to the defender's location before the defender stabilises their own jump-bridge. If they fail, the defender will be able to jump their own counter-fleet through to the defender's location and into the middle of their fleet.
  • They can try to safely close the endpoint, hoping to shut it down before the jump-bridge of the defender stabilises. If they fail, the above situation occurs.
  • They can try to shut the endpoint down quickly, but this has a high probability of explosively destroying the WHM-equipped vessel and anything around it. The WHM-equipped vessel is expensive, so even losing it alone would count as a considerable loss for the attacker.
You see that in a situation like the above, the attacker and defender may frequently end up racing each other to establish a stable jump-bridge before the other.

How does this affect other areas of the proposal? One other notable thing that this proposal affects is how exploration vessels could use WHMs. I previously intended for WHMs to be used mainly for backtracking through existing systems. Now, however, an exploration vessel with a suitably advanced scanner may be able to scan one endpoint and get locks on endpoints that are connected to that one, but which they haven't needed to physically scan themselves. They can potentially jump to endpoints that they haven't visited.

However, exploration vessels are likely going to spend most of the time charting unexplored and uncivilised regions of the galaxy. Most if not all naturally forming wormhole connections will be bidirectional connections between two endpoints, neither of which form connections with any other. In this case, an exploration vessel equipped with even the most sophisticated scanner would only get a lock on two endpoints every time it scans an endpoint of a natural wormhole: the endpoint it's physically scanning, and its pair. So it could now use its WHM to jump directly to the paired endpoint if it wanted to, but this would likely be pointless as it could just transit along the wormhole using the endpoint right beside it.

However, if more complex wormhole connections can form naturally, then an exploration vessel with a more sophisticated scanner would have an advantage in these situations. Exploration vessels would also have an advantage in developed/civilised regions of space, where complex wormhole setups are more likely to form. They could scan one endpoint that is part of a complex network and obtain locks on many other endpoints as well, allowing them to travel around the civilised regions of space quite quickly. I think this is ideal, since exploration vessels are built to explore and so it shouldn't take too long for them to move around civilised/previously-explored regions of the galaxy.

Couriers equipped with more advanced scanners could potentially find faster ways of getting around the galaxy as well, decreasing communication delays between commanders and subordinates (for both the player and other agents) in the case that they cannot instantaneously communicate over an established information network.

Edit: "transit zone" -> "transmit zone"
Last edited by ThymineC on Sun May 04, 2014 11:08 am, edited 5 times in total.
Post

Re: Jumpdrives, Jumpgates and Wormholes

#249
Gazz wrote:
Cornflakes_91 wrote:i found a problem with one way connections to random wormhole ends

if you connect your jumpgate to an already existing, enemy controlled wormhole you can send ships through without fear of immediate retaliation, as there is no direct way of travelling to the source of the ships.
effectively unlimited attack without possibility of counter attack? sounds like dangerous terrain for balance...
I've been repeating this so often I'm starting to feel like a broken record. =P
Any means of travel that lets you pick a destination in another sector does that. It doesn't matter if your destination is a wormhole or any old point in space.
Not neccesarily.
With my always two way wormhole solution you know where they come from and give them some of their own medicine.
You see where they come from, you can mount an counter attack.
Post

Re: Jumpdrives, Jumpgates and Wormholes

#250
Cornflakes_91 wrote:mcsven:

how is this simpler than the charge mechanic?

instead of 1 easily understandable formula you now have a maximum value for transits and a time between transits which are independent variables.
with charge you have 1 formula from which you get both in a simple and transparent way.

also you have split wormholes, jumpdrives and jumpgates in 3 completely independent mechanics, which were nicely unified with charge.
I don't really agree that one mechanic split three ways is simpler to understand than three clearly differentiated mechanics. I mean, constructing a jump gate and performing a fleet movement are clearly different than moving through wormholes, which are present in the universe when it's created. Unifying them doesn't obviously simplify anything in terms of gameplay for the user (though it may do in terms of lore, which is different).

The constraints I proposed were simply a distillation of the charge mechanic where it's applicable. After all, how will the charge mechanic manifest itself? In a time delay until the user can use the wormhole. So instead of pushing some aspects of the wormhole lore on the user, I've just suggested cutting to the chase for the ease of gameplay. As for maximum mass: I presumed that this was always going to be the case, unless you are happy for any mass to move through a wormhole?
Cornflakes_91 wrote: this "key" mechanics also makes exploration something between very hard and impossible.
as when you dont know the key of an unknown system, how do you travel there?
I'm not sure whether this is a misunderstanding or just bad comms on my part. I said I toyed with the idea of the "key" but decided against it. Otherwise my suggestion has no real bearing on the ease of exploration, with the exception of requiring permission to fly through faction-owned jump gates. Ultimately these are simply Freelancer mechanics, so I don't see too many major issues.
Cornflakes_91 wrote: your FTL drive also increases complexity as you have to select every single ship to travel with you,
whereas with the charge-based jumpdrives you create a wormhole which everyone can pass who wants/needs to use
which would also be no different in any way than a natural wormhole besides recharge.
the charge based approach also limits the amount of simultaneous ships to transfer, as you have to supply the charge to the wormhole you need for the mass to transfer
Let's not be too disingenuous. To assemble a fleet you'll have to identify the ships that belong to the fleet. That's all I was saying, nothing out of the norm. If you specify that the fleet object should move then every ship in the fleet moves too. All other mechanics are simply to handle the "sudden appearance of overwhelming force" factor.
Post

Re: Jumpdrives, Jumpgates and Wormholes

#251
mcsven wrote:
Cornflakes_91 wrote:mcsven:

how is this simpler than the charge mechanic?

instead of 1 easily understandable formula you now have a maximum value for transits and a time between transits which are independent variables.
with charge you have 1 formula from which you get both in a simple and transparent way.

also you have split wormholes, jumpdrives and jumpgates in 3 completely independent mechanics, which were nicely unified with charge.
I don't really agree that one mechanic split three ways is simpler to understand than three clearly differentiated mechanics. I mean, constructing a jump gate and performing a fleet movement are clearly different than moving through wormholes, which are present in the universe when it's created. Unifying them doesn't obviously simplify anything in terms of gameplay for the user (though it may do in terms of lore, which is different).

The constraints I proposed were simply a distillation of the charge mechanic where it's applicable. After all, how will the charge mechanic manifest itself? In a time delay until the user can use the wormhole. So instead of pushing some aspects of the wormhole lore on the user, I've just suggested cutting to the chase for the ease of gameplay. As for maximum mass: I presumed that this was always going to be the case, unless you are happy for any mass to move through a wormhole?
Its not a mechanic split into 3 parts.
Its a single mechanic.
You travel through a wormhole: you look at the charge and travel through.

You build a jumpgate: you take an wormhole module and pump charge into it until it suits your needs. Like you do with an wormhole

You want to use an jumpdrive: you get an wormhole module and treat it no different than an jumpgate.

All usecases work the same way and do not need different interfaces or usage methods

Its also not forcing any lore into anybodys face.
Its an number next to the entry of the wormhole, maybe with a few extra numbers like current charge rate, charge needed for your ship and time until your ship can use it.
No lore, just 1 (+may a few) number(s).


Its complexity is proportional to the size of your operations.

If you have a single JD equipped ship simply an derivated "max range" gets shown in the JD menu.
From there you may drill down to the precise charging rate and transform rate numbers from where you can calculate additional numbers.
Like max mass per distanve transported and stuff.
Post

Re: Jumpdrives, Jumpgates and Wormholes

#252
Are we really disagreeing over that much?

In both cases:
  • For a wormhole the previous user will have an affect on your ability to immediately access it
  • For a jumpgate, you have to build something
  • For a fleet operation, you will need to have a ship equipped with a piece of kit
  • In all cases the user will probably select the object and hit "use" or "dock" or whatever, just like in Freelancer
Naming convention aside, there really isn't going to be a significant difference to the player when using these systems. I guess there's a subjective preference between saying "here's the current charge level" and "you have to wait 2 minutes to use the jump hole" but practically speaking it will have little import. As I said in the original post, I think telling the user how long they have to wait is simply the simplest way to implement the charge mechanic.

The differences therefore come mostly in the fleet mechanics, the subtleties of how wormholes are connected together and the need for permission to use faction-owned jump gates. I can't see the latter really being too objectionable to anyone, so really it's about wormhole connectivity and fleet movements. The wormhole stuff is a combination of the bits I like from the thread and a desire to keep it understandable and the fleet mechanics are simply a potential way to handle the overwhelming force problem. If you're married to unrestricted fleet movements however, then clearly we won't agree... but to me the rest is basically small variations on the same theme.
Post

Re: Jumpdrives, Jumpgates and Wormholes

#253
I'm also in favour of the way Cornflakes' system nicely unifies things. When I scan a wormhole endpoint, I (minimally) expect to see the following information, depending on my scanner's resolution:
  • Wormhole type
  • Charge rate
  • Decay rate
  • Net charge rate
  • Current charge level
  • Projected equilibrium charge level
  • Projected time until equilibrium is reached (or endpoint closes if projected equilibrium charge <= 0)
  • Level of charge needed to transit my ship/fleet
  • Projected time until charge level where I can transit my ship/fleet
  • Number of connected endpoints
  • Endpoint that this endpoint "points" to, if information is available
  • Endpoints that this endpoint receives from, if information is available
Last edited by ThymineC on Mon May 05, 2014 8:16 am, edited 1 time in total.
Post

Re: Jumpdrives, Jumpgates and Wormholes

#254
mcsven:
Yeah, our disagreement is simply a matter of UI
You proposition can as well be implemented ontop of mine (besides of Jumpdrives) with an UI layer.
No need to change the fundamental mechanics.

In which form is my jumpdrive mechanic more or less restricting for fleet movement than yours?
(Irrelevant if you can make wormholes to everywhere or just to choosen positions.)
With my mechanic you open a wormhole and move the forces through you want through.
with yours you select them beforehand and they get dragged along.
Restriction difference where?
Post

Re: Jumpdrives, Jumpgates and Wormholes

#255
At this point in this conversation, I think I have decided on a naming convention of my own.

Henceforth I will simplify the terminology by referring to all of LT's mass-transferring objects, whether natural or artificial, as "massholes."

I look forward, when I discover one of these orifices in space, to exclaiming, "Wow! What an unbelievable masshole!"

Online Now

Users browsing this forum: No registered users and 0 guests

cron