Mother, May I Keep It? Post-Mortem

The development process of "Mother, May I Keep It?" was a challenging journey. Version one was created for Kaijujam 3, but it was not released until over a month - and many, many revisions - later. This was due to technical and publishing challenges on our end, which need to be corrected with realistic expectations and detailed procedures. This post mortem will explore some of the challenges we experienced and planned solutions. We will refer to "Mother, May I Keep It?" as MMIKI.

Regardless of it's challenging development, MMIKI is an excellent proof-of-concept of the general process and finished product we are developing at peerfuture.games. A cornerstone of both is the use of LEGO® building bricks to worldbuild. As Peer Future Games expands, physical construction will remain at the core of our process due to its tactile feedback, creative limitations, and physicality. Using real objects enables and encourages consistency in design motifs. It demands attention to physical constraints and best-practices including balance, durability, and kinematics. It literally brings the world of the game - the built environment, machines, and even creatures - to life, brick-by-brick, strategically limiting the creator and, hopefully, inspiring the audience.

Physical Models, Digital Assets

Using a strict color scheme which denotes the purpose and material of each brick, as well as *tending towards* specific motifs for different factions, enables using building bricks to construct not just the working physical model, but the tautological purpose as well. Here the cockpit, here the airlock, here a weapon, here an engine. Red lights on the left (port), green on the right (starboard).

That's one we actually messed up - not on the build, but by flipping the photograph of the model over the vertical axis. To correct this required a good half hour to forty five minutes of manually editing the colors, near the end of the 2nd to last proper day of fully working on the module. Not a fun realization to make near the end, and just one example of process deficiencies we will examine later.

The build has to be convincing enough that even someone unfamiliar with LEGO® bricks can believe that this is a real spaceship, not just a toy. It was thrown about to test durability, and its center of gravity tested. Aerodynamics were considered, although, not tested in a wind tunnel (hey, it *is* a spaceship).

We aren't just playing around with minutely detailed prototypes - the goal is to create a final asset suitable for publication. This avoids duplicating the labor of concept art to detailed plan to 3D render.

So how to convert the model into a visual asset? We experimented with two methods: a 3D scanning app and photography. We used a phone camera for both tasks, and took the scans/photographs in a home office, which is a far cry from a photo booth.

3D Scanning App

We utilized a top contender in the 3D scanning space (will not promote). Unfortunately, the lack of a dedicated photo space, or way to suspend the model, made this a non-starter. For my first attempt, we took dozens of photographs, none of which identified the target model and, in the end, only gave us a pretty convincing model of a table top:

To give credit where credit is due, the app did a great job capturing my tabletop. You won't find a flatter tabletop scan out there. You can also see where it tried to capture the peanut butter jar holding up the model. Unfortunately, it did not detect the model at all, likely due to poor lighting and the complicated backdrop.

The second attempt went "better", but it looks more like a derelict that decided to ignite it's engines inside a highly dense and combustible nebula:

Obviously, these poor results can't be attributed solely on the technology, but were due to our preparation too. Without a proper photography backdrop, identifying the target of the scan is difficult for the app. The clear plastic stand did not help, either. Even if the model had been captured, relying on natural sunlight (hardlight, if you will) would create a harsh model, possibly losing some details. 

We plan to build a photography booth, rigging, and camera system to take more consistent and higher-quality photographs and scans of the models. That's an ambitious plan, and we'll likely rely purely on photographs, which proved easier to capture than a 3d scan.

Photo Editing

Creating the final photo required several rounds of editing in different programs. Unfortunately, these steps were not well-documented and will have to be rediscovered next time a module is created. 

We utilized value sliders, magic selection tools, manual erasing of the background and some unwanted model features, skew tools, and edge detection to tease out the final graphic. It gives a heavy, foreboding air, convincingly metallic, the outline reminiscent of night-vision goggles. It's immediately identifiable as LEGO® building bricks to any fan, with the logo visible on the studs running down the milling bay doors. We left in the undersides of two more bricks, but erased most of the receiving posts visible in others in the underside of the wing and hull. We weren't trying to hide the origin in any way, but removed some of the reminders to maintain immersion.

Cover Illustration

We wanted to maintain the world-building benefits of literally building creations, brick by brick, with the lifeforms that descends upon the ship. However, photographs of building bricks is not a convincing biological illustration. So for the cover art, we decided to build the "skeleton" of the creature, and then embellish the "skin".

To build the skeleton, we sketched out a "How to draw an owl"-type starting point, and then started to build. This is the only build throughout this process that there are photos of, so enjoy a collage of the process:

The model features spring-loaded jaw action. With a double hinge, the teeth can open up to almost 90° wide. This was impressive enough to absolutely terrify a young, recently-adopted kitten when they were opened up and allowed to spring shut in her face. Scary stuff! Beyond the final result of the above collage, the second pair of eyes - envisioned from the start - was added, before drawing the final illustration.

We used this model as a reference to draw a fairly one-for-one sketch of it as a skull. After that, the flesh and skin was filled in, progressively adding more detail. Just like how the model took shape as it was built, the creature took shape as it was built and then. Appropriately, this was drawn while playing a game of MOTHERSHIP®. Alas, being already distracted from playing the game by drawing, it didn't feel right to constantly photography the process, too. Next time, we'd love to do a timelapse of the illustration.

You can truly see the refinement of the concept throughout this process. The first sketch was wider and softer, looking more like a cuddly Toothy than a real threat. In my imagination, the creature looked more like a cat, to encode the playful and curious nature of the creature which was intended to interact with the asteroids of Chalythra Cluster and the equipment onboard the Shepherd's Dog. The final illustration utilized edge detection and other artistic filters to create the frantic, vibrating eyes, and wispy outlines.

In the end, the Lego build turned out more reptilian than our initial vision, especially in the long neck. The neck is rather featureless because - well - we never *built* the neck. In this method of worldbuilding, if you can't or don't build it, it will naturally have less detail. Most of our little details emerge organically from the construction process. We like how this turned out - they're comparable to the slugcats of Rain World; heavy, fast, and very low-to-the-ground. After all, these guys entirely depend on clinging to comets for their travel, survival, and reproductive cycle, so they should be staying low to the ground where they won't be brushed off and lost in the void.

The creatures abilities and statistics evolved significantly throughout writing. Initially, we reached for the classic "Creature-infects-crew" reproductive method. The "dust bunnies" (consider the name ironic, in light of their appearance) would, somehow, inoculate any objects which were composed of minerals and water (hydrogen). In the end, this felt far too cliched and predictable. Additionally, we didn't have the inspiration - or space - to describe their infection process or lifecycle.

Therefore, in the final round of revisions, their life cycle was left mostly shrouded in mystery. Development in this regard is ongoing, in preparation for running the game as a one-shot. But their life cycle is hinted at by one of the "salvage rights" rewards for the adventure: a frozen geode, which leaves a loose end in this module for hinting at a slumbering thread in MOTHERSHIP®'s TOMBS cycle.

Currently, we are preparing to run MMIKI as a one-shot. Therefore, additional thought is going towards the creatures abilities and intelligence. We plan to release a creature feature supplement for MMIKI, with some additional ground rules for the abilities and decisions of these mysterious "dust bunnies".

Perfect is the Enemy of Good

All of these revisions took a considerable amount of time. The hardest part was editing photos in a non-parametric or reproducible way, and being unable to go back and correct early mistakes. E.g. the red/green running light mix-up mentioned earlier. Or the way one arch was deleted off the photograph while erasing the backdrop.

Poor planning and coordination further delayed the release. I began a road trip about a week before the official end of the jam, during which time, I had very little time to finalize the release. I did carve out and allocate some time the final day of the jam. Unfortunately, technical difficulties - a non-cooperating wall wart - prevented me from submitting the project during that final crucial block of time. After that, other obligations took me away from my computer.

Additionally, not having the final version cleared with Tuesday Knight Games made me hesitate to release what I *did* have sooner. In the future, I will be sure to have a plan for this sooner, by either coordinating the approval more closely or deliberately releasing an "unlicensed" version. 

Course Correction

When we created my first MOTHERSHIP® module, Faith Crown Body, it's only publicity on release as a Cosmic Horror Jam III submission. (Funnily enough, I also came up the dust bunny concept for that jam, and used *that* for Kaijujam 3.) That module still has less than 20% of the views of MMIKI, and barely 3% the downloads. This illustrates how essential it is to know your target audience. Typically, the developers entering jams in the MechaJam family are computer game devs. They aren't likely to be very interested in playing, or even downloading, a supplement for a TTRPG. Not to mention, this community is very small compared to the /r/mothership subreddit.

Besides understanding the steps I need to take to successfully create and publish supplements in the future, we also understand the target audience better and am developing a release strategy. Additionally, now that MMIKI is live on DriveThruRPG, I have two published titles and should be able to release future titles there on my own schedule. It's nice to have one process improvement happen for free, but there are many more steps to take before we can expect a development cycle to proceed smoothly and economically.

Here's a list of immediate preparations to make before the next project:

Templates

1. Itch.io - New Project form
2. DriveThruRPG - New Publisher Title form
3. Trifold - General module
4. Trifold - Warden handout
5. Trifold - Player handout
6. Character sheet
7. Monster sheet 
8. Ship sheet (optional)
9. Contractor sheet

Photography and Editing

1. Photo rig
2. Camera
3. Camera data card
4. Publisher program
5. Photo editing program
6. Detailed photo editing sequence

Program coordination

1. Coordinating release with publisher
2. For jams, having an unofficial version ready to drop for the voting period
3. Coordinating release on DriveThruRPG
4. Publicizing the release on social media and to an interested audience

Final thoughts

Coming up with creative concepts, drawing the concept art, and creating the final 3d model or illustration - on top of design, layout, and writing - is a demanding cargo. We went through all these steps during Kaijujam 3 - and it *was* too much. That's why we'd like to automate many of these processes in the future. This could include a robotic camera studio, macros for photo editing, and scripts to generate content for storefronts and social media. These are ambitious goals, but we feel very confident in reaching for them. Over many years of game development under unrelated monikers, we've narrowed down the motifs, narratives, and mechanics we devise best. These abilities need to be refined into structured capabilities, at which point the momentum of Peer Future will start developing real inertia.

Thank you to everyone who has taken an interest in "*Mother, May I Keep It?*". We hope you enjoyed this development post-mortem. With this publication, character sheets have been added to the Itch page and the title submitted to DriveThruRPG for approval. Once it's live on DTRPG, the free-sample period will end, and the module re-listed here for 3 USD. So get it while you can - and spread the word!