This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Underrepresented genres

Underrepresented genres
by on (#53748)
We've had a few topics before about designing games around the NES's limitations.[1][2] I've written an essay on the wiki speculating that these might be the reason why a few video game genres didn't become popular earlier. Agree or disagree? Am I forgetting any genres that arose after 1991?

by on (#53749)
Miracle Piano Teaching System had rhythm games (Robo Man). It's just not emulated yet.

by on (#53752)
I think there is more to say about the "Simulation" genre. The first thing we think a game that simulates a big world needs is a lot of RAM. A while ago we discussed platform games with lots of destructible blocks, how they'd need a lot of RAM. I believe we agreed that there was another option: patching the original map. Not as good as allowing everything to change, but allows a decent number of changes.

Say you want to make a "The Sims" type of game on the NES. It starts up with pre-made neighborhoods, houses, people and such. This is all stored in ROM. The typical player will never change *all* of it. They will design a number of new characters, new houses, will play with the lives of some of the existing characters and remodel a few existing houses. The changes, by themselves, might fit the constrained RAM.

Although not as versatile as having everything in RAM, the original state could be stored in ROM and whatever changes are made are stored in RAM. If we can predict how much of the original state is likely to change, it might be possible to dedicate a fixed amount of RAM for the changes.

Of course this isn't the optimal way to do it, but makes it partially possible, which is better than not possible at all. Atypical players might bump into some restrictions, but even the original "The Sims" has its restrictions (number of floors a house can have, number of Sims living in the same house, and so on).

by on (#53756)
tokumaru wrote:
A while ago we discussed platform games with lots of destructible blocks, how they'd need a lot of RAM. I believe we agreed that there was another option: patching the original map.

Yup: that's where we figured out the technique of a destruction buffer with one bit per column.

Quote:
Say you want to make a "The Sims" type of game on the NES. It starts up with pre-made neighborhoods, houses, people and such. This is all stored in ROM. The typical player will never change *all* of it.

I also mentioned SimCity, which we agreed was probably canceled for the same reason as what came to be called Earthbound Beginnings: replication cost. The Micropolis engine of SimCity definitely needs a 120x100-cell array to hold the current state of the city, but I'm not familiar enough with the engine to know how many bits wide each cell is.

Quote:
They will design a number of new characters

The hair, clothes, etc. need to get rendered onto the character. Without 3D hardware, each piece needs to be stored in all possible directions. There also aren't enough colors in a sprite for outline, hair, clothes, and skin to have separate colors, but that has workarounds.

Quote:
new houses

How much data would a house, with its room layout and all its furniture, take?

I was also thinking about Animal Crossing, where trash can be left anywhere on the map. I can think of a few optimizations, based on only allowing 32 items per acre or room and RLEing each room down from 512 or 1024 bytes down to 96, but as I explain on my more detailed analysis, there are still a lot of things that I can't figure out how to cut.

by on (#53758)
tepples wrote:
The hair, clothes, etc. need to get rendered onto the character. Without 3D hardware, each piece needs to be stored in all possible directions. There also aren't enough colors in a sprite for outline, hair, clothes, and skin to have separate colors, but that has workarounds.

Yeah, there will obviously be limitations. In the best case scenario the game would offer different hairstyles, faces and bodies (divided in top and bottom?), all previously rendered in all directions, and they'd be combined in real time. If the sprites are really small you could possibly stack the different parts as different sprites (and not generate patterns dynamically), allowing for more colors per character (although the game would probably have to use a fixed set of palettes and the individual pieces would have to conform to one of them). Like you said, there are workarounds.

Quote:
How much data would a house, with its room layout and all its furniture, take?

Not sure. A room could be defined by it's dimensions and floor and wall textures. Furniture and objects could be a list of ID's, coordinates and parameters, like regular game objects are. Doesn't seem like that would expand to more than a level map in a more conventional game. There would probably be a limit on how many houses the player can create depending on how complex they are.

I don't think you can fully port the game, of course not, but you could certainly capture a good deal of it's atmosphere and essence of gameplay, IMO.

Quote:
I was also thinking about Animal Crossing

I never played this game so I don't really know what's the deal with it, but from reading the first paragraph of the page you linked to I have to say that there certainly is a limit to the NES and there are things it will never do. But I strongly believe that there is still a lot to be explored before we reach that limit. By that I mean that there are a lot of new game ideas that appeared after the NES "died" that could be adapted to work on it, but weren't just because many assume that "if it wasn't done back then, it's probably not possible". Will we ever explore all that potential? I don't know, depends on whether we can think outside of the box.

by on (#53761)
OK, I read your article about Animal crossing. IMO, when trying to convert a game to a system with obviously less resources than the the one where the original runs, analyzing the technicalities of the original is a bad place to start.

For example, I'm trying to mimic as closely as possible the feel of a Mega Drive/Genesis Sonic game on the NES (meaning I'd like to do a better job than was done for the Master System). You know I'm not looking at the 68000 disassemblies and trying to do the exact same thing with the 6502. I'm studying how the game plays, how it behaves under certain conditions, and redesigning it from the ground up as a completely new game using a completely different architecture.

I ended up looking at how some things were done in the originals out of curiosity, and although some of it resembles my own solutions to certain problems, much of it was done in a wasteful way, because the resources allowed it. Many times, if you think hard enough, you can find a less wasteful way to solve the same problem. Professional developers hardly go through all this trouble though, as they are always on a tight schedule and can't waste all the time needed to perfect something. They are lucky if they manage to ship a game that's not in beta state (because that's what seems to happen nowadays, when a game isn't ready in time they ship it anyway).

So, Animal crossing. I'm totally skipping the PPU issues (graphics can always be dumbed down, look at how the Atari 2600 manages to represent detailed arcade games with flickering colored squares on a black background that are still big hits) and going straight to the storage issues.

You mentioned a lot of figures and how each of one thing occupies so many bytes and how many of them there are and so on, but you never mentioned compression. Does the original game use any? I'm sure the 244-character letters would take much less than 11712 bytes if properly compressed. Also, you have to make sacrifices if you want to see the game running on the NES. Can't you have smaller letters or carry less of them?

You mentioned maps with two layers. Is the switching between the two layers so present in the whole map that you really need the second layer? Can't you invent a special way to overlay smaller maps only over the areas that actually need a second layer?

Anyway, I can't say much about this because I really don't know the game. But if I did, and had the desire to see something similar running on the NES, I'd not be looking at how it was done, but I would be thinking about how I would do it, just from what I know from playing it. Features will be lost? Certainly! Stick to what you like most and ditch/cut down what isn't so important to you.

by on (#53775)
tokumaru wrote:
You mentioned a lot of figures and how each of one thing occupies so many bytes and how many of them there are and so on, but you never mentioned compression.

I did mention compression. For example, each acre and each room can be RLE'd down, but we can't set a cap on the size of each room unless we set a cap on the number of items in the room. The "list of ID's, coordinates and parameters" for each room would take 96 bytes, comprising 32 (x:4, y:4, id:16) tuples. Using this same data format outside might leave players scratching their heads as to why things disappear when dropped outside. I could assign shorter codes to more common items to be found outside (tree, rock, fruit). But then getting hit in Sonic for Sega Master System or Somari for NES already spits fewer rings than in the Sonic games for Genesis.

Quote:
Does the original game use any?

The GameCube and DS games use an 8-bit character encoding, which could be considered compression compared to the UTF-16 representation that games for some bigger systems use. LZ doesn't work on such small strings because there isn't repetition. Huffman with a static table might work.

Quote:
Can't you have smaller letters

To an extent. The GameCube and DS games cap the length of each letter with a meter represented as "ink". I'll revise my AC analysis to cut the amount of "ink", especially considering Huffman coding.

Quote:
or carry less of them?

That could be cut in half, but each of 8 neighbors carries only one.

Quote:
You mentioned maps with two layers. Is the switching between the two layers so present in the whole map that you really need the second layer?

Not really, It just allows, say, a table lamp on top of an end table.

Quote:
Can't you invent a special way to overlay smaller maps only over the areas that actually need a second layer?

Only the indoor areas need a second layer, and I'm taking them down to 96 bytes anyway with the RLE.

Quote:
I'd not be looking at how it was done, but I would be thinking about how I would do it, just from what I know from playing it. Features will be lost? Certainly!

I'm trying to analyze which features would be the first on the cutting room floor.

On a whim, I tried your approach of specifically defining things that I'm sure I want to keep, and we're still over 8192 bytes.

by on (#53783)
tepples wrote:
On a whim, I tried your approach of specifically defining things that I'm sure I want to keep, and we're still over 8192 bytes.

Well, I just suggested that looking at the problem differently could make things look more possible, not that you could do it for sure. At least you are trying.

In the end you might come to the conclusion that you will have too cut so much that you will not consider the result enjoyable, and just give up on this conversion. But another programmer that also likes this game might favor other aspects of it, or even find a very different technical approach to implementing the difficult things than you and succeed in creating his version of the game, one that is enjoyable at least to him.

Anyway, If it really is a dream of yours to see Animal Crossing on the NES, just keep thinking about it. You don't have to start coding it right now, just keep thinking of all the problems and slowly the solutions will come. I usually find solutions to my programming problems when taking showers or sleeping. I've had several programming breakthroughs that way. Just take notes whenever something new comes to your mind and someday you might realize you have enough to code the damn thing. Just don't deem it impossible and forget about it right away, because then it will never happen for sure. If you don't ever find enough solutions to make it possible, tough luck, at least you tried and didn't give up on it.

by on (#53787)
Even with bit-packed data, it's still possible to compress it if there are very long strings of ones or zeroes.

by on (#53788)
Quote:
We've had a few topics before about designing games around the NES's limitations.[1][2] I've written an essay on the wiki speculating that these might be the reason why a few video game genres didn't become popular earlier. Agree or disagree?

I apologize for sounding harsh/in a bad mood, but all the energy spend to compile this long article (and long thread) about what is not possible to do on the NES would have been better spended in making something that is possible on it.

by on (#53789)
tokumaru wrote:
much of [a commercial 16-bit game] was done in a wasteful way, because the resources allowed it.

And a lot of the fat could be cut, as seen in HKO games. I clarified this in the article.

Quote:
I'm totally skipping the PPU issues (graphics can always be dumbed down

That's fine. All that part talks about is the specific kind of dumbing down that will happen, as a way of preparing the reader for dropping one-fourth of the save at once.

Quote:
But another programmer that also likes this game might favor other aspects of it, or even find a very different technical approach to implementing the difficult things than you and succeed in creating his version of the game

And anyone who cares can clarify such "a very different technical approach" on the talk page.

Bregalad: Don't worry; I'm working on that too, even if I have to camp out away from other people for a while. I'm describing the consequences of memory and other limitations so that other programmers know what they have to work with and can more easily concentrate on coming up with "something that is possible on it".

by on (#53794)
tepples wrote:
All that part talks about is the specific kind of dumbing down that will happen

I read it. When I said I'd skip it I meant I wouldn't comment on it, but I read it. I feel that the graphical limits of the NES are generally more well known, and I thought it was pointless to talk about it specifically since I don't even know what the original looks like.

Quote:
And anyone who cares can clarify such "a very different technical approach" on the talk page.

Sure, what are the odds of another competent programmer that likes to play Animal Crossing showing up? =) Seriously though, that's the point of a wiki, contribution. My english writing skills suck, I have a very hard time getting a point across, so I can't really write technical stuff without making a mess.

Quote:
I'm describing the consequences of memory and other limitations so that other programmers know what they have to work with and can more easily concentrate on coming up with "something that is possible on it".

I'm not here to tell you what to do with your time, specially since we are here because we like to interact with people that like the same stuff we do, even if that isn't always productive (if it were like Bregalad said, we should all be coding instead of commenting on stuff here). So writing or reading an article about converting a game to the NES might qualify as "fun", and you are certainly exercising you brain thinking of all these aspects that are involved in converting the game, possibly preparing yourself to do it some day.

However, I see very little instructional value in an article like this. If you have to tell a person what's possible and what's not, that person certainly doesn't have the technical knowledge to pull it off, so there is no point in telling them it's possible.

Before taking on an ambitious project you must have a very clear picture of how you're going to do the key parts of this project, as well as decent knowledge about the target platform and some experience with it, enough to conclude on your own if it's doable or not.

by on (#53811)
tepples wrote:
And anyone who cares can clarify such "a very different technical approach" on the talk page.

It's not much, but I thought of a few space-saving ideas.
The Sims
by on (#53873)
(Seeing as this is my first post, perhaps a brief introduction is in order. I'm Smallhacker, a CS student at KTH in Stockholm, Sweden. While I'm primarily a SNES hacker, I have a certain interest in the NES homebrew scene, even though I'm too lazy to learn all the intricacies of the NES to actually code for it myself. And with that out of the way, let's move onto the actual post.)

As I read the parts of the topic discussing the feasibility of a NES port of The Sims, as well as the wiki article simply dismissing the idea, I decided to look into how possible it is to do from a SRAM memory standpoint. So, forgive me if I hijack the topic for a moment as I analyze the SRAM memory requirements. From what I've understood, the largest "normal" SRAM memory available is 8KB.

Unless I've forgotten something, there are only two main things to store: Houses (design and some misc. settings) and the characters. Through trial and error, I found a reasonable limit of six houses, each with up to 4 people for a total of 24 people in the town. Additional "Sims 1-style" NPCs (i.e. with limited or no interactions and the inability to form relationships with them) could be added to make the town seem slightly more alive.

Let's start with the house. A reasonable size I found is 16x16 tiles. (Let's assume that one in-game tile is 16x16 pixels large.) It should be large enough for most houses. For the sake of simplicity, each house has a single floor. Each tile uses 16 bits: 10 bits to determine the object, 4 bits for misc. settings (including orientation of the object) and 2 bits to tell if there's a wall at the north/west edge of the tile. (Which means that one can't build walls on two of the lot boundaries, so let's disallow that on the other two as well. The Sims did the same thing anyway.) Six houses with 16x16 tiles with 2 bytes each, that's 3KB.

Now, the characters are a bit more complicated, as there's so much to store. To increase readability, I'll just list each piece of data.
* Name - 40 bits (8 letters, 5 bits each)
* Alive - 1 bit
* Gender - 1 bit
* Age - 2 bits (Let's keep it simple and stick to the Baby-Kid-Adult formula of The Sims 1)
* Job - 16 bits (Career: 4 bits, Level: 4 bits, Performance: 8 bits)
* Skills - 120 bits (10 skills (IIRC), each with 4 bits of level and 8 bits of progress)
* Needs - 48 bits (8 needs (IIRC), each 6 bits big)
* Personality - 30 bits (10 aspects (IIRC), each 3 bits big)
* Relationships - 384 bits (24 people with 16 bits each, which should be enough to encode any relationship)
* Location - 192 bits (6 houses (as one could theoretically be visiting all houses at the same time, like in The Sims 1). 1 bit to determine if the person is actually present, 16 bits for X/Y coordinates, 2 bits for direction and 13 bits for the current action (including "time left before action ends"), for a total of 32 bits per house)
* Appearance - ? bits (Not sure, but considering it's the NES, it won't be too big)
* Unused - 190 bits

The final 190 bits are partially to have some margin for anything I forgot to add, but officially to pad the data to 1024 bits (128 bytes) per person. 128 bytes and 24 people, that's 3KB.

Now, we also need some settings for the houses (time, day, money, family name, etc). Let's say 128 bytes per house. That's a total of 768 bytes.

So, we have 3KB + 768 bytes for houses and 3KB for people. That leaves 1.25KB of the SRAM unused. One also has to store the NPCs for each house, but they only require a fraction of what normal characters need.

The conclusion is that unless there's something HUGE I forgot about, there's more than enough SRAM space for a decent NES port of The Sims.

(And now, I'll probably lurk for another 6 months and then come back with another wall of text.)