SUGallery might be the codename for an action-adventure game. Take a generic Zelda-style action game, put it in a ROM cartridge much too big for it, and fill the rest of the cartridge with pretty pictures that the player can unlock.
This project is on hiatus.
There are 80 still images, each 5 to 6 KiB in size, inside this cartridge. But to see them, you must convince other characters in the town to give them to you.
I'm not trained as a pixel artist, but I do what I can.
marshallh and ReapWORK say Frank's Adventure series is like this
The first town will probably end up as my first crack at implementing a subset of DX Town.
Because most of the game will take place in the player's home town, I want to avert the thriving ghost town pattern so that I can have quests involving gaining the favor of multiple NPCs. So in order to figure out what houses to include, I need to know what friendly NPCs will live here. What occupations would be needed to make a village self-sufficient?
About the thriving ghost town pattern, Chris Covell wrote: "A game with a realistic number of NPCs hanging around outdoors would be creepy -- like some poor country capital where 80% of the men are unemployed." abadidea suggested reading "Medieval Demographics Made Easy" by S. John Ross to get an idea of what NPCs might be needed. See also articles linked from answers to "What are the different types of stores I should include when designing a town?" on RPG Stack Exchange. But surprisingly enough, fast food is older than feudalism. In ancient Rome, a cook shop had a "support value" of 60.[1]
I don't feel like using the outdoor space compression pattern either. So I adopt a scale: 1 m = 16x8 pixels outside or 32x16 pixels inside. I also make the actual houses smaller.[2][3] The houses in this scene are 5 m by 5 m, big enough for two people to live in, with a second floor for sleeping. Roofs face to the south rather than to the west and east, and the reason becomes obvious once you get to the richer parts of the world that have rooftop solar panels.[4] That and south-facing roofs use fewer distinct tiles. The game will run in a 256x160 window, which outdoors gives a 16 m by 20 m visible area of the map.
I plan to use 480 KiB of the available 512 KiB for the picture books that the player can pick up. Without compression, I can fit a 192x128 pixel picture into 6 KiB. But with Huffman coding of 8x1 pixel slivers, gamma coding of run lengths in the vertical direction, and tile repetition, I might be able to fit comic-style line art at nearly full-screen sizes. For 1bpp line art, I have a test case that even beats PNG; I just need to make sure I can replicate the result at the NES's 2bpp.
The original plan called for explicit pictures, though this has since been toned down.
As of 2010, NES games are most commonly run on NES consoles connected to widescreen HDTVs, NES emulators on PCs, and the PocketNES emulator on Game Boy Advance. So the game abuses the sample playback channel as a raster timer to get a 256x160 pixel view so that it looks acceptable on a widescreen or in PocketNES unscaled mode, as seen in the demo. This also provides plenty of room for glitch-free video updates: a 256x160 pixel window on a 512x240 pixel vertical-mirrored nametable.
Characters will be able to walk behind things. But the NES has only one layer and no prio-per-tile, and we still have to show an outline so that the player knows where his character is. So instead, the game draws any sprite occluded by background objects as an outline.
The NES requires 5.0 V 8-bit parallel ROM for program storage. Cartridges in the modern era often replace this with NOR flash memories such as the 29F010 or 29F040, which have eight erasable sectors and 128 KiB or 512 KiB of space. Moore's law states that roughly every 18 months, the semiconductor process shrinks to double the number of circuit elements per square millimeter of silicon. At this point, the number of pins dominates, and 29F040 becomes just as cheap as smaller chips.
SUROM is an extension of SNROM to support 512 KiB games. It divides the ROM into two halves and using MMC1's CHR A16 line, which is otherwise unused in games with CHR RAM, to switch between the two. The only NES games using this board are Dragon Warrior III and Dragon Warrior IV, but the modifications to an SNROM board such as Ultima: Exodus are straightforward: rewire it to take standard flash, and then connect MMC1 CHR A16 (pin 11, next to GND) to PRG A18. And if this game ends up not using PRG RAM at $6000-$7FFF, one might be able to rewire SGROM the same way, as SGROM is the same as SNROM without PRG RAM.
But a playthrough obtaining all ten albums is expected to take far longer than the two-hour limit of a play session, so there needs to be some way to store the player's progress across a power cycle. The exact method used for saving the progress ultimately depends on what board is chosen.
The MMC1 mapper natively supports 256 KiB of PRG ROM, 128 KiB of CHR ROM, and 8 KiB of PRG RAM. SGROM has 8 KiB CHR RAM and up to 256 KiB of SUROM; there is no space for PRG RAM. SNROM additionally has 8 KiB PRG RAM and, with a couple resistors and diodes, can battery-back this PRG RAM; this game was used in the cheap,[5] forgettable NES game Ultima: Exodus. SUROM is SNROM with one of the CHR ROM addressing lines repurposed to control PRG RAM, but this board was used only in the fairly expensive games Dragon Warrior III and Dragon Warrior IV. Fortunately, it is straightforward to rewire SNROM into SUROM: solder one wire from CHR A16 on the mapper to PRG A18 on the PRG ROM. But count on having to replace the CR2032 lithium battery, as it has been 20 years since the NES's commercial era, and the 5-year warranty on the battery will have run out.
A password is an encrypted magic cookie given to the player at the end of a play session, which the player can enter at the start of the next play session to continue from approximately where he left off. It requires no battery nor even PRG RAM, so it will work even with an SGROM board rewired to switch PRG like SUROM.
An 8-character password can save a 32-bit payload and an 8-bit check. I have a demo for this, and I've done a breakdown of what can fit into 32 bits. A 16-character password can save a 64- to 72-bit payload and a potentially larger check. I don't have a demo for this, and as of August 2010, I don't yet feel like designing one because writing down and then reentering more than 8 characters is a pain.
If we go with a 29F040 flash chip for program storage, it'd be possible to reserve one of the chip's eight 64 KiB sectors for saved games and one for wear leveling. But then that would limit the space available for the photo albums. Small-sector flash, such as the GLS29SF040, has smaller (4096 byte) sectors, and saved games would need only about four of them: two for the saved game data and two to manage the log-structured file system.
Categories: DX Town, Video game sketches