Last time, I shared with you an experiment where I used AI to make Pong in one of three frameworks. Each of them had its pros and cons, but a choice had to be made.
And I decided to go with Rust.
Why? Well, configuration was the least troublesome. Macroquad is a little bit like Raylib (it is inspired by it), only the language is newer.
Cons? Well, although portable to Linux, Web1, Mac, iOS, and Android, there are no mentioned successes when porting to consoles. It is possible, I think, just not documented. I'm afraid no publisher will be able to assemble a team of Rust developers experienced in porting to consoles. But then again? Why think about consoles when you can rock the PCs! Seriously, that way of forward thinking is clouding something more important, which is making games!
Let's drop the ambitious dreaming of selling on consoles for now.
In the meantime, I created a newsletter (Rusty by Choice) in which I will document my learning of Rust. Didn't want to bore you with code here. The other one will not necessarily be a regular newsletter, but this newsletter taught me one thing: if you want to progress with anything, make it a newsletter.
I did say that learning a programming language is not the goal with AI. I still stand by it, but I want to understand what the AI will write for me, so I will do some small code experiments. Join if you like. You won't lose anything if you don't ;-)
But before AI writes my games soon, I still need to decide what to make. I need to refine my workflow2. And fast.
What should a great workflow have?
We all know that one should not start with their dream game3.
Since I already note game ideas, I need a way to choose from them. And nothing helps more than a little prioritization by segmentation!
Segments like:
1. Complexity
2. Iterative
3. Templative
How did I refine complexity?
You probably remember when I created this. Since then I learned that this complexity measure is... too complex. It is redundant in itself, so I decided to keep the differantiation of 2D/3D in a separate field.
The current complexity measure I use looks like this:
1. Jam - the proof of concept as a game. It can be done as quick as a game jam.
2. (formerly single-I/A) Gameplay-Focused - it's a little bit like Jam, only requires levels, enemies, etc.
3. (formerly double-I/A) Requires Written Content - Story, usually. It's basically gameplay-focused but with actual story.
4. (formerly triple-I/A) Requires top-level art. An idea that can only work with beautiful art.
It's much simpler and more descriptive. The I/A was good when comparing to the real world, not really when I was assessing what complexity level an idea is. Now it's much better. I managed to judge my ideas in two evenings 😉
How do I want to achieve an iterative workflow?
By iterative work, I mean make a game, show it, and then make a better (more complex, more beautiful, more experimental) game based on the previous game. A solo developer cannot jump too much; he has to focus4 so that he does not waste too much time and effort.
One of the best examples of iteration, even if not made by a solo developer - is the Metal Gear series. Every game built upon the last one, added new features to stealth mechanics, and ended with the genius gameplay of The Phantom Pain.
But since I'm not Hideo Kojima, I need to think about it differently. So I decided to switch from thinking in genres (kinda) to thinking in iterative levels.
Let's say I make a top-down shmup. This will give me the basics of a top-down game. Let's call that a level-1 top-down game. Where do I want to go from here? A classic 2D Zelda? Maybe a chess game like Fire Emblem? Or maybe a 2D RTS? All of them, which I will call Level-2 Topdowns, will build upon the Level-1 Topdown but will introduce mechanics/controls that will be different from each other. It does become a game from a genre, but I think more about mechanics and perspective than genre, which I consider too high-level.
What do I mean by templative?
Well, if you want to use the benefits of iteration, you will want to reuse code from previous projects. Once you can use the code for the previous game as the basis of the last game it would work like a template. It's more of a code thing. In Rust, it should be very easy, from what I've seen. In .NET, it wasn't. Only recently did I learned that you can export a complex project as a template and reuse it again (and replace all the metadata). The .NET ecosystem can sometimes be so bloated that I learned this thing after 10 years doing .NET.
---
Currently, I'm learning my new tools. Already tried Cursor and Visual Studio Code with Copilot. I guess I will try Windsurf, because it's a little bit cheaper than Cursor. After that, I might be capable of choosing the best option.
Prototyping on a website does sound like a great idea.
Hey, Chad G. Petey, refine my workflow 😜
What is my dream game anyway? I don’t think I know that.
Says the man who jumped ship once again