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.

ruinsofneohongkong

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.

Annonser

Who wants a gothic action platformer for the NES?

 

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.

castle_x2_3_2towerscroll

Short note on sprawling cave systems

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.

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

 

 

base4base4_2

Cross Section perspectives

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.

PS.

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

1st year of doing NES gfx, 1st post on the blog.

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:

test3-256x240

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.

test3

2x upscale

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.

screenshot

mobile phone camera on flat tv screen

The future
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?

Glossary
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!