Yet another game-engine is in the works, and you might want to pay close attention to this one.

So sure, there are lots of game engine out there, so why not another one? What does this engine have to offer?

Well, for one, this new engine is not going to price gouge its users once it realizes it's popular enough to milk money from them. Of course, that's only a promise and nobody can predict the future, so you'll have to trust me on that.

But aside from that, I have some pretty interesting plans for NAPL, which should let it stand out of the crowd, and provide an attractive alternative to all those other game engines out there.

Everything is just pure data

First of all, what does NAPL stands for?
It's stands for Not Another Programming Language.
So is it a new programming language, is it not? I'd say it's more than a new language. The idea behind NAPL is that everything that you build when producing a game, all the assets, entities, game logic, calculations... are all produced by assembling data.
You might need to write a script, let's say some logic to display a message on the screen. The code behind that logic in javascript could be alert("Hello World"), or in C++ printf("Hello there");. In NAPL, that command will be represented purely as an object, which can be serialized into JSON or YAML. This might not be the exact syntax, but it could look something like this:

{
   "message": "Hello NAPL!"
}

Why does it matter?
Well, it does give programs a lot more flexibility. In a language like C++, Java, C#... the code is compiled, then it becomes inflexible at runtime. You can't really come up with a string and turn it into code, and run it at runtime.

In interpreted languages like JavaScript or PHP, you could do something like that, although there are security measure to prevent this.

NAPL lands in the second category, where you will be able to turn data into code at runtime. This lets you do things like generating some code on a client, and send it to a server which will execute the code, then send back the program with some result and it will finish executing on the client.

That said, NAPL being purposed as a game engine, it has other use for that flexibility.
Imagine being able to have a game running, then just change its code on the fly to modify its behavior. You're making a platform-game, and suddenly need to provide the double-jump ability to your character, even though it's not yet implemented. You should be able to just generate that object, send it into the game, and see the result right away without even restarting the game.

This provides flexibility for game developers to iterate on their game.

Component for any platform

Your NAPL program will execute within an engine, embedded in the platform you are using. This can be the web, iOS / Android, or it could be within another game engine like Unreal, Unity, Godot...

This helps the game developer break free from the shackles of an engine. Let's say you have been developing your game in your favorite engine, but they suddenly change their pricing plan and you're now million dollars in debt because your business plan didn't account for it. As a NAPL developer, you can take the core part of your game and port it into another game engine.
Remember how Adobe Flash was the engine of choice for making web based games in the years 2010-2020, until it became obsolete? This could happen to any game engine. Also do you recall what happened to Stadia.

All this to say that you can't rely on being comfortably dependent on one game engine. You need the ability to pivot at any time. NAPL provides that flexibility, without the need to rewrite your game from scratch.

Of course, the idea is that the NAPL engine will need to be written in all those different platforms and game engines, but that's just a one time task per platform, and hopefully I won't be the only developer doing it.

One might say that some engines are way more capable than others. For instance, you can't get the same 3d realism in Unreal as you would on a web game.

The NAPL engine will support all the basics of your typical game, but to make the most of a platform, you would need separate components specifically in that platform to take advantage of it. For instance, a NAPL game running on the web would have less special effects as its same version running on Unreal. In some case, developers might want to restrict their game to certain platform. While the goal of NAPL is to be multi-platform, it doesn't prevent that possibility.

A codeless future

Another important aspect of having NAPL being entirely object based, is that it can be represented visually. Essentially, one could imagine a NAPL program built entirely by assembling visual components, connecting them, specifying some parameters...

So NAPL could potential enter in the category of tools that allow code-less programming.

Given that NAPL will be open source there's a chance for everyone to just build tools for it, once the language becomes popular.

So where's NAPL at right now

Admittedly, not very far. I did start the work on it, so it's more than just an idea up in the air, but it's far from complete. Usually, I wait until I built something solid before putting out into the world, but this time, I've decided to put things out a bit earlier.

Rather than keep the idea under wrap, I hope to gather some support or feedback. Perhaps I can find a community that works on a similar problem, and join the effort.

Either way, I hope you find this post inspiring, and please follow to keep up with my progress!