Project ”obituary”: T-rex Rider

I was going to do a blog update about some few design points on this project, but unfortunately, the programmer recently had to cancel further development due to personal reasons. Well, who knows what the future might hold. I do hope this project will get resurrected at some point in some form, because the NES needs a game about a lonesome cowboy having a terrible idea.

Anyway, i learned a few things in the process and writing things down helps solidify those experiences. I might aswell share them – here’s something to listen at while reading/looking at the rest:

trex_rider_gamescreenlayout

Comp-1_3x4

4x zoom

 

 

 

 

 

I’m fine with how the sprite animation ended up at this point, but the head could still need some position-domain alterations to make it seem more alive, as pointed out to me by the very skilled nes graphics maker M-tee.

Animation
The main thing i want to point out with the sprite animation is the technique for making teeth seem sharp. With a resolution and sprite size like this, you can only get square pixel blocks for teeth. But if the head is at an angle so that they line up diagonally, you can turn this downside of resolution into a feature. The edges of the pixels now become the pointy ends of the teeth! Admittedly, this effect gets distorted by some on a regular tv. You’d want a bright colour like white, off-white or pastell to keep them in line as much as possible on NTSC/PAL.

It was hand-drawn frame for frame (16 frames in total) and is run at a constant 10fps (for now). Hand-drawing is tedious but does provide a more organic feel compared to layer compositing (the other main mode of raster graphics animation).

Sprite design
The t-rex has a highlighted outline (rather than a dark one) partly out of style (nonrealism, cheery cartoonism), but also because it’s an ”avoid everything coming at you” type of game. Boundaries for hits need to be clear. What you see is what you hit.

Soundtrack notes
The music was written with the following technical specs in mind: Since the game is NROM, there’s no irq to help with scanline counting. Since the game was meant to have some scroll splits for parallax effects, even timing was important. That meant the music engine shouldn’t produce workload spikes and work with a constant amount of cycles, lest the scrolling breaks. Luckily, pubby on nesdev had released such a music driver under MIT license. It comes with severe limitations. As such, this song doesn’t make use of FamiTrackers’ volume channel, nor any effects. The mixing is written into the properties of the  so-called instruments.  All in all, it takes 2,5kB of ROM space, but after conversion from FT to pubby’s format, i assume it would be somewhat larger.

Playfield layout
While this isn’t to be taken as the final set of graphics, there’s one thing to note.
By limiting the height of the play field and keeping graphics simple at the top and bottom, you get a more widescreen-like field of play. This helps guiding the player’s eye towards what is important: the mid-right, where enemies and obstacles will appear as you run continously to the right.

Acknowledgement
Many thanks to El Seyf who wrote the code; including an ingame animation tester.

The code has been made open source, and can be found here. Especially the macros might be useful for other NES projects.