top of page
FutureGames (2019 - Current) Game Design Student
FutureGames (2019 - Current) Game Design Student
BOBBAN JONSSON
TECHNICAL DESIGNER
A short prototype that I helped to develop at Futuregames. During this project, I collaborated and divided the tasks with my teammate. I handled state behavior and state switching. I also produced some tools for designing the demo-level, namely the buttons and doors, and the wind-tunnels.
Mass-changing
Weapon System
Project Details
Genre:
Project length:
Developers:
Game engine:
Responsibilities:
First-person Puzzler
2 weeks
2
Unreal Engine 4.23
Blueprint Scripting
Game Design
In this short prototype, you have the power to change the state of mass of certain objects! Make them light to let them drift in the wind, or heavy to have them sink in a body of water.
Use the different states to solve puzzles by combining the different properties of state-driven puzzle objects!
Game design and object-states

Normal Object State

Heavy Object State
Light Object State

Our idea was to create a system that could allow emergent interactions in gameplay.
The key feature of this prototype is that specific objects can be in a specific state decided by an enum. There is no restriction on which state an object can be in, but it can only be in one state at a time.
Each state has a different interaction with the environment. For example, normal state objects are buoyant in water and heavy objects will sink in water.
We wanted to utilize the different properties of the states in interesting combinations to produce emergent situations!
Object state interaction
Environmental effects
Default behavior
Water behavior
Sticky behavior
Wind behavior
Bounce behavior
Heavy State
Bounce at same velocity
Won't stick to sticky surfaces
Won't be budged by wind
Can't be budged by
the players
Will sink
Light State
Floats up at
constant rate
Will float with streams
Will be moved by the wind
Will immediately stick to sticky surfaces
Carries no momentum
Normal State
No particular reaction
Will be buoyant
No particular reaction
Will immediately stick to sticky surfaces
Bounce at same velocity
Object state and level interactions
The puzzle objects in our game have their properties set based on what state they are in. This is set both in construction and on an event when shot at by the player.
By using an enum to set the state of our object, it could be re-used for other elements as well! Our buttons also use the same enum, if the button requires a specific state to activate.
I added a funky function that we had to use when objects bounced on certain volumes. Our heavy objects would increase in velocity whenever it bounced, which we had little control over. As we needed to get it working to finish the prototype, I would limit the linear velocity of objects on tick.
This is definitely a feature I want to revisit and improve on, either by better logic or by deterministic physics!



Buttons and doors
I scripted buttons and movable obstacles that my teammate could use to design the demo level. I focused on keeping these intuitive to use and versatile.
The button blueprint uses an enum to activate under different circumstances. Such as remaining active permanently, or only for a short while.
Having these varied uses allowed us to design more intriguing puzzles, and to reuse them for several instances, such as trapdoors or regular doors.



Toggled switch
In order to control resources, some buttons require objects to remain on them to operate.

Permanent switch
These permanent buttons could also be used for trapdoors and other puzzle shenanigans!

Toggled switch
In order to control resources, some buttons require objects to remain on them to operate.
1/2

Exposed parameters for developers to utilise when designing puzzles and levels!
Wind-tunnels
The wind-tunnels were a great challenge for me in this prototype. This feature is something I would like to recreate with a different approach sometime!
Whenever a light object exited a wind-tunnel, I would scan for additional wind-tunnels and let their behavior run on the object.
This was because exit behaviors preceded enter behaviors, meaning our objects wouldn't be caught by adjacent wind-tunnels consistently.
We wanted to use physics to promote emergent outcomes, but next time I'll definitely make this more deterministic for a more easily anticipated behavior in the puzzle objects!


bottom of page