reMemory


reMemory game link

First, a giant caveat: I am newish to all of this, so please comment if you have corrections or advice for improvement! I have used Twine for my development as I have experience with HTML and want to learn JavaScript.

Code and Narrative Experiment

I initially set out to create a game that captured that experience during character creation when you start to pick vague details about your character - a backstory detail, a trait or a specific look - and you begin to daydream about what sort of story they have. Does that stealth talent stem from a life of crime in the streets or a history of intrigue and reconnaissance? Most narrative is told TO the player, but I wanted to create a gameplay experience where the player really feels like they are directing the story.

Clearly capturing such an elusive moment wasn’t a lofty enough goal, so I decided to then tell this entire experience in reverse, with the player beginning the game at the moment of conflict, in the final battle scene. The narrative will only play out in memories and so by selecting which memories the player resonates with, they will craft their own story about this spacefarer.

In theory.

It was definitely out of scope for the time limits we had, but, hey, another area to practice.

Narrative Templates and Random

Right before I started this jam, I played through Scents and Semiosis which reminded me just how much I love randomness. My earliest coding attempts were making random strings of emotes to smile/laugh/dance with people in MUDs and since then I’ve always enjoyed trying to balance the more nonsensical outputs with human context. Emily Short's theories on procedural generation were an excellent read, especially about how randomness has different types of uses.

I decided to make several templates which I would then generate the memories based off of. Here are what some templates look like, which I created in the JavaScript section of Twine. 


setup.templates = {

basicMemory1: [

   "subject", 

    "adverbTime", 

    "verbEmotion",

    "preposition",

    "article",

   "nounPlace"

],

action: [

"subject",

"adverbTime",

"adverbMood",

"verbAction",

"preposition",

"article",

"adjectiveBeauty",

"nounPlace"

]

….

}

I then created words to go into those templates:

setup.words = {

   subject: ["you", "she", "he", "they"],

conjunction: ["and", "but", "as", "for", "yet", "after", "before", "once", "when", "until", "while", "as soon as", "now that"],

   pronoun: ["you", "he", "she", "they", "you both", "you all"],

  …..

 }

And then assigned the words randomly based on the template structure:

<<set _tt = setup.templatelist.random()>>

<<set _template = setup.templates[_tt]>>

<<set _m1 = "">>

<<for _i to 0; _i lt _template.length; _i++>>

    <<set _m1 += " " + setup.words[_template[_i]].random()>>

<</for>>

Many thanks to the Twine discord for helping me with this and teaching me about JavaScript variables! It made this so much easier than using just Sugarcube script. Eventually I want to make a JS script for this part of the script, as it’s currently a bunch of repeating code for different values, but at the start of this jam I didn’t know JS at all, so variables is a decent step so far.

A constructed sentence may then read like:

Subject + adverbTime + adverbMood + verbAction + preposition + article + adjectiveBeauty + nounPlace

You + once  + sadly + danced + in + the + lovely + forest.

Very quickly, I realized that this was going to need a LOT of careful curating and further contextual-based word selection. Since time was running low I decided to pepper in some handwritten phrases to give us a semblance of coherence, so I added templates like:

moment1: [

"remember",

"time",

"pastIs",

"moment"

],

Which uses both procedural and handwritten phrases:

  moment: ["gliding on dwindling acceleration", "waiting for that refuel and wallowing in the grasping wake of the dying star", "laying there, your bodies tangled together beneath a pale wash of starlight",.... ]

The merge is clunky and in the future I need to break the handwritten stuff down further and blend it in more smoothly. Every now and then, however, the scripts produce something that sounds like an android soliloquy, which is pleasantly surprising - beauty from chaos.

Player Setup

I think we were much more successful in the setup part of the game, which also heavily uses random text, but it is all far more handwritten. Polygon Native did an amazing job of creating evocative yet vague hints of the world this game exists in. We shuffled the threat, ship names, player location and player reason for being out there to enhance the replayability of creating a story.

Gameplay

Due to rushed time, I decided to make the core loop fairly straightforward: it’s essentially just rock, paper, scissors, but the player has to figure out which resource type beats which attack type each time they play through the game - although, without a robust loop and appealing narrative from the memories, the replay value is a bit less than I intended.  

Core game flow can be diagrammed out as:  Title --> Setup --> Ship UI/Get Attacked --> Allocate Resources --> Rock/Paper/Scissors for result --> Select a Memory --> return to Ship UI --> repeat until dead then repeat everything again.

I took inspiration from Seedship for this, but there is a lot more balancing to be done. I like the idea of something simple that has compelling tension for a somewhat short, repeatable loop, ideal for mobile gameplay.

Because so much is focused on generation, the game skeleton is very small and could use some fleshing out. The core loop is a series of 3 passages that cycle back through each other, with most of the other Twine passages (see below) created so I could use <<replace>> and insert text into the setup section for a smooth flow.


The memory log section is intended to track the player’s actions from game to game - when finished, the idea will be something akin to tarot or tea reading that encourages the player to sift through the patterns of their own choices.

Art Collaboration and UI

As I was building this in Twine, I used rough placements and CSS for the eventual assembly. I used multiple layers stacked on top of each other to create composite background images and the use of grid and divs to create containers for the game art and text contents. See the css skinning section for more details on the code behind this. 

I am new to coding and to Twine, so I wanted something that would be easy to assemble - different conditions, like ship damage or enemy units, was to be illustrated by weaving transparent layers in to the UI. I’ve pasted an example of the layer assembly process below:

I began this game with an idea of a narrative coding concept I wanted to explore, but my initial art thoughts didn’t get much more detailed beyond space ship and stacking layers. Initially I was imagining a wireframe architecture diagram with simple circles for enemy units, but Kale Wesker took an amazing lead in art direction and developed a beautifully hand-drawn aesthetic, which he augmented in Blender and Photoshop.  Jael created some gorgeous space backgrounds and some awesome computer art that I sadly couldn't implement in time.

Filters were applied over the initial art to enhance the hand-drawn look and give the game personality, as illustrated by this art process below:

   

Alpha version of rough UI layout: Ship and Resources page:

Submitted version:

Sadly, I ran out of coding time to add the truly wonderful parts of the art: overlays for ship damage and area threats. The green lines were to anchor the text, but since I was short on time I made a css class and applied it to all the buttons in the game - not nearly as fancy, but it seemed a wiser use of time given how limited I was at crunch.

I’m looking forward to going back to finish this game to give the art the showcase it deserves. Here are some lovely pieces that we didn’t get to highlight:

 

Css Skinning

Changing Font

Applying fonts was a quick way to make a lot of impact across the game, and I think it was absolute worth the time I took trying several out. I’ve outlined the process I used below:

  • Import some custom fonts. First download them and then unzip them to your game folder.
  • Create a new font-face in your CSS file. font-family is whatever you wish to title the new font and src:url(“path.ttf”) tracks the route to the .ttf file the font information is stored in. If it is in  your game folder, you can simply use the file’s name without a path.

@font-face {

    font-family: computer4;

     src: url("goodtiming.ttf")

 }

  • Then set the font in your CSS using font-family: ‘name’;  For example, I have a class called memorybox that I use to style the box behind the text options to select memories. To adjust the font family, the text size and to add an outline around the letters to improve legibility, the CSS looks like:

.memorybox {

      font-family: 'computer4';

       font-size: 20px;

      text-outline: 1px black solid;

    }

Creating Layout Boxes

To keep layout somewhat responsive and to avoid having to spend a lot of time on positioning elements, I used the grid property and a series of nested containers. I initially tried flex but realized that was the opposite of what I wanted - while it would be somewhat responsive, it would also wrap the second half of the UI to a second line. I decided for now to let mobile users use landscape mode and created a grid to hold my UI elements.

  • To set a grid, you will want to use display: grid; and specify the widths for each column in your grid through grid-template-columns: x% y%; In my code snippet below, I have the left hand section of our UI (the ship section) taking up 60% of the entire layout box.

.layout {

         display: grid;

      grid-template-columns: 60% 30%;

     height: auto;

       width: auto;

}

  • Within the layout box, I have another class that is also a grid. This one divides the box into 4 pieces, one for each quadrant of the ship. These divs are then where I put the buttons the user presses to interact with the ship.

Styling Buttons

 

Again, time was a struggle so when I realized I wouldn’t have time to properly align images, I did some quick and dirty work to get some buttons. In Twine, the code I wrote looks like this:

<span class="button">

<<button $area1 _buttonLoc>>

 <<set $playerAreaSelected = $area1>>

<</button>>

</span>

This creates a button labeled with the value of a variable $area1 that holds the name of Area 1 on the map. Originally I was going to have things more complex with changing ship layouts, but the values are currently just set to static values of “Sector 1”, “Sector 2” and so on. The temporary variable _buttonLoc determines where the player goes when they click that button, based on their resource levels - this is currently how the end of the game is determined although right now it’s just a bit of a hack I wrote in before the Jam ended so players could actually finish the game.

<<if $playerResourceALevel <1 and $playerResourceBLevel <1 and $playerResourceCLevel <1>>

 <<set _buttonLoc = "End">>

<<else>>

 <<set _buttonLoc = "Resource Allocation">>

<</if>>

To skin the buttons, I used a series of classes to handle various behaviors, such as hover. I used this demo by Alex Hart as the basis for this part of the code.

Production

I started a few days too late but managed to find teammates quickly and their passion and excitement had us hitting the ground running. I have ADHD so time management and organization are something I constantly struggle with, but every project brings some improvement as I develop skills and habits that work for me.

This jam we had an organized discord, including channels for builds and art assets and clear documentation for needed writing assets. While my direction was unclear with art, I think this gave our artists a place to shine and we had some very fun and productive brainstorming sessions because of this. I think creatives are so important to the development process and should be involved very early on - some of my coding changed trajectory because of their ideas. Had we done something more waterfall, we would have much more rigid code that couldn’t adapt to highlight the art.

One other aspect of production I was able to dip into was very light user testing. I used discord to poll a range of people about potential game names, including some detailed Q&A about what they thought of when reading different potential names. This helped us whittle down the names we suggested as a team into one that is appealing to players.


Conclusion 


Time was the biggest enemy to me here, but a less ambitious scope would have been the way to address that. Coding takes up a lot more time than writing, I've discovered. I'm still learning how to code and need to research a lot as I go, so I need to bear that in mind when gauging how fast I can work and assessing potential workloads. In addition to everything I've learned from this, I now also have the groundwork for the memory system which I can experiment with in other projects, such as for NPC dialogs. 

Leave a comment

Log in with itch.io to leave a comment.