Development Until Now
This is a wall of text so here is a TL;DR if you are just here for the pictures and video:
We talk about multiplayer implementation, spherical worlds and gravity along with some general development flow until now.
Last week Ghostly Horizon went official with Website, Instagram, Facebook and an IndieDB page.
So far most interaction with the public has been through Instagram. We are hoping to build a community around this game during the fall and winter for a beta Q4 2017 and early access release Q1 2018.
Now onto the topic of the day, development until now.
Development has been active since March 8, 2017. Progress has been made in a rapid pace and that is a due to good planning beforehand. When starting out a game-project one need to think about what type of game this will be. First off, Ghostly Horizon is a multiplayer game with authoritative server, therefore all the code from day 1 is written as multiplayer code, and this is a lot different and more difficult than programming a single-player game with the same features. Secondly Ghostly Horizon is set on a planet, a round sphere that is circumnavigation able which makes the game open-world as well (we have no borders or restrictions in movement).
The first thing done in development was to get different builds running for the server and for the client and have them connect to each other over the network. We also wanted to have different player templates (prefabs) depending on where they are instantiated, Server, Client or Proxy (See explanation below).
Player Server = Your player on the server.
Player Client = Your player on your computer.
Player Proxy = Your player on other players computers.
This allows us to have a clean code with only the methods needed for that specific role. For example, the proxy version, how you see other players on your computer and how other players see your player on their computer. This gameobject doesn’t need to have any code at all that takes input from your keyboard. And either the client or proxy need to have code that manages the stats (health, stamina and energy) since this is controlled only by the server version of the player and is synced via the network to the client and proxy. A lot of planning and clever programming goes in to what should happen on the server, client and proxy versions of a player.
The other thing special about Ghostly Horizon is the spherical world. This has many implications for the game and the development. Game engines like Unity3D and Unreal Engine have standard assets and codes that one can use to make development easier, but these are all built with gravitation in one direction, down, since almost all games are made on a flat surface. We therefore had to program our own gravitation code that draws objects towards one point (the center of the planet). We implemented this code on our players along with a code that makes sure they are pointing their heads in the opposite direction of the gravity. And then we went on to create movement for our players and sync that across the network. Movement is dictated by the server and predicted on the client, so the client cannot hack and teleport his character to the other side of the planet because the server is really the one in control, not the client. If the client is in the wrong position the server will make sure that the client snaps back to where he should be, and proxy versions only move where the server tells them to move. Now we have a sphere with gravity and players that can walk around on it and that movement is synced over the network with an authoritative server. We are on our way!
Next up was a stats system that is controlled by the server. The player has Health, Stamina and Energy and these regenerates automatically. We wanted to implement a stats system before going on to attacks/spells because we wanted to make sure we have a good way of delivering damage and spending energy etc. before we build the massive codes need for all the different spells in Ghostly Horizon. When we were happy with the stats code we went on to just that, started building up a bunch of different codes that we can build spells of.
In essence we have a code for projectiles and a code for rays. Along with impact code and status effect code (burning, DoT etc.). But with these codes we have a large and diverse system to create hundreds of different spells that are all slightly different in function, depending on how they use gravity, how they impact, how they deal damage, etc. We have slashes, sprays, rays, instants, projectiles, bolts.
At release we will have 8 different elements with 4 spells in each element, and no spell is exactly like another. (More on spells in a later blogpost though)
A major thing to solve with spells was gravity again, and trajectory prediction. To aim the spells we use a trajectory line that simulates how a projectile with this speed and gravity will travel and this would not be so complicated with gravity downwards but when the gravity-angle change for each position this made it a bit harder. This just makes the development fun though, with challenges to overcome.
After this we made a temporary planet model and filled it with trees and rocks. Created a sun, two moons and a full day-night cycle with a homemade dusk and dawn visual code since this is again something that is standard for flat worlds but not spherical ones. (More about the world in a later blogpost)
When the planet was in place we needed some gameplay, we went for a conquest style gamemode to begin with. This is not set in stone yet, we need to go through alpha testing to figure out exactly the details on what works and is fun with the different gamemodes.
This has been very broad strokes about the development but we hope it gave some insight into the project and we are very much open for questions about anything!
You can contact us here or via our Website, Instagram or Facebook mainly.