Game Development Journey
When I was young, my Dad took the whole family on a car trip across London to a computer shop; possibly the only one in London. This was at the dawn of the home-computer revolution. He bought a Video Genie. Being an organised kind of guy, he's cleared out a cupboard before hand. That cupboard remained empty. This new "toy" was never put away. I was still in junior school, and I was the only one with access to a computer.
I meticulously typed in programs from books and magazines. They never worked, partly because typing in so much code without a single mistake for too hard, and also because the code was always for a different, more popular computer. Even those that partially worked were rubbish. They were BASIC programs, and BASIC was too damn slow for video games. So I started to learn machine code. No teacher, just a single book.
Many years later, we had upgraded to a BBC Micro, and there was a game called Repton Infinity. It was more than a game, it was a game engine, with a (primitive) scripting language. Finally, writing games was easy. It took care of the hard parts while I designed the fun part. But it was so very limited.
Many years later, (computers were now ubiquitous), a Java programmer asked me about writing games. I explained that Java didn't have libraries suitable for games. Hey, why don't I write one myself. I took a high-performance C graphics library and wrote a Java wrapper around it.
At the same time, my nephew was showing interest in computer programming, but he'd never used Java, only Python. So I wrote a small piece of code around PyGame which hid some of the complexities. I would have loved this when I was young. I got carried away, and ended up with an entire game engine called Itch (a nod to MIT's Scratch platform). But it was a hot mess. For some reason, whenever I use Python, I write garbage code.
Back to Java, and Itchy was born. The GUI editor used my previous same high-performance graphics wrapper. But this came at a cost; I couldn't use Java's UI libraries (such as AWT or Swing). If I wanted buttons, sliders, toolbars etc. I had to write them myself. But I didn't want to write a GUI toolkit, I wanted to write a game engine. The net result - it looked and felt clunky. The game engine itself was quite good. You could write games in Javascript, Groovy or JPython. Supporting 3 different scripting languages was really nice, but I didn't really like any of them. So I wrote my own language, called Feather. Strongly typed, but far less boilerplate than Java.
But rather than adding a forth scripting language to Itchy, I started again from scratch (no pun intended). I had learnt my lesson, and this time the editor used a "proper" GUI toolkit (JavaFX). I now had a good editor, language and game engine. But there was a problem. When playing a game, it used high-performance graphics, and when editing the game it used a completely different graphics API (one which worked with JavaFX). OMG, so much duplicated code.
But it worked. It did everything I wanted. Except... It would be nice if I could run my games in a web browser. Kids can share/show off their Scratch games with a link. No need to install anything. I can't do that with Itchy.
By this time, I was using Kotlin (not Java), and it had a nifty new feature. It could be "compiled" to javascript, and run in a web browser.
OK. Just one more. A new games engine called Kyd, named after the Elizabethan playwright (my game engines use a Theatre metaphor, with classes : Stage, Actor, Costome, Role etc.)
But I still hadn't solved the issue of graphic library / GUI Toolkit.
I only have three requirements :
1. Fast! 2. Not clunky/ugly. 3. Compatible with multi-platform Kotlin.
AWT, Swing, SWT and JavaFX all fail to meet requirements (1) and (3). AFAIK, that leaves only one. It's called Glok.
If you've never heard of it, that's no surprise, it isn't popular. In fact AFAIK, only 1 programmer uses it, its author. Me.
Kyd took very little time to write. Partly because I knew the correct path to take. But more importantly, by using Glok everything fit together perfectly without any friction. FYI, I didn't write Glok specifically for this role. It started off as a toolkit for a vector graphic editor (similar to Inkscape). That project has been on hold for a while. I may return to it after playing with Kyd.
I really feel like my 40 year journey is over. Kyd is "perfect". It does everything I want. It's clean, fast and simple(ish). I can knock-up a game in a day or two. Game code is simple - no need to wrestle with complicated graphics APIs. Resource management is taken care of by Kyd.
There is one strange twist - my choice of scripting language.
All game developers know that the game engine is written in a compiled, high-performance language, and the game logic should use a scripting language. The scripting language doesn't need high-performance. It needs rapid development. Change one line of code, and test it ASAP.
I chose Kotlin.
I'm sure many would be shocked - it isn't a scripting language, it's compiled. So is Python, so is Javascript, so is Feather. As long as it compiles quickly, who cares? The JVM supports dynamically loading classes on the fly. I can change a line of code and check the results almost immediately. Running the game in a web-browser does required a slow compile (~1 minute), but you only need to that when the game is finished.
Maybe my journey has one more side-quest. There's one feature that Kotlin lacks - a sandbox. Ideally, I'd like to use a language which only has access to a small subset of the game-engine's API.
PS. Kyd isn't finished. Far from it. It doesn't even support sound yet. No software is ever finished. But the design is solid, and I have no need to change what is already written.