Hacker News Reader

Comment by segmondy | Hacker News Reader

This is really neat, I wonder if there was a gameboy studio that really used such a tool to churn out gameboy games.

Not likely. Engines were not reused back then, each game was coded from scratch. We know this because there are few similarities between disassembles, even of games from the same company or even the same series that look and play similarly.

Companies would roll their own assemblers and asset tools, but that is only known anecdotally and sometimes from pictures, and the majority of that software is lost to time.

A lot of people are really nostalgic about development back then but I'm honestly happy to have entered the industry at a point where excellent tools are readily available.

Apart from engines, the evolution of graphics debuggers such as RenderDoc, NSight, and PIX over the last ten years has been amazing.

I can't speak for modern gamedev, but as far as the classic console homebrew scene goes, most popular systems have extremely accurate emulators with step-thru debuggers that make writing and testing code exponentially easier. Testing on real hardware is easier too, aided by flash-carts with micro-SD cards. I'd imagine devs back then would have killed for such luxuries.

From what I've seen they at least had hardware which allowed for memory dumps and step debugging. But yes, modern tools for emulation and development targeting older consoles are really impressive.

A lot of games have built-in memory dump views that's been disabled in the release (but you can enable them by flipping a bit), so at least that implies to me that memory dumps from the hardware wasn't universal.

If you look at the information available regarding the SNES dev kits[0] you'll see the one intended for programmers included memory inspection and breakpoints. However, from what I've heard, a lot of SNES developers didn't actually have access to these tools.

I should probably ask some colleagues who I knew developed for the SNES back then, I'm sure they can shed some light on what it was like.

[0] https://www.retroreversing.com/super-famicom-snes-developmen...

From the documentaries of most devs it seems they usually had some sort of set of studio tools. Then each game was coded from scratch. There was some re-use of code between games. But not really in any sort of lib but more of a 'hey I have a function that does xyz'. Then they would use in place or rewrite to match their internals. Usually if it was the same dev you would see that a lot. But sometimes in a studio you would see some sharing of code. These days it seems most studios buy/download one of the big engines and start from there. They will also re-use an engine from game to game even if it is not what the original engine was built for. The game engines really came to the forefront when you are targeting 4 different platforms and need that abstraction away from each platforms API/hardware. If you are targeting 1 platform it may be just a matter of fill this memory region out correctly and tweak an interrupt and let the hardware do the rest. Not much for an engine to do.

>Not likely. Engines were not reused back then, each game was coded from scratch.

Eh, not so much. Metal Gear Solid -> Perfect Dark.

The advantages of a generic engine are somewhat diminished when you have to make sure your game fits on a cartridge potentially as small as 256kB. You can't really afford too much overhead given to generic functions and structures that you don't actually need for this specific game.

That early on in the industry's life it would likely not have been worth the investment in creating such an engine given the minimal return you get back from it.

The biggest GB cartridges were about 1MB if I recall them well.

Reply on news.ycombinator.com