March 01, 2016

Space Ships

Awhile ago I undertook a goofy little “game-play study” with space ships.

I’m calling it Space-Ships.

I wanted to see if 2D game-play (like S.P.A.Z.) could “feel” like traditional 3D. (like Freelancer) To study this I built a game-play prototype with a 2.5D chase-cam in (Unity) a 3D game engine. I used engine’s existing rigid body simulator (PhysX) to provide a limited version of physics. After constraining everything to a 2D plane and fiddling with the inertia values in various ways I was happy with the flight mechanics. I made a doo-dad generator to setup and teardown an infinite (not quite) random set of space junk - amusingly this reduced disorientation with the slight tradeoff of vague motion sickness. I created some guns and a dumb AI ship that flew in circles until e saw something and started shooting at it.

Even when constrained to a 2D plane, the “accurate” dynamics simulation annoyed me. Momentum became an obstacle when I wanted to rapidly change directions to pursue another ship. My I changed the ships to get a lot of “inertia” when the controls weren’t being used - take your foot off the gas and you start to slow down. (It wasn’t actually inertia - it was “drag” … I think the manuals call it inertia … which is going to bug me now) Hunting down other ships was amusing, but the core of the game-play literally felt shallow I think that it would work for PvP style game-play, or as a sugary layer over any game with a meta-strategy system - but I’d worry about trying to make a game out of just shooting other ships. The lack of height variation limits the size of ships a bit so doesn’t lend itself to sweeping space-opera drama without big triangular ships looming over the audience’s view.

I don’t consider the technical aspects especially interesting - however, I’ll outline them for the purpose of self-promotion. The project allowed me to go nuts with extending the UnityEditor - an experience that I’m happy to repeat. Unity’s Editor is the real star of Unity - adding extra shiny-bits in the SceneView is relatively easy, and extending or replacing the inspectors to give each script its own special arrangement of buttons doesn’t take much thought. The most delightful of this was using a drop-down menu to assign string values (parsed from ProjectSettings/Inputmanager.asset) to controls that had to read from Input.Get??(...) - a trick that I’m surprised I haven’t seen this sort of thing in Unity proper. (It’s too cool to be a new discovery, though … also it relies on using forced text asset serialization)

At a higher level - I experimented with a sort of “detached manipulator pattern” to decouple functionality without relying on inheritance. The spaceship’s engines and guns were MonoBehaviour classes with public variables to control whether they were firing or pushing or whatever. The player’s ship and the AI ships both had an additional MonoBehaviour class that grabbed these scripts and set the values as their logic needed to. The player (of course) set the openFire field to the value of UnityEngine.Input.GetButton(...) on Update(). The AI ship used a trigger volume pointing forwards and “fired” whenever something which could be destroyed moved into that volume. While the pilot scripts were coupled to the flight system, the flight systems weren’t coupled to the pilots. This had the unexpected benefit of making it possible to “fly by inspector” and debug things that weren’t quite right.

For the moment I’m happy with this as a sort of “game-play study.” I’m not especially interested in carrying out more work on it at this point, but I’m not nearly as put off the idea as I would expect. I was able to try out various technical approaches and feel that while it’s not “done” it’s a decent RoI for the weeknights and weekend I spent on it.

Maybe someday I’ll add multi-player …. or maybe I’ll try out a 2D isometric adventure.

… did I mention that there are SPACESHIPs!