CAUTION

i couldnt figure out what was wrong and after months of trying to figure out i have given up

TODO

get normie eyes to read this

Introduction#

In the previous post, I shared my experience attending Coventry University’s Summer School and provided a week-by-week breakdown of the program. As a culmination of all our efforts, we participated in a game jam during the final week, which was an exciting and intense experience. Together with Shashank Bhave, we created a 2D platformer titled Fractured Elements.

Purpose of the Current Post#

In this blog post, I will dive into the technical aspects of how we built Fractured Elements. I’ll discuss the game’s mechanics, how we implemented the core theme of “Continuous Change,” and the challenges we faced during development. Shashank will then share his insights on level design.

Concept and Design of Fractured Elements#

Overview of Game Concept#

Fractured Elements is a 2D platformer where the core mechanic is the constant switching between different elemental forms. The player needs to juggle platforming, killing enemies, while they switch between elemental forms.

TODO

add concept art for the different forms

The game was inspired by Celeste, Super Meat Boy, Dungreed, Terraria, and various other games.

The source code is available on GitHub

and the game is available for download on itch.io

Here is a video of the gameplay in ~10 seconds if you don’t want to play it.

Collaborative Efforts with Shashank Bhave#

Shashank Bhave was the key for the development of Fractured Elements. He took on key responsibilities including level design, sourcing game art and music, and creating the game’s lore. His ability to independently research and execute these tasks allowed me to concentrate on the technical challenges of implementing the form-switching mechanic. This effective collaboration was crucial for meeting our project deadlines and ensuring that the game’s theme of continuous change was thoroughly integrated into the final product.

Implementation Details#

TODO

replace the list with graphic of the architecture instead

The project contains the following scripts:

• BossController.cs
• BossPrefabSwitcherOnTimer.cs
• EnemyScript.cs
• HealthScript.cs
• InternalBossController.cs
• InternalPlayerController.cs
• LevelScript.cs
• PlayerController.cs
• PlayerPrefabSwitcherOnTimer.cs
• ProjectileScript.cs

Important Scripts#

The scripts related to the core mechanic of Continuously Changing are these:

Another special mention is the ProjectileScript.cs script used by both, the Player, and the Boss.

Other Scripts#

Enemy Script#

Jump back

This script handles the AI for the common enemies. The enemies have a Circle Collider 2D with trigger set to true. When this trigger is no longer being triggered, the enemy flips their direction.

TODO

reduce fps of gif from 5 to 4 or 3

TODO

make the player wobble / bobble / whatever so its feels a bit funny

Legend for the gif

TODO

replace this unreadable version with table, image on left, descrition on right

Prefab Switcher on Timer#

Jump back

TODO

add the gif recorded from unity here

These scripts have a serialized field called prefabs. It is an array of GameObject.

This class is overly complex for the sake of being easy to use. To switch prefabs, you need to change the SpriteIndex, everything else will be handled by a chain of getters and setters.

TODO

make a tree of whats affecting what

like call graph or smt

flowchart TD
 subgraph CurrentSprite["CurrentSprite"]
        B2["update CurrentInternalController"]
        B1["replace _currentSprite"]
        CurrentSprite_set[["CurrentSprite.set"]]
        B3[/"_currentSprite"/]
        CurrentSprite_get[["CurrentSprite.get"]]
  end
 subgraph SpriteIndex["SpriteIndex"]
        A2["set CurrentSprite to the appropriate value"]
        A1["make sure input value is within limit"]
        SpriteIndex_set[["SpriteIndex.set"]]
        A3[/"_spriteIndex"/]
        SpriteIndex_get[["SpriteIndex.get"]]
  end
 subgraph Once["Once"]
        C1["initialize SpriteIndex to 0"]
        Start[/"Start() : void"/]
  end
 subgraph EveryTick["EveryTick"]
        D2{"is timer up?"}
        D1["update timer"]
        Update[/"Update() : void"/]
  end
 subgraph subGraph4["TimerJustCompleted"]
        TimerJustCompleted[/"TimerJustCompleted() : void"/]
        E1["update SpriteIndex"]
        E2["reset timer"]
  end
    CurrentSprite_set --> B1
    B1 --> B2 & _currentSprite("_currentSprite : GameObject")
    CurrentSprite_get --> B3
    B2 --> CurrentInternalController("CurrentInternalController : InternalPlayerController")
    _currentSprite --> CurrentInternalController
    _currentSprite --> B3
    SpriteIndex_set --> A1
    A1 --> A2
    SpriteIndex_get --> A3
    prefabs("prefabs : GameObject[]") --> A1 & A2
    A2 --> CurrentSprite_set & _spriteIndex("_spriteIndex : int")
    _spriteIndex --> A3
    Start --> C1
    C1 --> SpriteIndex_set
    Update --> D1
    D1 --> D2 & _changeTimer("_changeTimer : float")
    _changeTimer --> D2
    changeCooldown("changeCooldown : float") --> D2
    D2 -- yes --> TimerJustCompleted
    TimerJustCompleted --> E1 & E2
    E1 --> SpriteIndex_set
    E2 --> _changeTimer

This script also has a changeCooldown field. This is the time in seconds after which the prefab will be switched automatically.

These scripts are applied to the root of player, and boss. They contain their respective internal controllers in code.

Player Controller#

Jump back

Let us focus on the unique points of the player controller. The PlayerController class has an instance of PlayerPrefabSwitcherOnTimer. PlayerPrefabSwitcherOnTimer exposes the current internal controller via the public variable CurrentInternalController. Now, CurrentInternalController exposes functions required for the player controller.

Internal Player Controller#

Jump back

TODO

make this section easy to understand or just remove it, esp if its internal controller

Note#

One of the challenges I had to tackle was making the player attack. I will explain it in the Spawning projectiles at a specific moment in animation Section.

Boss Controller#

Jump back

TODO

make this section easy to understand or just remove it, esp if its internal controller make animation of the truth table

Internal Boss Controller#

Jump back

TODO

make this section easy to understand or just remove it, esp if its internal controller

Note#

Boss attacks use the same system as player attack (Spawning projectiles at a specific moment in animation)

Once the boss is dead, it switches the scene to the win screen.

Level Design#

TODO: Shashank

---

Technical Challenges#

1. Switching prefabs
2. Spawning projectiles at a specific moment in animation
3. Reusing the prefab switching code
4. Boss AI
5. Projectile spawning system

Switching prefabs#

Jump back

TODO

maybe talk about theory here instead of implementation detail

what went through my mind

why i did it

The player consists of three components,

1. PlayerController: The root component. This component is responsible for all top level functionality, such as player controller, and health.
2. PlayerPrefabSwitcherOnTimer: The component responsible for changing forms
3. InternalPlayerController: The controller on prefabs, responsible for form specific behavior

Player Hierarchy

TODO

check if converting the breakdown to have nodes like blender’s geometry nodes looks better

PlayerController contains PlayerPrefabSwitcherOnTimer as an internal property.
InternalPlayerController contains ProjectileScript as an internal property.

PlayerPrefabSwitcherOnTimer has a serialized field of type GameObject[], this is where the prefabs are added via the editor.

Similar to the player, the boss also consists of three components,

1. BossController: The root component. This component is responsible for all top level functionality, such as AI, and health.
2. BossPrefabSwitcherOnTimer: The component responsible for changing forms
3. InternalBossController: The controller on prefabs, responsible for form specific behavior

Boss Hierarchy

BossController contains BossPrefabSwitcherOnTimer as an internal property.
InternalBossController contains ProjectileScript as an internal property.

BossPrefabSwitcherOnTimer has a serialized field of type GameObject[], this is where the prefabs are added via the editor.

Spawning projectiles at a specific moment in animation#

Jump back

TODO

this can be made into an animation

My first instinct was to check if I can just call functions on a specific frame similar to Godot ¹ . On a cursory search, I found out that I will need to use AnimationEvent ² . However, I didn’t want to learn the unity animation event system, and the event system in general with the short timeline. So, I resorted to digging around in the Unity docs.

The function I used is AnimatorStateInfo.normalizedTime.

Every frame, the script checks whether the attack animation is being played, if it is being played then how far into the animation is it. If the animation is past the attack time point, and it is the first frame after the attack time point, then it spawns the attack projectile.

Reusing the prefab switching code#

Jump back

In the original scope for the game, the boss was also supposed to switch forms. In the finished product, everything is set up, so it is possible for the boss to switch forms as well. To do so, I wanted to use the same script I made for the player. In the switcher script however, there is an internal field that holds the internal controller for the player. This field is required to transfer messages from the player’s root.

To make the switcher generic over the internal controller, I decided to use generics. This, however, is not possible in Unity. I could not find a way to make Unity recognize the script with generic, as a script. Thus, I ended up duplicating the code.

I have a hunch I could have instead used composition via interfaces, but I am unsure of how.

Boss AI#

TODO

move this to a better place, somewhere higher up

Jump back

The boss AI is not complex. The boss has two transforms attached to the root, one acts as a reference point for the boss’ “vision,” and the other one for the boss’ attack range.

TODO

redo the explaination, possibly with gifs

In the above image, the red dot is attackPosition and the blue dot is chasePosition. The white square is the boss.

1. If the player is in the blue region, then the boss will chase the player.
2. If the player is in the red region, then the boss will attack the player.
3. If the player is in the green region, then the boss will turn around to face the player.

Projectile spawning system#

Jump back

TODO

create gif for this

TODO

add credits to the video https://www.youtube.com/watch?v=k2pvAfU9Rsw

I remember hearing about the way Terraria spawns projectiles, and I wanted to implement it the same way.

The controller spawns the projectile, gives it a velocity, and then everything else is done in the projectile script. This way I can customize the behavior of projectiles depending on what the projectile needs to do.

There are three projectiles in the game at the moment.

1. player’s axe attack
2. player’s bow and arrow’s arrow
3. boss’ attack

The player’s axe attack and the boss’ attack have 0 velocity, therefore they are stationary attacks, and their time to live is very low.

On the other hand, the arrow has a velocity, and its time to live is long.

Final Outcome and Reflections#

The game jam submission is available here.

Reception of Fractured Elements#

Results#

Rating Distribution#

Judge feedback#

note

Judge feedback is anonymous.

Visually nice platformer game with a pixel art approach and switching characters that allow either melee or ranged attacks. Multiple levels make it interesting and force the player to master their jumping and attacking skills. There is a final boss for the finale. One improvement I would suggest is that I was unsure what caused me to change between the characters - I was not sure if it was timed, depending on where I was in the level or a button press. Well done to all involved in the game and the hard work you put into it!

Personal Reflections on the Game Jam Experience#

I am decently happy with the architecture of the code

I managed to not over scope much unlike the last game jam.

The game turned out to be too easy, but I feel like it is better that way.

I do wish I would have invested some time into learning the events system in Unity beforehand, but it is what it is.

I am pretty happy with how the logo turned out as well.

Asset Credits#