Overstory of Übermorgen

Some Background

I've been working on a PICO-8 game for a couple months now as my final for my Videogame Design class, and I think I'd like to start talking about it a little bit. I'm new to PICO-8, and I'm definitely an amateur programmer. My focus is primarily on story telling and art (which I'm also not super good at, but I do what I can). This is actually my first post on the Lexaloffle BBS, so I apologize for any weird mishaps and whatnot.
Anywhos... On with the show!

My game is an RPG sort of game, where most of the game is top-down open-world exploration with NPCs to talk to, signs to read, and chests to open. But there's also a turn-based combat state, where if you come across an enemy, you will be tossed into fight (I call this state "tcomba").

The writing of the game is in 3rd person, so the character the player plays as is referred to by name (Sinja; pronounced SEEN-ya) and third-person pronouns (she, her) rather than first-person pronouns (you, your), and the narrator "Suoi" is the main voice.

I took inspiration from all kinds of other games, such as Legend of Zelda, Undertale, and originally Slay the Spire (I was actually going to make Overstory of Übermorgen much more combat heavy, but I decided against it for programming simplicity). And of course, my game takes place in my world-building project.

In Relation to my World-Building Project: Project Krëshkia

For those who do not know -- which will be like, all of you -- my world-building project has been something I've been working on for the last 5+ years, and it serves as a setting for anything I make. Games, stories, e.t.c. Overstory of Übermorgen takes place on the main continent called Krëshkia (pronounced KRAYSH-kia or /ˈkɹeʃ.kiə/), and the main population of both the continent and the game are plezdrakons (pronounced plez-DRAK-uhns), who are dragon-like humanoids with fur instead of scales.

I ran a D&D campaign about a year ago, which laid out the foundation from which the story of Overstory of Übermorgen is based off of. My game takes place hundreds of years after the events of my D&D campaign, which in Overstory of Übermorgen is referred to as the War of Humans.

Many of the enemies, people, and referred names were actually pulled straight from my scripts/notes. The names Tantoezoe, Sinja, Veyet (Vēyet), Vezymya, Zimrence, Thia (Thié), and Captain Orville came from my campaign, as well as the Vokhrovi, which was an enemy-sort-being that plays the same role in both my campaign and my game.
Tantoezoe (plezdrakon) was one of the party's guiding NPCs, who was brothers with Vēyet. I ran a sequel one-shot to my main campaign last summer, where the party had to resolve a paranormal mystery with a guiding plezdrakonik NPC, Thié, who fell in love with the library owner Tantoezoe Sinja (plezdrakon, granddaughter of Tantoezoe). In the original campaign, Vezymya and Zimrence were dragons who assisted the party during combat. Captain Orville was the primary antagonist of my original campaign, who somehow defeated the Vokhrovi to acquire the legendary sword.

Now in Overstory of Übermorgen, Sinja Tantoezoe is a distant relative of the library owner and great historian Tantoezoe Sinja. Sinja's name was flipped from her ancestor's, placing the family name last instead of first, which represents the drift of plezdrakonik values and beliefs over the hundreds of years.

In Overstory of Übermorgen, the War of Humans is referred to almost like a bad memory, most of its emotions dissolved and its effects normalized.

Tech & Design Schtuffs

Designing within 32k of Memory

When I started developing Overstory of Übermorgen, I wasn't a 100% sure I was actually going to be able to fit an entire RPG game in a 32k cartridge, let alone actually enjoy playing it. But now that I've got almost every core feature implemented and a solid 33% of the planned content put in, I am definitely sure that I can achieve both enjoyable gameplay and rich open-world exploration.

Now don't get me wrong, Overstory of Übermorgen definitely isn't as informative as any modern RPG game, and will most definitely require some learning on the player's part. It can be hard to understand what you need to do next, where you can go, and even what certain tiles do. Which is just the nature of having limited pixels, but certainly hinders the experience for many.

I've had multiple people play my game, and half the time they'd miss a chest in plain sight, confuse green carpet with toxic acid, or straight up not read the explanations given during dialogue. Even early on, before I had people play my game for the first time, I started thinking about creating a playthrough guide, or some sort of encyclopedia to explain the tiles, items/spells, enemies, e.t.c.

Currently, as of version 0.1.4, my game only hits 4354/8192 tokens (53.15%) and 29363/65535 characters (44.81%), which sounds phenomenal, except there's a third limit, compression. My game is 10738/15616 compressed (68.76%), which is much less great... But I think it's mostly because of the extreme amount of strings, comments, and potential repeated code stuffs. A tip I heard once was creating constants for true and false such as:

t=true
f=false

In short term, it sounds kinda pointless, but looking at it now, I can definitely imagine how much I can save on a little bit of memory that way, even in just terms of character limit.
I also do recall, I have a good handful of variables that are no longer being used (remnant from cut content), so someday soon I'll have to clean up my code.

I am curious though, if PICO-8 will still run cartridges that exceed any of the limits. Would it run it with a warning label? Will it run it at all? I think I'll find out if I happen to surpass one of the limits.

Open-World

The open-world mechanic actually came from a YouTube tutorial series initially: PICO-8 Top-Down Adventure Game Tutorial by Dylan Bennett (MBoffin). In fact, the whole idea to make an RPG game in PICO-8 came from watching that playlist. The open-world mechanic is actually quite simple. It's just a sprite moving over the map, snapped to the tile grid, and whenever the player tries moving, check to see if the next tile is of any sort of tag, then run a function as needed (such as cancelling movement or triggering dialogue). The tutorial helped kick off my project with minimal road bumps. I think if I had to come up with a system myself I would of done a natural sort of movement separate from the grid, which could of resulted in extra code complexity when it comes to interacting with tiles.

The biggest addition I made to the original open-world system was using tables for more than storing strings for dialogue. There's a table that details where every non-random enemy is, a table that describes the contents of every chest, and a table that details tiles that have discrete teleportation (and soon non-discrete teleportation too).

Turn-Based Combat (Tcomba)

The tcomba state is I think one of the most complicated features in my game, much more than the open-world state, and it is entirely programmed by myself (I'm quite proud of it B] ). The tcomba_init() function takes a table, which should contain all of the details necessary to have a unique enemy. Each part of a turn is a function, and each function makes use of the dialogue system to reference each other and wait for player input (mostly to make the enemy's turn feel more like a turn). The tcomba state also makes great use of the inventory system and partially controls how the inventory system is run.

Dialogue

The dialogue system, along with the initial open-world system, was a thing I found. It comes from this BBS post: Dialogue Demo by Oli414 back in 2017. It works phenomenally and is a crucial cogwheel of my game. It is used to chain together the different functions in tcomba, and it of course allows me to save some headaches by wrapping text for me rather than myself having to manually insert \n ever few so characters. To be honest, my game probably wouldn't of done as well as my final as it did if it weren't for the dialogue system saving me time on programming and allowing me to crunch in those final hours (I made like 85% of the current content within 48 hours of the final due date; I procrastinated in the beginning).

Inventory

Probably one of, if not, the most complicated and most MIND MELTING systems to program was the inventory system. It makes use of a table defining each item, identifiable by an item ID (its position in the master constant table), and whenever a player gets an item, it copies all of the details of the item to one of two inventory tables. If it's a spell, it goes into the spell table. If it's an item, it goes in the item table. Then when the player is trying to view their inventory, depending on if the player is viewing spells or items, the the items or spells tables will be completely copied to a display table, which is used to allow the player to scroll up and down, and sometimes activate such items. This system is probably one of the most janky systems too. It is entirely dependent on functions placed before it that detect player input to override its own functions that detect input in order to prevent double input. It also assumes that the player knows exactly what they want and will take the time to read the item title they are selecting (I haven't been able to add a cursor that points at the item in the printed list) before activating it. Speaking of printed lists, there's a fuggly mathematic function (the mind melting bit) that allows the list to visibly scroll, and it is the soul reason I haven't been able to get a cursor implemented (not that I really tried though..). But it works! And I'm not going to complain.

Creating the Sprites & Tiles

Every tile and sprite was made by myself, except for some of the large tcomba sprites which I had help by a dear sibling of mine to create the lines and shapes for me. They're really good at drawing, so they became an unofficial "intern" at my "company", and now they draw assets for me when I'm too stupid to make them myself. Generally, I can draw my own sprites when they are either A) simple to draw, or B) small enough to not matter if I can draw or not. So 16x16 sprites work very well for me, especially since I come from a Minecraft resource pack background (I had to make a lot of 16x16 textures). But 24x24? Eh. 32x32?? Ehhh.... no. So I handed my sibling a piece of graph paper, which I had penciled two 16x16 squares and a 12x12 square. I commissioned the player tcomba sprite, the final boss sprite, and a high level enemy sprite.

Basically, my sibling would draw the subject within the square for me, and optionally coloured it if they desired, and then I'd take the paper and stare at it for a hot minute. For example, a 32x32 pixel sprite, my sibling would draw on a 16x16 unit grid. I could then create a 16x16 digital image in Paint dot Net and then meticulously colour each pixel as it would be on the paper. Then I'd double the resolution. Drawing the basic shape first gave me something to carve from in the higher resolution, and from there the physical drawing became reference and I'd make the sprite as one normally would. When I was done colouring and drawing, I'd correct the colours (if I'd happen not have the PICO-8 palette on me at the time), and then slap it into an exported spritesheet, and re-import it.

Boom! Awesome sprite in-game! And a beautiful example of team work!

Label Art

I temporarily made my own label (seen at the top), but it won't stay for long. I've commissioned my sibling again to make the line art for a new label , which will be the permanent label. I want to have the main character, Sinja, shown on the label, but that means drawing. The label being 128x128 pixels is WAY too big for me to even think about putting a pen to tablet. My current stock of graph paper is too small to fit a 64x64 (50%) grid or even a 32x32 (25%) grid, so I'm going to give my sibling near 100% creative freedom and just hand them my pen & tablet.

Publishing Overstory of Übermorgen

Why Not Already Published?

I did not include the cartridge for Overstory of Übermorgen, mostly because I don't think I'm ready to toss it onto the internet yet. I still have a couple things to iron out (cough! -- inventory system -- cough!), but someday, hopefully someday soon, I plan on publishing it. I'm treating this project as I would any other game project, where I'm going to try to properly finish my game before publicly releasing it. There's still a lot of big additions to be made, and I think it would be best that the first time people see my game it is what it will be.

Where Will it Be?

When I do publish Overstory of Übermorgen, I plan on posting a video about it on my YouTube channel, and then posting it to the BBS. I am making this blog post with the expectation that I may need/want to create a new post for the game itself, as this post is kind of just a generic bloggy post.
I am also currently using GitHub to make it easier for me to work on my game, which also doubles as a suitable place to share my game cartridge + past iterations + prototype cartridges + prototype sprites + prototype texts + other thingies. Again though, it'll be in the future, if I do decide publishing it.

Conclusion (?)

This has been kind of a lengthy post (and I'm kinda worried that it's a wee bit frowned upon), but I hope I was able to catch a little bit of intrigue. I'm definitely going to work on Overstory of Übermorgen some more, though I may become slower with it no longer being a graded and timed project. I don't post things on the internet very often, and this'll be a bigger, more grandeur project compared to some of my other... projects... But I'm excited nonetheless!

I'm probably gonna make a YouTube video about this soon after publishing this post.

Tschüss, Amity Nexishka