Today, I released Konkan Coast Pirate Solutions on Steam. It's a cozy puzzle game about helping pirate ships do pirate things.
These are some of thoughts and notes I have.
Before Zig and Gamedev
I wanted to learn a lower level language, and that's how I got into C. I just needed some kind of project to work on, and that's why I opted to make a game.
I made one small game using just C, and it can be quite a roller coaster. From having to understand how memory management works, to dealing with all the footguns. But I quite enjoyed it. I felt like I finally understood a bit of what was happening under the hood.
When I started making KCPS, I was still using C.
What got me off that was just the complexity of the build systems. It caused a lot of weird issues and I had no idea how to deal with them, or any interest in learning how to.
I had known about zig for a while at this point. Also some other languages like nim and odin. I selected zig mostly because of the talk that Andrew gave about The Road to 1.0. A lot of points that he made really resonated with me, and I decided to commit to zig.
I was already used to SDL, and since there is a sdl-tetris repo available, I just mostly copied things out of that. I started off in v0.7 and the release is in v0.10.
After the initial learning curve, I really enjoy writing zig. It feels like C after all the years that we have had to see what went right and what went wrong with programming languages in general.
It's a lot of the smaller things. Slices, namespaced struct functions, enums, standard library, @embedFile etc.
For the most part, the language just stays out of your way, and that's the way I like it.
WASM. Since zig has first class WASM support, I was able to make a web version at one point during development. Here's how I did that.
The compiler is still a little slow. At an approximately equal project size, C was compiling in less than 1 second, while zig took ~4 seconds.
Windows is not really a first class citizen. Running
zig build run on an unchanged project still takes ~1 second. This is not an issue on linux.
Similarly, for a long time, release-fast was broken due to some
And after some point in mid 0.9, the latest versions were not able to build my game, and they wouldn't log to terminal, so I couldn't even figure out the problem.
The Mostly my faults
I had never really intended to release and complete this game. It was just something fun to work on. As a result, I would semi-randomly update to the newest nightly versions, and have not kept any track of that.
So unfortunately, I don't think I can build earlier versions of the game, unless I want to trawl through various versions and/or make huge source changes (allocgate etc.) to each historic branch...
My Only Pet Peeve
02 Mar 2023: edited for clarity.
I vehemently hate whitespace requirements for binary operator.
const big_size = size *12.5; // error: binary operator `*` has whitespace on one side, but not the other.
I often use the autoformatter to fix my lazy formatting, and the uniformity required for arithmetic operators is what I want the computer to do for me. I get why it's in place, but it's only an issue with
-, I don't like that all the operators are covered in this rule.
Honestly, it was a lovely experience. I definitely see myself using zig more in the future. Especially for the WASM support. I'm excited for incremental compilation and hot-reloading. That would be amazing.
If you are looking for a language to make games, I will whole-heartedly recommend zig.
Congratulations on the release! I'm looking forward to playing this.
I deeply apologize for the negatives. I hope to address all four of these problems for future game developers, though I realize it would be too late to help KCPS.
I also think your suggestion to zig fmt regarding unproblematic binary operators is a reasonable one and would support such a change being made to the compiler.
The negatives were really small in the overall experience, and I appreciate your commitment.
That would be a nice change.
Wow great game! I just finished the main story (didn't do all the optional "Star Puzzles"). It felt polished and snappy, it was a joy to play.
I have some feedback if you're interested.
A few times I accidentally clicked through the dialog and missed some of the story. One idea that comes to mind is a "back button" to go to the previous dialog if you accidentally clicked it? Another idea would be to have some sort of transition animation when the dialog first appears which gives the player time to realize the dialog is coming and to stop clicking the mouse. Maybe this is just a me problem though, sometimes I liked to quickly click the "step" instead of play since I could click through it faster.
Again very nice job on the performance! The only time it felt odd was sometimes the animations would "reset" if you clicked "step" too quickly (before the rewind was complete for example). This was a little worse when there were multi-stage animations (like the currents).
I enjoyed the old "VCR button" aesthetic and the trays, the sound effects were great too.
I was also thinking it could be fun to play some of the levels on my next Twitch stream. Let me know whether that would be ok or not and if so how far into the game do you think would make sense to stream (so as not to give away too much of the story/gameplay).
Thanks so much.
I appreciate your points, and agree with them. I was too far into the project when I noticed them, and decided that it was not worth the effort to go back and fix. I will be keeping these things in mind for the next projects though, so thanks.
Sure feel free. I have no restrictions in that regard, you can show what you think makes the best stream =)
Can you provide a bit more background for "the unary operator zig fmt requirement"?
It's the situation where your code
with the error
It might be a compiler requirement, not zig fmt.
I was just saying from the perspective of how I use the autoformatter to clean up whitespace issues, but this is not considered a whitespace issue, but a bug.