How I failed to make a game: Raycasting on the GBA

2 days ago (mcejp.github.io)

Shockingly enough it is actually possible to do decent ray casting and much more on the GBA despite the incredibly minimal compute budget.

Joshua Barretto has been working on a GBA port of Super Mario 64 with entire 3D levels, characters, and movements. In my opinion just incredible work:

https://youtu.be/9mUsgJ-HiDM

It's funny to me when people apologize for not being artists when they've produced actually nice looking art. It's like a host saying "excuse the mess" when entering their nearly immaculate home.

I wish I had kept some of my game development experiments because then I could show you what actual bad art looks like!

  • I should have included a disclaimer -- I agree that textures and sprites are excellent, but they come from asset packs (for this same reason I cannot redistribute them in the source release). Only the crossbow placeholder is self-made.

    I don't have any issue with paid asset packs, I would gladly build the entire game with third-party art, but there is only so much of it in the necessary style, resolution and quality.

  • I was thinking the same thing and actually thought they should continue building it. It looks like a great game!

> Don’t get stuck on assets. Make a quick placeholder when necessary

Need this tattooed in my ADHD brain. Assets are such a rabbithole

Not sure if you care at this point, given that you stopped working on project, but there's a better way to find the ray direction for each column than using sin/cos for every one, which will also get rid of the slightly warped look:

Calculate the two vectors from the camera at the very left and right of the screen (using your fov angles and sin/cos, that's fine). Then, to find the ray direction vectors for each column, interpolate linearly between your left and right direction vectors, and possibly normalize the resulting vectors if your ray walking algorithm requires it.

This will create a perspective that integrates tightly with sprites that you 3D project the usual way, and lines will stay straight lines.

The takeaway that "content" can be the hard part in making a game is why I think its so important to make games with teams. There are some folks out there who will produce art the way an engineer produces code; all they need is to be empowered.

The best games are developed as a technical-artistic partnership, with both sides pushing and enabling the other.

As someone who has tried and failed at many points throughout the years at building a game I couldn't agree more with "Build a game, not a game engine" it's hard not to get sucked into the game engine black hole though.

  • Its depends what you like. Usually programmers focus more on game engine part, while designers on the other. And thats why is hard to make game solo :)

    Galaxial developer fall into that hole too. Too bad, because alphas looks absolutly super great.

> What didn’t work

> Content. Brace for an obvious statement: it is one thing to imagine a grand, Daggerfall-scale game in your head, and a completely different thing to actually start building the pieces that make it up.

This is what always kills it for me. It's not so much that there aren't good off-the-shelf content packs, its that unique gameplay ideas with unique visualizations don't have ready made assets. Even for a simple game like pong, if you want to do something graphically unique with it (make the paddle shake, charge up, or have a power bar embedded in it that fills up whatever), then you better be prepared to become an artist or find someone who will be your game's artist.

And also like the article points out, the latter is fine if you're looking to commercialize it, but it doesn't seem like there are many artists offering their skills for free games made casually in a developer's spare time. It seems there's a critical threshold of game development "seriousness" that needs to be committed to by all involved to make it worth the time and effort of others.

From my perspective, this is a great outcome for a game-making attempt. There's no shortage of fun games coming out lately - far more than I have time to play. But these days they're largely made by amateur non-programmer indie devs tooling around in Unity or similar, and have no technical merit despite being very fun. What I'm lacking these days are fun technical accomplishments to read about in the gaming space, like a GBA raycaster.

No offense meant to the author at all, but I probably wouldn't have played this game even if it were fleshed out and finished. Very glad I got to read about some of the technical decisions that went into making it and poke through the code though.

This reminds me of playing Ecks vs. Sever on the GBA. A raycasted 2.5d doomlike game based on a crappy movie. It was pretty impressive for a GBA game, and it ran well, never stuttering. It had some pretty cool levels, I remember one where you fight through a hotel using IR night vision. It also had a sequel which added a guided missile launcher and some crazy Robocop ED-209 type enemies. As I recall both had multiplayer deathmatch but good luck finding a friend who also had the game and a link cable.

One thing I took full advantage of as a kid was that both games had some cheesy behavior with the sniper rifle scope implementation.

In the first game, while zoomed in with the scope you could use the D-pad to move your view a few clicks left/right/up/down to refine your aim. However, this was not really turning you, it acted more like you were a ghost side-stepping and poking his head up and down. So, you could crouch behind a box, scope in on the box, then D-pad up to look over it and shoot an enemy mob who still couldn't see your character and wouldn't engage you. Or stand just slightly behind a corner, scope in, and D-pad right to shoot around it.

The last level of the first game involves fighting a boss character who has a powerful weapon and a ton of HP, and is surrounded by his infinitely-respawning goons. There's no way kid me would've beaten it without abusing this trick, which reduces the challenge to avoiding his attacks while fighting enough lower-tier enemies to obtain their precious sniper rifle ammo.

In the second game, the D-pad moves a crosshair around a fixed viewport rather than shifting the whole viewport around. So the trick doesn't work exactly the same way. If you zoomed in staring at some obstacle right in front of you, you couldn't move the viewport to see around it like you could before.

However... when you zoomed in, it worked like you were a ghost moving forward in space, instead of narrowing your FOV from your original vantage point. So you'd instead stand about 10 feet back from a corner, zoom in past the edge, and voila: you were able to see more around the corner just as if you'd walked up next to it. Sure enough, you could slide the crosshair over and snipe the enemies now visible in your viewport despite your player character still being safely 10 feet back around the corner.

Good times. They were still great GBA games even with this exploit, it just made the (scarce) sniper rifle ammo even more valuable to the player.