itch.io Community » Game Development » General Development

Ever made a game in your own programming language? Well, I did!

A topic by Daniel Brendel created 29 days ago Views: 221 Replies: 5

Viewing posts 1 to 3

A game in my own programming language

Yes, it was about time. I started developing my own programming language a few years ago and it's matured quite well, so that I tested further how far I could go.

I made many practical real-world scripts and applications and of course I wanted to make a small game with it.

But let me explain a bit more.

My programming language consists of two parts:

The script interpreter

So, my programming language is actually a scripting language. I got hugely inspired by AutoIt and AutoHotKey, which was very popular when I was a teenager around 20 years ago (wow!). Thus my scripting language is very similar.

The interpreter essentially consists of a C++ source and header file, and is designed to be used within your own C++ projects to outsource tasks in scripts. I used it in two projects so far: An own custom web server with backend scripting functionality and in my own scripting shell. The former project is lost, but the latter is progressing well! Meet AquaShell.

The scripting shell

AquaShell is a scripting and automation shell that I personally use as a substitution for PowerShell or cmd.exe. So far I've created many useful automation scripts, as well as complex scripted applications. And one of the scripted applications is a small asteroid inspired space shooter. :D

That said, the game is laggy as hell. Imagine writing a game in PowerShell, AutoIt, AutoHotKey, Tcl or whatever. But the flaws is also that my scripting system interprets on the fly. There is no VM or any other thing that would speed up running graphical applications. But it's fine. I mean the shell is not designed for that purpose, but it's funny to see how far you can go.

If you want to see the result, here is the game page, covering a demo video, screenshots and a download. But note that AquaShell is of course required to launch the game. Also AquaShell and all associated projects are open-sourced software using the MIT license.

https://danielbrendel.itch.io/aquaspace-game

Like Reply

Daniel Brendel22 days ago

Update: I've added the latest version of AquaShell x64 to the downloads of the PoC game.

Like Reply

crazyhoundgamedesign22 days ago

This sounds like an interesting project.

Do you have a goal in mind for using the language?

I'm not trained in computer science, but if you wanted to improve performance, have you ever looked at how a native c++ or other natural programming language operates?

As I understand things, the normal process appears to be that programs coded in languages like c++ are directly converted to machine code when compiled, where as for a scripting language, the code is interpreted back to machine code via a VM, or a similar process through a natural programming language, that converts the script on the fly.

If you were able to perform that interpretation on building your program, you could possibly increase performance without a VM because you wouldn't need to interpret the scripting language on runtime. If this reduces the flexibility of your language, then you might need to build something akin to a VM that can convert your script more quickly.

Again, I'm not an expert, but I would think a VM would act like an interface for converting your script into machine code. Your script would likely need to be loaded into memory and then the VM would interpret what is needed at the correct time (e.g. functions and classes, routines and co-routines).

Either way you look at the performance problem, it seems to me that you would need to go from your scripting language (user friendly), back to either a natural programming language or machine code (computer friendly). And either at build time or run time.

Hope this gives you some ideas. I can tell you now that I don't have the knowledge to help further, but good luck with it.

Like Reply

Daniel Brendel20 days ago(+1)

Hi, thank you for your response!

You're right, for a native running program, it's compiled and then linked together, so in the end it results in byte code that is run by the processor of the computer, where scripting languages can be interpreted by a VM via turning it into an intermediate byte code with an own designed instruction set, so execution is faster. Yes, currently my script language interprets on runtime, which is the bottleneck here. I've considered to build a VM system, but then didn't go ahead, as the original purpose of the language is the same as AutoIt or AutoHotKey: Performing administrative tasks or creating scripted applications for specific tasks. And for that it runs just fine.

But recently I thought, it would be cool to also make it way more performant speed wise, so you could also create more small games with it. I'll need to do some research tho, as creating a VM for a scripting language is not that trivial, but definitely doable.

Thanks for liking my project. :)

Like Reply

crazyhoundgamedesign20 days ago

Thanks for the response. It's reassuring to know I have some idea of it should work over all.

I guess how you expand the project depends on the focus you want to take. I get your initial goal was to make your own high level scripting language, and it looks like you've succeeded.

I like how you tried to push it to its limits as well.

I'm not aware myself of a scripting language flexible enough to be performant without a VM or similar set up, but it would definitely be interesting if there are other ways of doing this.

It also sounds like you made your own console application? Would there be a way increasing the capability of the console to run more like a VM for scripts read from file over using command line input? This could maybe include more instructions, more variety or more granularity for loaded scripts, vs simpler instructions from direct input to try to manage process times between the 2 approaches?

Like Reply

Daniel Brendel18 days ago (1 edit) (+1)

You're welcome and thank you for your appreciation!

Yes, I definitely succeeded in making a scripting language that fits its purpose. But yeah, at some point one wants to expand even more. :D

For performance, you cannot really avoid a VM. For games I think the so called phenomenon of amortization solves it. You trade one cost of just-in-time compilation to byte code for your VM, but gain large performance improvements for scripts that run for a longer period of time, which applies to games. The cost of compilation is amortized by the runtime performance improvements. If you want to even go further, you can use ahead-of-time compilation, however this goes with the development cost, as you would always need to recompile before testing. Or you support both ways, JIT for dev/debug and AOT for release builds. :D

The console application is basically just a REPL, which means you can interactively execute script code or enter commands, similar to cmd.exe. It's basically just a user interface. The heavy work happens mostly behind curtains, so to speak. The host application however can also be launched with providing a path to a script to be executed. If that's the case, the REPL is hidden and the host application exits once the script has finished. So, if you want to type in some script commands, you just launch the shell. If you just want to execute a script, you launch the shell with the path to the script - and optionally arguments that can be provided to a script.

Like Reply