I’m just trying to do something simple

I’m just trying to do something simple

Alright, I think last time it was a bit too long, so I’ll shoot for short and sweet today. I am extremely tired, but even my mum understood my pain, so anyone really should get what I’m saying here. And I’ll try to not enumerate all the implications.

Goal: build a cross-platform idle game

Task: prove concept of combat system implemented as two loading bars operating at different speeds

Dev or not, how hard do you think the above is? I thought it was simple. I was wrong. My original daring idea was to build a website and package that for other platforms using Tauri. Boy, oh boy, I was rudely awoken.

Here’s what I wrote: loading bars

Now, if you see what I see (after you click the button), despite the other bar is supposed to be 2x faster, you can clearly see that is not what’s happening. I tried recording video of it and going frame by frame and it seems to be simply offset. Originally I thought the offset is variable. Nevertheless, this shouldn’t be a hard problem, so I thought maybe I’m approaching it wrong and I asked for help.

I was given feedback on how to fix some bugs (that I didn’t bother to fix - click the button multiple times and see) and also on how to fix my issue. You see, you’re not really working with JS. You’re working with web APIs. But let’s not get technical. The answer is, I’m spawning two timers and due to <insert excuse for using legacy systems> they can’t run at the same time. I should rework my code to use only one timer.

Well, damn. I must admit, this made me give up. I probably would have been able to find a way use only one timer, but I didn’t dare to imagine, what other seemingly simple tasks will turn into my worst nightmare. So, maybe don’t deliver on the web? To cut to the chase, it seems like I did find the solution for my problem, but it’s black magic.

What if I told you, I can develop a native app, that will run natively on PCs (God help us ship on phones) and you could package that for web? Well, you don’t have to imagine, here it is! Using V and everyone’s favourite OpenGL wrapper - raylib. The code’s really simple, it runs like it’s native (because it is) and I can use v -os wasm32_emscripten my_app.v -o my_app.html to package it for web (as seen above). So everything is very complicated under the hood, but at least the things that should be simple, are simple.

As a side note, on this programming journey I discover a lot about motivation, peer-to-peer help, asking for help, resilience, God and so on. I want to share a story of how it came to be that the compilation from V to wasm runtime is as simple as I described above. To prove a concept of this pipeline, I needed a working wasm app. So I built an example project and … asked for help.

The response was astounding. The right honourable gentleman and my very good friend, spytheman wrote me a tutorial how to export the damned thing. But then he said and I quote:

hm, we can even package those files with the wrapper directly [so the user wouldn’t have to] download/fiddle with paths and env variables at all

He immediately pushed a change to the repo and asked me (and I don’t quote):

We simplified it to a compile command. Is running a compile command something you can do?

Needless to say, I could do that. So in a strange twisted kinda way, it’s as simple as I imagined it would be, sorta. Now, you might ask, why can’t we just distribute native binaries, since they much easier to work with and more performant. I can only say two things:

That’ll be it. I hope the demos work just as they work on my machine, otherwise you might get confused. Cheerio and come back soon.