Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Modern Vintage Gamer just released a video [0] discussing this leak in greater detail along with its expected implications.

Anyone who's curious can find the download links by backtracking through all the Pokemon Prototype General threads under the Pokemon board on 4chan.

One of the leaks that caught my attention was the source for Pokemon Blue, partially because of nostalgia and partially out of curiosity to see what an old game's codebase even looks like. The first thing that stood out to me was the project's flat folder structure, full of hundreds of files; I guess I was expecting things to be a bit more structured. The source is more readable and approachable than I expected, although I've only poked around in some of the more obvious places and definitions. I'd recommend watching The Ultimate Game Boy Talk [1] before trying to dive into any code.

[0] https://www.youtube.com/watch?v=n8G7eq0GlQs

[1] https://www.youtube.com/watch?v=HyzD8pNlpwI



I'm really excited by the Pokemon leak. The game was so large and detailed yet the resulting output so incredibly tiny. The developers implemented so many tricks to keep the size down. Now you can see what they did and how it worked. This could be really historically important.


I have zero experience in the video game industry, but I'd think that since video games get ~zero attention after they're shipped, writing maintainable code is less of a priority.

I'd be really curious to see how the Pokemon Red/Blue split was done. Is it a C precompiler flag? Build config? Actual config? Cloned repo?


In the Pokemon Blue codebase they use 2 flag variables to distinguish between the different games, these are `pokemon_type` and `pokemon_type_blue`. The name of the second flag definitely hints that it was added later in development.

These are the values for each game:

    Green:  pokemon_type=0 pokemon_type_blue=0
    Red:    pokemon_type=1 pokemon_type_blue=0
    Blue:   pokemon_type=1 pokemon_type_blue=1
The general pattern for branching between game variations looks like this across the codebase:

    ifn pokemon_type
      ifn pokemon_type_blue
        ; blue
      else
        ; red
      endif
    else
      ; green
    endif
Conditional assembly directives like `ifn` are resolved statically during assembly, so only the code between matching conditions is included as part of the output. To anyone interested in exploring this a bit more, I'd recommend reading Chapter 8 Section 13 of the DOS version of The Art of Assembly Language Programming [0], which starts on page 43 of the linked PDF.

Bonus fun-fact: In the Pokemon Yellow codebase it says `pokemon_type=1` is yellow, while `pokemon_type=0` is pink! This suggests to me that the idea of Pokemon Pink with Jigglypuff as your starter was probably being floated around but it was eventually scrapped. (The only remaining options for a pink starter pokemon with a pink evolution in the original 151 would be Clefairy and Slowpoke, neither of which are very cute.) The idea of Jigglypuff as a starter is further supported by her appearance alongside Pikachu on the roster of the original Super Smash Bros. which seems rather unexpected unless they had bigger plans for her.

[0] http://www.plantation-productions.com/Webster/www.artofasm.c...


I found some supporting evidence from bulbapedia "Clefairy was originally going to be the official mascot of Pokémon, but Pikachu was used instead due to the popularity of the anime and Pikachu's familiarity with fans".

Source: https://m.bulbapedia.bulbagarden.net/wiki/Clefairy_(Pok%C3%A...

Very cool find about the pink version!


I seem to recall watching a video somewhere, perhaps on Didyouknowgaming, that Clefairy was intended to be the Pokémon mascot before Pikachu. I could be completely wrong here, but if so that is really cool to think it may have had its own game!


Very cool, uncovering game development history via the source code.

Thanks for this!


In the old days that was probably more true than it is today, since so many games are "as a service" now with shared engines, online platforms, continual updates/patches, tons of expansions and DLC, supporting mods, etc.

The downside is that we'll never really be able to play today's games nostalgically like we can with old burned-to-ROM games.

Online multiplayer games have a shelf life of sorts that depends on the servers being available and having other people to play with. There's a few examples of community-driven projects to revive classic online multiplayer games with mixed success but it'll just never be the same thing.


After MSN Gaming Zone died in 2006, the Age of Empires II community developed a multitude of alternatives to play the game online (with a rating ladder). The one that was the most widely used up to the very recent release by MS of AoE2:DE on Steam was Voobly, which exists since 2008, although back then it was called IGZones.


Well there is always the case of iterative releases of games of a genre. So Pokemon Silver vs Pokemon Blue. It is going to based off of the original source code. So writing maintainable code is desired (from the dev at least).


That’s not my experience of modern games. There are loads of games out right now that get patches constantly, sometimes even weekly. It’s not just multiplayer games; lots of roguelikes are in constant development as well.


They’re touched much less often than most software, but even older games would occasionally share engines and stuff. Games these days often have DLC.


I might be wrong but it would make sense to me that the second gen games (Gold/Silver) would share a far bit of code from the first gen (Red/Blue/Yellow). In that sense in this case, the code did infant live longer than the release of the first game.


Incidentally, Pokemon Red and Blue were disassembled years ago:

https://github.com/pret/pokered


Maybe relevant, but Pokemon Blue is part of the American release, which came quite a while after the original Japanese release of Green (both had a red). They had to rework some things to handle English. It wouldn't surprise me if that contributed somewhat to a less ordered structure in that it's an alteration of the original.


Is the reason for the flat structure saving space? I know on older games, space is at a premium and referencing files from the root might save some bytes so maybe that's the reason due to shorter file reference names.


It was way more common to simply not attempt to organize projects in this way "BITD" - it complicates your build system because now it has to manage paths, which entangles it with the OS file system. Not every file system even has subdirectories and not every tool acknowledges or agrees upon how to use them, so depending on how antiquated their dev environment was, it may have been totally impractical.


I don't think the filenames of the source files would end up in the final ROM.


This was probably development environment limitations. You have to remember that this game was released in 96, which means it was probably developed on a command-line machine with an IDE like Turbo C.


I wouldn't be surprised. As I understood it, just translating the game into English was a problem because there's more characters to cram in the cartridge.


Or maybe it’s in part cultural. Deep nested hierarchy is not very Japanese concept.


The most shocking part of this story is still that Nintendo keeps all its code in CVS. CVS!!!


For game code written in the mid 90s I'm actually pleasantly surprized. I would have expected just a bunch of copied folders with weekly snapshots.


It wasn't Nintendo's CVS it was BroadOn's CVS. It was a third party Chinese company Nintendo allowed to produce Nintendo compatible hardware in China. They had access to a bunch of sdks and the source codes for the system to develop their hardware.


It was probably iGware's or Acer's CVS when it was hacked, if I'd have to guess.

RouteFree->BroadOn->iGWare->Acer Cloud Technology (as of 2011, now just a business unit)




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: