ORDER is a short little prototype with a horror theme that was submitted to a GameJam hosted by JackSepticEye and Ducky Dev Games.
Game
Jam
Game
Jam
2 People
4-5 Days
Figma, Unreal,
GitHub
Designer &
Programmer
Introduction
ORDER is a short little interactive horror experience drawing inspiration from "Anomaly Hunting" games such as Observation Duty while leaning into the "Analog Horror" vibe and atmosphere.
This game was a submission for the "JamSepticEye" game jam event hosted by Youtube profile JackSepticEye and Ducky Dev Games studio. The game jam spanned for a total of four days. Working in a team of two, me and my UX Colleague.
The theme for the jam was "Death is an Opportunity" and everyone involved was free to do whatever they wanted to within the short timeframe.
producT
overview
ORDER is as mentioned above, a short interactive horror experience that is completely UI-based. The goal of this little game is that you have to make it until the end of your shift at this "dubious" company that you just started at. You have to observe a set of camera angles, find what is different at certain time intervals and then "report" them, clearing them from the screen. You have to hold on until 05:00 to finish your shift, then you win. If you falsely reports any anomalies or if there are a total of five active anomalies, you lose.
Short, sweet, interactive and in-scope for only two people within the timeframe of four days.
ORDER is a short little prototype with a horror theme that was submitted to a GameJam hosted by JackSepticEye and Ducky Dev Games.
Designer
& Programmer
Game Jam
Figma, Unreal
Engine & GitHub
4-5 Days
2 People
Introduction
The CAMERA
SYSTEM
I wanted the camera navigation system to be as smooth and easy as possible while still giving it the little extra flair with the extra view mode, which became a "Night Vision mode". And to add to that, I wanted the whole gameplay-screen to be limited to one Widget Blueprint only in only one "level" that would then communicate with the other widgets and blueprints from within the "main blueprint" so it would be easy to work with when we had such a short deadline, also during school hours.
Starting out by having some placeholder pictures to work around with, I divided the camera sections into two Widget Switchers so the visible layer of the chosen Switcher would take front place whenever the player went into "Night Vision Mode", so that mechanic also functioned as a switcher between the Widget Switchers. It was also important that the indexation of each screen followed along, so when the player switched between the "Default Camera 1" to "Default Camera 2" that change would also follow along in the background in the night vision mode and vice versa, otherwise the whole experience would be a confusing and jarring mess for the player.
It would also make sure so that when one anomaly spawned in on camera one, it would only be on that one and nothing with the anomaly or it's functions would bleed over to it's night vision version.
Example of how the camera system is set up,
click for larger image.
What follows is a video of the blueprinting itself where I had to first set the camera indexes, what is default and night camera index in what Switchers. Followed by what happens when the player clicks the "next" or "back" button, the system must know if the camera is currently viewing the "Night Vision Mode" or the default mode.
Later comes the whole indexation, the system counts the indexation plus one in relative to how many cameras are in the Switchers, both at the same time so the player can repeatedly go to the next camera and come back to the first and keep going. The same goes when going backwards but I had to create a temporary index that it stores since it counts negative when going backwards and still keep the same loop effect.
Anomaly
Manager
The anomalies in the game is the main thing that the player interacts with in the game but, how they are handled was a bit more tricky situation to actually get to function properly the way we wanted to in that short timespan. A lot more testing both internally and with a test audience would have been preferred. And the blueprint itself could have been more effectivized and structured but I had to do what I was capable with for this short timespan and my limited knowledge within Unreal Engine, at this point I have only been working within Unreal Engine for a couple of months within my education, so I'm still incredibly happy with how it turned out.
A breakdown of how the Anomaly Manager works:
First when the game starts, it will set the active anomalies to zero, since five active will cause a game over. Then set up the necessary communication it needs to the Game Instance and the Widgets that comes into play.
Then it will set the loop for the cameras one through six with it's corresponding anomaly classes, making sure it's in the loop within the spawning process and that each cameras availability is always checked, since we wanted a set number of anomalies in each camera, so that not everyone spawns into the same.
Then it calls the next function that, for this version of the game, will send further instructions that an anomaly should spawn in every 20 seconds.
Afterwards it will check how many anomalies are currently active, since 4 active will trigger a warning message to the player, then it continues on.
Then it will go on to set the candidates on which camera it will choose, which is based on if that camera is available for looping and doesn't have the max quota of currently active anomalies for that camera. It will keep checking this everytime so it knows which candidates are available. It will pick one at random and if it isn't a candidate, it will try again to find a canditate, if it succeeds, it will pick a random anomaly from within that cameras class and spawn it into the game.
A litte video follows showing this proccess so far:
After it has gone through the camera checks and chosen an anomaly to spawn in, more events and functions has to play through:
An extra fail-safe just in case it did go through even though the chosen camera is not available for anomalies, it will double-check and in case, it will go back to the initial spawning process.
Then it will take it's corresponding anomaly class and create a widget for it, also checking in which of the Switchers it belongs to, either "Default" or "Night Vision" Switch.
It will cast further to the corresponding camera screen widget and add it to it's canvas as a child with the set position agreed upon.
Then it will fill itself as an active anomaly within that camera widgets array list, occupying a slot within it's array. Removing that anomaly in-game clears that array from that anomaly from within it's own blueprint, freeing up a space for the next spawn.
Then as a last step, it will check with the Instance if this was number five in current total active anomalies, if it was, then it will trigger a game over, if not, it will go on and call the "Next Spawn".
And so the Anomaly Manager continues to loop itself until either win state or lose state is met.
A litte video follows showing this proccess as well:
RECEPTION
We got some wonderful reception for ORDER from the other participants in this Game Jam, and for being the first Game Jam I attended and still learning game engines and design, this was an enormous morale boost. Out of a total of 1,166 entries, ORDER ranked about somewhere in the middle, but with an incredibly high score when it comes to enjoyment. There we ranked in at #285 out of 1,166. And I'm so proud of what we accomplished!
We also got some really nice reviews and quotes on the ORDER such as:
"I shat my pants the moment I launched it :D By far the best and most compelling intro I've seen among other jam entries.”
“This was so well done for a observation duty kind of game and the knocking really made me jump. I dont see how death was an oppourtunity int he game but still I enjoyed the gameplay very much”
“Great choice of ambient sounds in the background - kept me at edge of my seat, never knowing what to expect.
Subtle but distinct sound cues that blended so well with the atmosphere that it made you second guess your sanity ("Did I really hear that or did it come from the room I'm in").
Intro sequence being a huge high-light of the game, very well-produced.”
"Mandela catalogue vibes and I always love an anomaly hunting game. the addition of night-vision was a nice touch."
CONCLUSION
Attending a Game Jam was fun, challenging and also, a bit stressfull to be honest. While it was a fun personal challenge to test how much one can act on intuition in how to give a good User Experience without going as deep as one is used to since time simply wouldn't allow it, it was also a bit stressing.
Doubting thoughts often occurred such as: "Is this the right way to do it? Shouldn't the focus be more on player feedback and communication? Can we afford the time to test what we have, but we don't?"
Having to put those thoughts aside and just getting our hands dirty and produce, produce and produce was a fun little project. Nothing I would do again for a while since I want to be able to go in deep, research, analyze and test the direction a project is going, is more my style.
And one last thing I want to highlight, team is everything! Working with someone whom you are completely in sync with, have full trust in and can communicate flawlessly with makes the impossible, just possible!
Download and try out ORDER for yourself here:
And also, check out my colleagues portfolio,
Josefin Berntsson
as well. Whom I worked together with this project and without would not be possible.
We are currently working and expanding on ORDER, do keep an
eye out for the full experience!
ORDER is a short little interactive horror experience drawing inspiration from "Anomaly Hunting" games such as Observation Duty while leaning into the "Analog Horror" vibe and atmosphere.
This game was a submission for the "JamSepticEye" game jam event hosted by Youtube profile JackSepticEye and Ducky Dev Games studio. The game jam spanned for a total of four days. Working in a team of two, me and my UX Colleague.
The theme for the jam was "Death is an Opportunity" and everyone involved was free to do whatever they wanted to within the short timeframe.
product overview
ORDER is as mentioned above, a short interactive horror experience that is completely UI-based. The goal of this little game is that you have to make it until the end of your shift at this "dubious" company that you just started at. You have to observe a set of camera angles, find what is different at certain time intervals and then "report" them, clearing them from the screen. You have to hold on until 05:00 to finish your shift, then you win. If you falsely reports any anomalies or if there are a total of five active anomalies, you lose.
Short, sweet, interactive and in-scope for only two people within the timeframe of four days.
Goals
The primary goal for this project was to have at least one game jam under my belt, since I always found these events quite daunting, having to create and produce something in such a short timeframe. It was also a great opportunity to challenge ones own mindset and principle since as a UX designer I like to take my time to really dig deep, analyze and understand what is needed for the best possible User Experience.
In this case, all those principles kind of had to be completely put aside since there's simply was not enough time for two people to go that deep. It was just quickly come up with a plausible concept for the timeframe and then just produce and implement at a high interval every day. So that was not only a good goal to test oneself but also a fun test to see how much I value the proper time and dedication I can give to my UX principles whenever I can.
So, we opted for creating a total Widget based game in Unreal Engine since thats what we´re both, and me, most comfortable area to work in within the engine and we were pretty confident that we could create a nice little experience within this timeframe by solely focusing on widgets.
KICKSTARTING THE PROJECT
As soon as the theme was revealed and the Game Jam had officially started we started with a brainstorming session of what we wanted to do. We aimed big with having a narrative story and lore within the game to give it a bit of a more flair. By having an antagonist showing up during your shift and present the player with a set of choices that would alter the ending. Although what we came up with would have been impactful and deliver that extra something we wanted to deliver, it just simply wasn't possible for us in just four days so we had to take a step back and ended up just focusing on a compelling intro instead that would set the mood for the gameplay.
Not only that but we also wanted to have "certain types of anomalies" that would show up during set intervals that would provide with a bigger spook, almost in a jumpscare kind of way. We looked a bit at Observation Duty and Five Nights at Freddys to see how they deliver the tension and dread to the player experience.
The bigger, badder spooks also had to be cut short since the game would have been to easy if those were the only ones we had the time to implement since we also wanted objects that would be a little bit harder to spot in order to deliver a bit of challenge and varation into the game. What we ended up on as a must have for this game:
A short yet atmospheric intro that sets the mood.
A set of camera-pictures that the player can swap between.
An alternate way to view the cameras, for a bit more depth and interaction.
A set of anomalies, around 16-17 so that at least two playthroughs would be unique.
An "Anomaly Manager" that handled the spawning and reporting of anomalies.
A timer that would start from 00:00 and count upwards to the goal time. Cutting the game once it reaches 05:00.
Visual and Audio cues that signals to the player when they report.
A winning and losing condition with corresponding screens.
With our goal and our must list set in stone, I started to work on the mechanics and functionality in Unreal using placeholder graphics and elements while my colleague worked on the graphical elements such as the UI, Screens, Anomalies etc, helping each other out when needed with implementation of defined graphics and audio.
We also went out in our local area to snap some pictures of public places that we could use as our camera-screens in-game.
THE CAMERA SYSTEM
I wanted the camera navigation system to be as smooth and easy as possible while still giving it the little extra flair with the extra view mode, which became a "Night Vision mode". And to add to that, I wanted the whole gameplay-screen to be limited to one Widget Blueprint only in only one "level" that would then communicate with the other widgets and blueprints from within the "main blueprint" so it would be easy to work with when we had such a short deadline, also during school hours.
Starting out by having some placeholder pictures to work around with, I divided the camera sections into two Widget Switchers so the visible layer of the chosen Switcher would take front place whenever the player went into "Night Vision Mode", so that mechanic also functioned as a switcher between the Widget Switchers. It was also important that the indexation of each screen followed along, so when the player switched between the "Default Camera 1" to "Default Camera 2" that change would also follow along in the background in the night vision mode and vice versa, otherwise the whole experience would be a confusing and jarring mess for the player.
It would also make sure so that when one anomaly spawned in on camera one, it would only be on that one and nothing with the anomaly or it's functions would bleed over to it's night vision version.
Example of how the camera system is set up, click for larger image.
What follows is a video of the blueprinting itself where I had to first set the camera indexes, what is default and night camera index in what Switchers. Followed by what happens when the player clicks the "next" or "back" button, the system must know if the camera is currently viewing the "Night Vision Mode" or the default mode.
Later comes the whole indexation, the system counts the indexation plus one in relative to how many cameras are in the Switchers, both at the same time so the player can repeatedly go to the next camera and come back to the first and keep going. The same goes when going backwards but I had to create a temporary index that it stores since it counts negative when going backwards and still keep the same loop effect.
ANOMALY MANAGER
The anomalies in the game is the main thing that the player interacts with in the game but, how they are handled was a bit more tricky situation to actually get to function properly the way we wanted to in that short timespan. A lot more testing both internally and with a test audience would have been preferred. And the blueprint itself could have been more effectivized and structured but I had to do what I was capable with for this short timespan and my limited knowledge within Unreal Engine, at this point I have only been working within Unreal Engine for a couple of months within my education, so I'm still incredibly happy with how it turned out.
A breakdown of how the Anomaly Manager works:
First when the game starts, it will set the active anomalies to zero, since five active will cause a game over. Then set up the necessary communication it needs to the Game Instance and the Widgets that comes into play.
Then it will set the loop for the cameras one through six with it's corresponding anomaly classes, making sure it's in the loop within the spawning process and that each cameras availability is always checked, since we wanted a set number of anomalies in each camera, so that not everyone spawns into the same.
Then it calls the next function that, for this version of the game, will send further instructions that an anomaly should spawn in every 20 seconds.
Afterwards it will check how many anomalies are currently active, since 4 active will trigger a warning message to the player, then it continues on.
Then it will go on to set the candidates on which camera it will choose, which is based on if that camera is available for looping and doesn't have the max quota of currently active anomalies for that camera. It will keep checking this everytime so it knows which candidates are available. It will pick one at random and if it isn't a candidate, it will try again to find a canditate, if it succeeds, it will pick a random anomaly from within that cameras class and spawn it into the game.
A litte video follows showing this proccess so far:
After it has gone through the camera checks and chosen an anomaly to spawn in, more events and functions has to play through:
An extra fail-safe just in case it did go through even though the chosen camera is not available for anomalies, it will double-check and in case, it will go back to the initial spawning process.
Then it will take it's corresponding anomaly class and create a widget for it, also checking in which of the Switchers it belongs to, either "Default" or "Night Vision" Switch.
It will cast further to the corresponding camera screen widget and add it to it's canvas as a child with the set position agreed upon.
Then it will fill itself as an active anomaly within that camera widgets array list, occupying a slot within it's array. Removing that anomaly in-game clears that array from that anomaly from within it's own blueprint, freeing up a space for the next spawn.
Then as a last step, it will check with the Instance if this was number five in current total active anomalies, if it was, then it will trigger a game over, if not, it will go on and call the "Next Spawn".
And so the Anomaly Manager continues to loop itself until either win state or lose state is met.
A litte video follows showing this proccess as well:
These two systems are what I primarily worked on and spent the days on during this Game Jam, I did also work on and help out with the Intro Video and other smaller functions but I'm so happy with how these two systems worked out yet not having spent that much time in Unreal besides the school projects that I'm currently attending.
There was a lot of going back and forth and frustrations also, since bugs did appear every now and then and sometimes it just completely broke, but, perserverance is key!
RECEPTION
We got some wonderful reception for ORDER from the other participants in this Game Jam, and for being the first Game Jam I attended and still learning game engines and design, this was an enormous morale boost. Out of a total of 1,166 entries, ORDER ranked about somewhere in the middle, but with an incredibly high score when it comes to enjoyment. There we ranked in at #285 out of 1,166. And I'm so proud of what we accomplished!
We also got some really nice reviews and quotes on the ORDER such as:
"I shat my pants the moment I launched it :D By far the best and most compelling intro I've seen among other jam entries.”
“This was so well done for a observation duty kind of game and the knocking really made me jump. I dont see how death was an oppourtunity int he game but still I enjoyed the gameplay very much”
“Great choice of ambient sounds in the background - kept me at edge of my seat, never knowing what to expect.
Subtle but distinct sound cues that blended so well with the atmosphere that it made you second guess your sanity ("Did I really hear that or did it come from the room I'm in").
Intro sequence being a huge high-light of the game, very well-produced.”
"Mandela catalogue vibes and I always love an anomaly hunting game. the addition of night-vision was a nice touch."
CONCLUSION
Attending a Game Jam was fun, challenging and also, a bit stressfull to be honest. While it was a fun personal challenge to test how much one can act on intuition in how to give a good User Experience without going as deep as one is used to since time simply wouldn't allow it, it was also a bit stressing.
Doubting thoughts often occurred such as: "Is this the right way to do it? Shouldn't the focus be more on player feedback and communication? Can we afford the time to test what we have, but we don't?"
Having to put those thoughts aside and just getting our hands dirty and produce, produce and produce was a fun little project. Nothing I would do again for a while since I want to be able to go in deep, research, analyze and test the direction a project is going, is more my style.
And one last thing I want to highlight, team is everything! Working with someone whom you are completely in sync with, have full trust in and can communicate flawlessly with makes the impossible, just possible!
Download and try out ORDER for yourself here:
Check out my colleagues portfolio, Josefin Berntsson. Whom I worked together with this project and without would not be possible.
We are currently working and expanding on ORDER, do keep an eye out for the full experience!
Goals
The primary goal for this project was to have at least one game jam under my belt, since I always found these events quite daunting, having to create and produce something in such a short timeframe. It was also a great opportunity to challenge ones own mindset and principle since as a UX designer I like to take my time to really dig deep, analyze and understand what is needed for the best possible User Experience.
In this case, all those principles kind of had to be completely put aside since there's simply was not enough time for two people to go that deep. It was just quickly come up with a plausible concept for the timeframe and then just produce and implement at a high interval every day. So that was not only a good goal to test oneself but also a fun test to see how much I value the proper time and dedication I can give to my UX principles whenever I can.
So, we opted for creating a total Widget based game in Unreal Engine since thats what we´re both, and me, most comfortable area to work in within the engine and we were pretty confident that we could create a nice little experience within this timeframe by solely focusing on widgets.
KICKSTARTING
THE PROJECT
As soon as the theme was revealed and the Game Jam had officially started we started with a brainstorming session of what we wanted to do. We aimed big with having a narrative story and lore within the game to give it a bit of a more flair. By having an antagonist showing up during your shift and present the player with a set of choices that would alter the ending. Although what we came up with would have been impactful and deliver that extra something we wanted to deliver, it just simply wasn't possible for us in just four days so we had to take a step back and ended up just focusing on a compelling intro instead that would set the mood for the gameplay.
Not only that but we also wanted to have "certain types of anomalies" that would show up during set intervals that would provide with a bigger spook, almost in a jumpscare kind of way. We looked a bit at Observation Duty and Five Nights at Freddys to see how they deliver the tension and dread to the player experience.
The bigger, badder spooks also had to be cut short since the game would have been to easy if those were the only ones we had the time to implement since we also wanted objects that would be a little bit harder to spot in order to deliver a bit of challenge and varation into the game. What we ended up on as a must have for this game:
A short yet atmospheric intro that sets the mood.
A set of camera-pictures that the player can swap between.
An alternate way to view the cameras, for a bit more depth and interaction.
A set of anomalies, around 16-17 so that at least two playthroughs would be unique.
An "Anomaly Manager" that handled the spawning and reporting of anomalies.
A timer that would start from 00:00 and count upwards to the goal time. Cutting the game once it reaches 05:00.
Visual and Audio cues that signals to the player when they report.
A winning and losing condition with corresponding screens.
With our goal and our must list set in stone, I started to work on the mechanics and functionality in Unreal using placeholder graphics and elements while my colleague worked on the graphical elements such as the UI, Screens, Anomalies etc, helping each other out when needed with implementation of defined graphics and audio.
We also went out in our local area to snap some pictures of public places that we could use as our camera-screens in-game.