The goal of this thread is to coordinate development on our project codenamed HighSpace - a mod for Freespace 2 that will be a mashup between it and High Fleet. A description of how the mechanics of the two games could be combined is available in the first thread.
Who we have
-
@FCfromSSC - 2D/3D artist
-
@Southkraut, @RenOS, @netstack - Interstellar Warfare Consultants
-
Me - developer
I hope you don't mind I moved you to Consultants for now, @netstack. I'm always torn between keeping people in their originally declared roles as encouragement, and not wanting to harass them into contributing, when writing the contributor list. I'll be more than happy to re-add you as a dev if you're still on board.
Who we need
The more the merrier, you are free to join in any capacity you wish! I can already identify a few distinct tasks for each position that we could split the work into
-
developers: “mission” code, “strategic” system map code
-
artists: 2D (user interface), 3D (space ships, weapons explosions)
-
writers: worldbuilding/lore, quests, characters
A small note if you want to contribute:
Don't be afraid to ask questions however small, or silly you might find them. This is literally one of the primary functions this thread has. The Hard Light documentation is... there... but it's not great, and between that, the peculiarities of LUA, the FS2 scripting API, RocketLib, and other parts of FS2 modding, it really might not be obvious how to resolve issues you run into. I might not be able to answer all questions, but I've dabbled in all these things, so there's good chances I might be able to help.
What we have
-
An official Highspace Github Org and Repository
-
An official Highspace Wiki
-
Even more concept art for ships, curtesy of @FCfromSSC:
-
A proof of concenpt for “strategic” system map we jump into on start of the campaign. It contains a friendly ship and 2 enemy ships, you can chose where to move / which enemy ship to attack.
-
A “tactical” RTS-like in-mission view where you can give commands to your ships.
-
A somewhat actual-game-like workflow. Attacking a ship launches a mission where the two ships are pitted against each other. If you win, the current health of your ship is saved, and you can launch the second attack. If you clean up the map you are greeted with a “You Win” message, or “You Lose” if you lose your ship.
Updates
It was another slow month, but things are finally starting to move. Literally. I added a current time display (set to the very beginning of the universe for now), and time can be paused / started / fast-forwarded. I also added a side bar with some help text (I thought the controls were relatively obvious, only to realize that what seemed obvious depended on the game I was most recently playing). The planets are the only things that move on their own for now, but I should be able to extend that feature to ships pretty soon. I'm not sure if this idea will go anywhere, but I'm thinking of having ships be able to move through conventional and subspace drives, the former obviously only being useful for planet-moon type distances.
Other than that I spent a lot of time optimizing. Brute-forcing my way through "find me the ship under the mouse cursor" was fine for a proof-of-concept, but I was finding myself making more and more "get me the nearest X" queries, so it was time to shove everything into a spatial index. I'm quite happy with the result, but it's not really something you can show off visually (well, unless you really want to).
What's next
-
Getting the ships to move along an orbit.
-
Real-time ship movement (sub-space, and conventional)
-
Obstacle mechanics for the planets
Jump in the discussion.
No email address required.
Notes -
Forgot to respond to this part. What's the scenario you have in mind here? Like, burning at max speed away from pursuers, firing on them as they close? This used to be a preferred defensive tactic when I was playing gun-navy games like navyfield or World of Warships, but I think it's a bit more problematic in space.
The short version is that we can do it, but there's some moderate-to-serious tradeoffs, and I'm not sure how worthwhile it would be as a tactic, either gameplay-wise or fluff-wise, without a clearer idea of how FTL and the other ship mechanics work.
The long version:
Tail-away from the enemy is a pretty disadvantaged position; if you're doing focused armor/defenses, the armor's probably mostly going to be up front, and all these designs so far have the drive and reactors in the back. Taking damage to either can take a ship out of the fight completely, so this is a pretty rough situation to be in, which means you want to get out of it as quickly as possible. If you're running, where are you running to? Playing for time, keeping the enemy at max range as long as possible? Trying to get the FTL charged/get to a jump point? Something else?
Superposition turrets can shoot "over the shoulder", so if you can burn mostly away and still bring a closing enemy under fire. This is going to involve trading space/time for firepower, whether you burn at angles to the enemy, or tack back and forth to alternate fire and acceleration, you're going to be getting less acceleration than if you just burned straight away, and probably cost you some firepower too as the maneuvering cuts into your guns' optimal cycle time.
The other option, depending on the scenario, would be to burn toward the enemy. You get your armor and full guns toward them, and you minimize the engagement time. The head-on engagement is going to suck, but if you make it past them you're continuing to accelerate while they have to decel, flip, and accelerate from scratch, which means you could open up enough space to break contact entirely, if your ship isn't absolutely swiss-cheesed in passing. Definately a high-risk option; short-range spaceship combat could very well be unsurvivably lethal.
Also, missiles and torpedoes don't mind this scenario at all; in fact, you could probably get a pretty decent weapon specialization out of torpedoes optimized for use against pursuing ships; you can use a much smaller drive, since the enemy is accelerating hard into them from relatively short range.
Anyhow, the basic problem with making full-360 turrets is that only one turret mounted on the highest point of a given hull surface can work this way. Turrets mounted in superposition block each other, any sort of external protrusion or superstructure gets in the way... there's no ideal way to do it, just tradeoffs. For the current cruiser in particular, the sides can't take turrets this way, because the external fuel tanks and other components stick out too much, so you're stuck with just the top and bottom surface for turret mounts. A couple options.
Use the current turret layout, but space the turrets out more to reduce the dead zone at the rear as much as possible, maybe to something like
30 degrees.Use the current turret layout, but move the turrets up and back until the rear turret is high enough to clear all superstructure, allowing full rotation. move radars and other infrastructure to the sides... but then, at least fluff-wise, the sensors and guns have different blind spots, which is kinda annoying. meh.
Switch back to side-by-side turrets, move the turrets up and back until they clear everything. All four turrets can fire full salvoes in a 40 degree arc both ahead and behind, but broadsides can only use two turrets at a time. This is probably a better method than superposition since broadside engagements are the worst possible scenario in terms of survivability, but it still leaves the sensor problem at least from a fluff perspective.
Possibly do a "superturret", mount the turrets to a rotating assembly that can swing them around as a unit to face whichever direction? It'd be kind of a weird design, but weird designs can be interesting. I'm not sure I'd want all or even most capitals to use it as a core part of their philosophy, though. Alternatively, turrets mounted on tracks or on swing-out superstructure to allow them to adjust firing angle.
Hmm...
The superfiring problem only arises if all the guns' primary rotation planes are the same, including the sign of the area vector. That is a required premise to get "you can't have gun A above gun B and also gun B above gun A" - if "up" means different things for each turret, it is indeed possible for gun A to be above gun B from gun A's point of view and gun B to be above gun A from gun B's point of view.
...If I'm understanding you correctly, this was what I was getting at with "a given hull surface". The current cruiser has a square cross-section, so you could do a set of superfiring turrets on each of the four sides, but only the back turret of each set would actually be fully reversible.
Seems I screwed up. Sorry. Carry on.
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
Yes, exactly. I don't particularly like the idea of this tactic, but it just felt natural when I watched ships fighting it out. It felt particularly viable when a larger ship is pursued by a number of smaller faster ones, and tries to pick them off in order to be able to face the remaining ones.
On the other hand, I'm happy to leave it at that. Having an organic way to punish cowardice sounds great to me! Maybe with the exception of:
Yes, that's pretty much how FTL works according to FS lore:
So buying time for the drives to charge sounds like a valid use of the tactic. I like the idea of having the tradoffs you mentioned here. Maybe, with power management, it's better to redirect all power from the weapons to the enignes anyway. Maybe if you want to retreat you'll have to leave some of your ships behind, so they can buy time for the more valuable assets, etc.
Specific jump points are for interstellar travel, so I think the most common scenario involving these will be running blockades.
Haven't thought of that, that sounds good.
I love the idea, but I agree it should be limited to special ships. They'd also take more time to implement - we'd need to crack the animation code, and probably write a dedicated AI for them.
More options
Context Copy link
More options
Context Copy link