KEY INFO

Platform: iOS for Apple Arcade
Release: December 2022
Genre: Third person platformer
Studio: Gameloft Brisbane
Timeframe: 9 months to release + 4 months live so far (whole project 18 months to release)
Tools: Unreal Engine 4
My role: Mid-Level Game Designer
Game Team size: 40+

Awards: AGDA 2023: Excellence in Mobile Games

For this project, I worked as part of a generalist design team in a role covering several areas, including level design, technical narrative design, and systems & gameplay design. Here I’ll cover the level and narrative components, and you can read more about gameplay components in my upcoming dev blog.

On MLP, the design team worked closely with environment artists and the art leads to bring the world of Equestria to life, creating engaging gameplay scenarios for players to enjoy. We also worked with Hasbro (My Little Pony’s licensor) to adapt the storyline of existing My Little Pony content for the game.

With short milestones, as designers we were needed to be technically independent and adaptable for whatever was needed at each point in the milestones. This was challenging, but it means I got the chance to learn about everything from fixing bugs with visual scripting to helping the artists with animations and particle effects!

About the project

MLP: Mane Merge is a game with multiple spheres of play. These are:

• The Merge Board, where players merge matching items to level them up, fulfilling pony wishes to earn primary currency. There’s also a set of weekly challenge minigames based on the merge board mechanic.

• The Brighthouse, where players play a set of minigames to earn secondary currency that allows them to keep merging items on the Merge Board

• The World View (internal naming), where players spend their primary currency to complete tasks and progress the story. These world areas are split into Chapters (levels), each involving various characters and locations, with chapters grouped into Books.

Focus Piece: Chapter 1

Here I’ll be focusing on my role developing the Chapter areas from a level and quest design perspective. I’ll break down the process of creating the chapter through plan, sketch, blockout and polish followed by some notes on other related activities, like adding dialogue. Included are a few challenges I worked through in the process.

Through the course of development so far, I have worked on levels 1, 6 and 8 of the initial 8 chapter Book and level 2 in the first 3 chapter update book, which were all based on an original high level storyline developed by our lead designer in conjunction with Hasbro and Apple. A second update is currently in progress.

For the third update, I have been tasked with developing the entire questline of the Book based on an upcoming My Little Pony Netflix episode, which I will be able to share more about when it’s released.

The flowchart grouped the task sets into “Scenarios”, between which cutscenes and dialogue would take place. They function as the beats of each chapter level and the tasks within relate to the story beat of the scenario.

Alongside this I developed a rough 2D map of the location (at right), which shows the groups of tasks as yellow dots with numbers. The numbers correlate to a master spreadsheet of the chapter which lists the scenarios, tasks, story beats and dialogue in more depth.

For the most part, the flow of activities remained unchanged, but the layout ended up taking on a horizontal flow rather than the vertical style of the map, due to the choices around camera angle.

Blocking out the Gameplay

From my original blockout, the level artist iterated on it with some existing assets in a functional Unreal scene so that I could start blocking in the tasks and scenario structure. Because we figured out that we would need the Bridlewood location for another chapter later in the book, the flow of scenarios ended up being reversed from my original blockout to work better with the layout needs of the later chapter. Another area was also added on the far right of the space for this chapter. In the layouts, the chapter flowed left to right in my original but right to left in the final.

With this blockout agreed upon, the level artist and I were able to work concurrently using the Unreal scene levels system, where she had a level in the scene for working on the environment and I had one for setting up the task locators. These are the green capsules seen in the second blockout image (right). Without going into too much depth, these were the points where the individual tasks would take place and the player would interact with the world using their earned currency to fix an object or clear away vines for example. Behind this were several data tables where designers declare the order in which these tasks take place, and for declaring the assets these tasks would start as (viny objects) and turn into (fixed up objects).

CHallenge: Defining the camera angle

At the early stages of production, since I was the first designer to start blocking out a level environment, it came to me to test out a few different options for how the camera would be handled in the World view. We had some general ideas, such that it would be a third person style with the player having some control over it.

Amongst the team, it was generally not expected for designers to do blockouts (previously this was up to the level artists) but since I was coming from a level design background it was natural for me to do this as the next step, which I think they appreciated the help with.

I started by blocking out the environment of the level with primitives (and learning Unreal at the same time) and created some demonstrations of a third person style camera, following the layout in a forward moving direction. We decided it wasn’t feeling right, so my next attempt was more of an isometric style with the playable character moving more horizontally in relation to the camera. This experiment was handed to the art team, who finalised the camera angle, zoom and relationship with the player based on this.

Challenge: Tools for Environmental Storytelling

At the point where tasks were starting to be blocked in, it became clear that the design team (and the game) would benefit greatly from the ability to have tasks be dependent on each other. That is, when a certain task is completed by the player, another task is triggered to change its asset as well. With a spec, I requested a system to declare when tasks should be dependent on other tasks, which turned out to be a huge help in terms of selling the narrative of the chapters because we could do much more complex things with the task assets. For example, in Chapter 1 Scenario 3, Izzy discovers some sneaky kid ponies hiding in the tree when she fixes it up. Later, those same ponies become trapped and in need of rescue in Scenario 4. Because the camera is mostly free for the player to move around, they would have been able to see the ponies trapped before the story point at the tree had played out. This tool enabled me to “hide” the ponies in Scenario 4 until the tree task is completed.

Left, you can see how this looked in game, with the top image the final task in Scenario 3 at B and the location of the ponies being trapped at A.

Polishing the level gameplay

After all the art assets were placed, it was time for a pass on the orientation of the various components of each task. This included several (sometimes challenging) elements that as a designer, I was responsible for:

• Camera zoom and anchor orientation: The camera zoom level was tuned to ensure the player had a nice framing shot of the task asset and the pony reasonably in frame for each.

• Pony anchor orientation (where the playable pony lands at each task after walking from the previous one) and transition flow: Because we were limited by the playable pony only being able to walk in a straight line between anchors, they needed to be carefully tuned for each task so that the pony didn’t clip other task assets or environment objects. For this reason, I opted for most scenarios to have tasks be completed in a circular format, which also helped the camera move in a smoother way between tasks instead of ping ponging around the scenario area.

• Task UI anchor orientation: Ensuring the task UI (the rainbow Fix It! bubble the player interacts with to complete the task) was in a good position on the task asset and within the shot, not overlapping anything important on the asset or the pony.

• Task transition flow and delay: Transitions between tasks were also polished through combined adjustments of the camera anchor position, zoom and location of the pony anchor. Pony anchors too close together combined with a large distance between camera anchors resulted in an unpleasant quick camera shift while transitioning between tasks. Included in this was tuning the transition delay between the tasks. In Chapter 1, the whole first scenario has bespoke transition delays so that Izzy’s movement between tasks would perfectly match the timing of the movement of the little critter she is searching for.

Handling Dialogue

One of my key roles as a designer on MLP on top of developing the narrative beats of the chapters, was developing and implementing dialogue and cutscene sequences.

The process for this had the following steps:

• Immersing ourselves in the Generation 5 MLP world and getting to know the characters and their personalities

• Drafting the dialogue lines and working with the external narrative team to refine them

• Moving the lines to string tables for localisation in other languages

• Hooking up the correct string keys to dialogue events in cutscene sequences

• Using data tables to connect characters and their emotion animation portraits to the lines, designating who was speaking when and on which side of the screen their portrait showed up

• Cutscene sequences were setup using the Unreal Sequencer and shots blocked out with events for dialogue, fades and other elements, before being handed to our VFX artist to finalise

• Debugging and fixing any issues relating to dialogue and sequences