Orradev's Eudaimonia

I finished Day 2 and the Day 3 cutscene. I also fixed more of the cutscene bank swapping code which had me blocked for a while. Here’s some test art with different types of lighting for a corridor.

It seems like I always take long break from working on the game during the summer.

Now that the air is cooling off I’ve been itching to dig back in.

Tonight I worked on my latest round of “I’ve run out of space to put things so let’s make something bank swappable that wasn’t bank swappable.” In this case it was the cutscene code.

I had been putting off cleaning up the cutscenes since that code has been around for a while and is pretty kitbashed. I cleaned up a bunch of routines and made the simpler cutscenes runnable with a generic function.

I spent a couple of evenings this weekend working on solving the “I need ROM space for music” problem. I tried several approaches and eventually landed on one I’m happy with. I moved all of the music and sound effects to their own dedicated bank. This bank gets switched into PRG space right before making any call into Famitone. If I end up needing more than 8k of music and sound effects (likely) I can use additional banks as well.

Having music running throughout the game highlighted some major timing issues related to how I was splitting the screen for the HUD. If I spent too long doing work in the NMI handler the IRQ for the HUD split would be late by 5 - 15 scanlines resulting in a nasty smear of offset tiles. This was a longstanding problem that always showed up when showing or hiding a textbox. With the music playing it was constant and completely unacceptable.

Fortunately, I recently started digging into Mesen’s substantial debugging tools and they were a lifesaver. I was able to step through carefully and see that I was scheduling my screen splits in the wrong place entirely. I moved the split code and bam. All of the offset artifacts disappeared across the game just like that.

What’s even better is, while debugging, I was able to see my textbox show/hide routines running instruction-by-instruction and it revealed a whole bunch of issues with the display logic. I’m confident now that I can resolve the issues and get a nice clean display without the weird tile popping that can bee seen in earlier videos of the textbox rendering. 

I had been imagining a polish pass sometime after finishing the demo content but wasn’t sure how much I would be able to do. I think I’ll be able to get something nice and sharp put together, which is exciting.

Music

I’ve been spending time practicing writing music for the 2a03 sound chip lately. Before I can even nail down what the music in the game should sound like, what ideas it might express, I have to get better with the tools. It’s been a good process and I’m seeing improvement. 

Just like with the pixel art, the bar for homebrew game soundtracks is insane. I’m working hard just to get to a point where I won’t be too embarrassed to ship something. :P

(Listen on SoundCloud)

House Cleaning

While importing some new music into the game I ran into a ROM space limitation. This prompted me to finally, once and for all, really learn how the compiler generates the data layout for the ROM.

All this time I had been mostly muddling through but there were several little bugs and issues I never really resolved and I haven’t slowed down enough to learn what I needed to fix them.

Tonight I took the time. The game is written mainly in C and uses cc65/ca65 to generate and compile 6502 assembly. The compiler supports a few different features which allow you to define where the various bits of code and data in your program will live in the final assembled binary. I realized that I had misunderstood how the program was treating various data types and spent the evening petty much going line by line through the assembly making sure I understood where every part of my program was ending up.

I fixed several bugs related to incorrectly mapped data, majorly cleaned up and documented the layout, and even found and fixed a bug which reclaimed 97 bytes of RAM!

As you can see, I have loads of space for more game content. It’s all a matter of making it accessible with one switchable bank.

Next steps

This whole journey started because I wanted to add more music. Even with the cleanup, one new track doesn’t fit in any of the free areas in those last three blocks of program ROM. Fitting a while soundtrack would be out of the question. 

I need to make the music data bank switchable so I can spread the game’s music across multiple banks. I’ll work on that alongside writing some more music for the game. 

I also have the last cutscene for the demo designed. It just needs to be implemented.

I finished building out the last level for the introductory section of the game. It’s now possible to play the whole first day from start to finish with all of the dialog and triggers. Whew. That’s a big milestone!

I am now going to spend some time cleaning up what I have, adding additional music and sounds, adding cutscenes, and improving the title screen. This will all be towards preparing a demo I can provide to testers so I can get some early feedback on the design of the game.

Dr. Orra is looking aloof. Perhaps her conscience is getting to her...

Progress update

I took a break from development for a bit (as I do from time to time) but I’ve been itching to dive back in. So, tonight I worked on a level that has been a placeholder from back when I first added triggers.

This room is the first time the player meets one of the key characters in the game (Dr. Orra) so it’s important that the decor sets the right tone.

I built out the layout for the level and added metasprites for the new character and another related character and added them to the game.

Next, I’ll build out the dialog and extra triggers.

Status update

I haven’t posted much lately but I’ve been working steadily on the game. With most of the major engine systems in place I’ve been focusing on writing and building out levels. 

Months ago I did a full pass on the game in a graph paper notebook and blocked out all of the major areas for the facility. I highlighted key item locations, characters, major plot points, and more or less designed the structure of the game. 

Now I am spending most of my time actually building the rooms I designed months ago. Art, story, and gameplay are all starting to come together. To that end, I now have to be very specific with regards to what characters appear in each room, how the rooms connect, what the dialog is for characters and item descriptions, and so on.

A heavy stick

The toolchain I have in place for building levels is really complicated. It requires me to use a mix of Windows and Mac tools on different physical machines. I have one tool for creating the art, another for building level graphics, another (custom) editor for building level collision and entity placement. Then, all of that gets complied into the game code which has to be updated with dialog and any custom code required to make the level do stuff. It’s a bad environment for creative work as making small changes can require a whole round trip through the pipeline.

So, to help the situation, I’ve been using Twine as the main tool for writing the game:

I can treat each in-game room as a passage in a twine story. Passages have connections which match the room connections in the game. I arrange the passages in the Twine editor in a way that mirrors the physical layout of the in-game rooms. 

This let’s me write some dialog then run through a sequence of rooms and see if the dialog flows properly. What happens if a player skips a room or visits characters in a different order? Does the dialog still make sense? Does the tone fit?

I can write and edit and delete quickly without fear of messing up a bunch of work. Then, when I’m happy with how things feel I can start doing the level layout knowing I shouldn’t need to make many big changes.

Designing level art

Level builds typically start in Aseprite and are really fluid. At this stage things are still really flexible. 

This is the initial concept for the Shower level:

I need to make sure that for any given room the choices I make here need to:

Be renderable with a maximum of 13 colors

Use only tiles from one of my tilesets

Any new tiles added here have to fit within the available space of my chosen tileset

When I have something here that is starting to work I usually try to get it in game as soon as possible. Palette colors on the NES can be wonky and inconsistent depending on what is doing the rendering so a choice that looks great using Aseprite’s NES palette might look meh in Fceux and eye-scorching in Nintendulator or real hardware. It’s common to make a lot of round trips at this stage to find a good balance without just using the same palettes everywhere.

Laying out NES background data

The next step is to rebuild the level in NES Screen Tool using tiles from the tileset. This tool generates data which the NES uses to load background graphics which make up the level you walk around in.

Here’s what the Shower level above looks like when built out in NES Screen Tool with some palette adjustments:

You can see the tileset used to build this level on the right. That is the holding_cells tileset. It still has a lot of room for cool new art.

At this stage I will usually do a lot of tweaking to the position of various items in the level. I may add or remove props or inspiration might strike and I’ll create all new sprite art to include in the level.

I will also try lots of palette variations here as it’s very fast to do.

When the level layout is more or less complete, I export a bunch of things:

A .map file for the level which I use when making edits

The background data for the level as a C header file

The updated CHR data for the tileset

The palette for the level as a C header file

A bitmap file of the tileset in case I want to edit it in Aseprite

A bitmap file of the level layout to use as a reference in my custom map editor

(If I could make only one change to my current process it would be to make the above steps scriptable.)

Adding map data

Next I add the level to my SCP project in my custom map editor. I import the bitmap I generated previously and use that as a guide to mark up the level with collision information, NPCs, and triggers for dialog and game events:

That data gets exported into the game as C code which looks like:

The big block at the top defines the type of every tile in the level (e.g. walkable, non-walkable, trigger, exit, etc.). 

Some tiles (up to 16) can also have 8 bits of extra metadata. This is used so exits can define where they link to and so triggers can indicate what procedure should run when they are activated.

The spawns define the type and location of entities and pickups in each level.

Finally the level state is 8 bits of persistent data which is kept in memory for every level in the game. The level editor uses this to mark which doors are closed and which are opened but game code can use those bits to keep track of pretty much anything. Those bits can be read even if the player is in a completely different level. Simply put, this allows a switch in one level to open a door in another level.

With just the above done I can load the level in game, walk around, and check the art.

Hooking it up

To get the dialog and triggers working I need to add two files. The first is the dialog definition for the level:

The dialog is all hand-written and is based on the dialog in the Twine passage for the level. Here is where I make sure that each line actually fits in the dialog box. I also add markers for quotes (\x26), line breaks (\x01), and page breaks (\x02).

This is where Twine is such a life-saver. Making changes to dialog in C code with all of the control characters is a giant pain in the ass.

The second file I add contains the scripting for the level:

The details of this are destined for another overly-long technical post. For now, the important thing is this is where we hook up the dialog lines from the previous file to the triggers we defined in the map editor.

This all has to be done by hand because dialog can change based on the game state and activating a dialog will, in some cases, trigger actions to happen in the world. This is the code that ties all of that together.

The result

When you put all of that together you get a finished game level:

It can take several days to go through all of the writing, design, and art for a small simple level like this. Then, the technical buildout and revisions typically take one or two evenings of head-down work.

It is a lot of effort but I’m pleased with the results so far.

Worked on the walking animation for the player character today. Got most it done and implemented in the game. The existing animation code worked well and I was able to simplify some of how I was storing the metasprites so that’s all good.