ＯＶＥＲＤＲＩＶＥ is a endless runner driving game, in which the player has to get the furthest distance by avoid as many obstacles as possible along the way, the score will be based on the distance travelled past a certain point, high score’s will be kept and points will be redeemable for new car skins with “different stats” and abilites.
The game will be completely designed in Magicavoxel and It’s art style is heavily influenced by the 80’s and 80’s nostalgia.
You play as Max Drive, a space cop from the future with a passion for justice, after all crime has been successfully wiped from the future, officers are sent back in time to chase down and hunt some of the worst criminals. Max Drive was assigned to the 1980’s
There will 12 separate lanes in which the player (Marked in Red) can traverse to avoid obstacles (Marked in Yellow below, Gray for the centre tile).
Tiles will spawn behind these in the same position to create a tunnel, individual lanes will consist of a array of GameObjects. the player will move towards the next transform in that lane array, switching lanes will switch the array that the player reads.
Technical Design process has just started, further updates will be posted however extra time is being taken to ensure a smoother process.
Reflecting on the initial design it was evident that it had some flaws. Lets look at the how this was previously working.
So the design intent was a continuous tunnel (Shown below). New sections of the track would be built after crossing the half way point of the previous Section, then deleting the previous section to save memory.
So for example if we were crossing the middle section and we got half way, it would build the new section in front of us and delete the previous section behind us.
However there are a couple of issues with the current design:
As mentioned in design above, the movement system was getting each tile in a line then moving to the next position in that array. When deleting previous sections however (which is essential for saving memory) it would delete part of the array that the player was reading, which in turn messed the player movement.
Float Point Error:
Another thing that could be a potential issue is a float point error, as the track is moving in a single direction, once a float gets beyond about 5000 units its accuracy becomes inconsistent. which is a pretty big problem when creating track and obstacles.
How to fix these problems?
First of all the movement will be changed to instead of reading an array and moving to position to instead just moving towards the next Turn Points. This will save on a heap of memory and stop any issues caused by clearing previous sections.
To help solve the float point issue there will be a design change to the track which includes Turn Points.
What are Turn Points and how will it work?
Turn Points will be fixed locations in the world which will determine between closest points which way the track is being built.
This way the track will never stray to far away from zero and also never be able to get to a float point error. Also it will create variety in the track, turning different directions to give the sense of unique levels.
Turn points will control the player through spline to the correct position and rotation required.
Audio Place Holders:
To start with i need five place holders for audio. These include:
- Crashing into something
- Passing a Obstacle (think near miss)
- Destroying a Obstacle
- Engine sound
- Game music
This time I’ve tried to use a similar approach to that of a Foley artist, using objects to make similar sounding noises and then editing the rest.
To create the destroying obstacle sound, i recorded in audacity dropping a ledger onto a table, from there i applied a reverb to that noise, slowed it down and increased the pitch slightly.
This came out way better than expected, and even has a retro 8 bit sort of sound to it.
Design Pivot, Abilities:
Initially Overdrive was going to abilities based on the individual vehicles, however i don’t want to limit the players in game experience based off an aesthetic preference.
Each vehicle will still have different stats and by that i mean;
- Acceleration, how long it takes the car to get up to Speed
- Speed, the vehicles max speed
To balance the user experience though, the difference in these values will not be extreme. So beginner players don’t feel like they are getting bogged down but instead rewarded for progress.
New Ability system
The new ability system will be instead power ups that the player can pick up along the journey.
Its going to be very similar to most driving/go karting games (think Mariokart)
By that i mean power ups will be pick ups that will be randomised upon pick up. however instead of being spawned at fixed locations, there will be a very low chance that they can spawn at any location.
Abilities will be “oneshot use” to begin with but there is a chance this will change in the future.
Abilities State Machine:
Now the player needs to know which Ability they have and what Ability they picked up. This could be made by having a variety of different scripts that spawn on a pick up. However i’m going to go a different route and use a State Machine to control this, as a can keep control of this from the one place (the player).
The State Machine needs to know what weapon it currently has and needs to display, it also needs a random function to pick between those on pick up.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|public class Abilities : MonoBehaviour|
|public Weapons currentWeapon;|
|public PlayerMovement pM;|
|public GameObject weapons;|
|public Image selectedWeaponImage;|
|public Image weaponsImages;|
|private int weaponSelect;|
|private int selectedWeapon;|
|public enum Weapons|
|switch (currentWeapon) //Switch between states|
|public void ActivateWeapon()|
|if (currentWeapon == Weapons.Empty)|
|// do nothing|
|else if (currentWeapon == Weapons.Minigun)|
|else if (currentWeapon == Weapons.Rocket)|
|else if (currentWeapon == Weapons.Laser)|
|else if (currentWeapon == Weapons.Bomb)|
|else if (currentWeapon == Weapons.Bagpipe)|
|public IEnumerator FireMinigun()|
|yield return new WaitForSeconds(1);|
|yield return new WaitForSeconds(1);|
|currentWeapon = Weapons.Empty;|
|public IEnumerator RandomWeapon()|
|weaponSelect = Random.Range(0, 14);|
|for (int i = 0; i < weaponSelect; i++)|
|selectedWeaponImage = weaponsImages[i];|
|yield return new WaitForSeconds((0.1f * i));|
|selectedWeapon = (weaponSelect / 3) + 1;|
|if ((int) Weapons.Minigun == selectedWeapon)|
|currentWeapon = Weapons.Minigun;|
|else if ((int)Weapons.Rocket == selectedWeapon)|
|currentWeapon = Weapons.Rocket;|
|else if ((int)Weapons.Laser == selectedWeapon)|
|currentWeapon = Weapons.Laser;|
|else if ((int)Weapons.Bomb == selectedWeapon)|
|currentWeapon = Weapons.Bomb;|
|else if ((int)Weapons.Bagpipe == selectedWeapon)|
|currentWeapon = Weapons.Bagpipe;|
Checks what the current weapon is, activates a object on the vehicle and then calls an action (i.e. firing minigun).
Picks a random number between 0 and 14 (3 times the item length)
Then it scrolls between that many items get longer with each scroll (to imitate slowing down of a wheel)
Now it compares the selectedWeapon with what ability that equals and then equips that weapon.
Bare in mind this still needs expanding however its a good basis for a weapon select system
Design Pivot, Abilities:
After feedback from play testing, the previously proposed changes didn’t make a lot of sense, Overdrive is based mostly around dodging obstacles so adding in random elements you have to collect (which at high speed at hard to distinguish) is counter intuitive to the game.
Instead i will be testing a new system that involves score, (think of call of duty modern warfare for example). which rewards the player for doing well with random weapons. thus snowballing the potential score as well.