I have an absolutely enormous collection of old games. Literally thousands of them. While I do play a lot of newer games, I also dip into this collection on a near daily basis. It would be easy to write this off as nostalgia, but I don’t think that old games are better than newer ones, or that game development peaked sometime back when I was younger. It’s more that I think a good game is a good game, no matter when it was made. And sometimes a game that isn’t very good might have some aspect to it that is worth investigating. I play with old games, because I play games. All of them.
I solved some development problems today.
That isn’t really noteworthy. Making any part of a game is solving an unending torrent of problems. Nothing more, nothing less.
Making games, like any sort of creative work, never really has any procedural aspect. A point where you are going through the motions. You solve one problem, then another, then another. Maybe you make a new problem when you solved that third one, so you add that to the list and solve it as well.
It ain’t perfect. It’s not even that much fun. But it works.
I wrote about the Calgary Arcade Jam last week. Well that got me inspired.
I’ve been working on an arcade style game for a while. That meant I have had to create a whole lot of systems and processes to make 3D meshes look and move like 2D sprites.
Turning an entirely 3D, triangle based, game into a 2D, pixel art, game takes a lot of fakery. Up until now, a lot of that fakery leaned on a few scripts and processes that were largely CPU based.
Work continues slowly on my game.
I have reworked a lot of my Blender to Godot flow. I have simplified some of my shader setup so that my CRT effect lives completely independent of any graphics it’s modifying. I have added menus, proper pausing, and a save/load functionality, though most of that hasn’t gelled to anything close to final.
The game I am working on uses an orthographic perspective… orthographic perspective is sort of an oxymoron. Maybe orthographic projection. Orthographic camera? It tries to look like an old game, and so, it uses old game graphics limitations.
Recently I started combining all of my distributed experiments and gameplay tests for my game. That meant reorganizing a lot of the half baked scenes and projects that I have been working on into one unified project. Of course, that instantly broke everything. I have a slightly complex shader and viewport structure, and trying to combine that with other scenes that have things like basic menus, startup screens, pause menus, swapping levels, etc. caused all sorts of blank screen and screen size problems. Long story short, it broke my shader. The good news is that I made all of the shader and viewports setup. Since I was the one who made it, I was always going to be the one who had to fix it. So I did. It wasn’t easy, but I have now reworked the entire project so that I can run all of my menus and scenes in a really clean and efficient way. There is one main scene that runs all of the time and all of the child scenes either get loaded and unloaded, or set to visible, on the fly. All of my shaders and filters are on this main scene so that any popups menus or UI can run independent of the 3D portions of the game, but they get the appropriate filters applied. So yeah. game stuff is still happening and it’s still happening slowly.
As I move incrementally forward on my personal game project, I keep updating how I do things behind the scenes. The game is a top down, 2D, arcade style, game with a look that aims to hover somewhere in the mid 90s. So 2D pixel art, but run on hardware that can throw some graphical sparkle around. Except the game isn’t 2D and none of what you are looking at is pixel art. Under the hood, it’s all 3D models, skeletal animations, and shaders. In some ways, that is a more difficult task than making a 2D game with 2D graphics, but it also lets me get away with a lot that would also be difficult in 2D. Besides, I know 3D graphics and shaders. It’s sort of cool to have fun with those. Up until recently, the game included a bunch of flat polygons with textures on them as a stand in for the tile based graphics of a lot of older arcade and console hardware. For a few reasons I have removed all of those textures and now everything in the game is actually flat-ish, shaded polygons. Again, some of the things I am doing to create the art might be easier with textured polygons, but this shaded polygon approach also lets me get away with some effects and animations that would be very difficult any other way. Making each tile or prop object is pretty quick and easy, and there are a load of Blender and Godot tricks that I am using to make 3D models look like 2D sprites. One day I will probably do a whole write up on how the graphics in my game get drawn to the screen, but for now, I think I will stick to working on getting more systems into a playable state. My hope is, once people are actually able to play it, they won’t much care how the pixels are being lit. They will just want to run around and interact with the world.
I’m a bad programmer.
I have written similar sentiments here before, and I likely followed up those comments with the same explanation that I will add here. Like I said, I’m a bad programmer, but that doesn’t mean I don’t program. I have written a fair number of computer programs in several different languages. I have written programs that convert data from one format to another. I have written library software for a large company. I have written enemy ai code for small games. And the list goes on and on. All of these programs worked. Most of them were bad. Badly optimized, badly structured, and badly maintained.
For now, this is some fire. I think this won’t be the last version of this fire.
I’m going to try to put some screen shots and a video or gif right at the bottom of this post. I’m not sure how that will work, but hopefully it will.
I’m making my game using the Godot game engine. I have used Unity pretty extensively in the past, and recently I have been using Unreal for some other work, but I’ll be sticking with Godot for my personal project.
I just prepped one story to send out (it will probably be in the hands of a publisher by the time I post this), and I am getting another one ready (again, it might be ready by the time you read this). It’s been a hot minute since I sent out a story. I’d almost forgotten how to format a story. Almost, but not quite. There is no single way to format a story for submission to an outlet. There is a standard, but there are usually unique requirements for each outlet. Just simple things. Specific fonts, ways to organize the header. Nothing onerous, but it does meant that you can’t just send things out on autopilot, you need to actually make the effort to figure out how an outlet likes to operate. And while you are there, maybe read some of the stories they publish and figure out if they are a good fit for what you are writing. I will likely get back a quick rejection or two, but I have to say, I sort of missed it. Maybe I should keep fixing up the many other stories that I have sitting on the back burner. At least one of them has to be good, right? That’s just normal odds.
I am redesigning some of the assets for my game, because a few of them didn’t fit the gameplay and level designs.
I tried to make the airship work, but it just didn’t. So now the airship is a lifter and the ambulance is a regular ground type vehicle. I really wanted the player to be able to fly around, but creating obstacles in the air felt false and arbitrary. I know that 90s arcade games could be arbitrary, but false always feels bad.
Work on my own game does continue. I promise. It’s just slow.
Recently I swapped the base shader that is applied to most objects in the game. This is the bit of code that tells the computer how to apply color and deals with lights. There are about a million other things it can do, but all I’m using it for is color and lights.
Recently I have been doing a lot of work with shaders. If you are unfamiliar, shaders are little programs that typically run on computer and console graphics processing units. They tell the GPU how to draw pixels to the screen.