Choosing a programming language

A though decision | Jan 29, 2023

So, I began to work on my Ascendancy remake. I had to find the right tools for the job.

tl;dr: the port is being made in PYTHON. It was not my first choice as explained below, and it’s not ideal either.

The code will be available on Github Make sure to checkout the develop branch: I’m pretty far from any official release.

Python comes with some compromises (which alternative don’t?), but fits well into my goals.

  • The project is going to be open source anyway. Delivering the game in source code form is not a problem. On the other hand, you can make native-like executable from Python code, so users won’t need to install a separate interpreter and environment to run the game.

  • Python is fast enough. Yes, it’s 100+ times slower than hand-optimized C code and it’s slower than Java in most scenarios. But it’s fast enough to run a game that was originally designed for 40 Mhz CPUs. Plus, it has no compile times, but extremely fast startup times.

  • There is PyGame, which is more or less an SDL wrapper for Python. It’s not blazing fast, not up to date, but very easy to use, has a huge community around and then again: it’s fast enough to support a game that was designed for a 486DX.

  • Apart from PyGame, I also considered another great framework, pyglet. More on this later.

Originally, Ascendancy was written in C++, probably Watcom C++, which was quite standard in its time for MS-DOS game development.

So, one option could be to implement the remake using OpenWatcom. The project seems to be dead, and I never used this tool before. It’s not worth to learn these days. As I never used it before, It won’t give me the joy of nostalgia. Apart from that, the IDE and the C++ dialect is probably very outdated.

I need better options, here are my points:

  • Code first. After trying a few modern game engines, I have to admit, I couldn’t work as a game programmer these days. I enjoy writing code and not using a visual editor to connect the dots. I respect how these engines sped up game development, and how they lowered the bar for becoming a game programmer, but this is not what I want. I want to write code in the old-fashioned way. Otherwise, I could just ask Chat GPT to do the job, right?

  • Focus on game play. I spent a decade in my early career building game engines. Even though I want to avoid modern visual game engines, I also don’t want to code low-level tech. I need something in the middle: a technology stack that can handle most audio/video/input stuff I need, but I can implement the game in pure code

  • Learn fast. I’ve spent a lot on online courses for different modern technologies. Then I realized, I don’t want to be a professional game developer anymore. The investment in learning tech like Unity doesn’t pay back unless I want to create professional stuff later. I’m looking for a tech stack where I can have visible results quickly.

  • Fast development cycle: I want fast build & debug cycles instead of waiting for the compiler. I want the same experience I had with Borland products (Turbo Pascal 7.0, Borland C++ 3.1). Code something, hit compile button, see it running within a few seconds, learn from mistakes, adapt code, start over

  • Avoid dependency hell. To me, the most frustrating thing of modern programming environments is the constant battle with dependencies. It’s cool that there is a library for almost everything. In the old days, you had the compiler, maybe some support libraries from its vendor, or licensed from other 3rd parties and that’s it. Today you have a complex network of 3rd party libraries, constantly updated. Sometimes updating dependencies mean your code won’t compile anymore. Then the little free time you have to work on your pet project is spent on updating your code to catch up with the updates. And this is the better option. Sometimes the update fails, because the complex network of cross-dependencies can’t be satisfied anymore.

  • Modern systems: I don’t want to use emulators for development (DosBox, etc.) to create the port. It should run on my system (ThinkPad X1 Extreme Gen2, Ubuntu 22.10) natively

  • Portability: The remake must support major desktop operating systems: Windows, macOS and Linux. It would be nice to port the remake to different systems, e.g.: iOS, Android, but it’s not a priority for the moment

Options I actually tried:

  • Joke #1: Use Turbo Pascal or Borland C++. I’ve began an Ascendancy remake back in my childhood using Turbo Pascal, however I never reached any playable state. It would maximize the nostalgic factor, but would be a lot of work to create the game engine itself:. The IDE itself is also a bit outdated, lacking lots of features that I use every day: code completion, symbol browser, etc.

  • Joke #2: Free Pascal. Comes with a text-mode IDE similar to Borland products. Compatible with modern systems, although not widely used these days. I don’t want to code in Pascal anymore.

  • Use a modern game engine, e.g.: Unity or Godot. I started to learn Unity, created a simple shooter games based on tutorials. Unity is modern, sexy, comes with a huge asset repository. Would be an excellent basis to make an improved remake or a modern game only inspired by Ascendancy. However, to make a good and accurate remake, Unity is way too advanced and complicated. Has too steep learning curve and the development cycle is not efficient for such a small one-man project. Godot just seems to be poor mans Unity.

  • Modern C++ and some kind of simple and modern graphics framework, e.g.: raylib. I’ve developed a dozen games (and other applications) in C++. I loved the language. I literally felt grown up when switched from Pascal (Delphi) to C++. I developed my own multi-platform game engine that served my own 4X space strategy game Betelgeuse Brawl. I still have PTSD from C++ build systems, late night debug sessions, memory corruptions, STL syntax though. There is a slight chance to port this remake later to C++, but not for now. I need a more fluid development experience.

Other options I considered, but never tried:

  • Java and libGDX: Java is everywhere. Having an open Java project in my resume could help, right? Maybe. But the development experience is terrible. I never liked Java language itself: it seems a dumb, unfinished copy of C++. The library support for game development is also far from ideal. Apart from the short J2ME era, game developers never considered Java seriously. Even Android games are made in C++ or high level game engines and not Java.

  • C# and MonoGame: similar option to Java+libGDX, but using my all-time favorite programming language. C# is what Java meant to be: take all the goods of C++ and present them with a more clear and elegant syntax. It is also used in one of the most widely used commercial game engines today, Unity. I’ve skipped this option for two reasons:

    • If I ever going to create an improved, modern interpretation of Ascendancy, I want that to be a completely separate product. I think, using a different programming language really helps to keep things apart: no shared assets, no shared code, only inspiration is allowed

    • MonoGame is even less supported than libGDX. An enthusiastic project with a very small community and a few commercial games. Also note, MonoGame is a re-implementation of XNA. XNA was a very good framework from Microsoft, but it came with its own asset-pipeline. Less than ideal for a remake that comes with its own asset library in its own proprietary format

  • Joke #3: JavaScript or TypeScript with React or Angular: Well, it’s not a joke. I really considered it, and it’s still on the table. I have a concept to offer two different UX for the remake:

    • The default UX will use some kind of game framework to follow original Ascendancy experience as close as possible

    • An improved UX using web technologies to offer a modern user interface on top of the classic gameplay

  • Rust. The language is a rising star today, especially in systems programming. Not sure if it will play an important role in game development as well. There are many commercial game engines build around C++, and I don’t think Unreal Engine or CryEngine would be rewritten in Rust anytime soon. There is one huge drawback of Rust: interoperability and compatibility with C++: it’s not better than any older languages (Java, etc.) on the market. Rust is not compatible with C++ type system, so in order to interop with the existing game engine, you need some kind of glue code, probably written in C. Of course, it should not hold me back, as I don’t want to use these engines, and I could build my own ecosystem in Rust from scratch, or use one of the already existing indie game engines. I’ll pass it for now, but there is a slight chance that I’ll give it a try at some point.

That’s it for now, have fun!