Inherent Smile behind the scenes

Last years’ NESdev compo, i drew and animated the title, ending and battle modes for calima’s ”Inherent Smile”.

placementguide2

The game has the technical merit of being the first functional 3d maze game to be released for the NES. It also included two vastly different and ambitious subgames – a somewhat fully fledged RPG battle system with a hint of punch-out type timing mechanics, and a character dressing game. More on that later.

As it turned out, i was a tad naïve both when it came to available time and just about how much animation and inventory data we could fit into the compos’ mapper restrictions along with the game, and so some things had to get trimmed or cut out altogether while some other things were left a bit unfinished. The files are sitting in a dark corner of my project folder so i thought it may be time for a little show and tell. I honestly don’t remember exactly what made the cut and in what shape, but here’s some highlights and design-wise points of interest regardless whether they made it or not:

minotaur_timing200
Most famously the final boss was missing (on strike, as the end text would tell you). It was to be animated on the background layer with the help of scrolling. The player would stand on a cliff on the sprite layer. I thought i had a mockup of that but can’t find it at the moment. So here’s just the background layer.
Note that the tail goes missing in a few frames – it’s not for any technical reason, but rather that i never got it completely finished. The punch out nature of these RPG battles would’ve become apparent in this battle if not earlier, since the minotaur is literally finting and punching as its standard attack.

Given the amount of time i spent on it, don’t be surprised if i recycle it into another project.

Here’s a snapshot from my workspace including the cliff. It also shows the spriteset in some state. To fit it all, i opted to reuse some tiles from the cube enemy in another palette as part of the cliff. worskpace

 

blobjump sneezing
The sneezoid had a bit more detail to its jump as i recall it, but it still was fully functional.

lantern_normallantern_bad_signlantern_active
The possessed lantern would have three subtly different patterns to hint at actions and when to time a block. It was made with position animation. of just 4 tiles, which helped:
lanterntiles
I don’t recall if all of it made it, or just a subset.

electricity
I don’t think this lightning spell got into the game quite this way, but either way i’m not terribly proud of how it turned out – it was a bit of a rushjob towards the end, iirc. Compare it to the mockup of electric arcs in Project Blue, which looks and feel more natural:
electric-arc2

On the other hand, the electric attack in Inherent Smile was made using only a a couple of tiles thanks to the help of mirror bits, so it’s resources are well justified. I didn’t get the animation pattern quite right though.

Here’s a funny one. The bat didn’t make it into gameplay at all iirc, because we simply didn’t have more room to spare for animations. It was a blessing in disguise because i wouldn’t have had time to fix that very pelvic nature of its attack. You can still find the tiles in the ROM, i believe.

ghost_spellcasting
The ghost was to use this wavy pattern when preparing spells – it’s a little bit cheap but works okay. It did make it into the game in some form, but not quite as was planned iirc.

river_chasm_alternate
I originally had fantasies about animating this molten iron river, but quickly realized there were more important priorities.

One thing i’m particularily proud of was the paper doll dressing subgame – equipping different items would visibly alter the character. There were even colour coded set items. It worked because of careful placement of enemies and player on the battle scenes.
Here’s the basic unequipped player running.

animated_guidecycle_halfway
jumping_guide
And here’s a still frame of the player attacking with equipment.

He’re some of the possible combinations of gear – the player would pick and experiment freely. Unfortunately, we didn’t find the time (or space) to balance it against the general difficulty scheme. The easiest way to beat the game is to find the exit quickly, rather than taking time experimenting. It’s sort of hard to describe, but there litterally wasn’t even a handful of bytes left to make it more nuanced.

gearandenemies2
All of these items and more were in the game iirc. Again, the bat didn’t make it.

ratidle
Here’s the rat taunting you. I remember that was in the game.

The vines on the title screen, just like the general theme of the game was inspired by greek mythology, was inspired from a classic-time greek ornament. They were put on the sprite layer:
decor
For those who’re interested in the game, it was part of NESdev compo 2017 and combines realtime 3d maze crawling with said paper doll system and RPG battles with a little nice touch of timing attacks and blocks. The game is part of the next action 53 multigame cartridge, once it is released. Thanks to calima for having me along the adventure of making it, and for angelic patience towards the end.

the_end_placement

 

 

Say hi!

Just introducing the proposed heroine for a game i’m designing for a museum. The setting is this: A few hundred hears from now, the swedish westcoast needs to be sanitized, badly. Armed with her wits and protected by her trusty yellow raincoat, how much trash can she sanitize before the sun sets and the coastal, flooded ruins of our time become too dangerous? She might even find some rare collectibles among the floating scrap.

_helloworld

Some of the game objects you may encounter. Do not trust the seagull. items

ca65 programming tricks: Trimming and merging tileset assets

Don’t want to copy, paste, trim, split or concatenate binary files (such as tilesets and other rodata, or precompiled programs) manually in your NES project?

if using ca65, you’ll be happy to know that the .incbin directive is rather versatile. You can add an offset and a specified length of bytes you want to use, like so:

.incbin ”myTileset.chr”, 0, 3328
.incbin ”myOtherTileset.chr”, $D0 * $10, 768

Since tilesheets are a common target for the .incbin directive, it may be easier to multiply any parameter by $10 if you’re counting tiles, rather than bytes. (one tile = 16 bytes = $10 bytes in hexadecimal).

Here, it was used to provide a reusable method to paste 3 rows of HUD elements from one level sheet and the rest of the other level sheet, making a new one.

Okay, so the practical example is a bit unwarranted since you can achieve the same in one line in bash on linux or powershell on windows.. But it is still convenient to know how to do this inside a project, and you can of course replace these magic numbers with defined constants, make the cc suite compile assets for you from smaller modules, and so on.

You can download the zip here, containing the .bat, .cfg and .s files that make up the example. The graphics have been replaced with something that’s just there to make it work. Naturally, you need to edit paths to fit your environment/preference.

merger_example.zip

 

HALCYON: Position animation and tile reusage

Happy new year! Here’s some dog- and bird-friendly fireworks

explosion4
Most explosion type animations on classic NES games keep to a 16×16 pixel pattern (that is, 2 by 2 8×8 pixel sprites). There are some ramifications that encourage this, but it’s not a hard limit. The main one being the famed sprites per scanline limit, which means only 8 sprites can be shown at the same horizontal line at any one time, leading to sprite cancellation (or flickering if the programmer has seen to it that the PPU takes turns showing up to 8 at a time). Another is that some game engines limit how an objects’ sprites may be positioned in a compromise between simplicity and utility. And sometimes, that’s what you want.

A bit on the technical side, but for HALCYON i’m simply exporting raw chunks of Object Attribute Memory (OAM) data for each animation cel, which is in a way the simplest and most versatile way to handle metasprite animation. Positions can be made relative by adding object position to the OAM position. Additionally, you can hard-code palette, layer priority and mirror-flip attributes into them to be manipulated (or not), and used (or mask-ignored at will) by the object handler. One way to know where one metasprite ends and another starts is to include a terminator message in the form of a byte after all the metasprite data of an object or animation cel is done. For example, a value of 128 will set off the signed math flag which can be used to determine this, or if you really need bigger offsets than 127, you could let $FF be the terminating value. INC, INX or INY it once, and test the zero bit. The rationale for this is that the first byte is the Y position, and you’re completely unlikely to give any sprite an Y axis offset so great that the metasprite component will be be put offscreen or wrap around to the other side. A metasprite handler like that could use the same object handler for sprite overlays on title screens and the like, aswell as gameplay objects (at the same time even), but i’m getting way off topic.

Anyway, this allows objects to be position animated.

I want the explosion to be 1)big, 2)use no more than 4 sprites at any one time 3)clear itself out of the way to not cause clutter. The first goal is in order to have a satisfying impression on the player after defeating an adversary and to make ”more” than was traditionally done for the console. The second and 3rd goals work together to minimize sprites per scanline over time. Since the 4 sprites spiral outward in a diagonal pattern, they clear themselves away from any frontal position the player character might be likely to have, ie. avoiding taxing the scanlines as fast as possible.

In the video, i’m stepping through some of the animation cels to give a better insight into how i move the sprites.

Since quite a hefty percentage of the total tilespace is used to do smooth main movement animations of the main player character, tile recycling is helpful. The explosion is mostly reusing the same tiles with the help of tile mirroring. Note that the NES PPU can’t properly rotate sprites (not even in 90 degrees), but sometimes mirror-flipping is good enough, as shown in the video. I also figured the 4 first cels of the explosion may be good for for energy obtainables or the like.

 

The one of the right is made out of 4 sprites, but is only using as many tiles as the one to the right (which is one sprite) thanks to the mirroring bits.

I’m using similar tricks for the pie chart-type meter i posted about earlier.

EDIT:
explosionanatomy
Here’s the explosion with a more didactic timing, a grid and sprite boundaries, to show what is happening. A nice thing is that the twirly movement lets it expand while not taxing any more than 2 sprites per scanline From the moment it expands into four sprites, it takes 12 frames before it starts clearing up scanlines from clutter to an extent that is lesser than the classical 2-sprite-width explosion. Lastly, you see that sprites are removed from the list. That’s another nice thing with variable metasprite sizes and termination bytes – you don’t need to use more sprites than necessary.

Not shown here is that the four first cels take 2 frames each in realtime, and the twirl outward goes at a rate of 1 frame per cel, but eventually slowing down gradually to 4 frames per cel as the last ember flades in a floating state.

Looking at it frame for frame, you can spot plenty of beauty faults. The gap between the 1 initial sprite and the 4 following them is one – but given how fast the explosion goes, you can get away with it and save some tilespace.

One thing that i changed from the first iteration (you’ll notice that the gif is named explosion4) is to stagger the changes from one tile to the next on each sprite. That helped it look a bit more naturally chaotic. The same goes for the sprites being deleted off the metasprite list in the end.

Now, a variable total sprite usage during gameplay might not be that useful in itself, apart from the obvious advantage of having somewhat leaner object representations on any one scanline. You could seemingly get away with more action on-screen in something like a hectic shoot em up this way since you might be more efficient before reaching the 64 sprite hardware cap. But having an action game run smoothly with that much stuff going on would be the bigger challenge. And for the hardware cap, that’s just another occasion where you hypothetically can use priority flickering again if you get to that point of unusual sprite density.