Blogs - agamerguy

Recently I obtained a Raspberry Pi 5. As usual, I like getting these devices to play around with game dev on low end hardware, and to see what others have made for them too. When setting up the usual suspects through apt; In this case Godot, GIMP, and Blender; I ran into a lot of trouble with Blender. Dependency issues on the latest RPi OS for 2.79b, and the latest build that works with the OS runs like garbage due to minimum OpenGL requirements can only be met through GPU driver emulation.

Curious to try other Raspberry Pi compatible apps, I got Pi-Apps and started browsing. Lo and behold I found blockbench (BB), a simple 3D modeling app. I had never heard of it, but without many other options on my shiny new Pi 5 to try, I give it a go. At first launch it ran at full screen and still runs fairly slow and not really fun to model with. It was about 15-20 FPS at 1440p... yes there's an on screen fps counter by default! So I just made the window smaller, and voila, usable. So I spend some time with my shiny new tool, both on and off the RPi I found it on, I learn the basics and made some reasonable assets.

I think there's a tendency to get overly excited when finding a new tool to want to switch everything over and do it all a new way, and I was getting caught up in that excitement. I even taught my kids how to use the tool. Which is great! It does seem like it was made for minecraft which they love. But for the games I want to make some features weren't making sense for me to use. In particular animating, which is actually cool in BB for how simple it is. I keep realizing I don't really want to spend all my time on art, and when I do spend my time on art I want to do the parts I like. I intend to balance the coding, art and design work I do for my games. I'll buy sound and music packs!

Using BB has helped me come back to an idea to make several games with a single palette each. I think a nice palette may help set a mood, help with visual consistency and help make assets faster purely out of the restriction. This can help save me time to actually make games for personal fun, creativity and edification instead of market and work.

Journeying through game dev feels like a constant molding of thoughts and tools to work to get a final product. I've felt pretty lame since I haven't released my own personal game in almost 9 years now. I'm rarely using skillsets I want to during work these days so there's a lot less satisfaction there, and am trying to make up for it with my hobby projects.

Wow, I was intending to have a blog post a month and it's been like 2 years... Going to try and keep things more casual while catching up on the engine and game development progress. There is plenty to get out there and I've tried to keep at least some screenshots of the engine's progress, but overall looking back it's pretty crazy how far things have come. This update will cover stuff I worked on all the way back in 2019, somewhere during the summer if I recall correctly.

Last blog post I was showing off some fairly basic rendering, and the next step wasn't terribly different in that department. Originally I was content with using my basic .obj importer I cobbled together, but there were many things I found unsatisfactory about it. So instead I decided to write my own exporter for blender, which also meant learning some Python. This wasn't too bad since the job I had changed to since last post had warranted learning Python to an extent anyway.

In addition to wanting a file format which prioritized loading quickly over being readable, I also wanted to start involving some real game related logic, so I included a first pass at collision data, a simple navmesh. The way I incorporated the mesh was to have it's borders act as collision in completely a 2D space. This made figuring out the math relatively simple as I set up methods to make the collision feel smooth and not sticky.

What do I mean by sticky? Simple logic could make you think: object hits wall; stop object. But this results in the player being required to direct their character precisely away from collisions in order to move. Instead I wanted to ensure the player would keep moving along the wall as much as they could with the input they gave to the game. This is seen in tons of games of course and if a game lacks it, it often results in a player feeling like they keep getting stuck. Pretty much any modern engine handles this in some way or another, from Unity to Godot. So I figured out a solution and I thought it felt pretty darn good.

Though my collision solution was fully 2D, I did add some height resolve to the nav mesh to allow the player to go up and down. This was nice and fairly easy to figure out the math for, but as I'll talk about next time isn't an ultimate solution for a fully 3D game. In addition to these changes what the following screenshots will represent is one fun rendering addition I did make during this time period, ordered dithering. I absolutely hate visual banding (well unless it's stylistic and purposeful), and even at the higher bit depths of newer games you can see ugly banding at times, so I decided to use this method to combat banding, doing my color math at 10-bits and dithered down to 8 for desktops, I thought it looked pretty good. However, it is pretty common for less expensive portable screens to use only 18-bit color (like the game shell's), so I implemented other levels of the dithering method. In the screenshots below, I have dithered down to 5-bits per channel, to give a purposefully PS1 style to them.

Hope to be writing these more often now! See you next time!

Ever since I first saw Doom and its contemporaries, I wanted to learn how to make my own 3D engine, to understand how these amazing images could appear on my screen. A friend of my brother's introduced me to Doom by showing me how I could make my own maps with DoomCAD and Doomed. This was a fascinating start that appealed to my creativity but I certainly had a long road ahead of me before I could understand computer graphics.

I was a fairly good student, getting As and Bs for the most part. My interest in game development and particularly 3D rendering helped make my choices for college too. I started college early as a dual enrollment student, and was even able to take OpenGL programming classes before finishing high school. I learned a lot in my college years, but many of the things I learned wouldn't click for me until much later. For 8 years after college I would think 'I want to make an engine'. I'm a very slow paced person. In that time, I got my first and 2nd game development jobs, as well as other jobs before and after. But then, there was Unity.

Up until that time, my encounters with game engines usually went a little like this: 'Okay, it's great for that game, but will it work for MY game idea?'. Before college I would toy around with things like the original Unreal here and there. But Unity was different than those experiences. It felt more like a new programming language and specialized game IDE. I spent 7+ years using Unity, across dozens of game projects both professional and personal. Unity really can be great, and while I think it's really easy for a programmer to learn to use compared to other engines, its ease comes at the cost that it's difficult to use to it's full potential. Unity has a bad reputation I think due more to inexperienced users than the engine itself.

Recently I got a new job. In this job I'm learning to use Unreal 4. As game creation tool, it is much improved over past experiences with older versions. However, like Unity, it still has lots of pros and cons. Things like blueprints are actually pretty awesome, something I never thought I'd say of visual scripting in a game engine.

Ultimately, learning Unreal is what sparked my interest in making my own engine again. I have a lot more experience making games now, and was able to delve really deeply with Unity thanks to my last job. I don't want to make an engine just because I can though. I want to have concrete reasons for doing it, after all Unity and Unreal can both be extended and each offer great benefits.

The last factor in the puzzle comes along: a new wave of single-board computers. The current Raspberry Pi is a pretty darn capable computer, and to my knowledge, there's no support from the two aforementioned game engines. I have seen plenty of source ports available for older game engines such as Doom, Duke Nukem 3D and Quake. And that's great too, people could certainly build their own game off of them, which is something I was considering doing myself.

A little more than a year ago I got a Raspberry Pi. I started looking into what I could do to make a game on it, keeping it somewhat relevant to my skills and job. Part of what that meant is making something I could easily port and work on between my primary computers as well as on the Raspberry Pi itself. This is when I found SDL. It is a great piece of software, offering a wide array of device support, and giving a great set of features that would be a royal pain to port, like input support, window handling, etc. At this time I'm still thinking 'Oh, I'll just do a quick 2D game'. That could've been fine, but I've never been nearly as excited about working on a 2D project as I have been about 3D, so I ended up setting that project aside. Fast forward to about 2 months ago, and I ordered a new single-board computer device, the GameShell. I'm now bringing all my past experiences together and learning a ton of new things to make a 3D game engine to run on this tiny little device. It is the best feeling I've had working on something in over a decade. I'm really excited to share what I can about it!

Here's a sample of my software renderer in action!