Game Development Process & Notes from Playtesting



Game Development Process & Notes from Playtesting:

├── Abilities

│   ├── Dash.cs

│   ├── Shield.cs

│   └── Timestop.cs

├── Constants.cs

├── Control

│   ├── InputControls.cs

│   ├── InputControls.inputactions

│   └── InputSystem.inputsettings.asset

├── DontDestroyMusic.cs

├── Enemy.cs

├── Entity.cs

├── Game

│   ├── Game.cs

│   ├── LevelDefinitions.cs

│   ├── PauseMenu.cs

│   └── PublicVars.cs

├── Group.cs

├── IMovable.cs

├── InventoryPreset.cs

├── LookAtCamera.cs

├── Managers

│   ├── AIManager.cs

│   ├── BulletManager.cs

│   ├── CollectableManager.cs

│   ├── DropItemManager.cs

│   ├── GunManager.cs

│   ├── HealthManager.cs

│   ├── Hint2.cs

│   ├── HintManager.cs

│   ├── InventoryManager.cs

│   ├── LevelManager.cs

│   ├── MeleeManager.cs

│   ├── MovementManager.cs

│   └── WeaponManager.cs

├── NextLevel.cs

├── Player.cs

└── Weapons

    ├── BaseWeapon.cs

    ├── ExtensionRegistry.cs

    ├── FireContext.cs

    ├── Gun.cs

    ├── IModifiable.cs

    ├── Melee.cs

    ├── Modifiers

    │   ├── CommonBulletModifier.cs

    │   ├── CommonFireModifier.cs

    │   ├── CommonKnifeModifier.cs

    │   ├── IModifier.cs

    │   └── MissileModifier.cs

    ├── Rarity.cs

    ├── WeaponPrototype.cs

    └── WeaponRegistry.cs

The development shifted from phases to phases 

  1. Week 1

Marking the start of our great project, we drafted a rough structure of how our game will look like. The goal is to create enemies that become increasingly difficult throughout the gameplay, and let the player grow by collecting weapons and extensions (that can be installed on weapons to improve it).

This week, our design choice for building the weapon system is to create an abstract layer for each weapon that has nothing to do with the in-game game object, and let it expose several events (e.g.: fire event is triggered on fire) to the public. The actual fire logic will be handled by the weapon manager, which then invokes the abstract weapon and notify all the event listeners.

To manage different types of weapon, we will use the weapon manager and the weapon registry. Each weapon will have its own prefab, and each prefab has a weapon manager with some basic information about it (e.g.: power, rarity, name). And then we register the weapon in our weapon registry, which is like a place for constant enums related to the meta information of our weapons. Whenever one needs to instantiate a weapon, they can refer to the weapon registry and find the prefab for the weapon there.

The basic weapon system does not work without an inventory system. Our inventory system only stores the abstract weapon objects instead of the weapon managers. When the weapon is switched, it will destroy the current weapon manager and spawn a new one. We don’t care much about losing the old weapon manager since it can always be restored from the abstract weapon. In this way, we can keep track of the available weapons all the time.

  1. Week 2

This week, we mainly focused on building the levels and continuously improving the weapon system.

Many mechanisms in this game have a dependency on each other. The AI manager needs the movement manager to conduct movement; the player and enemies are required to be entities (which are a type of gameobject that always has a health manager, inventory manager, and movement manager); the weapon manager interacts with objects that have a health manager to deal damage on it. We heavily rely on the event system for implementing these features. For example, the enemy subscribes to the “Die” event on its own health manager, and has a “HandleDie” that decides what to do when it dies, the missile modifier subscribes to the bullet creation event, and adds a missile to the list of bullets when it is triggered. An advantage of using this pattern is that one event can have multiple subscribers, and we won’t need to hardcode function calls everywhere to connect everything together. The dispatcher has zero information about the listeners, and this helps us decouple some logic pretty well.

We implemented the missile that tracks the nearest enemy and causes damage. This is the very first standalone weapon extension that we have ever made (the other ones are some generic modifiers that apply to most weapons, like CommonBulletModifier that creates a bullet). The missile modifier can apply to any weapon of the type Gun without the need to change the specific weapon, the generic interface of the extension system helps us achieve that.

Actually, the process of making a weapon can be really simple with this system:

1. Draw sprites for the weapon and import them

2. Create a Prefab for the weapon, drag a single sprite to the

   prefab, add GunManager/MeleeManager to the weapon (depending

   on the type of your weapon)

3. Slice the sprite sheet and create a animation called "Attack"

4. Fill in the blanks of the WeaponManager on the prefab

5. In WeaponRegistry, add an enum for the new weapon. Its value

   do not matter for now.

6. In WeaponPrototype, add the name of the weapon, note that the

   filename must match and the weapon prefab must be placed into

   the Assets/Prefabs/Resources/Weapons folder.

7. To test it out, add it to the end of the `Weapons` array in

   InventoryManager. However, this might be removed in the future

And we will have a similar process for creating extensions once the system is more completed.

  1. Week 3

We created InventoryPreset that allows us to quickly set up inventories from predefined configurations. This comes in very handy when we want to equipe the enemy with something interesting with a single change in the inspector. It’s quite notable that our weapon system is compatible with the enemy AI so everything the player can do may also be accomplished by enemies too.

To let the player have more fun collecting items, the weapon/extension systems are designed to be compatible with a collectable system. This system consists of DropItemManager, which allows us to specify which item to drop, if it’s a weapon, what extensions will the dropped weapon have. This is super convenient for us to set up the drop rates for different levels and different enemies. 

The DropItemManager is also responsible for spawning the collectable. Every collectable has a CollectableManager that parents the sprite of the item and interacts with the inventory of the player. The CollectableManager adds the extension or the weapon to the player’s inventory.

This week, we also finished designing more extensions, enemies and put them into the map, with sound effects added. Each of them has their unique effect.

The process of creating extensions has become really easy. There are only three steps:

  1. Create the sprite
  2. Import the sprite into a prefab and add an entry for the extension in ExtensionRegistry
  3. Write the modifier script for the extension and include it in the ExtensionRegistry

Depending on the type of the modifier, a number of events will be exposed to your script. Most of the time you just need to override the generic modifier that does a raycast or creates bullets.

To ensure that the music and the player do not go away during level transitions, we have used some tricks with the DoNotDestroyOnLoad function in the LevelManager.

  1. Inventory System and Collectables
  2. Weapon System
  3. Entities
  4. Level Management
  5. Abilities
  6. UIs (HealthBar, Pause Menu, Hints)

PLAY TESTING NOTES

From playtesting, we realized that the player and enemies would occasionally get stuck inside the platform tiles. We also realized that we should give more instructions on the controls and abilities before the gameplay. For the first playtesting session, we had the player taking damage on collision so if there was a collision and the enemies were not separated from the player, the player would stop taking damage. It was mentioned that we should change it so enemies would constantly do damage if they were within a certain range. Furthermore, we had a minimap for some levels and the testers suggested removing them to keep the difficulty level high enough. Another problem that we realized was that the boost was refilled too often which made clearing obstacles and traversing the map too easy. They suggested that we should make the boost a little bit stronger and have the time between refills longer.

Files

PlatformerWebGL.zip Play in browser
Oct 22, 2021

Get Group Red Platformer

Leave a comment

Log in with itch.io to leave a comment.