- Joined
- Apr 25, 2013
- Messages
- 53
- Reaction score
- 0
Added Section 2B. Changed title
Contents
I - Introduction
This thread consists of various ideas I have conjured up, some of which with the aid of others. My ideas generally aim at adding more depth into the game, in order to give every player different experiences, moreso than they already have, and to make specialisation a more viable strategy in the game.
II - Credits
I was helped by other people in the development of these ideas, without them, they would be vastly different.
- Bazul
- MrApplypie
- Calbiri
- Comr4de
- Various other people who I have probably forgotten to add
- People who posted constructive criticism
1 - Weapons
As it stands, the weapons system is very static. The behaivour of weapons can not be controlled to a great extent, and changing this could add in a whole other area of ship design.
My idea is instead of having weapons blocks, such as AMCs, missiles, and the like, we have basic emitter blocks, maybe an Antimatter generator, a shell loader (loads various types of shells, such as MAC rounds, and missiles), a laser diode, and various other types. The amount of these in a group would only slightly affect certain, aspects of each weapon, maybe power, or decrease the amount of shots between reloads (More shells in the system at once = burst fire).
These weapon blocks could then be affected by various modifiers. Let's use the laser as an example. By default the laser would be a continuous, weak (not incredibly weak, but not very strong either) beam. The laser would then pass through various modifiers and each would have an effect on it. A modifier you could use to increase power could be a focal lens, which would condense the laser down into a smaller point, decreasing area damage. There could also be an "Optical Amplifier", which increases the base power of the laser, at a high energy cost, and would produce a lot of heat. Another modifier would be the "Laser Capacitor". These block would store up laser energy, while the laser is being fired, emitting lens flare and special effects, until it reaches it's maximum capacity, determined by the percentage of the box size that contains blocks, then it passes this energy on to an output, which determines the size of the laser, and the concentration of power. The laser would then be released from the capacitor, with more power, dependent on the capacitor, and other modifiers in the line. The capacitor would then have a cool down, which is determined by the amount of energy the can be stored, and the total surface area of the capacitor
The laser modifiers would work by being grouped to the laser diode, but they do not necessarily have to be touching, instead, the laser just has to hit the modifier's input, to get it's benefits, and then gets passed through the modifier's output (not to be confused with the aforementioned laser output).
Modifiers would be be connected to the which spawns the projectile to be modified, somehow.
The modifiers I mention here would not be the only ones, they are just examples.
These are only some examples for the modifiers (I only went into lasers), I may add more in the future but there should be a lot of variety in them (Laser inverters for tractor beams), so everyone has different weapons. With enough balancing, this systems should be complex enough to become very in-depth, but for people who don't want to get too involved, they could make simple ones, or perhaps follow templates that can be selected in build mode, and appear as glowing boxes, to show them where to build. In the end, it should still be possible for a newbie to make a decent weapons system, but an experienced person could make a very complex weapons system for a very specific purpose.
2 - Communications
At the moment, players can automagically communicate with people on the other side of the universe, this is ok with global chat, making that difficult would be cool, but simply not viable... perhaps... However, this would be an interesting feature to add to faction chat and PMs.
This idea would require factions to setup communication devices to communicate over long ranges. By default, players would be able to talk at a range of about 1 sector, with interference near the borders of the sector (random characters inserted into the chat). A ships core would be able to communicate over a slightly longer range, maybe the 8 surrounding sectors, again with interference. That is the limit of default, unmodified communications.
Now, how would one communicate over longer distances? Well, communication relays would be setup to form the backbone of the infrastructure, these would consist of a antenna blocks, and a computer, maybe a few turrets for the important ones. Factions could set these up on asteroids, stations and planets. The range would be determined by the antenna (maybe shape, or maybe longest dimension), the axis on which the antenna is longest is the one with the best transmission distance. However, a computer would only be able to control a certain amount of antenna blocks, so you wouldn't be able to build a single relay which covers the entire universe, on one computer (That would be a bad idea anyway, what if something happened to it). If a communications relay was in the range a ship could transmit, then it would get relayed to everything in the area covered by that relay, including other relays. Enemy factions would be able to destroy these relays
Now, this would be a very static system, good for an infrastructure, but what if you are fighting out of the range of the nearest relays? What do you do? Well, you put them on your ships, of course. This would give smaller ships a reason to stay near bigger ships, unless they were doing missions that did not necessarily require communications. The ships antennae would be more effective if they were outside the ship, but this gives them a weakness, as they would be able to be destroyed by enemies, cutting off the smaller ships that relied on it, from communicating long distances.
The network in the above diagram has a redundant line: if the battleship or the communications relay with the bug is destroyed, the fighters connected to the mothership would still be able to get a message back to faction home.
It would also be possible for enemies to take down communications relays that are not very well protected. This would have disastrous consequences for a poorly designed network, but could be avoided by having redundant lines (multiple paths to get around the network), sentry AI's (blocks that send an alert if enemy ships are nearby a station for a designated period of time), and general station defenses.
Less aggressive enemies could attach bugs to a communications relay, and pickup any communications that pass through it. If the enemies are clever, they can use these bugs, and the resulting alerts, if sentry AI's catch them, to figure out the network of a faction.
Perhaps another, more advanced use for the communications network, would be sending blueprints and other data (maps with updated enemy locations, or missions files) to the stations throughout the network. To save a ship, you hook up to a communications relay, save it, and it gets stored at faction HQ. To build a ship, you go to a station with shipyard capabilities and, if the station had up-to date blueprints, it would be there. Players could also send you PMs through a communications console (in a dialog) at one station, and you would be able to pick it up at another station's communications console.
If you were going to make this system work for global chat, you could have AI communications relays, or factions could setup separate channels for global chat, and charge for uses.
Emergency messages could ignore faction settings on communications relays, so they get as far as they can go.
Of course these features might not be fitting for every server, and they could be optional in the server config file.
2A - Radar
In the current game, every player controlled entity, be it players themselves, or ships can detect every entity in an approximately 2 kilometer radius. The name of the entity, the type of entity and it's faction can all be detected. Not only is this unrealistic, changing this system would make factions organise themselves to protect radar stations.
With this idea, players will have a very small radar range, maybe up to 50 meters, but this can be improved if they are in range of a faction radar station or ship, but this will have an upper limit. The same will apply to cores and ships without their own radar systems. The radar base would have to include a radar computer that connects to the radar dish. This computer could then be connected to a communications antenna and send it's data to ships in it's range. The data from this computer could perhaps be accessed from other faction bases. The computer could also be hooked up to a holographic display, or a screen, and this could be used for planning, and a variety of other uses.
Ships could have their own onboard radars, moving the functionality of a ground based radar station into a mobile ship. Smaller ships would only need a few blocks to better the current radar performance (2km). In order for smaller ships to have viable radars, a certain amount could be connected to the ship's core, but with the loss of some of the functionality of the radar computer. Bigger ships could tune their radars to maximize performance in some areas, maybe pickup the size of a vessel, or its shields, or some other statistic. Perhaps they could increase the range of the radar in one direction with a radar of a certain shape.
To encourage more creative design, and allowing more tactical options in battle, radar would be blocked by hardened hull, so you couldn't put them in the center of your ship, (You would still be able to pick up ships made out of hardened hull), instead you would have to put them either externally, or surround them in standard hulls. This would create a tactical target for enemy ships, especially fighters with the agility to target specific areas on a ship. Radars would also get interference from reactors and perhaps shield generators, which would only really be noticeable on poorly designed ships, as you do not want to put critical components near each other and make the opponent's job easier.
This idea uses the communications relay idea as a backbone for it, so disabling that in the config file would also disable this.
2B - AI Drones
Comr4de and I were discussing the Communications relay idea, when he brought up this topic.
This idea is pretty much a straight extension to the Communications relay idea. With this idea, a single AI drone on it's own, outside of communications range would not be very effective: only being able to execute basic combat with limited effectiveness. Having multiple drones in nearby would only help by increasing the amount of firepower.
To make drones more powerful you would have to have a drone mothership, which is in communications range of the drones. It does not necessarily need to be connected to the communications network, but that would allow for more functionality. The mothership would be able to coordinate maneuvers between the "child" drones, improving their functionality. The drones' basic AI would also get improved. If the mothership was to be connected to the network, a player could send commands to the AI, but there would be a time delay depending on the amount of relays the signal has to go through and the distance between them.
The aforementioned (Section 2) sentry AIs, which would watch for nearby enemy ships for a user defined amount of time, could also send requests to shipyards, asking for them to send AI drones from either available parts or docked ships with AI permissions.
I will elaborate more on this later, but I don't feel like typing too much right now.
Contents
- Introduction
- Credits
- Weapons
- Communications
Radar - AI
I - Introduction
This thread consists of various ideas I have conjured up, some of which with the aid of others. My ideas generally aim at adding more depth into the game, in order to give every player different experiences, moreso than they already have, and to make specialisation a more viable strategy in the game.
II - Credits
I was helped by other people in the development of these ideas, without them, they would be vastly different.
- Bazul
- MrApplypie
- Calbiri
- Comr4de
- Various other people who I have probably forgotten to add
- People who posted constructive criticism
1 - Weapons
As it stands, the weapons system is very static. The behaivour of weapons can not be controlled to a great extent, and changing this could add in a whole other area of ship design.
My idea is instead of having weapons blocks, such as AMCs, missiles, and the like, we have basic emitter blocks, maybe an Antimatter generator, a shell loader (loads various types of shells, such as MAC rounds, and missiles), a laser diode, and various other types. The amount of these in a group would only slightly affect certain, aspects of each weapon, maybe power, or decrease the amount of shots between reloads (More shells in the system at once = burst fire).
These weapon blocks could then be affected by various modifiers. Let's use the laser as an example. By default the laser would be a continuous, weak (not incredibly weak, but not very strong either) beam. The laser would then pass through various modifiers and each would have an effect on it. A modifier you could use to increase power could be a focal lens, which would condense the laser down into a smaller point, decreasing area damage. There could also be an "Optical Amplifier", which increases the base power of the laser, at a high energy cost, and would produce a lot of heat. Another modifier would be the "Laser Capacitor". These block would store up laser energy, while the laser is being fired, emitting lens flare and special effects, until it reaches it's maximum capacity, determined by the percentage of the box size that contains blocks, then it passes this energy on to an output, which determines the size of the laser, and the concentration of power. The laser would then be released from the capacitor, with more power, dependent on the capacitor, and other modifiers in the line. The capacitor would then have a cool down, which is determined by the amount of energy the can be stored, and the total surface area of the capacitor
The laser modifiers would work by being grouped to the laser diode, but they do not necessarily have to be touching, instead, the laser just has to hit the modifier's input, to get it's benefits, and then gets passed through the modifier's output (not to be confused with the aforementioned laser output).
Modifiers would be be connected to the which spawns the projectile to be modified, somehow.
The modifiers I mention here would not be the only ones, they are just examples.
Laser capacitor:
Emits increasingly bright lens flare in the colour of the laser
Burn out if overcharged and need to have a fuse replaced in them, perhaps a manufactured item also used in the manufacture of the blocks. This would require the ability to access the capacitor
Cooldown could be increased if exposed to vacuum, rather than hulls
Energy release/second could be determined by the surface area touching the modifier the energy is being released into.
Max Capacity: #blocks / Volume * 100
Cool down Time: Surface Area (and something involving the max capacity, maybe *10^-1)
Focal Lens:
The lens would be more effective with narrow beam weapons, as the focus would be smaller for longer. The focal point, is at a set distance, and is the most effective at that point.
The lens does not have to focus the beam, but could also spread it out, if the sides are thicker than the middle.
To remove some of the difficulty with making these there could be templates that appear as highlighted areas to build in for a set focal distance, more advanced people could shape their own.
You could implement something where the lens is customized in a dialog by activating the lens block, rather than building a lens, but that wouldn't be as cool. The building a lens also makes it more in depth to make a good weapon that won't kill everything.
Formulas for focal length (Point where the beam would be most powerful) can be found here: http://en.wikipedia.org/wiki/Lens_%28optics%29 and http://www.rp-photonics.com/focal_length.html. Also, I recommend you use the refractive index of crown glass (1.5) because that is the type of glass used in optics.
Amplifier:
Amount of blocks add 10 to the power of the laser, but it uses up an non-linear amount of power, and smaller ones use less power, but the amount starts increasing a lot, but eventually floors out a bit, so it is not to punishing.
Generate heat while used, amount of heat depends on the amount of blocks. Maybe add in a heat sink block to diffuse heat.
If the amplifiers overheat they break, and maybe get destroyed.
Laser output:
This just determines the end size and power of the laser, coming from some modifiers
The end size of the laser is an ellipse determined by the perpendicular dimensions of the output. I will come up with a diagram for this soon.
Each block can only take a certain amount of power, or it burns out, disabling the entire array.
Maybe the amount of energy passing through each block a second could heat the block up, and maybe disable it after a heat threshold is reached. This would put more pressure on the remaining outputs.
Outputs that are destroyed/disabled put more load on remaining outputs, requiring redundancies or well designed systems.
The amount of blocks in the output spread out the power, and thus determine the maximum, non-crippling array power. It also spreads out the power of the laser, so it is not focused onto one point
Lenses still have affect after the outputs, maybe only if they are connected (for optimization reasons).
One laser could be spread out into multiple outputs.
Mirrors:
These would reflect the incoming laser at whatever angle you want, if the size of the laser is bigger than that of the mirror, only part of it is reflected (Awesome disco ball weapon anyone?)
These are only some examples for the modifiers (I only went into lasers), I may add more in the future but there should be a lot of variety in them (Laser inverters for tractor beams), so everyone has different weapons. With enough balancing, this systems should be complex enough to become very in-depth, but for people who don't want to get too involved, they could make simple ones, or perhaps follow templates that can be selected in build mode, and appear as glowing boxes, to show them where to build. In the end, it should still be possible for a newbie to make a decent weapons system, but an experienced person could make a very complex weapons system for a very specific purpose.
2 - Communications
At the moment, players can automagically communicate with people on the other side of the universe, this is ok with global chat, making that difficult would be cool, but simply not viable... perhaps... However, this would be an interesting feature to add to faction chat and PMs.
This idea would require factions to setup communication devices to communicate over long ranges. By default, players would be able to talk at a range of about 1 sector, with interference near the borders of the sector (random characters inserted into the chat). A ships core would be able to communicate over a slightly longer range, maybe the 8 surrounding sectors, again with interference. That is the limit of default, unmodified communications.
Now, how would one communicate over longer distances? Well, communication relays would be setup to form the backbone of the infrastructure, these would consist of a antenna blocks, and a computer, maybe a few turrets for the important ones. Factions could set these up on asteroids, stations and planets. The range would be determined by the antenna (maybe shape, or maybe longest dimension), the axis on which the antenna is longest is the one with the best transmission distance. However, a computer would only be able to control a certain amount of antenna blocks, so you wouldn't be able to build a single relay which covers the entire universe, on one computer (That would be a bad idea anyway, what if something happened to it). If a communications relay was in the range a ship could transmit, then it would get relayed to everything in the area covered by that relay, including other relays. Enemy factions would be able to destroy these relays
Now, this would be a very static system, good for an infrastructure, but what if you are fighting out of the range of the nearest relays? What do you do? Well, you put them on your ships, of course. This would give smaller ships a reason to stay near bigger ships, unless they were doing missions that did not necessarily require communications. The ships antennae would be more effective if they were outside the ship, but this gives them a weakness, as they would be able to be destroyed by enemies, cutting off the smaller ships that relied on it, from communicating long distances.
The network in the above diagram has a redundant line: if the battleship or the communications relay with the bug is destroyed, the fighters connected to the mothership would still be able to get a message back to faction home.
It would also be possible for enemies to take down communications relays that are not very well protected. This would have disastrous consequences for a poorly designed network, but could be avoided by having redundant lines (multiple paths to get around the network), sentry AI's (blocks that send an alert if enemy ships are nearby a station for a designated period of time), and general station defenses.
Less aggressive enemies could attach bugs to a communications relay, and pickup any communications that pass through it. If the enemies are clever, they can use these bugs, and the resulting alerts, if sentry AI's catch them, to figure out the network of a faction.
Perhaps another, more advanced use for the communications network, would be sending blueprints and other data (maps with updated enemy locations, or missions files) to the stations throughout the network. To save a ship, you hook up to a communications relay, save it, and it gets stored at faction HQ. To build a ship, you go to a station with shipyard capabilities and, if the station had up-to date blueprints, it would be there. Players could also send you PMs through a communications console (in a dialog) at one station, and you would be able to pick it up at another station's communications console.
If you were going to make this system work for global chat, you could have AI communications relays, or factions could setup separate channels for global chat, and charge for uses.
Emergency messages could ignore faction settings on communications relays, so they get as far as they can go.
Of course these features might not be fitting for every server, and they could be optional in the server config file.
2A - Radar
In the current game, every player controlled entity, be it players themselves, or ships can detect every entity in an approximately 2 kilometer radius. The name of the entity, the type of entity and it's faction can all be detected. Not only is this unrealistic, changing this system would make factions organise themselves to protect radar stations.
With this idea, players will have a very small radar range, maybe up to 50 meters, but this can be improved if they are in range of a faction radar station or ship, but this will have an upper limit. The same will apply to cores and ships without their own radar systems. The radar base would have to include a radar computer that connects to the radar dish. This computer could then be connected to a communications antenna and send it's data to ships in it's range. The data from this computer could perhaps be accessed from other faction bases. The computer could also be hooked up to a holographic display, or a screen, and this could be used for planning, and a variety of other uses.
Ships could have their own onboard radars, moving the functionality of a ground based radar station into a mobile ship. Smaller ships would only need a few blocks to better the current radar performance (2km). In order for smaller ships to have viable radars, a certain amount could be connected to the ship's core, but with the loss of some of the functionality of the radar computer. Bigger ships could tune their radars to maximize performance in some areas, maybe pickup the size of a vessel, or its shields, or some other statistic. Perhaps they could increase the range of the radar in one direction with a radar of a certain shape.
To encourage more creative design, and allowing more tactical options in battle, radar would be blocked by hardened hull, so you couldn't put them in the center of your ship, (You would still be able to pick up ships made out of hardened hull), instead you would have to put them either externally, or surround them in standard hulls. This would create a tactical target for enemy ships, especially fighters with the agility to target specific areas on a ship. Radars would also get interference from reactors and perhaps shield generators, which would only really be noticeable on poorly designed ships, as you do not want to put critical components near each other and make the opponent's job easier.
This idea uses the communications relay idea as a backbone for it, so disabling that in the config file would also disable this.
2B - AI Drones
Comr4de and I were discussing the Communications relay idea, when he brought up this topic.
This idea is pretty much a straight extension to the Communications relay idea. With this idea, a single AI drone on it's own, outside of communications range would not be very effective: only being able to execute basic combat with limited effectiveness. Having multiple drones in nearby would only help by increasing the amount of firepower.
To make drones more powerful you would have to have a drone mothership, which is in communications range of the drones. It does not necessarily need to be connected to the communications network, but that would allow for more functionality. The mothership would be able to coordinate maneuvers between the "child" drones, improving their functionality. The drones' basic AI would also get improved. If the mothership was to be connected to the network, a player could send commands to the AI, but there would be a time delay depending on the amount of relays the signal has to go through and the distance between them.
The aforementioned (Section 2) sentry AIs, which would watch for nearby enemy ships for a user defined amount of time, could also send requests to shipyards, asking for them to send AI drones from either available parts or docked ships with AI permissions.
I will elaborate more on this later, but I don't feel like typing too much right now.
