Core Goals

Key Takeaways

Responsibilities

Below you will find the four key stages of development this project went through. Click on the respective image for the stage you would like to see.

To begin the project we held various blue sky brainstorming meetings to come up with an interesting idea we all were excited about exploring. During these sessions I’d take notes and collate all of our ideas into an “Ideas Page” for us to refer back to later.

From these sessions we came away with a shared love for the idea of turn based tactics, building ones own dungeon/playing field as they progressed each turn and the idea of player-driven stories.

I took these concepts and drafted up a few pitch documents, showcasing the various approaches we could take in exploring the idea.

Along with the pitch documents I sketched out how I saw the user flow of the core building mechanics in my head to illustrate how the game would function.

I paired the pitch documents and sketches with an interactive user flow/animatic thrown together in Adobe XD. It focuses more on the high level concept of how the dungeon building could function from different angles rather than the holistic user experience.

The first shows an isometric angle, the second shows a top down angle. Click on the respecitve images to walk through the one you’d like to see.

After pitching the idea to the team and walking them through the sketches and prototypes we agreed to take the core idea of dungeon building through turn based combat forward.

I got started on expanding the idea further to flesh it out, researching settings and similar games to mockup an early gameplay loop, illustrating core actions the players would conduct and suggested systems we could use to create the desired gameplay.

To respect the skillset of the team and scope the project responsibly, we decided to focus on the “Defending/Attacking Enemies” and “Checking on Team” atoms.

So I started doing research into world building and the narrative setting the game would play within, keeping a log of any narrative ideas pitched and accepted/rejected by the team.

Our team loved the idea of playing as “Quantum Planet Hunters”, chasing down various rogue planets dissappearing from solar systems and rescuing the survivors left behind.

Once the team were happy with the direction of the narrative, I threw together some moodboards of narrative concepts, like enemies and a “quantum infection” plaguing survivors, to help inspire our artist.

To start our early prototyping I jumped into paper prototyping with the team, focusing on what we believed made the game novel: Dungeon Building.

We conceptualised a small collection of mechanics and rulesets, aiming to establish unique relationships between mechanics that would dynamically effect each other to create unique game states.

Using cards/tiles to represent rooms, and tokens on top to represent events or actions we experimented with mechanics like room adjacencies, doorways that funnel movement, healing and combat rooms etc. Everytime something didn’t work, we would iterate on the fly.

We quickly progressed from paper to digital paper prototyping, using Tabletopia quickly implement our ruleset.

This allowed us to test more mechanics using dice, such as a simple combat system, drawing cards representing room shapes and lengths, movement mechanics and even tile deterioration mechanics.

Once we felt we were getting closer to finding a core ruleset, we started jumping into the Unity engine to rapidly prototype the building mechanics.

While the team and I were trying to find the fun in the core gameplay prototype, I was continuing with research into narrative systems, and performed a deep dive into the “Storylets” approach to narrative design.

Essentially using pre-conditions (such as player actions or choices) determine what content is fed to the player, which in turn effects the game state, creating more preconditions etc.

I collated my findings from research into illustrative flowcharts that helped to deconstruct the exact needs of the narrative systems inputs, process and outputs, showcasing the end result to help unify the vision in everyones minds.

I presented two primary approaches that would work best with our intended gameplay design, focusing on ways to bridge the gap between narrative and gameplay.

We needed a primary vessel to offload narrative payloads for the player and tell an overarching story.

I pitched to the team some potential options, including utilising more embedded player characters, with defined backstories (Ala Darkest Dungeon 2) or embedded side characters, who’s missions/tasks would help shape the main characters through player decisions.

The latter worked better to allow all backstory work to be established on the player side, utilising apophenic design and the content selection from storylets to help create player-driven stories.

Inspired by Ken Lavines “Narrative Legos” I used the O.C.E.A.N model of behavioral pesonality psychology to form the basis of the core stats of the player characters.

Through interaction with Storylets the player would mold their characters personalities, gaining traits in each catergory that allows NPC’s to form opinions of them through their pre-disposed likes and dislikes. NPC opinions serving as a function of the players stats.

Pairing this O.C.E.A.N and NPC opinion system with a minor Fleet Management system, where the player would only be able to recruit a certain amount of NPC’s into their fleet (serving as the meta-game) would help create a Zero Sum game.

Each NPC would be assigned to a specific team in the fleet, providing unique rewards and benefits if recruited, but also unique events if jilted.

I also mocked up a quick flow of how the storylets could be presented to the player based on the preference for our procedural approach to the narrative.

After flowcharting our intended narrative system design I started delving into tools we could use to achieve it. I integrated INK with unity and mocked up a few rapid prototypes to test and see if we could achieve a storylet structure with it.

To wrap up the early prototyping I threw together an early visual of the dialogue system we would use in the form of a futuristic Datapad, with side panels for tracking stats of your characters, fleet and resources.

I took this further and animated it in AdobeXD to showcase how the Datapad would work functionally alongside the turn-based gameplay. To view the mockup click the image below.

To transition to development on a collaborative 2D prototype we needed a way to effectivley track the production of tasks and any found work.

I setup a collaborative group work space on Codecks, tracking each feature as a deck of cards and the tasks required to complete the feature represented as individual cards comprising the respective decks. We used this to work towards MVP.

To help determine our production time and how much we could feesibly get in, I set up several milestones based on a Vertical Slice plan covering all necessary features, assigning each feature/deck to their respective miletone.

These were regularly reviewed at the end of each week to ensure we were still on track.

To better support our programmer we switched engines to Godot. I jumped in, doing tutorial projects in my spare time in the Engine to get up to speed with it so I could be as useful as possible.

After that I started helping the rest of the gameplay team port their gameplay systems into the engine. Starting with the building mechanics, turn based systems and AI.

Godot presented a small problem with using INK. It had no official plugin at the time, and the ones available were unfinished and didn’t provide certain functionality that would accomodate my intended Storylet approach.

The programmer and I managed to correct this quickly, implementing a more robust text parser that could listen to the HTML Tags functionality in Ink, adding functionality for an Observer through a “Globals” file to store variable changes both in gameplay and in story, and even extended the core implementation of the plugin with functions that can apply affects to the game state from the story, and vice versa.

For my first prototytpes using it in Godot I mainly focused on the functionality of the text parser.

I extended the OCEAN stat system, creating 15 different traits (3 for each stat), allowing the player to get 1 trait for each stat on each character, providing the opportunity to get 5 traits per character that can help define their personality and affect the combat/building abilities.

I took care to make these orthogonal, allowing traits that don’t sound like they should match on paper to still work as that is what leads to interesting personalities with intricate complexity, like the people you meet in real life.

I then needed to start planning out how to front end this information to the player, so I started redesigning the Datapad.

I took into account managing obscurity to help the player to use their imagination but also giving them enough information to make informed decisions, so I chose to include when an OCEAN stat would change, but not show it’s exact value, just the associated trait.

I worked on some early sketches, then refined them into a few key concepts.

I wanted the narrative system to feel like a disconnection from conversation, due to our Orwellian and Lovecraftian influences.

I designed the core dialogue system to feel like a messaging system on your phone, seperating each line of text into message types that I’d flag through INKS “Tags” depending on who was speaking, a player character or an NPC. I also designed how choices would appear and illustrated it through a flowchart to my team.

Before jumping back into engine I wanted to structure this out better to understand how the messaging system would work technically. So I flowcharted how the choices would work by deriving from a message, then assigning choices from the story to each button.

I then planned out theheirarchy of the Datapad (PDA). A storytrigger would activate the PDA, which would then read the current story fed to it, instantiate messages based on the initial text and check for any choices with each line of text it read through.

I then needed to tie an Observer that would check a story being read on the Datapad (PDA) for any variable changes, updating the Globals with the new variable when it detected one.

I also implemented another Observed onto the Globals itself to alert the gamestate whenever a change had occurred in the story, which would then update the game state. The game state itself would update the Globals’ variables, of which each story derived from etc.

With that I was able to easily refactor the datapad to accomodate the new technical plan and update it’s visual layout. I implemented OCEAN stat tracking and trait assignage and learned how to animate the UI in Godot to have an opening and closing animation with activating and retracting the character panels.

I worked closely with our artist to draft up an art requirement sheet and and asset list for the Datapad, directing through feedback and iteration what the art style we were going for was for the Datapad.

The primary components I needed to take into account with the communication of information was the OCEAN stats, in-game resources shown on the panel at the bottom as these played into the progression, and the main character panels.

After the core functionality was in place I pushed to work on some polish, researching and implementing various shaders like a glitch shader to communicate talking on rundown dying channels, and a CRT/VHS shader with rolling scanlines.

To improve performance I also refactored the shaders into one single shader that could have certain features of the CRT/VHS and glitch effects disabled depending on how the designers wanted to use it.

We loved this so much we ended up using the Datapad as most of the UI screens, including the win and lose screens.

I pushed the polish further with a turn-to-static transition animation for whenever a character changes during a dialogue sequence and constant tweaks and iterations from playtester feedback, prioritising readability and usability while also pushing for some style!

While working in-engine on the Datapads functionality I would regularly communicate with the rest of the team regarding the gameplay ability design. I designed and implemented several abilities, taking into account their properites like shape of building tiles, effects on enemies and allies and damage dealt.

I threaded all of the game state user facing variables through Ink to be affected by the stories by writing the functions in Godot that would connect the gameplay and narrative systems together, acting as the go to point for all things narrative and progression.

I designed the mission flow for the vertical slice, taking into account our scope and balancing of combat later in the demo.

To accomodate this I designed the narrative delivery system, which would pick from a bucket of storylets the most appropriate one to surface to the player based on a few factors, the most important being previous story decisions, currently held traits, soft traits (traits soon to unlock) and the section of the demo the player is in.

I filled this system wiht 15 seperate stories that couldnt be redrawn but were designed with replayability in mind for subsequent playthroughs.

I structured each story into an exposition/setup section to provide context to decisions, some first decisions/skillchecks, a connecting setup for further decions and skillchecks, then a conlusion.

Making key decisions in stories be noticed in other stories created quite a large writting overhead for myself but I pushed to fulfil it to create that sense of meaningful decisions, like the players choices were being noticed.

After rigerous playtesting and iteration, we finally showed off the prototype together at ADGS, Abertay’s Graduate Show, with me acting as the teams spokesperson.

I organised my teams booth at the event, leading the team to focus on tasks and polish surrounding this milestone and prepare promotional material for the booth. I also prepared this gameplay video showcasing the majority of the 2D prototype in action.

To take the game to compete in DARE Academy, there needed to be a redesign of the structure and flow of the prototype to accomodate being played at a large Expo like EGX. From a large amount of playtester feedback I knew there were a few things that had to be prioritized for the next milestone.

These prioritise included:

• A proper introduction and setup to the prototype.
• A tutorial that introduced players to the core mechanics properly.
• A little more refining of the core loop to ensure an equal balance of combat and narrative along with some polish for the combat loop.

To start, we needed to pitch our proposal for the new direction and work needing done to prepare for the event to the exhibition holders. I organised the team to create a pitch.

Initially we were aiming for a rotoscoped intro cinematic that we would use the development funds to outsource while we worked on improving the game.

I wrote the script for it and planned it out in it’s entirety but we decided, due to a reduction in scope and time constraints, to scrap the cinematic and pivot towards a different creative direction, more on that further below.

To help redesign the game for “booth style play” at EGX I refined the overall game loop to accomodate more of the turn based combat, while utilising the narrative systems and Datapad to help deliver the tutorial.

We scoped down the amount of stories to just focus on a few highly polished ones to showcase the ideal experience and I drafted up the Technical Requirements for the new Mission Design approach as well as a more in-depth breakdown of each requirement.

I wrote up a high level tutorial design page, outlining the structure of the tutorial and specifying when/where things needed to be taught, considering the new player experience.

I then wrote the Tutorial page itself, going into detail with the tutorials flow, and writing out the final dialogue that will occur in each Tutorial story, iterating with playtester feedback.

Thanks to the ideas generated from the narrative, there was a creative shift in the prototype that everyone wanted to explore.

The idea to take it 3D, placing the player in an orwellian “commander training simulation” that tested the players multi-tasking and tactical abilities by managing tasks on several different screens, inspired by spikey and stressful design like Papers Please and Darkest Dungeon.

We wrote up the structure, retaining the 2D prototype for the main game screen, moved the Datapad onto it’s own screen and have other screens with additional information.

We started with translating the 2D prototype into a 3D project, ensuring we could get it working as intended but with the player clicking on the main computer screen to command units and the left screen for the Datapad.

Once that prototype was successful we fully moved forward with the direction, drafting up artistic, sound and VFX requirements and iterated until we turned the vision into a reality.

To address a design concern over players losing track of their units, enemies and objectives we added additional screens that contained all the vital information necessary.

This had the dual effect of heightening immersion. I was responsible for helping architect these screens for a 3D environment, drafting up design side requirements and working with artists and sound designers to direct and implement them in-engine.

We also spent a lot of time working on polishing the 2D prototype, focusing on user communication regarding combat, refining the snap-to target camera during an enemy turn and adding overlays and audio-visual feedback to communicate enemy attacks and units state of fatigue.

I also helped drive polish over all aspects of the demo, working on the CRT/VHS, Glitch and transition shaders on all screens, ensuring uniformity and readability accross all facets of gameplay.

This also applied to polish over the 2D prototype, including creating asset lists and feedback sessions for artistic requirements such as visual effects on attacks and abilities, animations and sound effects, ensuring a cohesive vision was being upheld.

I designed and implemented the tutorial, adding scripted elements for onboarding. These also helped with intrigue and to provide narrative context to certain mechanics, like oxygen, fatigue and abilities building the environment.

I wrote all of the tutorial dialogue and designed it with a beat-by-beat structure, putting the player through their paces and teaching each core mechanic while incentivising experimentation.

The final prototype was showcased at EGX 2022 on behalf of DARE academy for Abertay University and won the Runner Up Award and a £1000 monetary prize.

The reception at the Booth was fantastic and it was an amazing experience seeing how many people loved the game. I recorded and edited a few playthroughs of the game of which you can view below or download the build on Itch.

Responsibilities

A Mankind’s March was developed initially as an Honours Research Project into Emergent Narratives and Player-Driven Stories, I conducted a copious amount of research and collated them within a personal repository before tranferring vital research to a collective one.

This research was disseminated into my work throughout my prototypes. Below you can find my final Dissertation, a study into emergent narrative techniques used by developers to elicit stronger player-driven stories.

I have also included my personal database of research below. Click the image to see the full database.

Below you can find the groups database, a collation of all research, documentation and meeting schedules to which I helped architect, upkeep and organise.

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.