This devlog is for the final submission, as this game was developed for a uni project.

How well does the final game compare to the concept document?

There were several differences from the original plan, mostly as a result of feedback in testing.

The largest difference is likely the lack of distinct enemies, and of interactive environments. In my concept document, there was a plan to include keys that the player could collect to open doors, and the dungeons weren't going to be completely linear, and there were going to be enemies the player could kill. 

The lack of these features was mainly a response to feedback; originally, flight was going to be a big part of the game, but not the main focus. It was going to be one of a handful of spells the player will be able to use, but in early testing many people said they found it a lot of fun, and seemed to be more excited about seeing how far the flight mechanic could go in terms of skill ceilings than about the other aspects of the game. As such, I pivoted to make the game focus on flight more than other aspects such as puzzles and combat, and favoured creating more levels and level-features than other interactions such as puzzles, item collection, and combat.

Summary of feedback gathered during testing session, and how each piece of feedback influenced the final game.

The testing details, feedback received, and responses to feedback may be found in this devlog.

Asset List

  Scripts

    Dialog

• DialogHandler:
  • A singleton script attached to a text UI object. This script handles the displaying of text to the player, including the slow scroll, and toggling the visibility of the dialog box. It is not persistent between scenes.
• DialogInstance:
  • A standard class instantiated from code only. This class is a wrapper for a JSON file that contains script data, that makes use of Unity's inbuilt JsonUtility class. 
• DialogTrigger:
  • A MonoBehaviour that is given a text asset, which is read from when the scene loads. This could later be done in an editor script to avoid loading text files at runtime. This script requires a collider on the attached object. When the player enters the collider, the DialogHandler is called to display text.

    Managers

• GameManager:
  • This singleton manages scene-wide data. It does persistent between scenes for transitions, but data is usually not stored. It only exists in level scenes, to enable the use of the level shortcut keys. It handles the current respawn instance, universal prefabs such as the respawn particle effect, and records if the player is on the first checkpoint or not for use in several other systems.
• SettingsManager:
  • This singleton manages settings for the entire game, and persists in levels and on the menus.

    Player

• Player:
  • This script handles player data that is not related to movement. It handles death/respawning, and the stun/high-speed kill mechanics.
• PlayerBasicMovement:
  • This script handles the movement of the player, including flight and walking/jumping. It also controls the animation states of the player by linking to its state machine.
• CustomRotationPhysics:
  • This script is a custom physics controller. It only handles rotation, by rotating the sprite: the rigidbody attached to the player never rotates. This was done to allow the player's collider to never rotate, while still being able to tilt from side to side for the movement mechanic. The player's collider being able to rotate lead to weirdness and unpredictability when landing sideways, which this script solved. See movement iteration devlog for more details on justification for the creation of this script.

    UI

• AlertText:
  • This singleton script attaches to a text UI component and displays messages sent from other scripts, with a fade in and fade out duration. This is used for shorter messages that aren't story related, unlike DialogHandler, which can display multiple pages, and a large amount of text. One use is the end of time trial message, and another is the Checkpoint message.
• DifficultyButton:
  • This is the button on the Settings menu that uses presets for the other settings available.
• LevelTimer:
  • The timer shown in the top left. This singleton script is freezable and resettable from other scripts, such as resetting on death in time trial mode, or freezing when the player dies, and being turned on again when they respawn.
• MenuLevelLoader:
  • A scene changer script that loads a level with a specific mode in settings. Currently the only modes are PlayMode and TimeTrial.
• MenuSceneLoader:
  • A scene changer script that loads a menu screen, using the menu fade-in/fade-out effect to create smooth transitions. This script is only used for moving from one menu scene to another.
• RollButton:
  • The button to cycle between preset values and update the settings manager accordingly. Used on the settings screen for everything except the DifficultyButton
  • RollButtonEditor: Allows the scene to update the type of the attached button text in real time while editing, as well as changing the default.
• SceneFader:
  • The script called when loading or unloading a menu scene.

    World

• CameraChangePoint:
  • A trigger collider that switches which camera is active when passed by. 
• EndOfLevel:
  • A scene changer script that moves on to the next level when collided with. However, if there are no further levels, it will show the "End of levels" message and freeze the timer, and prompt the user to use Escape to return to the main menu.
• RespawnPoint:
  • A trigger collider that sets the current respawn point to a predefined location when the player passes it, and then disables itself.  When created, it dynamically loads the particle system prefab from the Game Manager. It also contains a field for checkpoint density: When set to High, it will only appear on Easy. When set to Default, it will spawn on both Normal and Easy. When set to Low, it will always be there.
• SceneChangerTrigger:
  • A scene changer that uses the vignette zoom when the player touches it. Used for the doors at the end of levels. Obselete; no longer used, in favour of EndOfLevel.

  Art

• King: Custom art by myself in a similar style to the main character.
• Player: By GrafxKid on OpenGameArt.org. 
• Fonts:  "Almendra". Retrieved from fontsquirrel, at this address, with its license here.
• Fireballs: By GrafxKid on OpenGameArt.org. Used as moving obstacles.
• Particles: Extracted from parts of art by GrafxKid on OpenGameArt.org, modified and turned into particle spritesheets by me.
• Spikes: Custom art by myself in similar style to majority of the tileset art.
• Throne: Custom art by myself.
• Main Tileset: By @JoeCreates on Twitter, with minor modification to allow for use of rule tiles and half-tiles.

  Prefabs

• Player: Contains preset values for movement and speeds for stun/kill collisions.
• Fireball: The fireball used in levels 4 and 5.
• Small Fireball: As above, but smaller :)
• Canvas: The in-game UI.
• GameManager: The default game manager used in all scenes.
• Grid: The group of tilemaps used in each level. This prefab is used to speed up level development, and is detached as soon as the level starts getting edited.
• Main Camera: The main camera with preset values and a cinemachine brain.
• Default Camera: The cinemachine camera with predefined settings for use in all levels.
• Menu Camera: The camera used in menus
• Particle Systems:
  • Glow: The effect used when the player is flying
  • Poof: The respawn effect
  • Respawn Particles: The yellow wall of particles used to show checkpoint locations
  • Stun: The flash that appears over the player's head when they get stunned or killed.