
Making a Game Boy Game. Part 1: Getting Started - broahmed
https://invisibleup.neocities.org/articles/18/
======
sneakernets
Game Boy development was interesting in that you were always coding with
battery in mind. You couldn't simply "NOP" your way through something, you had
to "HALT". So your game loop was always "halt and wait for interrupt, do
action, halt again".

Allegedly, if you didn't do this, Nintendo would reject your game outright.

~~~
anyfoo
I'm not too familiar with game development, is that unusual? It's pretty
natural in other forms of software development. In user space, you mostly wait
on system calls (e.g. select, blocking read/write, thread synchronization
primitives), and in the kernel that usually translates to another process
being scheduled. If there's nothing to be scheduled, you hit the idle loop,
which, roughly spoken, halts the core until the next interrupt. Sometimes you
need to poll a device that does not signal completion with an interrupt, or
some locks may actually spin (for a while at least) before sleeping, but,
conceptually at least, I'd almost call those exceptions to a rule.

~~~
white-flame
This isn't necessarily different for game development, but it's different for
Game Boy scale hardware, where there is no scheduler/kernel/OS/anything. You
manually have to halt the hardware if you don't want the CPU to spin, and
busy-loops were common on home computers & mains-powered consoles of the same
era.

~~~
anyfoo
I got that, I was just wondering if there was more to it between e.g. Game Boy
and NES than having the extra HALT in your main/idle loop, and maybe less
unconditional polling. Apparently not, thanks!

------
notadog
This is part one, but the author has also written 4 other parts. They are also
pretty interesting, and some more focused on the visuals. The author also made
the in-development game called Aqua and Ashes open-source on GitHub
([https://github.com/InvisibleUp/AquaAndAshes](https://github.com/InvisibleUp/AquaAndAshes))

* Part 1 - [https://invisibleup.neocities.org/articles/18/](https://invisibleup.neocities.org/articles/18/)

* Part 2 - [https://invisibleup.neocities.org/articles/19/](https://invisibleup.neocities.org/articles/19/)

* Part 3 - [https://invisibleup.neocities.org/articles/20/](https://invisibleup.neocities.org/articles/20/)

* Part 4 - [https://invisibleup.neocities.org/articles/21/](https://invisibleup.neocities.org/articles/21/)

* Part 5 - [https://invisibleup.neocities.org/articles/23/](https://invisibleup.neocities.org/articles/23/)

------
thanatos_dem
The intro to low level computing class at Georgia Tech used Game Boy Advanced
as the platform that the projects were built on.

It was cool at first, but I ended up too deep in the weeds with platform
idiosyncrasies to really get much actual C knowledge.

~~~
anyfoo
The original Game Boy is very different in that regard, to the point where
it's relatively simple to get an emulator implemented that can decently play
some games.

Of course, there are more intricacies the deeper you dig below the surface,
but for the original Game Boy, that is more of a concern for emulators that
aim at going towards 100% compatibility. As a game developer, you can probably
stay at the surprisingly small apparent surface for quite some time (and at
least the earlier Game Boy games often did).

------
voltagex_
See also [https://catskull.net/gameboy-boot-screen-
logo.html](https://catskull.net/gameboy-boot-screen-logo.html)

~~~
catskull
Wow I think this is the first time I've been mentioned on hacker news! That
was a super fun project and I use the header utility very often!

~~~
voltagex_
You should submit some of your articles - they're super interesting.

------
broahmed
Just a note that she has four other articles in this series at the moment! You
can easily find them by clicking the _Articles_ link at the top of her site.

------
airstrike
Off-topic: this is the first I've heard of neocities.org but I went there with
high expectations and I'm positively impressed. I guess having been online for
20+ years makes me relatively "old" (many of those much older than my
generation were not so keen to get online way back when) and by God do I miss
the "old internet".

Neocities' description truly resonates with me:

    
    
        > Neocities is a social network of 216,300 web sites that are
        > bringing back the lost individual creativity of the web. We
        > offer free static web hosting and tools that allow you to
        > create your own web site. Join us!

~~~
baroffoos
Yeah its pretty cool. Its not just another free static web hosting but a place
to find quirky bits of art and creativity unlike Git* pages which is just
blogs and project pages.

~~~
derefr
There's nothing stopping you from putting "quirky bits of art and creativity"
on a Git-host+static-site-generator site. Given that most of the Git-host web-
apps have editing interfaces, there's not even a barrier to entry.

IMHO, it's mostly just that "you can freely host a static website on the same
services programmers use to freely host source code" isn't a well-known thing
outside of the programming community. GitHub/GitLab/etc. should do some
outreach at the digital-art/interactive-media departments of universities.

~~~
baroffoos
The big big difference is discovery. Neocites has an explore page that shows
you all of these mostly pointless personal pages and js games which often link
internally to other neocities pages so you end up with a bubble resembling the
old web rather than other static hosts that have websites that are just
another blog in the modern commercialized internet.

------
Domark
For me I do it this way: 1\. Get a sprite system, audio, sfx, save state, game
loop solution going for the platform (GBC). Usually something is available
like Cocos.

2\. Create the game! Sprites, animations, sounds, game code for all parts.

Then I test play, and iterate until it’s ready to share.

Starting from scratch like this website is like starting from step zero, not
step one.

~~~
duskwuff
Yeah, nooooo. Cocos2d is a relatively heavyweight game engine aimed at
platforms with bitmapped graphics and lots of CPU and memory. It's completely
unsuitable for an embedded system like the original Game Boy, which uses
hardware tile/sprite graphics and has very limited compute resources (4.19 MHz
Z80-like CPU, 8 kB SRAM).

