site banner

The Motte Moddes: HighSpace (August 2023)

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

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

What we have

  • Concept art for a long range missle cruiser, 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 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.

  • A “tactical” RTS-like in-mission view where you can give commands to your ships.

Updates

  • The System Map and the Tactical View got minor pimp-ups. The System Map now shows the ship names, and the Tactical View has a grid to help with orientation, draws ship icons if the ships are too far away to see, and draws waypoint, and target icons to give some indications of the ship's current goals.

  • The System Map now supports Battle Groups, and the player is now in charge of one - the original GTC Trinity cruiser, and a wing of fighters.

  • We now have “just in time” mission generation. Like I mentioned in the previous thread, the scripting API gives you access to the file system, so it was pretty easy to generate a mission file on the fly. This has some advantages over using a “blank” mission file and setting up the mission via the API, because not all mission features are exposed to the API. The most obvious example here will be how there's no longer an “extra” player ship, just the ones explicitly declared for the System Map (in the previous versions you'd be flying a fighter, even though in theory there were no fighters in the System Map).

  • Thanks to the fighters and their current load-out it's actually not that hard to win the game at the moment. Your cruiser will easily dispatch the Shivan one, and as to the corvette, you can order your ships to run away, and take out the turrets yourself, then order your ships to attack. It will take a while, but with a defenseless enemy it's only a question of time.

What's next

  • The System Map didn't get a lot of attention so far, so I'd like expand it. It would be nice to move around an actual star system, add camera movement, and split/merge mechanics for fleets.

  • The Tactical View is somewhat functional, but still needs to give a player handle on what's going on, and better control over their ships. I wanted to add subsystem status, beam cannon charge status, and a handier way to give advanced commands.

8
Jump in the discussion.

No email address required.

Another update.

I got the real-time ship movement sketched out. Ships now have a destination instead of teleporting, and move towards it at a constant speed. Or they would, if I wasn't crashing the script with nil access.

Attempting to debug this led me to ask the question: where are those debug statements getting sent, anyway? Hardlight seems to expect an fs2_open.log. It also seems to think we can tell whether or not we're on a debug build using version numbers, which hasn't panned out. And it doesn't mention scripting at all.

I'm going to shelve this for tonight. Let me know if you can see my github account, and I can push my questionable branch to the repo or something.

Attempting to debug this led me to ask the question: where are those debug statements getting sent, anyway? Hardlight seems to expect an fs2_open.log. It also seems to think we can tell whether or not we're on a debug build using version numbers

I'm on Linux, so I'm not a 100% sure where it ends up on other OS', but I think it should be something like C:\Users\<USER>\AppData\Roaming\HardLightProductions\FreeSpaceOpen\data\fs2_open.log. Good point mentioning debug builds, I think only they output to the logfiles. Knossos should be downloading them automatically, and you should have the option to launch a debug build from it (I usually build the game myself, and run it from the IDE when working on the mod).

And it doesn't mention scripting at all.

Yeah, I'm a "hit things with a hammer until they do what you want" kind of guy, and for whatever reason the Freespace API feels pretty intuitive for me, so it's never been an issue, but the documentation is not that great. You might want to check out the Scripting API page on the Hardlight wiki, the FS2 Open Lua Scripting page, and the Scripting functions reference page I mentioned earlier.

Let me know if you can see my github account, and I can push my questionable branch to the repo or something.

Yup! I sent you the invite.