Project Scrapped Project Page

Core Goals

Key Takeaways

Responsibilities

To help the artists visualise the world I created a range of gameplay, character and environmental moodboards to help direct them better.

I maintained the project through a weekly kanban board and project backlog. I also created a project schedule and regularly iterated on it throughout production.

Below is a sample of flowcharts depicting pipelines the producer and I set up for our team and weekly sprint planning, informed by team feedback and progress made during the current week of development to remain agile.

This is a section of the vertical slice plan I made alongside a producer for the team to better plan out the gameplay prototype we were making and to help with the overall direction and scope.

A few snippets of asset lists I helped create and maintain throughout the project.

Throughout the project I would create and present all of the presentations for when the team reached a new milestone to showcase our current progress to our Academic and Industry mentors and get valuable feedback for the team. Each of the links to these presentations can be accessed via their respective images below.

Responsibilities

Our core goal was to teach programming concepts through play, so we needed to design something small enough to fit our scope, but still capture the core experience of coding.

I came up with the idea of “Logic Editing” to fix the world’s Characters, whose “programming chips” had lost their logic nodes through the game being scrapped. I worked closely with our concept artist to to support her in mocking up a game in a frame (or a few frames), then pitched it to the team.

To help capture this we needed the puzzles to be self contained while allowing multiple solutions and being easily readable at first glance. To do so we visually seperated puzzle space from world space, for the player to grasp exactly what they needed to do.

And so the idea was born to code “Golems” to walk in such a way where they navigate towards buttons and stop when they reach them. Similar to Sokoban!

To teach loopable behaviour and condition checking, I then designed various types of logic nodes, such as the “IF” statement and “FOR” loop, and gradually introduced these to players over time as the puzzles increased in difficulty.

To also teach the principles of classes and prefabs, I designed puzzles with multiple colours of Golems who all operate using the same code in their colours logic chip.

To incentivise returning to your code and restructuring it more effeciently, I then added constraints to usage such as “Chip Memory” and rewarded more “Gem Bytes” the lower the memory used, then tied Gem Bytes to progression through “currency gates” which unlocks more efficient nodes!

Puzzles were designed with player freedom in mind, allowing them to tackle most in any order, so a lot of time was then spent balancing the difficulty curve of the puzzles through rigorous playtesting and feedback.

I learned from the edutainment genre that most people learn best with games indirectly, when they don’t realize they are learning. A lot of thought went into the design of how we would teach concepts through fun engagement, and the first time user experience is essential to this.

I always aimed to take great care with the user experience and how the player would learn programming concepts through play. To help with this I created a Skill Chain Diagram, conceptually walking through the use of the core mechanics while viewing them from the perspective of a brand new player using Daniel Cooks Skill Atoms.

This helped to better understand where player burnout would occur during the onboarding phase to improve the overall experience of the game. For a full view of the diagram click here (You may need to zoom in).

A few examples of my approach to wikki based feature documentation using Obsidian. This evolved from our initial approach to use google docs based on feedback from technical designers and programmers. I would help maintain this wikki for the whole project.

In the early stages of production I often worked in Miro to brainstorm puzzle ideas with other designers in our system design board, create UI Mockups and think about the game mechanics. This was open to the whole development team and I encouraged my team to provide vital feedback on all work to iterate on.

To prototype core mechanics and puzzle elements I would rapidly produce various digital prototypes each one aimed at answering a key design concern regarding the core loop and mechanics.

My puzzle design approach involved planning out puzzles with respect to the core loop and mechanics available. I would usually use Miro to quickly digitally illustrate puzzle scenarios and their solutions, always designing them with more than one solution in mind to allow the player to feel like they are creating their own solution to the puzzles.

I used tools created by our technical designers to set up tutorial “contextual tips” which would provide tips for the player during play accross certain puzzles if certain pre-conditions were met.

This was to achieve the design goal of not talking down to the player through the tutorial and only provide tips when absolutley necessary.

Responsibilities

To help with world building and location assessment for use in the vertical slice I created a world graph that depicts how each of the locations are connected to each other and which locations the player would need to pass through to get to other locations.

Early on in the project I did a lot of reasearch regarding the games narrative design approach and the overall story of the game. I condensed this into a Narrative Design Document that I made available to my whole team.

I regularly updated my team with any developments to the narrative, rather than relying on them reading through it.

I used our wikki documentation to keep track of all NPC’s in the game and and what their technical requirements would be to set up in-engine. Then, using the tools created by our technical designers, I implemented the characters and dialogue.

I also made sure to apply narrative contexts to everything in the game to give gameplay more of a sense of purpose within the world while also championing the implementation of narrative enhancing concepts.

For example showing the player unlocking the amulet item that contextually allows them to break the fourth wall of their world to edit the Golems and was mischeviously gifted by the main characters sinister sister!

When placing characters I made sure to make the most use out of the environment and assets as I could by creating little narrative encounters the player could enjoy. I tried to create a sense of purpose to the world and create little stories of funny encounters with the animations at hand.

I worked closley with the level designer to plan out areas for unique events, this would usually be informed by playtests and player movement flow research.

Once the blockout was made and the assets were available I worked in-engine to dress the entire level to provide a narrative to the world and provide content for the players to interact with.

I also produced lighting passes for the art team and balanced our pixelated shader to achieve the right level or crunchiness!

What I Learned

Below is a short summary of my key takeaways from the project and the things I learned through it’s design and prototyping.