SPACE DEMO REFERENCE
In Game Controls
Move the Ship - Move the mouse
Fire Weapon 1 - LMB
Gameplay notes: Your ship has limited shields and once damaged can not be repaired. Once your shields are gone your ship is destroyed. Your weapons will also overheat if your heat bar reaches max so plan your shots accordingly.
The Space game demo is a brief example of an on rails shooter. We kept all the implementation for the first version simple to show off what you can do in a short period of time. Systems were keep robust enough so that they could grow as needed but only do what they need to as of right now. One example of this is the high score system. Users submit their scores on death automatically and it then tracks the highest one ever submitted. This could later be expanded to a robust stat tracking system and leaderboard for persisted stats.
Prop System Usage
We leveraged the prop system for all the destructible objects in the game. This makes it very easy for a world builder to go in and add more or less enemies to an area and setup more paths that those enemies could spawn on. Props are made via predefined library command that set specific settings on the prop. This does mean that all our enemies are on set paths and do not have any AI. That was beyond the scope of our implementation and game design.
Scripts Involved(not a complete list):
The scoring system is very simple such as would be in similar on rails games. A player earns points via a running timer and through destroying objects. Destroying an object rewards a lot of points so that the player is encouraged to destroy objects rather than not. In a more broad implementation hittable objects could be assigned different score values making some objects more desirable to be killed.
The ship is a very basic HBnode and not a dynamic character. This means that the character controller is not responsible for the movement of the ship. Again this was done to keep the game simple and in a full game you would want to have the ship be a character its self. Some engine functions and systems treat characters differently so you would not want to limit what operations can be done to the "ship" in a full game.
The ship moving around the game area is accomplished in couple of ways. The first way is that the ship is attached to a dynamically created path follower that moves along the "Game" path. Also the ships rotation is changed based on the path's waypoint rotation as it reaches a new waypoint. This was done to simulate spinning and banking through turns. Lastly the ship moves by positioning itself relative to where the mouse is positioned. This is done in the Space_Input_Command script by transforming the mouse position into a position relative to the path follower. Remember that when something is attached, or parented, to another object its position is relative to the parented object.
Attacking and Damage
Our game uses a very simple raycast from the mouse to determine if the player hits anything. When you hit a hittable prop with a raycast it takes some amount of damage. The ship will then play a "shooting" fx from the ship going to the object you hit as well as another FX on the prop that was hit. If you miss entirely the shot with go from the ship off to some point in the distance where your mouse was aiming when you fired.
Players also have a heat bar to add a twist to shooting objects down. As you fire you build up heat, a float value on the ship, that slowly dissipates over time via a timer. If you ever reach max heat your weapons become overheated and must cool down before you can fire again. This adds some variety to the game play in that you can not just hold the fire button down the whole time and must consider how much heat you have. Also players have another bar which is the ships shields or health. There is no way to build your shields back up and once they reach zero the player is dead. To make these bars animate GUI animations were used as well as simple liner interpolation.
We implemented a very basic collision system for the ship and objects. The ship and all hittable objects get a sphere radius assigned to them based on their size. As the ship moves it checks its squared distance from an object and if its less than both their radius squared then a "collision" has happened. A more complex system using in engine physics and space partitioning might be useful in a more robust game but the sphere collision test was quick to implement and provides good enough results.
The world itself is created with multiple heightmaps and then various rock assets for the "enemies". The rocks were pulled from our HJ reference world and fit with our space theme well. A non textured spaceship was created to serve as the character which is scaled down to a much smaller relative size to accommodate our needs for the game.