GB Studio: A game maker for the Game Boy | Hacker News Reader

GB Studio: A game maker for the Game Boy

gbstudio.dev

250 pointsazhenley53 comments

Game Boy and NES were my first consoles, but being an avid retro gamer in these days (hail RetroPie!) I must admit SNES and Genesis is as far back as I'm willing to go.

The 16-bit era is when consoles got really good and there are too many games from this period I'm still discovering. I could only dream about a tool like this for SNES games.

There's a lovely scene still making awesome games and cartridges for Genesis (with old tools I guess). Check out Xeno Crisis and Tanglewood.

Before the pandemic we had a small group of Nintendo fans at work who would gather each lunch to play through various NES games together and discuss what made them work or not. As a game developer who grew up with SNES it was a very nice way to experience the generation I missed.

It was a lot of fun and I hope to get back to it once we aren't all remote anymore.

Unsurprisingly, the one I liked the most was the original Zelda. Its sequel, Zelda II: Adventure of Link, is fascinatingly weird.

Wow. This is a really cool team-building and morale boosting practice, I think.

How would you take turns and decide what games to play?

The way we chose which to play was mainly through civil discussion about what we have been wanting to try or revisit as well as which games inspired or were inspired by what we played last.

As for who holds the controller: we usually took turns, switching to whomever was most eager whenever we died.

As soon as you mentioned Zelda II, I figured an overstatement about how either great or terrible it is was coming. "Fascinatingly weird" is probably the best description I've heard of this rough-around-the-edges game that I love :)

I still think the original Zelda is one of the best Zeldas. Yeah, it was the game that got me obsessed with video games as a kid (so heavy nostalgia factor there), but it's still pretty expansive as far as simple games go and the artwork is pleasing while leaving plenty of room to use your imagination.

I'll look out for Xeno Crisis and Tanglewood -- can I counter-recommend Micro Mages for the NES?

trailer: https://www.youtube.com/watch?v=VFX401vvKTQ

Pandemic opened up a world of retro gaming to me too. I’ve discovered so many great games that I never had a chance to play when I was a kid / teenager. And my current skillz in Atari 2600 SeaQuest really make my childhood scores look like child’s game! I would also agree about what you say about SNES/Genesis. Raster based games and gameplay really seemed to peak in those years. RetroPie/RetroArch shaders like ScaleFx or Xbrz by the way work miracles on some of these 16bit console titles to make them look slightly more modern (pc / gpu required, I don’t think pi has enough muscle yet).

I was learning Godot game engine the other day - It would be pretty awesome to be able to use something like that to output a SNES/Genesis game. Or old skool demo without having to learn snes etc. assembly :D

I think its interesting how there is sort of a revival of retro style games and we are now getting brand new games that look like they came out in the 90s. Games like Dusk are awesome fun but don't have all the weird quirks of running old games on a modern system.

Game Boy Classic was my first (and only) console and I actually use it quite often nowadays, usually to play Tetris in bed before sleep. I love it because it does one thing only, batteries last a looong time, games are simple but fun and challenging, it's super comfortable to use and I like looking for and buying games in physical form. The only thing I've modded in my Game Boy is the screen, I've replaced it with a modern IPS one and I absolutely recommend it to anyone who would like to use Game Boy - it takes nothing away from the "retro" feel but is sooo much easier on the eyes and games look as good as possible.

I've recently taken an interest in modding gameboys. I was planning on reselling them (at cost price) to fund the next ones, but most hardware can only be bought from US or UK. So since the Brexit, it's literally an unsustainable hobby because of all custom fees :(

Wow, I never even thought about that. Do you have any place where I can read to get started?

The Retro Future is a great YouTube channel for such things. His second channel is much more in-depth on the technical aspects.

Game Boy Classic has a lot of interesting puzzle and action puzzle games that didn't really get ported to any other platforms. Kwirk, Mole Mania (designed by Shigeru Miyamoto, even! super underrated), Amazing Penguin, Dexterity (kill enemies by flipping tiles Othello style), Catrap (one of the first games with rewind mechanics, predates Braid), Ishido, Quarth, Daedalian Opus, and Mario's Picross, which started the whole Picross line, still going on today.

If you include Game Boy Color, then you can add Hexcite (weird rules at first, but once it clicked I started loving it), Rox (drop dice, clear out everything between two matching dice), and Klustar (almost katamari-like, but with tetris blocks, very addictive).

I missed most of these the first time around, became aware of them mostly from Jeremy Parish's Game Boy Works retrospectives.

It's still on my bucket list to, one day, port my simple strategy game Proximity to either NES or Game Boy (or both). It's just a hex grid and number tiles that capture surrounding lower number tiles when placed, lots of fun, and the flash game went viral a long time ago.

Unfortunately most of these NES/GB game making software assume either platformer or adventure games, so to make my game I'll have to do a deep dive into the architecture, but that's okay, assuming I can find the time to do it. Still need to finish my Pico-8 port, first though, which is close enough I really should probably just release it. And I'm working on the third game right now, which I'm planning to add some fun Twitch support to, so hundreds of viewers can play the game along with the streamer.

It's great for making "Pokemon style" top down RPG's, if that's what you want to make, but as of the latest release you are fairly locked into that style of game.

The tools feel very nice to use, and the developer is still actively adding features. I'm excited to see where it progresses.

The new 2.0 (which is currently in beta), adds support for several new game types, including side scrollers (with parallax), platformers, and point and click. It also has support for ejecting the game engine, so you can easily customize it even further

You mean you can actually code then? Do you know what language the engine is in? Is modifying it difficult?

I have contributed a bit to the 1.0 branch. The engine is written in C utilizing GBDK. It's not hard, but it has a few caveats.

I worry about things like this trivialising the difficulty of the past. Something like this is more like modding a game than making a new game in terms of tech. It makes it seem like it's really easy to make a Game Boy game, when the creators of this put in heaps of work (more than just making a game) into making a tool that gives people the ability to reskin their base game.

Homebrew that's designed to run in an emulator isn't the same as running on actual hardware either. In the past people had to think about things like how to fit a 20hr RPG into less than 1MB. Now you could make tile sheets for each room because the game can be much shorter. Other things like how art assets can look good on a modern LCD monitor when on an actual Game Boy they would be a blurry mess also contribute to a misunderstanding of retro games.

People already have an unrealistic view of "retro" games because in GameMaker or Unity it's easy to have 1000s of sprites, shaders and 32bit colour(You can even have HDR sprites if you want) when that isn't possible on the actual hardware.

I'm not trying to hate on GB Studio it looks great, just some thoughts.

Despite your gatekeeping thoughts I think things like this are great. You make it sound like it's a bad thing that you abstract the difficulty from past times away, but what actually will happen is that it makes this stuff much more accessible to get started with it at all. There will be a few people among those falling down the rabbit hole and end up at reading and writing raw code for the Game Boy because stuff like this will always limit you in some way.

I think there's lots of good things about GB Studio I just didn't want to write some kind of HN manifesto on Game Boy game development. For example I'm sure with GB Studio it's possible to run into hardware limitations like sprites per line, music causing lag etc.

GP makes some valid points, why would one accuse GP of gatekeeping? I think anyone who jumps to such an unfounded, uncharitable conclusion should consider their own biases first.

> [...] why would one accuse GP of gatekeeping?

Well, for starters the comment was listing all the good things about GB Studio as bad things, going even as far as being "worried" about it. The motivation was that it makes this stuff look too easy and giving people an "unrealistic view", whatever that is even supposed to mean. Basically every line is going into full defense, trying to tell how "super-duper elite" the whole idea of programming "back in the day" was or rather still is. This perception, at least for OP, needs to stay that way for everyone else and GB Studio is putting it into danger. That's gatekeeping. Look it up.

You're absolutely on the money. If you scrape the surface of Game Boy development you'll find that it's even inadvisable to use C since the hardware is so weak (compared to today's standards) that you really need to squeeze out performance at the instruction level.

If GB Studio and GBDK spurs someone's interest to get into Game Boy development, great, but getting the most out of the hardware requires a lot more effort.

Aside from some a couple performance critical parts of code or if you're trying to push the hardware to it's maximum limits with effects or complex mechanics, C is totally sufficient for writing entire (and performant) games on the Game Boy. Many polished homebrew GB games have been (and are being) written and completed using C.

Of course, now the number of games now being made with GB Studio completely eclipses the number written in C and assembly.

Most of the GBDK/GBDK-2020 API used for C development is written in assembly, so if you use C you get some benefits of using assembly anyway.

Here's a more nuanced guide for choosing which development tools to use. https://gbdev.io/to_c_or_not_to_c.html

And a couple recent-ish examples of polished games:

GB Studio:

https://lumpytouch.itch.io/super-impostor-bros

C/GBDK:

https://pocketpixel.design/super-jetpak-dx-game-boy-rom.html

https://user0x7f.itch.io/black-castle

https://tangramgames.itch.io/tobu-tobu-girl-deluxe

C/GBDK + ZGB:

https://aiguanachein.itch.io/powa

(edit: line breaks)

So, is this akin to using React native instead of writing native iOS and Android apps?

Yes, and despite the comment above that's a GOOD thing. Making things easier for people to get into, and get interested in, is always a good thing. It might not be the "best" way to do something, but if it gets them keen and learning then eventually they'll reach the limitations of it and be motivated to move further up (down?) the stack to learn more "proper" methods/languages/etc later.

I started with GameMaker Studio and it let me get a simple platformer up in a weekend, and let me make/publish multiple "full" games that have been enjoyed by my kids for hundreds of hours. It then led me to learn Unity/Blender/etc so I could get beyond the limits of GMS.

I myself am very glad that game development tools are becoming increasingly accessible and the barrier of entry is lowering. If I see people making new stuff with little effort I'm happy to see more people expressing their creativity and choosing to make stuff, not upset that they don't appreciate how hard it used to be.

>In the past people had to think about things like how to fit a 20hr RPG into less than 1MB

You mean the didn't use cross compilers/art tools under Amigas/i386 PC's? Don't be delusional, man, everyone used these tools, even stuff like Deluxe Paint and them a custom tool to convert between graphic formats.

Also, most developers rehashed engines over and over. They would write an engine once per genre/game type.

Simillar environemnts exist today for the ZX Spectrum and as long as you can optimize/rewrite with inline Z80 code, they should be fine.

> trivialising the difficulty of the past

What's bad about that? Is the purpose of game dev to write the most efficient game code, or to make more fun games?

If it's the latter, then it's simultaneously the case that 1) this IS "trivialising" (or removing unnecessary) difficulty and 2) that's a good thing.

There's more to life than trying to fit the richest "20hr RPG into less than 1MB" -- who's to say that's what the goalpost should be anyways?

OP, thanks for posting this and bringing it onto my radar again. The GBP (with a copy of Pokémon Red) was my first foray into the world of gaming as a wide-eyed 8 year old.

In the past, every time I've tried to put something together game dev wise, the toolchain onramp has scared me away and any project I've tried to work on has inevitably failed. I wonder if things might be a little different in this case just because of the creative constraints. Of course, the cranky engineer side of my brain is saying "just suck it up and learn Unity" because of the ecosystem.

But speaking of creative constraints! I've spent a while looking into an active corner of the Pokémon fandom that is concerned with making custom Pokémon games. It hinges around a pretty complete and powerful toolchain called Pokémon Essentials [1] which uses RPG Maker XP as its base. It seems to have reached critical mass enabling fans to make custom Pokémon games which faithfully reproduce Pokémon's admittedly complicated mechanics without having to reinvent the wheel. Sadly, Nintendo took it down once it reached critical mass for understandable if regrettable reasons.

I keep thinking to myself that something along these lines would be incredible for game dev. RPG Maker in particular seems to be unique in how specialized it is compared to more generic ecosystems such as Unity and UE. Can anyone who has more experience in the industry tell me why that is? Is it just an economics and market reach thing?

[1] https://essentialsdocs.fandom.com/wiki/Essentials_Docs_Wiki

If anyone is interested in making a Gameboy game from scratch. Tonc is basically the resource that everyone is using to do that. https://www.coranac.com/tonc/text/

I think that's only for the gameboy advance, although it is what most people are using for the GBA.

For the gameboy people use raw assembly or I think GBDK if using C, although I think there are some problems with GBDK.

https://github.com/gbdev/awesome-gbdev#c

GBDK went mostly unmaintained for around ~20 years, and so it stagnated a bit. It has recently been upgraded to a modern version of the SDCC compiler with better optimization, and has seen bug fixes and a bunch of other improvements.

https://github.com/gbdk-2020/gbdk-2020

Oh that's excellent, I didn't realise it had been picked up again. Cheers!

"no knowledge required" -> game development without knowledge... YMMV.

Also, for a different approach, there was GBForth, but sadly is not as complete.

https://gbforth.org/

How about using (experimental) Go on the Game Boy :)

https://github.com/pokemium/gbdk-go

GBForth if improved would be far easier to handle composition and calling ASM in a really easy way.

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.

Is there a way to load these onto actual Game Boy cartridges?

there exist flash carts where you can insert SD cards and load them on your gameboy

at least the guy who wrote https://news.ycombinator.com/item?id=26857743 has custom cartridges for his games

There are tons of cartridge solutions available. Just search typical sites like tindie. That said, the most highly recommended solution is going to be the everdrive.

Either flashable cartridges (so you need to also buy a flasher), or more expensive cartridges with an embedded µSD card reader. Just be careful to buy cartridges with enough storage for your game(s).

I personally own an "El Cheapo" from Australian maker BennVenn, but they only make small batches a few times a year.

Reply on news.ycombinator.com