Since I pushed the previous demo last March, I had trouble continuing working on Typingvania in Godot. I disliked how there was no good, consistent way to generate resources: I had to run the engine in console mode and then delete and add the resource in the UI, and wait for a few seconds while it got processed. I quickly picked up GDScript and I liked it, but I couldn’t use for anything else — just like Swift at work. My book resource was as compact as I could make it in Godot but the game still required 1.5 GB RAM. Meanwhile, I was working on the key feature of the game, the word picking algorithm, and GDScript emphatically wasn’t helping.
Maybe I was doing something wrong, I saw many people have great experience with Godot but I needed more control over my data and its layout than the engine afforded. I took a break to work on Hayaku for a few months, and that went smoother because the requirements were simpler.
Come end of the year, I decided that Typingvania won’t be another failed project. Every other year in December I try to do Advent of Code (and invariably get exhausted by the end). This time I thought, what if I work on Typingvania every day in December instead of writing throwaway code and not even enjoying it? I noticed SDL3 with the new GPU API was practically released and thought, why don’t I go back to the ground truth? I’ve tried so many engines for Hayaku and now Godot wasn’t quite working out. Why don’t I write my own game engine? (Fast-forward: it worked out a treat!)
Unfortunately, I’m a programmer first and enjoy writing code, so in my mind producing a crystal of a program that I fully control has utmost allure. I have read all the arguments and knew all the pitfalls and still decided to do it. For those who don’t know, making an engine is The Curse™ in gamedev where you spend an inordinate amount of effort making a “universal” engine instead of shipping your game — I was fully aware of that.
To make things worse, I decided to use plain C. There were a few reasons that made it attractive for this project: it’s simple and you can’t forget it (like Go that I use for tooling), I needed to use several C libraries (SDL and FreeType), I wanted the project to run anywhere (it compiles and runs on my 32-bit Linux netbook), I didn’t want any dependency drift. At the end of the day, there’s a certain charm about C that I wanted to fully experience, and what better way to do it?
If it sounds like I’m making justifications, I do. I had to justify to myself why I was choosing the most inefficient way to make a game instead of using an engine — and a working prototype — like normal people. I haven’t written about it, but I have a history of becoming apathetic towards work in progress and it losing perceived value, which results in me dropping it. I did it many times. Now I know that even if I’m “committing” to this project, there has to be something else that keeps me coming back to it again and again. It’s only my side project (I have a full-time job) and there has to be something (or several somethings) that make you go: OK, I’m tired after work but I’ll sit down and work on it for a few hours. For Typingvania, both the technical aspect and the fact that I had a prototype that people liked kept me going, and only one of them clearly was not enough.
Since I already had the data model in place for generating the Godot resource, I decided to work on the hardest bit first: the word picking algorithm. Potentially, I could make a C library just with the algo and hook it up to Godot. To my surprise and after only a couple of weeks of effort, I wrote a binary serialization system that produced a file of only 4 MB in size and loaded it instantly and almost directly into memory. I scrapped my previous approach that didn’t quite work and came up with a new fast algorithm for word picking that produced dozens of suitable words in microseconds. When I had it onscreen (in glorious SDL debug font) I knew that this was progress more significant than cooking up some simple UI in Godot.
With that in place I started on showing some text and the learning curve was so steep I almost fell off.
Usually when you render text, you grab FreeType by the handle and it produces some glyph bitmaps for you that you pack into a texture. You know where this is going, right? Ever since it came out, I was fascinated by Eric Lengyel’s Slug library that rendered text on the GPU. I wanted resolution-independent text. Now that I had a lovely fresh SDL_GPU API, I thought, hell, why not make an attempt? I could always go back to bitmaps. I did and after a few days of tearing all my hair out it worked. The text below is rendered on the GPU by a shader directly from font curves and is resolution-independent i.e. you can make it any size and it resizes instantly. Why go to such lengths? Text is the primary interface in my game and I needed to be able to assign different colors to every letter and also animate each individual character, a simple “text label” you get in most game engines won’t let you do this.
The antialiasing wasn’t quite working and the text had rough edges, but I left it where it was (“good enough”) and implemented many other systems in the engine that let me do what I wanted to do: animations, input, scene graph, scene manager, text layout, somewhat reusable UI and layout, cameras, etc., etc. What Godot made me really appreciate is how many things you take for granted are already there. Implementing them is not the most difficult problem, it’s making decisions that allow all the systems to work together in unison. I didn’t mention it but my engine is also fully 3D despite being setup to show flat text in an orthographic projection — I simply didn’t have time yet to add some flourish that infinitely resizable text allows. Since it’s a shader (i.e. it works in screen space), you can also rotate and position the text at any angle to the camera and it still renders perfectly, and I intend to do it later.
In addition to word picking, I implemented what would become the base for savegames: full per-file stats. For every character that the user types, I store accuracy and time to type, from which I can derive the per-character and overall WPM. This all, in turn, gets applied during word picking to provide just the words to improve the weakest of the more frequent characters and even out your typing speed across the whole spectrum. I’m quite happy with how this system turned out and this is the unique proposition of Typingvania that differentiates it from the lot, not the UI. I know that Keybr has a frequency spectrum for characters, but it’s poor in word variety compared to Typingvania and my algorithm works across the whole spectrum at once — the user is training not one but several characters at the same time, picked by several criteria.
Just before the last playtest in the beginning of March, I descended on the shader with a vengeance and managed to fix the antialiasing (it was incorrect alpha multiplication), so now the text renders perfectly on any background and even in small resolutions the edges are smooth. The shader approach is less efficient than bitmaps (that’s why it’s so rarely done) because the text is rendered from scratch every frame, but because there is not much of it, and everything else is very lean, Typingvania still runs at 700-900 FPS on my M1 MacBook Air and at 4-7 thousand FPS on my Windows desktop. (Usually it runs with V-Sync so doesn’t burn the cycles and is resource efficient, you can leave it running as any other app — and it stops rendering completely when it’s not in focus.)
As of now, I have put in most of the UI that you will see while playing the game, and as soon as I implement saves I’ll put out private builds — a few people have asked. This is the first step to publishing. There is a lot of work ahead before it’s definitely ready, but the intention is to publish it as soon as I can and keep working on it. The risk of not shipping is highest in the initial execution phase, and with the saves in place, even though it’s rough, Typingvania will be “usable” and (for me) will fulfil its original purpose of being a better typing trainer than what’s on the market.
On the roadmap are:
- Multiple UI translations (the UI text).
- Support for multiple languages (as in, books in different languages) and keyboard layouts. I have earmarked French, German, Spanish, Japanese, Russian and Chinese. For example, for Chinese you’ll be able to train pinyin typing through hints by looking at the hieroglyphs. For French, if you have a UK keyboard, you’ll be typing “e” instead of “é” and “ê”, but if you choose a French layout, Typingvania will expect you to type them directly. If you choose a US ANSI layout, you’ll type “L” instead of “£” unlike if you have a UK layout.
- Menus where you’ll be able to change settings, save/load or start a new game and choose your book and layout.
- Multiple color themes to choose from.
- Stats screen with graphs showing your progress over time.
- Many achievements because I track your every keystroke and it feels good to hit some milestones.
To finish this off, here’s a video of me typing for a couple of minutes in the current development build: