The Broken World Demo
The Broken World Demo was an Open World RPG made in a team of 3 – Myself, Hugo Bailey, and Joe Allen (Both of which were programmers). Together over 3 months, we worked on Broken World (which at the time was only a working title) to create a short demo of it. After those 3 months were up, we moved onto creating the final version of the game – this has been written in a separate page – “Broken World“.
The work for this project, started off as any other, we needed to figure out what the game was going to be – This was a new IP, and nothing was specifically given to us (such as a brief or minimum viable product) other than we needed to make a game. We looked to a multitude of different game jam generators until we had a shortlist of different game ideas / themes.
- A Hidden World
- The World will End in 5 Minutes
- Contrasts
- Death is not the end
- Broken World
- Avoid the Light
- Your Life is Currency
- Save Yourself, not the World
A lot of these ideas are still some I want to work on in the future, but we ended up going with Broken World after I mentioned some ideas about an Open World RPG. A few days later, we fully decided to go on this path.
The design of the gameplay was a super interesting task, we started by looking at different gameplay systems we wanted in the game (either because we knew they would be necessary for the genre or because it’s something that either Hugo or Joe wanted to work on a portfolio-related piece). There were 10 different systems initially in the game, all of which had their own priority system.
- Inventory
- Crafting
- Quests
- NPCs & Dialogue
- Save & Load
- Mini-Map
- Shops
- Dynamic Music
- Cutscenes
- Randomly Generated Dungeons
- Combat
Out of everything on the list, combat was initially the lowest priority, and this was because we made it one of our USPs that this was an exploratory Open World RPG without combat in the game (You’ll see later on that this did not stick). We also made sure to get our core gameplay pillars set up as well so we know the direction of the game.
(These will become more apparent later on).
With the basic idea behind what we wanted in the game, I started work on the designs – once again using a specific process of design that’s been mentioned on this portfolio before:
- Problem | Identifying a problem(s)
- Research | Conducting research to solve said problem(s)
- Synthesis | Using the research to synthesise an idea that solves the problem(s)
- Refinement | Identifying any lasting problems with the synthesised idea (which repeats the whole cycle of the design)
To show an example of this, I’ll use the process of design for the inventory system:
Problem
- Why does the player need an inventory?
- What does the player need to hold?
- How could an inventory collaborate with the gameplay?
- Could the inventory negatively affect the gameplay (intentionally or unintentionally)?
- (Positive Negative) Does it add a difficulty curve in some way by hindering the player?
- (True Negative) Does keeping track of the inventory make gameplay less enjoyable?
These were the basic problems I had outlined when initially looking at the inventory system
Research
The research for this was over a 1,000 words long so I won’t go too in depth but I will showcase a resource I specifically used to help, which was an article showcasing a flowchart for different inventory systems to use.
Synthesis
Using this, we were able to identify to go towards a weighted visual inventory system.
Refinement
The refinement details different additional problems such as cons for a weighted inventory system and ways to alleviate said con, and had some basic ideas behind what the inventory should look like, which resulted in our first prototype.
This was all during the first week of production, but there was a lot more that we got working as well.
- Save & Load
- Crafting
- Customisation
- NPCs & Dialogue
- Basic Quests
- Design decisions based on whether the game should be third person or first person
- Breakdown of gameplay into second-to-second, minute-to-minute, and hour-to-hour
- Design of the different tools the player has
Week by week, we kept up this progress and were able to implement a multitude of mechanics, working with this team really felt like the “honeymoon period” went on forever.
The Player’s Tools
I mentioned this in the section early, what this specifically was were 3 different items that the player could craft to help them along their journey (although at this point, their “journey” had not been defined yet). These tools all had 2 uses, a basic use and an ability.
- Axe | Chopping Down Trees | Freezing Time
- Hammer | Destroying Crystals | Launching the player
- Pickaxe | Destroying Rocks | Allowing the player to pick up any object.
It didn’t take a huge amount of time for these to also be implemented into the game.
The Map Design
By this point (around week 2-3 of production), a lot of the base game had been designed, and we as a team were a little bored of working on the same bland test location so I decided to finally work on the level design. Like in Desolate Mind, I followed a multi-step process with different elements such as creating a Beatchart, grabbing photo references, creating the top down, moving onto a whitebox and finally then placing down the final art assets (however, as this was the demo version, not every asset was a final asset).
Beatchart
In this game, as we had decided on the theme Broken World, we came up with this basic idea that the world was under attack from an evil monster and the player had to stop it from making a “Broken World” by fighting it in a dungeon location – This was the Catacombs. We worked backwards from here and had decided on multiple different locations.
- A Village (The main area for quests)
- The Plains
- Desert
- Tundra
The 3 different locations in italics were initally designed with the idea that they would have their own dungeon, and each location would focus on one of the different tools the player acquired to complete puzzles (For example, the plains would give the player the axe, the desert would give the player the hammer, and finally the tundra would give the player the pickaxe). But this didn’t work out, there was just not enough time for me to work on this level design, while I also had to work on the gameplay design so we shaved the idea down. Instead of 3 large areas all with their own dungeon, we went with one large area with the Catacombs dungeon.
So I began to work on it, starting with the beatchart of each area.
After this beatchart, I began work on each of the top downs, however – there are a lot of images I could show for this, so below I’ve posted another page showcasing all of the top downs for this project.
After the top downs, I made sure to get working on the Whitebox of the different areas, like before there are just too many images to showcase on this page without it getting cluttered, so I’ve also set up a page showcasing the Whitebox:
Gameplay Design
Hang Glider
While working on the whitebox, one of the programmers made a random comment about how we were slowly working towards a game a lot like Breath of the Wild, and how he wanted to make a hang-glider to mess around with. Well, this resulted in me saying how much I now also wanted a hang glider in the game and after some of the design process (mostly just research into how hang gliders work, how pilots steer these gliders by altering the center of gravity – which changes the pitch and yaw of them).
Shortly after that, it was another mechanic we created a prototype of:
A few more of the designs at this point had become prototyped, including shops, a map for the player and a form of fail state (as at this point there still wasn’t any combat, so the player couldn’t die yet). This failstate boiled down to a hunger bar for the player to keep track of.
Combat System
By around mid-April, we had another discussion as a team about whether or not there should be a combat system, and after some feedback from others (who we were giving weekly presentations to about updates to the game), we decided it was time to add some combat into the game. My research started by looking at 3 separate systems:
- Dark Souls | Third Person based lock on systems with dodges, parries, and blocks
- Minecraft | Fast paced, clicking on enemies until they die while strafing
- Pokémon | Turn based combat using a “rock, paper, scissors” style of fighting.
While there are many other forms of combat, these were the ones I looked at to give us a broad enough idea about what to go for. I also started listing out the different advantages and disadvantages of each.
| Advantages | Disadvantages | |
| Third Person Lock On | High skill ceiling Engaging | Can deter people Doesn’t feel as smooth with keyboard and mouse Requires third person – adds a lot more work |
| Attacking while strafing | Easy to get into Doesn’t require a lot of practice Less time consuming to implement | Low skill ceiling |
| Turn Based | More unique gameplay | Some could see it as boring / not enjoyable Requires a whole new system – something we may not have the time for |
For the sake of time, we ended up going with an approach similar to Minecraft, and once again it did not take very long to get a prototype working in game.
(As a side note, I mention that prototypes never took long to get into the game, and that was because Hugo and Joe – the programmers I was working with – are incredibly good at what they do and somehow only ever took less than 2 days to get a functioning prototype of anything that needed implentation – even water, ladders and doors only took about a day)
However, I did use a specific mechanic from one of the other combat styles – The ‘Rock, Paper, Scissors’ elements of Pokémon’s turn based combat.
- Each tool was now updated to have 3 functions
- Basic function: Gathering Resources
- Passive function: Helping the player complete puzzles
- Combat function: Counters one of the 3 enemy types.
Enemy Designs
With the basic idea behind the combat done, it was also important to design the enemies in the game. For the sake of time, we decided to have 3 different enemies in the game:
- A small enemy
- A medium sized / player sized enemy
- Large enemy
These 3 types gave enough variety to be interesting, while also being basic enough so that they could be adjusted and changed whenever.
The enemy design came in a few different stages, starting off with the “style” of the enemies – While we didn’t have any artists on the team and had to rely on premade assets, I still wanted to try and fit everything to a style and started by looking at mythology – a place I typically start at when looking at enemies / creatures.
This led me onto Māori mythology, where the two creatures I first got inspiration from was the Tuhirangi – a creature with different (mostly sea related) forms. I also looked at Poua-Kai, however these two were not necessarily something I could use because of two issues:
- Tuhirangi | Requires water based AI – too time consuming for this stage.
- Poua-Kai | Requires flight based AI – also too time consuming for this stage.
So while this didn’t have much success, I knew I was on the right path with the mythology theme, so I went to German mythology with the Tatzelwurm, Aufhocker, and The Alp.
With some basic ideas given to me by this research, I tried creating designs for the specific enemies. An example I’ll show is enemy type 1.
The direction this enemy went to begin with was having him have some form of “dream” related ability – inspired by German myth, where they would jump onto the player’s back and start draining their health.T he player’s tool for this enemy would be the hammer tool which would create an AoE attack to knock off any enemies on the player’s back, while dealing damage to them. However, this got refined quite heavily, the jumping on the back mechanic was removed because there was very little visual clarity, and so to compensate we added a new mechanic of trying to surround the player, by multiplying.
The First Demo
After some more work on the map, we were able to get our first, very early, demo implemented.
This demo showcased:
- Quest System
- Chests
- Gathering resources
Dynamic Music
Shortly after that though, we were able to get dynamic music implemented as well – Something I was very happy about as it’s my favourite “mechanic” of all time.
And finally. We were able to finalise the demo, showcasing multiple quest lines for the player to complete, using all the different tools the player has, and even showcasing some new mechanics – puzzle related mechanics like buttons, doors, and moving platforms.
At this point we were getting close to the deadline of the project, but there were some changes still made.
Map Updates
This was a big one. After a bunch of tests, playing with others, watching others playing the game. I made the decision that the game didn’t feel that fun – which was honestly a big deal. This Open World game felt very empty, and I wasn’t sure what to do. We had a team meeting, and the others were both in agreement that it wasn’t that enjoyable. So, one of the programmers used one of our old maps for playtesting, adding in some new areas for the player to explore, while I added a small dungeon showcasing off the buttons, moving platforms, and some hazards in the game (crush traps, swinging axes and spikes). For the final map in the full version of the game, we decided to go back to the drawing board for it (with the exception of the Village).
That was mostly it for this demo. The full gameplay of this demo is linked below.
Project Duration:
March 2021 – May 2021
Team of: 3
Design | Noah Rigden
Programming | Hugo Bailey
Programming | Joe Allen
Noah Rigden 