Show HN: A remake of my 2004 PDA video game
nicollet.netMy background project for the last two years has been re-implementing my 2004 C++ shoot'em up game in TypeScript + WebGL, and it's finally done (just in time for the 20th anniversary!)
Play the game online: https://nicollet.net/blog/darklaga/darklaga.html
Technical article about the remake: https://nicollet.net/blog/darklaga/remake.html
I have tested Firefox, Chrome and Edge on desktop and mobile (no access to a device capable of running Safari).
It's amazing how much difference 20 years makes: the hardware is so much more powerful, the web as a deployment platform is so much easier than side-loading onto a PDA through a serial cable or sharing .exe files through e-mail, and my experience as a professional developer makes almost everything so much easier... but at the same, it didn't feel that the language, editor or debugger (TypeScript on Visual Studio Code) were significantly better than good old Visual C++ 6.
Repository with the code of the remake: https://github.com/VictorNicollet/Darklaga (sadly, I cannot provide the video and audio assets themselves under any open license).
Good stuff! Is there any chance you could write some instructions on how to make "darklaga.bin" locally.
I ran "npm install" and then the build script, but then got a bit lost.
When I open dist/darklaga.html, my browser dev tools (correctly) tells me that I can't get at "darklaga.bin".
I worked around this by going on the live demo, grabbing the "darklaga.bin" from the dev tools "Networks" tab, and plugging it to the dist/ directory. But it would be even better if I could just download the repo and make the bin from there.
The trouble is, darklaga.bin will not work locally because it must be fetched over an HTTP(S) connection. So, there's a darklaga.local.html provided when running locally. The build sequence is "npm run pack" then "npm run build", after which darklaga.local.html should work.
My own answer is here: https://github.com/3willows/Darklaga/blob/main/README.md
This is pretty fun! There's an annoying issue when playing from mobile safari on iOS where the canvas scrolls along with your finger. I think there's an HTML directive that can probably fix that but the name escapes me at this time.
On other browser/platform combinations I use fullscreen mode, which gets rid of the issue entirely. But it isn't supported on iOS Safari as far as I can tell.
Good old shmup, that's a genre that is sadly fallen into disfavour these days.
I played a bit however after 2 minutes or so some enemy ships get stuck going in a square pattern across the edge of the screen where they are impossible to hit and the game stops progressing. I refreshed once and got the same issue after a few minutes (Firefox).
The square pattern enemies are a bug (well, level design mistake) back from 2004, where they would move outside the range of the laser but would still be within reach of other weapons.
I must admit, since I no longer have access to the level editor, I edit the level files with HxD :-)
It's still alive today, but it's not called "Shoot 'em up" anymore.
These days it's been taken to extremes (signs of the times?) and called "Bullet Heaven" (you exterminate hordes of wimpy enemies) or "Bullet Hell" (you evade myriads of bullets).
Addictive game, well done. But why do you think WebGL is going to still exists in 20 years? Flash seemed to be here to stay, considering how much content was made for it, then "suddenly" gone.
/edit:
Whether WebGL as a whole will be replaced by WebGPU remains to be seen, but the 1.0 feature set is simple enough that I can imagine web browsers implementing those in terms of WebGPU, whereas the 2.0 features are more likely to be dropped, because they were never expected to be universally supported.
Well, this is a possible reason, but I'm not sure I agree with.
Flash was a proprietary browser plugin that went out of support (although you can still play .swf files with the standalone projector or Ruffle), whereas WebGL is a web standard which is very easy to implement on top of OpenGL ES; and that one is also a standard with many implementations, both in drivers and as open source libraries on top of more modern APIs, like ANGLE.
So I think WebGL is not going away anytime soon.
Great stuff! Amazing that playing a game written in 2004 which follows the style of games written in 1994 feels current in 2025 just because it runs in my web browser. But nonetheless it did feel modern and it was also really good fun.
I'm currently thinking of rewriting a personal website from next.js to plain html/css/js. Just don't want no bundling no more. My reasons are similar to yours, but one that's been itching at me was the loss of clicking view source and learning about code directly from a page with ease.
Didn't know I could still do typescript and just have my workflow strip the annotations out though. That's really worth exploring.
Congratulations, looks great, and feels addicting. I wonder if keeping ship offset from touch point was intentional game design choice?
And regarding testing on Safari, if you have access to any Linux distribution, you can try testing on GNOME Web, it uses WebKit, same rendering engine as Safari (with probably some minor differences).
Finally, you should put this game up on itch.io, as I am sure some players might like to leave some monetary support.
Yes, ship offset from touch point was an intentional 2024 change. In the 2004 version, touch screens used a stylus, which were thin enough that you could see whatever you were touching, so the player's ship was centered on the stylus point of contact. With a finger, it's much harder to see...
For Safari, I ended up having to investigate a crash on iOS Safari specifically, because it did not happen on Mac Safari.
I considered itch.io but I am still undecided on the whole affair.
This is ridiculously fun, kudos. I could definitely waste a few lazy afternoons playing this.
I didn't understand how the pick-up system worked nor how to trigger the progress bar once it filled up. But I made it to the end on Normal with 3.7 million points.
Nice work. Loved these sorts of games as a kid.
Congrats!. Curious if you tried to run your game in C++ of 2024. What kind of improvements did you see (speed, performance, etc..) compared to doing it in 2004.
Sadly I could no longer build the C++ version of the game because of some missing proprietary dependencies, but I don't expect there would have been noticeable improvements: it was already running at 60FPS on computers from the time, even in PocketPC emulation mode.
Very cool! I'm actually curious to learn more about how the bin conversion works. The pack files are pretty interesting!
reallyh fun game, made it past the second boss then died. Was a bit confused about pickups and how they worked, there was so much happening on screen haha
It works fine in Opera on an old Android tablet.
Cool (and intense!) game :) Pretty impressive you had something like that running on a PDA 20 years ago, I was probably playing J2ME games on a Sony Ericsson at that point so don't know the performance of those.
This constraint + your solution was pretty interesting:
> Only use technologies that can be expected to still be present (and backwards-compatible) 20 years from now.
I'd bet on that in 20 years TypeScript will no longer be maintained and also no longer be the most popular transpilation source language for JavaScript. Seems the JavaScript ecosystem always eventually finds a new "source" language even though everyone at the time is certain it won't happen with this current one.
Probably still wouldn't be hard to get the game running though, will still be easy to install old TypeScript compiler and run it.
Maybe by 2045 AI will be sufficiently advanced to simply say "make this old game run on my new PC", and the AI will read through every line of code, pixel of textures, and make a faithful playable reproduction in seconds.
If that's the case, it really doesn't matter what technologies you use.