nesdev.org

If I wanted to program a game for both, the NES and the classic Game Boy, how much of the code could I use for both?

For example, I assume accessing the PPU works differently in both consoles. But is the access similar enough so that I could just declare a sub routine for it and implement both versions in different source files and link them accordingly, so that the outer code still remains the same? Or are the systems so different that the whole structure and of the source code would be totally different?

By the way, is there a real game that plays exactly (or almost exactly) the same on NES and Game Boy? With the same graphics (only in black and white and a smaller visual window on the Game Boy) and the same game logic?

Shared game logic and separate hardware drivers is a useful pattern, and it would work on 32-bit computers, most of which can run compiled C code efficiently. It would also work for the NES and Atari Lynx, or the NES and TurboGrafx-16, because they're all based on 6502 family CPUs. But the NES CPU and the Game Boy CPU (an 8080 derivative) have drastically different assembly languages. Imagine one computer that you can program only in Perl, and another that you can program only in Python. Or one C and the other Pascal. Or one Java and the other VB.NET. The closest you could probably get is to write the game logic in C, compile it with cc65 for the NES, and compile it with some Game Boy C compiler.

sdcc's gbz80 target seems reasonably functional, and I've encountered several projects that use it.
C is often half-jokingly-half-seriously referred to as a cross-platform assembler.

As far as I can tell, Hello Kitty World on the Famicom is a (partly or wholly?) recompiled version of Balloon Kid on the GB. The 6502 code for HKW is so strange, copying variables from RAM to arrays in ZP, then working on them from there before copying back, that I suspect a machine did the retranslation.

But anyway, the NES and GB use such different CPU architectures that you can't feasibly share any code between them.

Then it might just work for something on the scale of, say, Zooming Secretary (an NES game made with cc65).

lidnariq wrote:sdcc's gbz80 target seems reasonably functional, and I've encountered several projects that use it.

AFAIK, when you program in C for such limited hardware using obscure compilers the code ends up not being generic enough to be run through different compiler... So even though there's a GBZ80 C compiler and a 6502 C compiler, I doubt you'd be able to share much code.

If the game logic is simple enough that it doesn't take a huge amount of CPU time, you might have better luck with a tool that automatically converts the assembly code of one CPU to the other, like appears to be the case with the Hello Kitty game that has been mentioned, with the parts that deal with video, audio and input registers being completely rewritten (as long as you have respected the lowest common denominator of hardware features when designing the game).

I'm not aware of any games that are identical on the NES and on the GB (I too would love to see examples of this!)... Most of the time games are reprogrammed from the ground up by different teams I guess. Also, it seems that GB games are always slower than their console counterparts, which is probably intentional and has to do with the blurry LCD, so programmers were actually avoiding making the games identical.

Bugs Bunny Crazy Castle is very similar from NES to GB versions. I think the levels are redesigned on the GB to fit the screen, but the gameplay, music, and sprites are about as same as they can be for the most part.

Bugs Bunny Crazy Castle looks like the typical port to me, I can't see anything that's 1:1 between both versions. Sure, it's basically the same game from the point of view of the player, but I can't really see anything that has been directly reused from one version to the other, from a technical point of view. The physics (or should I say "object movement", since there's hardly any physics?) is completely different... look at how smoothly Sylvester moves on the NES compared to the GB, for example. The sprite style is radically different too, on the GB they have cartoon-like outlines.

What about "Star Wars"? I'll have to check again, but as far as I remember, they are very similar.

DRW wrote:But is the access similar enough so that I could just declare a sub routine for it and implement both versions in different source files and link them accordingly, so that the outer code still remains the same? Or are the systems so different that the whole structure and of the source code would be totally different?

GB and NES use entirely different CPUs, so in case of writting in assembly langauge (the only option for action intense games) outer code simply can't be the same. And there is no C compiler that supports both CPUs as targets. Different compilers means that no real linking is possible. If game logic C code is well separated from the HW, it could be used in two versions of the game, but the whole enviroment between versions will be different, two compilers setup, two toolchains, etc.

Shiru wrote:If game logic C code is well separated from the HW, it could be used in two versions of the game, but the whole enviroment between versions will be different, two compilers setup, two toolchains, etc.

In other words, how cross-platform PC development worked before MinGW was mature.

DRW wrote:What about "Star Wars"? I'll have to check again, but as far as I remember, they are very similar.

They're just making the same game as far as the game design documents on both platforms and sharing art resources. They may play very similar but they share no code, only the game design.

Maybe questing for a cross-compiler isn't the answer.

Probably need to write system specific game engines that can take in assets and game event scripting. Something akin to Dezaemon or RPG School.

A script interpreter is how LucasArts built Maniac Mansion. But a script interpreter is even slower than C. It'll work fine for turn-based games and simplistic action games, but I don't see how it'd work for anything like Recca.

In many situations it is a better choice to just write your game for one platform, then port when it's finished.

Cross platform development has some advantages, especially if your program is already deployed and in use so you're making ongoing revisions. It's very good for verifying correctness, since errors often manifest differently on various platforms.

It has many disadvantages though. The biggest one is that it slows down all development, as every thing you implement now requires extra work to build/test/maintain on the various platforms. Even if you plan to compile the same code to multiple targets, the extra testing, feedback, and hardware constraints to work against really rack up development time.

The route I would take is to know your target platforms well, and keep them in mind as you write your code, but write for one platform at a time. Once the program is finished, if you did your homework porting should be straightforward. As an advantage at this point you've already defined the scope and function of the program and are no longer making design decisions about it, which hugely streamlines the process of building it.

Consider the conditions for a successful project. If you are doing parallel development of multiple platforms, to succeed you get all platforms or none. If you do them in series, each platform is its own separate success. Just getting to the finish line on one platform is difficult enough; if you add the inertia of trying to do 2 or 3 platforms at once you decrease the chances you'll ever get there.

There are situations where I think parallel multiplatform development is appropriate, but for games I don't think it is, usually. In my professional career working on console games, the developer generally needs a parallel PC port for tool/editing/testing purposes, but the publisher will often push for multiple consoles in parallel. I've seen successful parallel multiplatform releases, but I've also seen a few multiplatform failures. It's a lot less of a problem if you're not working on engine tech at all (e.g. if you're using Unreal or something where the engine author has tried to provide you a ready-made multiplatform API) but when you're developing it yourself it's adds a whole lot of extra risk to the project.