GameDev on Eturnip.com

712

Mon, 29 Jun 2026 00:00:00 +0000

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.

There is a trend that I am noticing in my explorations. Sometimes it can look like the game industry is dying, but that’s only because it is moving from one place to another, from one style to another, from one type of development to another. If your eyes are still on the old venues, yes, it will very much look like the game industry is dying. It never is.

I was playing some older arcade games and when you start to leave the 1990s and enter the 2000s you can see the ideas dry up. The arcade games become copies of copies of older games. It looks very much like the game industry is dying.

In the early 2000s game consoles went online and the people that played games didn’t frequent arcades anymore. They moved. They went home. They took the games with them. Gaming wasn’t dying, it changed.

One of the most expensive games ever made will release soon. It will probably do incredibly well. We probably will never see a game development that expensive any time soon. The level of production that can create a GTA6 just won’t happen again. When no game comes along to top it, that will look like this is the last gasp of a dying industry. It won’t be.

Games and game development is in the process of moving. It will move to the small studio creating something unique and new. It will move to individual developers creating experiences that are cherished by a smaller group of fans. They will be funded through direct sales, donations, and patrons. The creators of these games will be in direct communication with their audience in a way that a massive production never can.

Many of the massive companies making games today will fail and fold. This will appear to everyone still looking at where the industry used to be as an industry in decline. A death. It won’t be. People play. It’s what we do.

Someone right now is building a new collection. This collection includes works from creators that interact with their audience through twitch streams and regular small game releases. Those experiences aren’t peripheral to the games. They are integral to how this audience will play.

The game industry ten years, twenty years, from now will look different, but it isn’t going away. People play games. Old, new, big, small, expensively produced, made in a bedroom and given away for free. All of them. People play games, because games are fun. People make games for the same reason, and they always will.

711

Mon, 22 Jun 2026 00:00:00 +0000

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.

I have about 7000 problems left on this tiny side project, but today I solved some of them.

And that’s pretty good.

710

Mon, 15 Jun 2026 00:00:00 +0000

It ain’t perfect. It’s not even that much fun. But it works.

707

Mon, 25 May 2026 00:00:00 +0000

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.

Why not just use sprites?

Because. That’s why.

Anyway, I have made all of these neat systems, but I haven’t done what I really should have and turned all of those systems into a reusable template.

Well, now I have.

Any I started working on a little test scrolling shooter. But with a time travel mechanic.

Anyway, this is a test of that template.

703

Mon, 27 Apr 2026 00:00:00 +0000

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.

I spent a few days moving most of that work over to a couple of shader functions.

The result is that the CPU is now basically doing no work and the GPU is also doing almost no work, because even the weakest of modern GPUs can shift the small amount of pixels I am demanding of them without breaking a sweat.

Anyway, here is a video clip of the game running. Compression has really done it dirty so I might re-record this later and swap the video file.

701

Mon, 13 Apr 2026 00:00:00 +0000

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.

My main goal for the next month or so is to finish the most basic part of the play loop. Go out, find victim, get them out of danger without hurting yourself, do any rescue work required to stabilize them, get them back to your ambulance. Now do that four or five more times. That’s it. That’s the loop.

Then comes all the fun stuff. Building out levels. Adding new hazards. Working on the meta progression of making enough money to buy new equipment and supplies, while navigating a capitalistic dystopia… that’s all for the future though.

For now, it’s just get the loop done.

I already have a bunch of those systems built, but they aren’t bolted together in such a way that I can play the game yet. I’m a little scared to dive into all that, but I am also very excited to be able to play the game, even in a very prototype way.

I told myself at the start of this project, that if I couldn’t get it to look like an alternate history version of a 90’s arcade game, then I wouldn’t keep going on it and I would work on something else instead.

Well, is sort of looks like an alternate history 90’s arcade game where they had unreasonable levels of realtime lighting tech to work with now. I guess I did that. Time to take the next step and make it play like an alternate history arcade game with physics and ragdoll and analog control.

I hope it works.

697

Mon, 16 Mar 2026 00:00:00 +0000

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.

Except, of course, it doesn’t. I am making a fully 3D game using all sorts of modern shader trickery. Everything on screen is made of texture mapped polygons with all sorts of digital clamps applied to make it look like it is a 2D pixel art game.

Why?

Why not.

We have the whole world of possibilities and aesthetics available to us. This is the one I wanted to make.

In trying to get the orthographic perspective right I have worked through a lot of options and experimental processes. My current setup has me running standard 3D models though a geometry nodes process in Blender to have them come out at the proper skewed angle. It has worked well.

This weekend I went to an indie work event and a five minute conversation with another developer made me realize that I should go back to an earlier process that I had thought about and abandoned as too fiddly or costly or beyond my abilities at the time. Coming back to it, with my current level of understanding of shaders, it turns out it was actually pretty simple.

All of my meshes are pretty low vertex count affairs and they all need fragment shaders run on them already to make them look like pixel art so what’s a few more nanoseconds of processing to have the meshes skewed to an orthographic angle in the shader.

I wrote, implemented, and tested the shader in a couple of hours. It would have been even faster if I hadn’t spent a bunch of time messing around with different ways to test it out.

This does mean that I need to reorganize some of my game files, but it will mean reorganizing them to make them simpler, not more complex.

Turns out, I should go talk with other devs more often. It’s so easy to get stuck in a groove when you already have processes and tooling set up. Sometimes other avenues are not as far away as they appear.

695

Mon, 02 Mar 2026 00:00:00 +0000

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.

679

Mon, 10 Nov 2025 00:00:00 +0000

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.

668

Mon, 25 Aug 2025 00:00:00 +0000

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.

I think that last point might be the worst one.

In the recent past, I have been creating a lot of shaders. Shader programming has very specific requirements, and it’s own semi-specific language designed around manipulating triangles and pixels. Mostly pixels. I’m about as good at shader programming as I am at C# or python, which is not very. But I have been manipulating pixels for a long time, so I have a pretty good intuition about what is and is not possible in that space. I know roughly what effect any particular math operation might have on a pixel or set of pixels.

I can make a good shader. Still, I’m not great at programming them. My code is messy and probably not as efficient as it needs to be.

I have found LLMs like copilot or chatGPT invaluable for this. But there is a catch. I have tried to describe the result that I am looking for from a shader and found that none of these LLMs come anywhere close to creating a usable shader. It’s always borked in some new and exciting way. On the other hand, I am very good at writing code that works but is otherwise awful. The LLMs seem to be pretty good at cleaning that sort of thing up. Organizing and documenting. Pointing out small changes that enhance efficiency. When you are running a program every frame on every pixel, those efficiencies add up.

A bit ago, I adapted a fairly complex texture bombing shader that came on one of the old Nvidia GPU gems books. I could get it running in godot, and even managed to make it run fairly fast. I used an LLM, and it cleaned and organized. My framerate went from a few hundred (already respectable) to thousands. It made a few small tweaks that I may have gotten around to at some point, but I didn’t have to. The best part is that it made my code more readable. When I went back to the shader weeks later, it was so much easier to parse.

I haven’t really tried to use LLMs to create anything from scratch, because they do seem fairly bad at that, but I think I will continue to code badly and use them as an assistant to clean things up for me.

I won’t be using them to create art - ever - so don’t ask.

659

Mon, 23 Jun 2025 00:00:00 +0000

For now, this is some fire. I think this won’t be the last version of this fire.

655

Mon, 26 May 2025 00:00:00 +0000

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 changed something pretty fundamental to the graphics in my game, but I think it will be tough for people to figure out what changed, and that’s great. Exactly what I was hoping for. This is where I would probably bore you with the technical details, but I think I will just hold onto this one. I wanted this game to look sort of weird, and I think I might have achieved that now. It will look weird and most people won’t know exactly why. Anyway, enjoy some screenshots and videos if I happen to get them working.

(I haven’t gotten the videos working… yet)

651

Mon, 28 Apr 2025 00:00:00 +0000

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.

One of the main reasons is that Godot is open source and free to use. Of course, that means that the tools and engine features aren’t as well developed as some of the other engines out there, but it also means that I should be able to keep using this particular version of Godot for as long as I want. My ability to keep working on my game isn’t subject to corporate whims.

Now, there is no guarantee that everyone currently working on Godot won’t suddenly quit, or that they won’t change the license terms to make it unpalatable or impossible to upgrade to a new version of the engine, but the current versions are under pretty permissive licenses. Nothing is 100%, but using Godot is, currently, a pretty safe bet.

The other reason I’m sticking with it, is that I can sort of bend it to do what I need. I am making a retro-looking 2D game that is actually nothing of the sort. It is a set of fairly complex shaders layered over 3D polygons and dynamic lighting systems. This is probably not the way most people would go about creating an arcade style pixel art game, but that’s what I wanted to do. Godot lets me create that.

Just this past week I had a technical issue with malfunctioning positioning, but, because you can sort of bend the engine to do what you need, I changed some scripts, wrote a couple new ones, and fixed the issue. Of course it wasn’t as easy as that sounds, and it took hours of very annoying testing and bug fixes, but it works now. I’m sure I could do similar things in Unity and Unreal, but not without difficulty. Some of the ways they work can be shockingly inflexible.

Work on the game is still progressing slowly, but it is progressing. In the last little while I made some pretty major updates to the way everything is rendered, that is not only faster and more memory efficient, but it looks better too.

One day I will get enough of it pieced together to put a demo on Itch, but that day isn’t today. Today, I’m making 3D tiles, gantries, and door frames.

646

Mon, 24 Mar 2025 00:00:00 +0000

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.

645

Mon, 17 Mar 2025 00:00:00 +0000

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.

These are just drawings, but the model will be coming along shortly.

623

Mon, 14 Oct 2024 00:00:00 +0000

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.

I had been using a sort of hybrid shader that was part stuff I downloaded from godotshaders.com and part I wrote myself. Eventually I had replaced enough of the stuff I had downloaded that I figured it was time to just pull the bandaid off and I wrote a new shader that only incorporated the things I needed.

Now it’s a simpler effect, but one that does only what I need.

I also wrote some more of the interaction code that lets my player character use and toss items and tools. I think that means that I only have a few more systems to get up and running before I can make a vertical slice.

My goal is to be able to get a full mission of the game out for people to demo. I would like that to happen in the next couple of months, but I’m also being realistic. I only work on this game a few hours a week and achieving any progress is a win in my book.

I think I will do a little work on the throwing mechanics now. Should be fun.

621

Mon, 30 Sep 2024 00:00:00 +0000

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.

I think most artists don’t want anything to do with shaders. They are technical, the programming languages used to write them are a little arcane, and they don’t really offer the instant feedback of making a mark on paper. I think a lot of artists find creating or working with shaders sort of antithetical to making art. I know this, because they have told me as much.

I sort of love it.

I don’t know if I am actually that great at working on shaders. I have to consult cheat sheets for a lot of the basic functions like matrix rotation transforms because I don’t have those committed to memory. It sometimes takes me a minute to visualize some of the vector math. But still, I sort of love it.

I think of it like this. In the realm of digital art, especially realtime 3D game art, knowing how shaders work is sort of like making your own paint. You certainly don’t have to mix and prepare your own paint to lay color down on a canvas, but if you do know how paint is made, you are going to know how each pigment will blend, how the medium with flow. You won’t just be painting. You will know how paint works.

There is a huge incentive to specialize when working on commercial games. Stay in your lane. Only focus on your part of the assembly line. For an artist, that might mean only creating textures or only building models, with no concern for the people before or after you on that assembly line. You do your job and they do theirs. That’s fine I suppose, if you have an assembly line.

When you don’t have people before and after you on the line, when you are the line, it becomes very important that you understand how your medium works. My medium is digital graphics. Part of that medium is programming shaders to run on GPUs. Even if it’s not my specialty or I’m not the greatest at it, I think it makes me better at the rest of my work to understand how shaders work. A big part of that is making them. And I sort of love it.