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.
tepples wrote:
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.
Okay, maybe not a full fledged runtime engine for scripts. How about just data with attributes for movement patterns, hits needed to kill, etc..? I'm sure Dezaemon must do something similar.
rainwarrior wrote:
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.
So why does this parallel PC port so often end up not published? A game comes out for Xbox 360 and PlayStation 3 but not PC, even though PC supports a lot of the same DirectX APIs as Xbox 360.
Super Mario DX, Ghosts & Goblins (dual compatible), and Crystalis for the GBC were all based on NES games.
There used to be an internal Nintendo doc here:
http://web.archive.org/web/201210082358 ... g/library/which discussed the difficulties they had converting Super Mario Bros for the GBC.
I think the doc also compared the op code similarities and sound functions between the two systems.
Kid Icarus on the original GB may be similar to the NES game, but other than that I don't know of many original black & white GB games that were similar to NES counterparts.
GB Kid Icarus (a sequel, in fact) is not more similar to the NES game than games like Duck Tales or Mega Man. I.e. it is similar in design and gameplay, reuses the same graphics, but has many differences, like less levels, different level maps, etc. Kid Icarus has the maze levels that aren't present in NES version.
As long as you're aware of what your subroutines are doing in terms of logic and calculations, you can reimplement them for any processor you want, without having to literally translate every single opcode from one CPU to the other. I don't think there's any way to escape the need to manually write the code for both platforms.
Keep in mind, the NES/GB were in a time before code portability was a concern for most people. (Hell, even now, trying to set up a cross-compiler is still excessively complicated.
)
tepples wrote:
So why does this parallel PC port so often end up not published? A game comes out for Xbox 360 and PlayStation 3 but not PC, even though PC supports a lot of the same DirectX APIs as Xbox 360.
That's the publisher's call. A lot of publishers are relatively uninterested in PC releases because of the perceived piracy risk.
If the publisher is only interested in console release, and does not contract a PC port with the developer, the developer might create a PC version for their own internal needs anyway. However, because they aren't being paid for it, they never put in the work to make it publish-ready, and would never deliver it to the publisher for release.
If the console release is successful, the publisher may decide to have a delayed PC release once console sales of the title have dropped off (supposedly mitigating the impact of PC piracy on console sales). I think this scenario might be the most common one for multiplatform titles.
There are of course platform exclusivity deals made here and there, too, but if something came out on 360 and PS3 obviously that wasn't the case. This is kind of outside the scope of multiplatform development discussion.
Also, sometimes a multiplatform release gets aborted before all platforms are finished. A game I worked on had a PC and 360 release, but no PS3 release, even though we developed for all three platforms. The publisher cared most about the 360 release and it passed official testing first. The PC version wasn't subject to official scrutiny so it got very quickly wrapped up and released. The PS3 version just had to pass official testing but it never got submitted; the publisher decided to wait and see how the 360 sales went before they bothered, and apparently they were so disappointed with that they just dropped it altogether, even though the game was all but ready to ship on PS3.
At any rate, I have yet to be involved in any professional game development that didn't have a working PC version for at least internal use. This statement applies to TV consoles as well as handhelds and cell phones. (I'm sure there are developers/projects out there who don't do this but I haven't worked with them yet, and I think they're in the minority.)
I was hoping to be able to program a game for both consoles simultaneously (i.e. not just port it) with the platform-specific stuff of course written separately, but where the game logic is exactly the same, so that you really have one and the same game for NES and Game Boy and every change to the contents is reflected in both. But it seems like the Game Boy is really too different from the NES to implement this.
Couldn't you just use C with the system specific stuff parceled out?
Also, what's wrong with writing 2 different hardware specific game engines that both use mostly the same game data?
slobu wrote:
Couldn't you just use C with the system specific stuff parceled out?
The problem is that AFAIK there isn't a C compiler that targets both the 6502 and the GBZ80, so the peculiarities of each compiler would most likely prevent you from sharing the same source files.
Quote:
Also, what's wrong with writing 2 different hardware specific game engines that both use mostly the same game data?
That seems like the way to go, but even then each CPU has a different way of optimally addressing data, so you might benefit from reorganizing the data into formats that best fit each CPU as opposed to simply .incbin'ing the raw data.
psc wrote:
Super Mario DX, Ghosts & Goblins (dual compatible), and Crystalis for the GBC were all based on NES games.
There used to be an internal Nintendo doc here:
http://web.archive.org/web/201210082358 ... g/library/which discussed the difficulties they had converting Super Mario Bros for the GBC.
I think the doc also compared the op code similarities and sound functions between the two systems.
Kid Icarus on the original GB may be similar to the NES game, but other than that I don't know of many original black & white GB games that were similar to NES counterparts.
Does any body have this doc? I'd really like to read it...
mikejmoffitt wrote:
psc wrote:
Super Mario DX, Ghosts & Goblins (dual compatible), and Crystalis for the GBC were all based on NES games.
There used to be an internal Nintendo doc here:
http://web.archive.org/web/201210082358 ... g/library/which discussed the difficulties they had converting Super Mario Bros for the GBC.
I think the doc also compared the op code similarities and sound functions between the two systems.
Kid Icarus on the original GB may be similar to the NES game, but other than that I don't know of many original black & white GB games that were similar to NES counterparts.
Does any body have this doc? I'd really like to read it...
I do have it, But someone might have a hard time unless the admins and moderators allow me,
Plus, Copyright is an issue here if I give it, Nintendo might sue me if I'm not careful, It is a leaked document after all.