[Very Early WIP] Skies of Flame: Multiplanar Newtonian RTS

[OrbitusII]

[rant]So, recently I’ve become more and more dissatisfied with the RTS genre. I love the concept, but with 3D graphics developers should be doing a lot more than just single-planed combat.[/rant]

The Concept:
A fully 3D RTS game (by fully 3D I mean actions and strategy, not just graphics) with a fairly significant difficulty level and decent learning curve.

The Execution Plan:
Fully Complete, Basically Complete, Started, Planned

-Fighters, organized into squadrons directed from larger cruisers
-Missiles and other heavy weaponry (railguns, nuclear, etc)
-Ships (all sizes) have subsystems that need to be managed, increasing in complexity with increasing ship size-Fighters don’t need to be managed, but cruisers and other large vessels do
-subsystems include crew (survival, E.G. food; payment (campaign only); need enough to control ship), life support, cargo, engine power, weapon systems, etc…

-Planet management (including resource production and shipping to produce more ships; probably campaign-exclusive but longer skirmishes can have some of this)
-Multiplayer: Co-op campaign, head-to-head “skirmishes” (short, easy to set up battles)-iOS/Android devices providing control assistance through multiplayer system
-Large ship library (ranging from fighters to behemoths multiple kilometers in length) with customization to improve capabilities
-Possibly planet-based combat, but it needs to be good
-Looooong campaign (24 hours of gameplay would be incredible!)-Save/load system to make it possible to complete it without sitting down for days

Screenshots:
(Images are actually close to 1600*900 pixels, so open in a new tab to see them in all their glory)

A small fighter squadron heading to attack stuff (December 27, 2013)

Fighters providing flank support to a small frigate (January 5, 2014)

Some actual combat- two missile-equipped frigates and two six-fighter squadrons attacking two 5-fighter pseudo-squadrons (by pseudo-squadron I mean that they aren’t set up as squadrons) (January 6, 2014)

A graphic I made ages ago showing off the relative sizes of my different ship classifications. (September 25, 2012)

Playable Version?
I’ll work on getting a playable build up on here this week, but school is starting again and between that, a job, and my robotics program I won’t have much time to work on that.

About Me and SoF:
I’m just a casual programmer, and this is my first REAL project with Unity. I’ve messed around with it for several years and tried to make this starting more than a year ago, but that code wasn’t close to what I want. My current code isn’t quite there yet, but it’s a lot closer and I’ve made a lot more progress in a couple weeks than I did when I was previously working on this.Every script short of the camera manager is of my own writing in C#, and even the camera’s script has edits that I made.

For art, one of my friends who can actually model on a decent level is working on some concepts we developed at the end of 2012. He hasn’t gotten any models ready just yet, but he’s pretty darn good. I’ll get some of the concepts scanned and posted in this thread as soon as I get the chance.

Other Info:
Not much else to say, but be sure to let me know what you think! I want lots of feedback so that I can make this as fun as possible. Even though it’s just concepts right now, I’ll consider whatever you throw at me.

[OrbitusII]

Webplayer Version (23 January 2014)

Standalone Version (8 January 2014):
Features:Ships:
Fighters
Large Ships (a.k.a. battleships)
Weaponry:
Missiles
Railguns
Fighter Cannons
Gameplay:
Menu
Battleship selection
Some micromanagement (weapons fighter squadrons)
Save/Load system (needs to be updated, not seen in demo)

Downloads (hosted on Dropbox):
Linux Universal (click to download)

Mac Universal (click to download)

Windows 32-bit (click to download)

Windows 64-bit (click to download)

All versions

[OrbitusII]

Got railguns working last night (basic setup) and I refined their operation this afternoon.

The very ugly placeholder model(s). I threw this together in Blender in about five minutes.
The script I’m using to aim this thing rotates the turret along the base’s y-axis only and the weapons along their x-axis only. Aiming is still a little quirky but it generally works fine.

And this is why railguns will only be available for flagship-size and bigger vessels. Way overpowered without power systems and a decent model for sizing, but then again this is a WIP.

There’s also some placeholder GUI in the top left and bottom right. The toolbar is fully functional and the selection can be changed by using the number keys (Alpha1-Alpha4 currently). This has been present for the past few days, I just finally thought that it might be useful to explain it.

Squadron control menu. Click the button of the squadron that you want to direct and the little interface for choosing a target location will come up.

Weapon contol menu. Clicking on the “Fire Missile Volley” button or pressing ctrl+1 will fire a missile from every missile launcher on the ship.
Aim and Fire are for railgun integration; they currently affect every railgun on the ship but I plan on making the buttons appear on an individual basis. Click “Aim” or press ctrl+2 to aim the railgun and click “Fire” to fire at the current heading.

Power management. As you can see, it’s not yet implemented, but this will be where the sliders for allocating power will go once power systems are put in.

Empty menu for reasons. I figure it would be nice to have a nothing-selected menu to allow for a clear screen, but it’s also there in case I need another control menu.

The menus are based on the active ship’s systems. For example, in these images I have the cruiser “splitm1p” selected. If I was to select the cruiser getting exploded in the second picture (splitm2p) there would be no Squadron buttons, as Alfa and Bravo are registered as squadrons of splitm1p. The railgun and missile firing buttons are visible on every ship, but I’ll eventually have a check going to see if those systems exist and only show the button if they do.

Playable build should be up tomorrow. I want to add the big ships to the save system so that I can create a save to load when the game starts but that shouldn’t take too long- just override ToString() on the BigShipComp script and add that into the save creator, then add the parsing function for them. The things I need for sure are a main menu and some sort of quit button (my friend was having issues quitting on Windows when we were trying out the results of a networking tutorial I found), but the little bit of code needed for those will be fast.

[OrbitusII]

Got a playable build done! The biggest package is the Linux version at 155 MB, so there shouldn’t be free space concerns.

I guess I enabled the development console by checking the “Development Build” checkbox, so feel free to look at all the exceptions that I haven’t pinned down yet.

Downloads are from my Dropbox:
Link here
All versions are there (Mac, Windows, and Linux) so just click on the one that matches your OS. Windows doesn’t have universal builds so there’s two separate versions available for 32- and 64-bit.

Let me know how it runs on your system and I’ll take note of it. I’m on a 64-bit Mac so I know it works fine here, but peer review is nice to have. Also, bugs. I want to know about any and all of them (I seriously doubt there’s any right now but you never know) so I can eliminate them with extreme prejudice.

[OrbitusII]

Added some engine effects to the cruisers to make sure the system works, and this is what I got:

Throttle-able engine effects are now a thing! I also recoded the railgun’s aiming system to work correctly. Turns out writing my own code was the best option since only one of the answers I saw on the web used trigonometry (and pretty shoddy trig at that) so I did a little bit of my own math and got a much more effective system (thank you, AP Calculus!).

Probably a bit early to ask about feedback on the playable, but if anyone has tried it I’d love some. I’d hate to get super far into the project only to get loads of people telling me that the control scheme is terrible or the fighters are dumb and crash into each other 24/7.

[bepson]

Hey, I’ve been watching this thread for a while! Looks like you’re making great progress, keep it up. I’m in the early planning stages of a similar project.

[Ocid]

I sort of agree with you to an extent regarding the RTS genre but I think it all kind of depends on the setting of the game.

You probably already know but you should check out Homeworld games.

Anyway looking good so far and interested in checking it out once you get a little further along.

[OrbitusII]

Added a webplayer link to the second post. I’ll be using that to post the most recent version whenever I can because it’s a lot easier to build one version of the game compared to four. No save function is available because of web restrictions, but that’s no problem.

The cool thing is that I was able to figure out how to restrict certain classes to standalone only, so the SaveManager which uses System.IO doesn’t need to be removed for me to be able to build to web and mobile.

Link for people who don’t want to scroll all the way back up

I’m aware that the scroll wheel does not work on Safari. That’s an issue between Unity and Safari 6 that hasn’t been resolved yet, so using Chrome (as much as I hate to depend on it) is the best option.

[OrbitusII]

Updated the webplayer with a new background color and a button to toggle fullscreen. I was having issues with that because I tried setting the resolution every frame based on a boolean instead of using the button. I got it figured out and it works nicely. I also changed the controls so that the F1 key is used to abort targeting instead of Escape, which exits fullscreen.

Next goal: health and hangars for large ships!

[OrbitusII]

Updated the webplayer to the newest version again. The frigates (I should start calling them by their correct scaling terminology) are now destructible! What I did is move the health code from the FlightComp script into its own class and added a little bit more functionality to it, so now I can attach it to anything (ships, asteroids, space stations, you name it!) and that object will have health.

Here’s some footage of one of the cruisers getting destroyed by its ally:

SoF Development: Destructible Cruisers

TRAITOR!
Sorry about the low framerate when the demo scene loads- it runs fine on my end but my recording software sucks (it’s Quicktime, no joke).

Working on fighter storage next!

[OrbitusII]

New update! Only backend stuff to make sure things are optimized this time around. I combined the selection system and GUI management into two scripts that do the exact same things as the per-vessel code to improve performance some (not noticeable since I’m only testing two large ships currently, but I expect it should be better during large battles).

Basically, this is what happened:

BEFORE:
Big ship (multiple per scene)
-BigShipComp script
–Big ship control systems (including all weapons and fighter squadrons linked to and registered with this ship)
–GUI
–Selection system

Gamemanager Object (one per scene)
-SaveManager script
–save/load system, only used with standalone players

AFTER:
Big ship (multiple per scene)
-BigShipComp script
–Big ship control systems (same as before)

Gamemanager Object (one per scene)
-SaveManager script (same as before)
-SelectionManager script
–universal selection system for all BigShipComps
-GUIManager script
–universal GUI system using selected BigShipComp from the SelectionManager

It might look more cluttered in the “After” case, but with only one OnGUI being called at any time and the selection system only doing one raycast per click instead of a raycast for every BigShipComp in the scene, I expect it should perform better during large-scale battles.

In other news, I added a check to make sure the mouse isn’t over the toolbar in the top-left before deselecting something so that you can click on those buttons to change menus instead of just using the Alpha1-4 keys exclusively. There’s also an experimental camera effect based on velocity, but it’s basic and doesn’t behave terribly well (e.g. deselecting a large ship stops the effect changing but doesn’t reset it).

I’ll be working on the hangar and fighter storage systems over the next week or so (my weekend is really busy, unfortunately) and some art updates from my artist friend should be coming in at some point as well. The current frigate model has an extreme vertex count, so a new model is definitely needed to make this viable for use on lower-end systems.

[OrbitusII]

Quick update:

I’ve added the code to store fighters in a ship and assign their data when they are re-launched from the ship. This hasn’t been added to the webplayer yet but should be within this week, if I’m lucky enough with work and school.

Here’s some setup info:

The big red box is the trigger object, a child of the main ship object. When an object with the FlightComp component is detected, its data will be added to the set of data stored in the BigShipComp. The script will do this regardless of faction or team (although it will store that data for re-launching) until I add a faction option to the BigShipComp.

What I really need for this feature to be done are as follows:
-Launching fighters after they have been stored-Per-squadron launching is how this will work, in theory.
-Repairing fighters over time
-System to get fighters to find their way into the hangar (some basic pathfinding ought to do it for now)

Other things I want to do include making the BigShipComp non-dependent on triggers set as children to keep the number of gameobjects in the scene to a minimum. This will require some research but should be doable in a short amount of time.

Edit:
Started the custom hangar area stuff to eliminate trigger dependence. It’s gonna be a bit tricky to get this working but I should be able to get it done quickly enough.

[OrbitusII]

Alright, so after a lot of struggle and pain, I’m giving up on the custom trigger-free hangar loading system. I’ve had issues with setting the storage arrays and at this point the hangars can only load one ship at a time, despite my setup being theoretically capable of multiple. Overall, I don’t see any benefit to using the custom setup instead of colliders, especially in terms of code efficiency, so it’s back to triggers!

Edit:
Just finished the quick switch back to using triggers and I’m already loving the fact that it works. Sticking with them for the foreseeable future! Also going to sleep. I need sleep.