Broken World

This page showcases the process of creating Broken World – A separate project to complete the final version of “The Broken World Demo“, so I’ll be continuing where that page left off.

Starting work again

About 3 weeks after the deadline for the demo, we got back together as a team to work on the final version of the game. There was a lot to go through, and a lot of the game had been discussed between these projects that we had to adjust, remove or add.

Initial Major Changes

There were a few major changes that occurred in the 3 week lull state of the project.

Removing the extra effects from the different tools and giving them to the player as “abilities”

This was something that I didn’t want to remove or change, but it was based upon a lot of feedback. When playing against enemies it felt clunky and awkward to switch between tools if the player was fighting more than one enemy type at once. We transitioned each tool to a separate intrinsic ability for the player to unlock throughout the game.

• The Grab Ability from the pickaxe became an ability the player has from the very beginning but could be upgraded in one of the new maps so that they could pick up “heavy objects”.
• The Freeze Ability went through a few different iterations, and ended up being a projectile the player fires at enemies to freeze them.
• The Launch Ability stayed the same, but could also be upgraded.
• A new ability known as “levitate” was added, this would knock enemies up for a few seconds before crashing them down into the ground.

In addition to this, we added synergy into the game between abilities. If the player hit an enemy with the levitate ability, and then froze them, they would crash down into the ground and die.

Removing The Plains as a map, adding different but smaller maps

This was a big one, the work that had gone into The Plains was removed because it didn’t fit the game anymore, The Village stayed in the final version and the Catacombs was moved to be a new area. The two new locations were the Abandoned City and the Graveyard Desert (while the Catacombs had a complete overhaul to become The Dark Catacombs). This obviously resulted in brand new top downs, beatcharts, whiteboxes, etc.

Changing the game genre from Open World RPG to Action Adventure RPG with an included story

The scope was too large as an Open World RPG, and consistent feedback was “Why is it called Broken World?” or “How does the theme Broken World even fit in?”, well, we didn’t want to add new content to pander around the name “Broken World” – because at the time it was still a working title. However, as time went on we decided to narrow down the core gameplay loop to something that’s easily explained. So, after some brainstorming, discussions, and design / research work we came up with this basic core long term gameplay loop:

The Fire Monuments were a plot device giving the player a common tangible goal for them to work towards in every location.

Synopsis of planned gameplay

At this point, we had drafted an entire idea of what the game should play out as:

1. Complete the tutorial
2. Unlock the grab ability during the tutorial
3. Get to The Village, talk to the King to be given the main questline
4. Unlock the Graveyard Desert
5. Light the Fire Monument and unlock the Flooded City
6. Go to the Flooded City
7. Light the Fire Monument and unlock the Dark Catacombs
8. Go to the Dark Catacombs
9. Light the Fire Monument and “Save the World”.

The Map Design

The majority of this project, from my end, was on the map design. Gameplay design was mostly done during the Demo project, and so it was just about tying everything together to make it feel like a whole game (I ended up doing some gameplay design but this project was mostly map design). At this point, we had decided to go for the gameplay loop of “Complete area objective -> Light Fire Monument” which will be mentioned throughout this section.

The New Locations

The Abandoned City

The Abandoned City was an interesting area to design, it initially had the focus on combat – similar to Half Life 2’s City 17 where the player will have to explore building to building, running into different enemies and solving puzzles. This then had the player move into the center of the area to find the Fire Monument. There was only one top down for this area, and reflecting back on it, it’s not good.

This was definitely not my best work, and was really rushed, as a result it missed a lot of critical information – where the player can go, where they can’t go, what their path should be, etc. But this top down didn’t deter me from making a Whitebox / blockout using Unity’s ProBuilder + some art assets.

I wouldn’t be hurt if people said that it didn’t look very good, because it didn’t. So you wouldn’t be surprised when I say that this was abandoned in place of creating a brand new area.

The New Abandoned City

The new version of this started off with trying to decide what the “area objective” would be. After research, looking into different pieces of media, and trying to create something, I then thought about my favourite film Interstellar by Christopher Nolan – specifically the planet with giant tidal waves. This idea stuck with the team, and everyone seemed to enjoy it so we decided to go forward with:

• The player has to make it from one side of the level to the other.
• The player has to get to different “safe spots” to let each wave go past without dying.
• The Abandoned City will be renamed to the Flooded City

So it was time to get back to work on all the stages of the level design, but to not clutter this page up, I’ve set up pages for the Flooded City, as well as the Graveyard Desert and Dark Catacombs

The Flooded City Level Design

The Graveyard Desert Level Design

The Dark Catacombs Level Design

The Village Updates

---

Gameplay Design

Even though the majority of my time was spent on level / world design in this project, I still had to spend some time on gameplay design.

Creation of a Skill Tree System

This was an interesting one, to give the game more versatile and unique gameplay, I ended up designing a whole skill tree system, but it always went onto the backburner, time and time again we’d end up just doing other tasks instead of it. This would upgrade abilities, the player’s base stats or unlock a brand new ability for the player. Below is an early mock-up / previs I created for this system.

This didn’t showcase the system as well as I wanted to though, so I recreated the mock-up to be more detailed while taking inspiration from games such as Assassin’s Creed: Valhalla and Star Wars: Jedi Fallen Order.

However, this system was refined later down the line to simplify it – making the gameplay less confusing to the player while also cutting the amount of work necessary in terms of prototyping / designing / balancing.

The newer version ended up being a potion system where the player would pick one of three randomly generated potions at the end each area to give them permanent stat upgrades.

Quicktime Events

Quicktime events (QTEs) were something that was not only planned, but had a fully functioning prototype implemented into the game. But they were removed shortly after for a few different reasons, not enough time to refine them being one of the reasons.

There was a surprising amount of research that went into QTEs before I figured out a few different design implementations, from what kinds of QTEs exist, to how they should be used, to what not to do with them. The part that was the most intriguing to me was an article that discussed how QTEs can be used in the wrong way very easily, and how they should be about immersion and not skill / reaction speeds which definitely gave me a different view on them.

This was another situation where I decided to introduce a previs to help the programming team if they needed it.

Like I previously mentioned, these were ultimately scrapped but not before a prototype was made.

Responding to feedback

Responding to feedback we were given was an incredibly important part in the process of creating Broken World, almost every mechanic was tuned in some way due to feedback from outside sources and I thought I’d show 2 instances on this page.

Unlocking abilities felt lacklustre

When the abilities were first implemented into the game, it didn’t feel like an achievement for the player. So we needed a way of figuring out how to tell the player that they are stronger now that they have said ability. This was actually fixed with some incredibly clean UI by Joe Allen from the programming team.

Picking up objects covers the screen

Another one of the issues we faced is that when the player used the grab ability, it blocked the player’s view.

However, I remembered a game that had a similar issue. Slime Rancher.

When Slime Rancher first launched in its beta, if the player picked something up, it would cover their screen which meant they would no longer be able to see. They fixed this shortly after the Beta by making every object picked up semi-transparent. This fix seemed it would be good enough for our game so we created a material that made it semi-transparent.

Project Duration:

June 2021 – September 2021

Team of: 3

Noah Rigden | Designer

Hugo Bailey | Programmer

Joe Allen | Programmer