How to communicate technical concepts to players?

[Taehl]

Is anyone familiar with the "hidden worlds" in the original Metroid (for the NES)? They were bizarre, somewhat glitchy areas which could be reached by exploiting bugs to escape the map in certain areas. And they were huge. Far larger than the entire "real" game world. How did they fit hundreds and hundreds of extra rooms into a humble NES cartridge? The answer is, they didn't. The hidden worlds were the result of Metroid's map reader overflowing / underflowing / generally pointing at other data in the ROM, and the map reader was stable enough to not crash, but instead mis-interpreted whatever data it landed on as if it were a map. If this fascinates you (as it does me), you can get more info here and here.

Anyway. Researching that, I had an idea for a game, where that sort of thing would actually be one of the game's mechanics. The major hurdle I'm seeing, though, is how do you get the player to understand something so technical? As far as most game-players know, the map is just a big picture.

My best idea so far would be to make the background of the game a simple hex viewer which followed the player's coordinates as they moved through the game's memory. They could see the data scroll as they moved around, or change when they interacted with the "map". But I don't think this is good enough. I can't help but think that most players would give one look at the cryptic numbers and promptly ignore it.

Does anyone have any ideas about how a game could get a regular player to understand such inner workings of games?

[Robin]

Unless you're actually making an educational game, I'd say don't bother. Few players will want to know about all those things, and those that want to probably already do.

[Taehl]

Okay... Failing that (not preferable), do you think a player could appreciate something like "Every time I go out of the level, I make the game get more screwed up. I can leave whenever I want, but it will have consequences"? Would most people find that interesting?

[SoggyWaffles]

the more i learn about you game the more it fascinates me. You could explain it as living road map of sorts that only has a small part filled out, and once you leave that area of that map it tries to fill in the new space with areas you've already been to. So, you can find your location on the map by your coordinates, but finding your location from land marks will be impossible, cause they don't exist in any real sense. They are just the maps attempt to fill in the empty spaces. Am I at least tracking with your idea?

[Jasoco]

I'm fascinated with how these old NES games worked. In games like Zelda and Metroid, the entire world simply contained a grid of ID's and there was a set of "screens" that each had an ID that the map grid would point to. Which is why a lot of the time rooms looked the same. They simply held different "enemy and object" sets or used different tile sets or color palettes to make the room different. Was a way to save room in the memory grid. In Zelda, all the dungeon maps for each quest were put together like a puzzle meaning hypothetically if you were able to go through an outer wall in one dungeon, you might end up in another. They compressed all the rooms and maps as best they could because RAM was expensive back then. Metroid had a huge map but only used a fairly smaller portion of it. Mainly to make it seem more like caves. No reason to compress everything together. The Löve equivalent would be a two-dimensional table with a set of values for each room and each enemy set and each color palette and tile set to use for it as well as other data. Of course, back then this was required. Now we can use whatever space we want and just make the maps more detailed.

Remember the Minus World in SMB? Because of the overflow and lack of correctly set variables, if you entered a warp pipe in 1-2 before it was able to activate the warp itself, you got transported to a broken 2-2. I always assumed that it simply added 1 to the world but kept the level number the same. But some other variables were not set right so it didn't know where you were supposed to actually be so you were fed an infinitely looping 2-2 water world.

Of course I've been fascinated with it since Nintendo Power had an article about how the NES' CPU and PPU worked. That stuff sticks with you.

[Taehl]

Jasoco, I'm glad to hear that I'm not the only one fascinated by this stuff. It's like this thrilling nexus of programming, creation, and entropy. I don't know about you, but I actually find the result kind of terrifying. Which may be part of why I'm so fascinated with it (I love horror). Some of the most frightening, scarring moments I've ever had in games are from when they broke ever so slightly.

Am I at least tracking with your idea?

Exactly. And I have two very different ways I can take that idea. One way is Underlife, where the filling-in is caused by what I call the "Entropy", a force which counteracts your building (increasing order) by scrambling and/or spewing more area (thus decreasing order (which is where it gets its name)). The Entropy would be portrayed as an unfeeling, uncaring force which may or may not be a manifestation of the player's own feelings of apathy/futility.

The other way is a new idea I had (let's call it "Nesrom" (this thread was meant slightly more for it)) where the filling-in is caused by the player directly by their act of leaving the level and exploring / interacting with other parts of the game's data (which is interpreted as level data). So say they went left too far, causing a pointer underflow and going "down" in memory (towards 0x0000), where they find (for example) the game's graphic data. By messing around there, they'd start corrupting the game's graphics. The NPC the player can talk to will blame them for corrupting the world by abusing their power. And so on...

[Rad3k]

Your ideas remind me of two games I used to play on C64.

First one, Exile (one of the greatest games of its time, and for me personally, of all times), had a huge and diverse world. Because of RAM constraint, most of the terrain was generated on the fly using pseudorandom generator with fixed seed. I think that pseudorandom world generation gives very interesting possibilities - you can make the game "remember" only the changes that player makes to the world, and generate everything else from seed. This way you could have really huge (virtually infinite) worlds, and not have any memory or disk space issues.

In the second game, Chipwar, you flew a tiny "spacecraft" inside C64 computer. You had to wipe some virus that was corrupting the computer's integrated circuits. You had to land on each one of them and fix the broken schematic. If you did something wrong then, depending on which circuit it was, you could corrupt the game's graphics, sound, or make controls behave in weird ways, so it seemed like you're actually tinkering with your computer's hardware.

[Taehl]

Rad3K, I think you'd be very interested in the upcoming Introversion game called Subversion. Scroll down to the earlier entries, when they're talking about the city generation. In short, they use techniques like Exile did, only far more advanced.

[Rad3k]

Oh man, it looks so awesome! A really ambitious project, I'd love to play it when it's out. Thanks for pointing me to it

A bit off-topic - one quote from the development blog got me:

I'm overthinking everything, always looking ahead to situations that won't become problems for months, trying to design and implement everything correctly first time. This is usually a bad idea.

That's exactly like me... Sometimes it's so hard for me to get things done because of it. But ultimately I'll overcome this and will make really awesome games

[ikarus]

Just come up with a story that you're stuck inside a computer or something and that you must get out while exploring the actual code world that lives inside the computer. Just abstract the details, make it kinda tron-ish. Sounds awesome by the way!