kyletoom

[kyletoom]

Let’s make a Gameboy Advance game! Part 3.5

Hey all! It’s been a while, but as usual, I’ve been busy. I will admit that part of that “busy” is playing Pokemon Let’s Go, but hey, can you blame me?

In addition to school, Pokemon, and working on the start of marketing for my own game, I’ve been chipping away at what I think is my last GBA collaboration. If you can’t tell, I’m quite a fan of monster taming games like Pokemon, which is why I’m making my own game like it! This interest in monster taming games has carried over to other indie games, such as Monster Crown (weeks 1-2) and now Monster Sanctuary!

Monster Sanctuary is a very pretty monster taming metroidvania that is currently being Kickstarted with less than 3 days to go! If you like Monster Sanctuary and want to support it, go here, but gotta go fast!

This game with its visual complexity, let’s just say, is not an easy task to replicate in the Gameboy Advance hardware. I’m pretty sure at this point that I’ve figured out how to cram everything into the system’s memory, but as you can see from the screenshot, there are 4 visual layers involved. 4 very distinct layers. 

If you remember last time, I put a map together using two layers (although I probably could have managed with one layer). For that one, I just popped a whole 256 by 256 image into memory and overwrote parts of it with map data to get everything in... And it was a pain! Also, it took up the entirety of the GBA’s graphical memory. Can’t really get away with this time now that I have 4 layers to worry about.

For layers one and two, I don’t have to do anything too special (now that I’m playing it smart). The reason I ran out of memory last time was because I put the whole tileset into memory at once, meaning that there were more than 16 colors in the image. Why is that a problem? If you take an image that has more than 16 colors and put it onto the GBA then you need to make it so every pixel of the image takes 8 bits, which is twice as much memory as an image that takes 4 bits per pixel would take up. Last time I also put the images into memory regardless of whether or not I needed them, which took up a lot of space, so this time lets only put the ones into memory that I am going to be using!

This is what the tileset looks like after I have moved everything around and taken out unnecessary tiles. Notice that the types of tiles come in layers: this is so that I have three different 4-bit palettes instead of one giant 8-bit palette. Technically the order doesn’t matter, but putting them into layers makes it a lot easier on me and a lot easier to feed to my custom tools. This, I believe, is already taking up a quarter of my memory.

Using these tiles I can create a two-layer map that represents the above screenshot. Nowadays I am using a tool called Tiled to make my maps as opposed to my very limited custom tool. This, of course, means that I had to make a tool that converts Tiled maps into my own format that I feed into a tool that converts it into a form the GBA can handle, but I digress.

The next layer back is a bit more of a problem. You see, the developer of Monster Sanctuary actually has that as just a 256 by 256 image and handed it to me as such, which is a great approach for PC but a not so great approach for GBA. With all of the other stuff, there is no way that I am going to fit another 256x256 image into memory, so what do I do? Split up the image into 16x16 chunks and then only take the chunks that are special and put them into memory. In this case, any spot that is completely transparent or completely black can be ignored:

Before:

After:

After all that, we have compressed the map down to almost 25% of what it originally was! Theoretically, if I went ahead and broke the image down into 8x8 chunks and did the same process on it I could have saved even more space, but it would have taken about 4 times as long to do. While I haven’t done it yet, later I will take these tiles and construct them back into the original image by making them into a tilemap and then slap that into the GBA.

At this point I doubt that I will do the fourth layer, but theoretically, I could cram it in using the same techniques as the third layer. As you can see, though, by being smart about how I use memory I can get way more graphical complexity into the system than last time. As you can probably also see, this is quite a bit of work, so if you wonder why GBA games didn’t usually look as good as Monster Sanctuary does, then that’s why.

I’ll try to get this demo actually done soon, and then I’ll try to mess with the next challenge that I previously said I would do this time: sound.

Messan in a Bottle

So for about the past year now I have been gradually working on a game of my own. Introducing a monster taming game where every monster has its own personality: Messan in a Bottle!

https://twitter.com/messaninabottle/status/1064621898485637122

I haven’t figured out a good way to post videos so this time that link will have to do.

Until next time!

[kyletoom]

Let’s make a Gameboy Advance game! Part 3... and more!

So here I am! It’s been two days and two weeks since my last post, and boy have I been BUSY! So busy that I had to delay this post even. So what have I been doing all this time? Well, let’s just say I made two games in the last two weeks in addition to working on the stuff for this post. Buckle up because this is going to be a wild ride!

This week, I did a collaboration with @thewakingcloak to take his graphics and world and put them on GBA hardware. He sent me his tileset, his character sprites, and a screenshot of his game and I made it into this:

To do this, I had to do a few things that I haven’t done yet: designable maps and collision detection. To do the former of those things, I used a custom tool to design maps. This is what the tool looks like:

The red boxes indicate that the tile is meant to be collidable, or in other words, is meant to not be something you can walk over. I just strapped an option to export the maps to a format that I could slap into the GBA code into my map editor and I was in business! Or was I?

Turned out that it was a tad bit more fiddly than that. I spent several hours trying to cram both the tileset and the map into the very limited GBA video memory. This is one of the less insane visual errors that I got in the process:

Here’s a more insane one, the ones that I had a lot more of:

I actually had to cannibalize certain tiles, in other words, the ones I wasn’t using, to be able to fit everything into memory. It took a while to figure out which parts of memory to use and how to tell the GBA to use them, but in the end, I got it to work. If I had to do it again, I would use various sorts of compression to not make fitting everything into memory nearly as much of a pain.

Making everything collide was actually pretty easy because The Waking Cloak uses a very simple sort of collision. Other than making it so that the player couldn’t walk off screen, all I had to do was check “can this block that I want to move into be walked onto” before actually taking the step. This illustrates a point that I am learning too well about making games for the GBA: coding the actual game is like normal, it’s getting the graphics to do what you want them to that’s the hard part.

Now here’s something cool! My fiancee has actually been letting me use her GBA flashcart recently. For those who do not know, a flashcart is a game cartridge that lets you run whatever you want off of it. In the case of this one, I could put stuff onto a microSD card and load it up onto an actual GBA! Here is what this demo looks like on real hardware:

Next time I will attempt adding sound to something, which is a lot more difficult than you would think.

Here is the link to the ROM that I made for this post.

But wait! Don’t go yet! We’re just getting started!

ぼくの Bro Boosting Beats

As I said before, I have actually made two games since last post (and I am tired because of it!). This game was made in 48 hours with a team of four (I was the programmer) for Chillennium, a game jam held at Texas A&M each year. Game jams are competitions where people get together and make games in way too little time, often 1-3 days. The theme for this competition was “Transformation”, and if I recall correctly there were almost 400 competitors and 86 games produced.

What is Bro Boosting Beats? A virtual pet rhythm game about raising a neckbeard into a slightly better person of course! We styled it like a Tamagotchi and, well, this is how it came out:

We’re very proud of making such a strange experimental game! If you want to try it, you can download it for free from itch.io here for Mac and Windows.

Alfredo’s Mansion

Oh boy, what have I done?! Well, this I guess. Inspired by the spooky season, my fiancee and I created “Alfredo’s Mansion”, a game about shooting an infinite wave of ghosts. Also, it’s for the GBA and I made it in about 12 hours for a game jam-like competition called a Hackathon :P

You hold down the A button to make your shots bigger and travel further distances. Also, the RNG is quite broken because of an oversight on my part when constructing the random number generating system, but oh well.

It’s a super short arcade-style game, and you can download it here.

Unless I do more collaborations, I may build off of this game in future blogs, because the concept is rather fun and I think that I can manage to make the game sort of decent.

Something over the horizon?

More information to come soon...

[kyletoom]

Let’s make a Gameboy Advance game! Part 2

Hey all, it’s time for another episode in the adventure of making games for the GBA! Today I will be showing you how I got to the point of finishing my little tiny demo of “Monster Crown but it’s on the GBA” that I spread around a few weeks ago. After this week, I’ll start using new graphics as well as start the process for moving this towards a more original game. Well, sort of, you’ll see!

Anyways, let’s get to it! Last time we left off with having a character move around the screen. Now, unless this is a game taking place in an especially empty region of deep space, we probably don’t want to have the character floating around in the void. So let’s at least get the character walking around a far more interesting plain plain! (pun intended)

Well, if we’re going to have the character walking around in the same manner as a typical 2D RPG, as I like, then we need to fix the character’s position in the center of the screen. I also made him look in whatever direction we want to move in so that you could see that at least something is happening. Once again, credit to the folks at Monster Crown for creating these sprites. This is likely the last time that we’ll see them on this blog so if you get too attached to them be sure to check out the game they come from ;)

Next, let’s actually put a background in there so that you can see what’s actually happening. Just like last time, we have to split up the images for the tiles in a strange way. Instead of moving the character around the world, we are now moving the world around the character! This is a very common practice in game development and isn’t at all complicated in practice. It just sounds super strange at first. I didn’t actually design a map for this little guy to use this time; that will be next blog’s topic. Instead, I used the scanline’s current position on the screen to determine which block to put where to make it look sort of random. Don’t think too hard about that.

At the moment the character just kind of goes wherever he pleases. This is, of course, a valid approach that many games use, but it can require a bit more work. As a lazy programmer, I am instead going to simply restrict his movement to a grid so that I have one less thing to deal with!

Next, it’s kind of boring that the character just scoots everywhere, so we’ll make him use a walking animation. After all, I don’t believe that Segways exist in the Monster Crown universe. This is pretty easy: if the character is between 25% and 75% done with his step into the next tile, show him as taking a step, otherwise, show him standing still. If you do that, you get the result below. I did take a creative liberty when animating this walk cycle, and that is making it so that the character bobs a little up and down as he walks. This isn’t in the original game, but it feels a lot better to me so I added it.

Tumblr really doesn’t like big gifs apparently so I may have to switch to embedding Youtube Videos. We shall see.

Wait a second, what’s that gray thing??? Well, apparently this demo needed gargoyles. Don’t ask me why; I don’t know. My good friend @alliecatgames insisted on them, so I told him if he sprited one I would add it to the ROM and he delivered.

Anyways, having the gargoyle there demonstrates a special property of this map that we wouldn’t have seen otherwise though: it wraps. Also, it has no collision, but we’ll worry about that next time. If you go too far in one direction then you’ll end up right back where you started. This is a normal property of GBA maps, and they can only get a few times bigger than this, so you might be surprised to hear that all your favorite GBA games don’t run into the problem of having their maps wrap. We’ll talk more about that next time.

Speaking of next time, I will be putting my next demo on an actual GBA! My wonderful fiancee has supplied me with her old flashcart, which allows me to put games onto a microSD card and run them off of it. Unfortunately, I haven’t had time to buy a microSD card, so it’ll have to wait until next time. Also, there will be a big announcement and a collaboration next time? Whhhhhaaaaaat? Get ready for a real exciting blog in two weeks!

Anyways, that’s it for now. Hope you all enjoyed reading and see you all next time!

Here is the link to this week’s ROM.

[kyletoom]

Let’s make a Gameboy Advance game! Part 1

If you’ve come here, then you’re probably either here for my Gameboy Advance game development or are (at the time of posting) a time traveler who has already seen what else I will be posting in the future and came to the past to see the beginnings of it all play out. Both are completely valid reasons to be here, but first, let’s cover the basics:

About Me:

I’m a hobbyist game developer/college student studying Computer Science. I have an interest in Japanese things and have recently studied abroad there. I am also my University’s Game Development Club president, and I haven’t been mutinied yet, so that’s a good sign. My first game system was the Gameboy Advance (there is no such thing as coincidences, eh?) and my favorite game is Pokemon Emerald.

Why Tumblr?

Simply put, I wanted to share my adventure in game development with more people, and this seemed like a good place to do so. I also have a few friends here already, so might as well join the party. I have a Twitter too (@kyle_toom) but that platform isn’t particularly well suited for long devblogs.

What will you post?

At the moment, I am considering posting about once every two weeks. The reason for this is that I want to deliver quality posts... and am a busy person who can’t spend all day blogging and making games :P As for what I will be posting, for now, I will be talking about making games for the GBA, but in the future you can expect me to talk about another very special mostly-secret(TM) game. I am a programmer by nature, but I want this blog to be accessible to non-programmers as well, so I will leave the technobabble confined to technical note sections of the blog and explain things from a non-programmer’s perspective otherwise.

GBA! GBA!

Alright, alright. Let’s get to it.

Well first things first: how does one get started? There are two main ways to program a GBA, but we will be taking the C route. C is a programming language that is significantly easier to work with than the other option, assembly. Here is a sampling of each to see the visual differences:

Assembly:

C:

Yeah okay, it looks complicated either way, but at least with C you can give things names to make it a lot more readable. Both codes simply fill the screen with a given color, so nothing too fancy. However, thanks to modern compiler technologies we can turn C code directly into a GBA game file (referred to as a ROM). If anyone is wondering where I got the information to make GBA ROMs, you can find the tutorial I used here. Needless to say, though, it is geared at experienced programmers, so be warned.

So let’s make a simple GBA ROM! Well first thing’s first, we have to get an image, “sprite”, onto the screen.

Yay! We got a tiny 8 pixel by 8 pixel sprite onto the screen! That was easy enough right? Yeah, it wasn’t too bad. I made a sprite that uses two alternating colors in a palette and then put it at the coordinates (16, 16). As opposed to what you learned in math class, the coordinate system in the GBA starts with (0,0) at the top left, with the y-axis increasing as you go down. The reason it does this is because of how memory is structured and how the GBA handled scanlines. Yes, scanlines, just like an old CRT screen TV. Normally computers can flash an image onto a screen all at once, but GBAs do it one line at a time. This means that if you change a sprite’s position in between lines, you could end up shearing the image! Thankfully, there is a few millisecond period between finishing a frame and starting the next, so we actually change the sprite’s position in that brief time.

Another thing about images in the GBA is that they are almost always paletted images. This means that instead of using any color under the rainbow, an image has to use a small selection of colors. Technically you can draw to the GBA with its full range of colors, but this is actually too slow to draw at 60 frames per second with. Thanks to the Tools menu in VisualBoy Advance, the emulator that I use, you can actually see the palettes stored in memory:

The first (technically 0th) spot in sprite palettes is actually reserved for transparency, so I started adding colors at the next two spots.

Next, let’s make the square move! Because the GBA runs at 60 fps, it is pretty easy to write up some code to add consistent movement to a sprite.

But a little 8x8 square is pretty boring, huh? Why don’t we add a 16x24 sprite then? Well, things get a little bit tricky with that, actually. We can have 16x8, 16x16, or 16x32 sprites with the GBA, as well as other dimensions that satisfy the expression 8*2^n, but we can’t actually have 16x24 sprites. This leaves us with two options: take up extra space and use a 16x32 sprite to draw a 16x24 sprite, or use two sprites, a 16x16 and 16x8 sprite. I actually like the second option better so I will do that.

Player sprite borrowed from my friends at Monster Crown, an upcoming monster taming game! Woo! You can check out their fully funded Kickstarter here.

So that was no problem, right? Well, this time I have been vastly oversimplifying it. You can’t just take an image’s data and store it in the GBA’s memory directly. If you did, it would look something like this:

Now THAT harkens back to the good ol’ days with Missingno on Pokemon Red and Blue! This is because while normal computers take images row by row, the GBA can only work with 8x8 “tiles”. If you split it up correctly, this is one of the ways you can represent it:

The main thing that you don’t see happening here is that each third of the image is actually split into two 8x8 chunks. The data of the first chunk has to completely finish before you can get to the data of the second one, as opposed to storing the information row by row like normal. This is how the 8x8 tile that is the left side of the character’s head is actually stored:

Because this is a pain in the neck to do by hand, I actually made myself a tool to do it for me. After all, the motto of programming is “if you keep having to do something, make a function or program to do it for you.”

Well anyways, that’s enough for now. Next time I will show you how I add backgrounds and animation to my demo.

If you would like to try the demo out for yourself, here is the GBA ROM file.

Thanks for reading and I hope you enjoyed it!

Programmer time

Okay, time for me to let my programming talk run free! This time, I would like to talk about what we call I/O registers on the GBA.

You know how normally to get something on a computer screen you have to call a function? Yeah nope, not on the GBA or similar systems. Instead of calling a function to get a sprite on the screen, we have to write to a certain memory address. Except not even that! For instance, address 0x6000000 isn’t actually at that location in memory, as the GBA doesn’t even have that much memory to begin with. Rather, the top few bits of the memory address indicate which chip on the GBA to send the data too. While 0x6000000 is byte 0 of VRAM, 0x4000000 is byte 0 of the BIOS.

Anyways, to get a sprite on screen we have to do several things. First, we have to load the sprite’s image data into a certain part of VRAM. And then we have to load the palette into Palette Memory (yes it’s separate). Finally, we have to go into what we call Object Attribute Memory (OAM) to tell the sprite where to go on screen, which palette to use, which properties to have, and if it’s even supposed to draw or not.

Okay, so that’s not too crazy. But of course, every bit of every type of memory has to be utilized! Something that threw me off for a bit was that the y coordinate for a sprite takes up 8 bits of memory... While the x coordinate takes up 9 bits. Lots of bitshifts and bit masks.

The final caveat with memory has to do with how each memory is built into the circuit. Some chips are 16 bit, some are 32 bit. While this generally doesn’t do much, if you try to write a single byte to VRAM then, well, you’ve written two bytes with the same value. It very much enforces that 16 bit value when it comes to VRAM and I believe a few others. I can already tell that working with memory is one of the hardest parts of working with the GBA...but onwards none-the-less!