Inherent Smile behind the scenes

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


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:

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.

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:
I don’t recall if all of it made it, or just a subset.

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:

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.

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.

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.

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.

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

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:
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.




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.


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.


HALCYON: Position animation and tile reusage

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

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.

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.

HALCYON december update

Just taking some time cleaning up the main sprite sheet and made a new move for the player character. Now it can crawl though tight spaces. Falling flat on the ground may also be good for avoiding dangers, but you’re less agile while crawling. Another change is that while the player throws bombs in an arc while standing, ze is planned to roll them on the ground while ducking.


While i’m at it. Here’s a look at how sprites are organized when running. NES sprites are 8×8 pixels (unless the PPU – picture processing unit is in 8×16 mode, which is sometimes useful but not always). So mostly, you have to piece several sprites together to make a decently large and detailed character. For example, little mario is 2 by 2 sprites, side by side, and big mario is 2 by 4. But there’s no rule that states that sprites must be side by side. You’re entitled to free placement if your own code permits it.

I’m exploiting this fact to two effects:

  1. make the running animation smoother than most NES era games
  2.  sometimes have the character be fewer sprites in total.

The second point is sort of important because on the NES you have a sprite bandwidth of 8 sprites per scanline (that’s a horizontal line on the screen). If there are more than 8 sprites, the 9th and so on won’t show. Programmers quickly figured out that they could hack their way around the limitation by rotating the priority of sprites. That’s why you see flicker in a lot of NES games – which is still better than sprites being invisible.

Slimming the need for sprites on the same scanline means less flicker – and there will be flicker, because the player controls both a vehicle and a character, and then there’s projectiles, other actors, and so on. A side by side/mario style animation would in this case be a constant 2×3=6 sprites at any one cel, but instead in oscillating between using 5 and 3.

Tilespace-wise, it’s not very effective – the running alone is using 30 tiles if i remember correctly, though some of it can be reused for other actions. You can have 256 sprite tiles loaded in at the same time and that space has to be shared by enemies, items, HUD components and so on. Given that we’re using one quite agile player character and two vehicles ze can ride, that takes up some space. Luckily we can swap strips of it between rooms and areas so we can load in different enemies and items according to need, since the cartridge is using CHR RAM instead of ROM.


Sprite boundaries shown in slomo. Individual movement of tiles lowers the need for unique ones and also sometimes helps keep the sprite count down occasionally. 


The animation is slightly dated. Nathan, the programmer, found that the engine would be more effective if all objects were anchored from the bottom left corner, and this animation has it’s origin at the center-bottom. That’s a quick fix for me, though.

PROJECT BLUE december update

Stuff is really getting really into place! Most assets have been done by now – my graphics and donnys’ music. There’s a fair bit of level design, wrapping-up and programming tidbits left to do but we’re getting closer to feeling really confident about launching this game as a kickstarter campaign with the promise of a very short delivery cycle. Basically, we wanted the game to be fully playable (& enjoyable) before launching it so backers could feel confident, and so that you can have the physical cartridge in your hands quickly after backing. Also we don’t feel like sitting on a pile of other peoples’ money without having a product that’s already solid and shippable. But the campaign is supposed to go live in the first quarter of 2019! Hoping to announce a more set date soon. Anyway, here’s a few game content WIP shapshots i’ve been meaning to show off.

Here is some work being done to the later levels in the game. You there’s no traps,  enemies or other objects on these screenshots, but they’ll be there for you for sure. 🙂


Security desk and HQ lounge


Ride the streams in the underground sewer system… guck!




Catch your breath and get a look at the city centre from the HQ rooftop.


A labyrinthine section of the slummy ruins of neo hong kong. 

Some few animation guides for various objects in the game:



Saving the biggest part for last. Textile artist Per Fhager did this amazing cushion stitch in wool, 36 x 31cm, depicting a scene from level 1 as presented in an interim build of the game between the nesdev compo entry and where we are now. The meticulous stitching is just breathtaking to me. Fhager is mostly known from doing large-format scenes of some of his personally memorable moments from games of  the 80:s and 90:s. Some of them are done as-presented ingame, while others have been stripped from foreground layers and sprites to show off the nice but often hidden qualities of some of these games’ background art. Be sure to check out some of his works here.



HUD for Halcyon

For the scifi themed vehicular/planetary exploration game i’m working on with Nathan Tolbert, i started sketching a HUD. It’ll be wholly sprite layer based, except for any text boxes.

To the left is the first draft, and to the right is something close to what i want to be in the game. It exploits the fact that at least three of the sprite palettes are fixed during action oriented gameplay – since i know what the colours will be, i can use them to a colourful advantage even in the HUD, which usually tends to get a bit monochromatic otherwise in many NES games.  I’m especially happy with the flourescent effect on the ”piechart” gauge. It is making good use of the NES:s Horizontal and vertical sprite flip features, which minimizes the need for too many unique sprites, though unfortunately the machine can’t do sprite rotations, so it’s not quite as resource effective as it would’ve been on later consoles (and on those, you didn’t really need to be this resource effective).


For the font for text notices and such, i was looking for a rounded sci fi look that’d help the game gain its own identity compared to the historical nes library, but it’s still big mono-spaced, mono-coloured letters.



Next up is a long delayed update on Project Blue.





Project Blue goes Textile!

Here’s a sneak peek of a pretty special Work In Progress…


Per Fhager, textile artist, interpreting Project Blue!

Someone who’s making an art form out of taking his game related childhood memories and turning them into finely crafted, large scale needleworks is Per Fhager, whose work i first saw as at the textile museum in Borås, where i was freelancing at the time.

So when he agreed to needlepoint a scene from Project Blue of his choosing, i naturally felt both starstruck and privileged. His work is at this point not only fondly chronicling the history of 80s and 90s gaming, but also the still-going effort to keep these old consoles alive with new titles.

Textile arts, crafts, and methods of production on one hand,  and retro computer art and graphics on the other, has a lot in common, when it comes to techniques, limitations, and expressions. How an industrial weaving machine is producing its pattern is eerily similar to how background graphics work in old computers like the atari 2600, NES and c64, making use of patterns and palettes (or interchangeable sets of spools) and line-for-line drawing/weaving, and it’s perhaps not as surprising when you think about the textile industry being the first significant broad scale application for programming. Once you zoom in, you will also notice similarities in how a raster of threads or pixels can  create the illusion of a bigger, more coherent picture, using very similar techniques. Patterns for text and needlepoint and early raster fonts share a striking similarity.

When i held a workshop for kids in designing retro graphics and game concept, a lot of older folks asked where they could download shiru’s NES Screen Tool – they wanted to use it to sketch and share needlework patterns.


Next generation game designers? Photo taken for online publication with guardians’ permission


2001: A time odyssey

This particular song has been almost 17 years in the making. When i was about half my current age and still a teenager, i wrote a couple of songs on spanish guitar (with terrible playing technique) that were heavily inspired by how the castlevania franchise (especially earlier entries, and besides not too many were out back then) fused classical tensions and flavour with modern rock/blues sensibilities. I had noone interested in that type of sound to collaborate with in a band, so the songs got nowhere. Since they do me no good in the back of my head, i just recently elected to rearrange them for the NES. So in a way they’ve come full circle back to the musical medium that inspired me. Naturally, they’re for the gothic platformer project. This way, i’ve accidentally managed to expand the projects’ history retroactively from 2 to 19 years and going, haha.

The first rearrangement just got where i want it, so here it is.

As before, feel free to chime in with thematic associations and critique.

Edit: Replaced the old upload with a newer version which made a few things a bit clearer.

Project Blue: the wastelads of neo hong kong

This month and the previous have been slow going, NESdev-wise. But here’s an almost finished concept for the ”dystopian wasteland of neo hong kong” that Project Blue is set in.


Level 2 concept. Subject to change. Click to view full size.

Far background tricks
Due to the screen-flicking mode of camera movement (as opposed to scrolling), you’re afforded a bit of leeway when it comes to positioning the far background as you see fit – as long as the next screen hide the discontinuation (which is the function of the lower right quarter). Another trick (not shown here, but i aim to return to showcase it) is how you can achieve a sense of elevation by reusing the same piece of far background set at different heights on screens following each other vertically. That’s what the far background in the upper right corner is for.

The creative process behind it
This scenery follows the creation formula i wrote in the article ”making worlds alien” somewhat. First off, the history was first imagined before i went on to draw the blocks. Note that the following is just part of the process and not necessarily the story the game will officially adopt as-is, but we’ve worked out the boiler plate nonetheless. Basically, the fictional city of neo-hong kong is loosely based on an extrapolated subset of features of real-world current mega-cities; among them of course also the original Hong Kong. In this fiction, the quick growth of economy and population combined with a difficult terrain to zone/exploit (lots of mountains  on a peninsula) leads to high rents, cramped living spaces, and informally converted offices turned into black market squats (cubicle homes), sometimes even in unfinished or disused projects. There’s just no room for unexploited real estate. Because of the illegal status and sub optimal living standards, OMNICORP, who in this cyberpunk fiction is an entity already extremely influential in official policies, maybe even acting as a parastate, were at some point in the future able to dezone this particular area for their highly  lucrative military/security research complex. I imagine most squatters were forced into terrible sweatshop contracts moving into OMNICORP owned coffin hotels elsewhere. There are still dwellers living in this institutionalized drone-warzone, however they’re essentially guinea pigs for post-genève experiments. Adopting the mentality pf rodents to survive, they quickly scurry underground or into crawlspaces whenever they hear the hum of a hoverbot. At the event of Blue’s escape from the lab, this zone is now bustling with automated security detail. Because of the hot weather, there’s a lot of makeshift electrical installations for fans.

I tried to make the tileset reflect on the disuse, military testing, and squats. You’ll find DIY electrical installations, makeshift plank bridges, and crawlspaces. The level is intended to have the thematic structure of a series of ruined office buildings, with varyingly wide gaps between them. This to present as many opportunities as possible to make use of it’s slightly aerial-themed new mechanisms: there’s fans, parashutes, rotor blade-carried sentries, and moving platforms(tm).

Things still missing:
Some mechanisms aren’t drawn yet. Instead of the lasers from the first level, we’re looking to have little electric zaps from faulty wires, and sharp rebar spikes instead of the slime pools. Both these give material reason for more liberal placement, opening up the possibility for some new puzzles.