I’m having this little auction over at Nintendo Age where a few cartridges with concept art i’ve made are given to the three highest bidders. I thought i might go the extra mile and at the same time brush up some format ”skills” i haven’t used in a long while.
We’re announcing Project Blue (a joint effort between me and Toggle Switch), a game that will enter this years’ NES dev competition which ends in January, 2018.
Help Blue through up to 64 screens of high-tech action platforming and measure your skills against combinations of a dozen or so different enemies, a big bad boss, and various traps and obstacles.
Disclaimer: What you see here is still subject to some changes
The in-game end result will look something roughly between this…
(the game in its actual current state)
(early concept screen not taking into account all the software priorities made both before and since).
Maybe the coolest thing, although it stays out of the compo itself, is the custom level editor application that toggle switch did, with which one can design levels for Project Blue without needing to know the first thing about assembly, or programming in general. I’m personally amazed that he made a tool that will let gamers modify this coming NES game relatively easily.
What’s up next?
The plan after the compo is finished is to expand this game to make it larger, to justify a commercial standalone release on a physical cartridge.
Just something i started working on in advance the other month. In advance, because we still have an unannounced game to finish before this can get serious.
On the other hand, not being too deep into the production yet allows for another type of creative flow. These make ample use of unique characters/tiles and the cartridge hardware will just have to comply (ie have a rather big prg-rom). For example, the parallax effect in the second screen requires x8 as many tiles as normal for the treeline background. Thankfully, the cost of a 512kB prg-rom NES cartridge is close to that of one with less. Program size is not even the most significant cost factor, up to that point.
Here’s two snapshots from a level concept from yesterday and today for our space-fi game in-development.
While the previous is more colourful and works with contrasting colours, it sometimes felt hard to parse what’s solid and what’s distant background. This is because the four subpalettes get used for both to a large extent. To mitigate this potential problem, all solid rocks got a stronger/brighter outline to outshine intangible objects. Hopefully something along that way will do.
Next step is probably going over the distant background to separate it, in turn.
-Rock colouring is now regional, rather than random. A ”green” area is hinted at the bottom right, and there’s a single green ”milestone” in the bottom left quarter. While less colourful, my hopes is that things like that will help orientation in a larger, sprawling cave system.
-More distinctly diagonal shadows on the pillars in the bottom right quarter seems to help my depth perception.
-various details and decorations added. Some others might be cut in the future, but we still have half of the tile memory unused for this set, so there’s no hurry to rationalize.
Here’s something i’ve been working on. It could be seen as two projects, separated by theme. They both explore how to come up with cross-section perspective within the limits of the Famicom/NES. The first is a sci-fi/cyberpunk one, with emphasis on stealth. The ambitions for this design proved a bit much to chew within our the time frame we had set, so we shelved it for now and turned our attention to the second one, which is a gothic horror/fantasy theme more focused on exploration.
(click for pixel perfect view)
It’s easy to encounter perspective problems. While the whole cross section perspective is exaggerated, the trouble appears in seams between perspective shifts – you can only have a limited set of angles due to memory constraints, and ease of level management (which in turn ultimately is a storage constraint – you need to come up with a way to compress stuff and varying angles will not help). That pretty much means you may feel the need to justify the cross-section, fish-eyed perspective with something other than mere presentation.
In the sci-fi example room, it merely serves as depth for its own sake. In the fantasy one, it provides a factual z-axis that the game can as a mechanic for one-way passages which should be able to lend itself to themes of exploration, puzzle solving, and object/enemy interaction. It probably would lend itself to a sneak/surprise kind of game too, now that i write about it.
But with multiple levels of height, things get even trickier. In the animated gif example, certain planes are hard to parse in the lower room. Besides getting a perspective problem on the low-right corner less wrong, i had to cut away pieces of two platforms to show walls at an angle in order to properly tell the player/viewer what relation the neighboring planes had. Shadows alone just wouldn’t cut it.
The form is still not 100% set, but i’m getting there.
The theme of the gothic fantasy project was largely scavenged from the design documents i had made for one of my earliest attempts at doing NES graphics. The idea then was to make it a purely isometric experience; but because of the PPU:s limited ways of handling colour attributes, it makes for a somewhat more monochromatic experience. That’s why every room in games like Solstice have a unified colour scheme.
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:
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.
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).
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.
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.
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.
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.
Here’s a concept screen for an untitled NES collaboration slowly taking shape.
I tried thinking material this time. I followed a certain order to work out the details.
- First, define what ground looks like.
- Put that in a context. Ok, so we’re in some sort of ravine or valley. I also added a contrasting look to the distant background to foreshadow another set, but that’s beside the point.
- Establish what life forms would thrive there.
I went with two main vegetation strategies: something flourescent, moldy, creeping (thrives in the accumulated moisture of the shadows, may fit a symbiotic nische), and something striving to reach up, with a sensory organ (the eye-like thing) at its extreme. Those are meant to be animated and follow the direction of the closest moving object.
- Last, introduce alien-made constructs. Since we’re dealing with a moist environment, piping seems fine. Maybe it’s some kind of managed mold farm? Or a drain system? A structural skeleton? It’s really up to the player*.
Tile/character usage-wise, it’s acceptably efficient (by designing tiles to be combinable in different ways on the meta-tile level), currently using up 38% of the background tile page. There’s plenty of room for animations, bg-based enemies, or a whole other set loaded at the same time.
For comparison, here’s a snapshot from somewhere halfway in the set-building process. It is preferrably uncrowded. Levels shouldn’t use every asset every screen, lest you oversaturate the experience.
I’m interested in critique. If you have any, please comment.
*The last step makes a point. For it to feel alien or strange, let it be vague. Example: What’s so great about Alien, the movie? You don’t get told what’s what. It hints at a much larger, wondrous, and horrific universe with schemes and designs beyond the human scope. What’s not so great about alien 3, resurrection, prometheus and onwards, apart from their individual failings? They do their best (worst) to serve the audience a digestible explanation of everything (a substitution for a solid plot), which sucks the life out of the fantasy.
What better way to start off my new blog, than with a first post about my first concept work on NES compliant graphics? Mild warning: this post is a confused blend of personal retrospective and ”i-guess-we-can-call-it-an-inspirational/tutorial?” and i’m not quite sure who i’m writing for here beside myself. If you’re new to the technical side of the NES or 8-bit graphics in general, there’s a glossary at the bottom of this article that’s hopefully of some help.
Here it is – a background screen:
Telling without text
I’ve always liked visual story telling, and this was kind of half-consciously drawn to be such a story element. Retrospectively thinking, the idea is this: Rather than having a text tell the story or background, place meaning-carrying objects in relation to each other in order to create some narrative tension. Leave it to the onlooker to fill in the gaps on what the scene (or whole game background is about).
It could perhaps come across as ”Here’s a gothic romance scenery: something in decline, crumbling, left in disarray. What does it mean? -meanwhile, over there, there is some foreboding activity going on in a lone keep. Who- or whatever’s in that castle, might be the answer to the questions posed by the foreground.” I do not know that’s what would cross every mind, but i entrust the hypothetical player/s to come up with something that works for them. The point is that the imagination of the audience is a more dynamic tool than hard outright statements from the author. I also wanted it to be used by the player as an optional and implied roadmap or beacon. ”Here am i, and there is where i want to/have to go”. It’s the classic castlevania trick. Or the Lupin III trick, i suppose.
NES graphics does the gaps, you do the filling in
Black is an often facilitated background colour on NES/famicom titles. While it is a good resting colour, there’s more to it: shadows and darks are yet again a technique for letting the onlooker fill in the gaps. This is an effective remedy for the limited memory of the PPU (picture processing unit) to make a small set of graphical components seem like more. A contour can be enough for the mind to create meaningful content to the surface. The amount of detail on or close to that contour can help provide a sense of depth.
Getting more metatiles out of less actual assets
Placing the same 8×8 graphical tiles in different positionwise relations to each other on the nametable is another way of cramming out more from the same small set, but you don’t see that too much in the commercial cycle of NES games, mostly – i would assume – because data storage in the form of EPROM chips were expensive at the time, so you had to do viable business choices. Post-market/hobbyist NES development doesn’t suffer from this issue in the same way, so at least there’s a potential for more varied levels, story screens and what not today.
Colour and palette priorities
This screen is, perhaps suprisingly, using up all four of the NES’ background palette sets. This is so that the directional light could be more nuanced, and so the so-called attribute grid could be a bit broken up, at the expense of warm colours. They could possibly be compensated for in the sprite layer, which has its own four palette sets, but as it is now, this screen is background only.
A dubious choice of colours is the mountain reflection in the lake. Depending on PAL or NTSC (never the same colour) region of your console and TV the contrast and brightness of the latter (or laptop, phone, etc), it can look better, or much worse, as shown in this NTSC simulation, tool courtesy of NES veteran blargg. This is because it is only slightly differentiated in hue, not brightness, from the rest of the water body. Due to the indexed colour nature of how NES bitmaps, just changing the colour to something else also affects every other area using the same palette. A stylistic redesign on tile-level would be necessary if i wanted to change this to something more robust at some point.
Vertical lines, borders and hardware
Moreover, the thin blue vertical lines in the foreground gets a very noticable bashing on real hardware because of the way composite video works. They basically get a sawtooth like pattern. My first actual hardware tests were done some time after i began doing NES graphics. Several post-hardware test observations can be made. One is how fields of hue-axis neighbors on the palette get a thin dark dotted line between them.
This first concept screen stuck in the back of my head, and I hope to return to this specific concept one day in the form of actual game development when the time comes. For now, other projects are in the pipeline. More on that in a while…
If you took the time to read this far, what did you think of the direction this first post is going? In what direction would you like me to go?
If you’re new to development for the NES, here’s a short glossary to help the readability of the article.
Tile; sometimes called character or pattern (just like the in the textile and printing industry): an 8×8 px portion of graphics that can be held in the pattern table of the PPU. These are repeated on the nametable, which is essentially what you see on screen.
Nametable; a bitmap in PPU memory that tell what tiles go where on the screen. A NES program normally makes use of 2 or sometimes 4 screens’ worth of nametables simultaneously, depending on mapper/cardridge PCB.
PPU: Picture processing unit. Like a GPU, but with a hard defined set of tasks. When processing graphics on the NES, you almost always do it via the PPU:s hardware registers. Some unusual/special tasks, like shearing, must be done in software.
EPROM; stands for erasable programmable read only memory. It’s the physical storage chips in a NES where you store program and assets. A wipe is done by exposing the silicon to strong UV light for some time through the quartz window on the chip (normally masked with tape). A variant is the EEPROM (meaning electrically erasable). More versatile, cheap and quick-to-reprogram alternatives are available today, like flash ROMs.
Post Script additions
Rahsennor, who’s the coder of wrecking balls, sent me this new NTSC emulation of the screen. I currently only have PAL hardware for testing graphics. If anybody can chime in on the accuracy of this emulation, that’d be handy for future concepts and projects!
This is a test.