As mentioned in my previous post, I plan to move all my projects to use bunjs.

So in that process, I'm scrapping some old projects:

• extract some kind of demo out of them
• stash them

My goal is to send my projects to the graveyard, in a way that I can still go back and take out ideas from them, and that anyone can use if they have a better idea than me on how to use them.

The first one to go will be dok-gl-canvas.

As all project I start, I always think that I'll turn it into a nice solid engine which I'll be keeping forever, but it ends up becoming scrapped. That said, there are a lot of interesting ideas from that project that I want to document and reuse in the future.

The basics

There are three packages of that project:

dok-actions

This component translates NAPL objects into actual javascript code. It supports various basic coding logic:

• For loops
• If statements
• Calling subroutines
• Storing variables
• Pausing execution
• Executing game loops

Within this repo, there is a demo with an editor where you can write NAPL code and it will just execute it.

dok-gl-actions

This component is simply the schema. This makes it easy to build up NAPL code in JSON or YAML within an editor, having intelli-sense on some properties.

dok-gl-canvas

This component contains a React component that wraps a canvas and can be added on any webpage. Using NAPL code, we can execute WebGL commands.

The example shows various things it can do:
https://jacklehamster.github.io/dok-gl-canvas/example/build/

The Good

I had a tough time, but I reached the point where I could show actual WebGL animations,

I liked how I could represent different demos simply by having different NAPL code that was using the same underlying JavaScript codebase.

The Bad

It wasn't clear that the NAPL code was easier to work with than just writing JavaScript. Whenever I encountered an issue, it was difficult to debug, and I wasn't sure if it was part of the NAPL code or the underlying JavaScript code.

I also realized that adding more features would require a lot more JavaScript code to be written, which defeats the purpose of having a separate language.

The Ugly

One of the concept that NAPL wasn't able to handle properly was asynchronous calls. I couldn't load two separate images in parallel, and process them properly onLoad. As I looked further, it seems like some design flaw prevented this to work and the fix would require a deep redesign.

In Conclusion

This project was interesting, but the design flaws at the end made it difficult to work with. In future projects, I need to make sure asynchronous calls are handled properly right off the bat.
Having the WebGL engine configurable fully with NAPL code might be useful. It could provide the flexibility to change game genre on the fly. I'll try to explore this further in my future projects.