Similarly, I have a somewhat simple demo made for my website that is C++/Emscripten/Raylib. It's open source (MIT License) and you can grok the code here https://git.seodisparate.com/stephenseo/jumpartifact.com_dem... and check out the demo itself from the link within that page.
I love RayLib and I use it a ton, but it’s by no means a replacement for Unity. You would need to implement a lot of stuff yourself that Unity provides before you could switch a project over
Why so salty? His game will probably have a fraction of the resource requirements of the overkill, overbloated, kitchen-sink engines written in C# and C++. I would command this author for not going the easy way. This takes skills.
Because most folks on social media that suggest replacing engine X with Y, mostly reveal a complete lack of knowledge of what engine X's capabilities, market presence and synergies, or why studios pick it in first place.
You'd be surprised to find most studios pick X over Y because it's either familiar to their devs or cheaper. Better doesn't really play into it and a thorough evaluation beforehand isn't usually done.
As former IGDA member no wouldn't, however most of studios don't pick a raw graphics C library versus proper engine, unless its their first title and don't have any clue about the games industry.
Funny enough, during my 30 years (give or take) career I have seen many more game projects fail using Unity than projects using cobbled together inhouse engines. It's always the team that counts, not the technology (the technology just always gets blamed when the team fails to deliver, the actual reason is usually organizational).
That's terrible. Who knows, maybe this post inspires someone to get started in games development, maybe it inspires someone to write a new engine, maybe it provides someone with fresh ideas. Who are you to say what should or shouldn't appear on this site.
Someone whose sick of every kid on the site blogging every time they learn how to code a hello world in a new language. Like, this is the equivalent of half the shit that gets posted on HN now. I have to wonder how they are making it to the front page though? As none of it is novel, interesting, or news worthy. I can only conclude these people are maliciously gaming the system.
The reality is HN is filled with mediocre tech bros doing everything possible to hustle for more attention and leverage. Even though the vast majority of what they have to contribute is of little importance. There are so many people trying to get exposure to their work on HN now that anything interesting gets lost within the noise. It seems like the system now only 'works' for parties willing to cheat it. So that the people with the most friends end up with the most exposure rather than the parties whose work is the most valuable.
'Meritocracy' and other such bullshit terms that tech bros love. laughing my f-f-f-f[redacted] ass off. Guess you snowflakes can downvote this all to hell now.
A bit ranty but fair enough. There is a sea of code and articles out there and no one has the time to curate it. Also meritocracy has been dethroned, we are living in a Celebrityocracy.
"exactly, I would have liked the grisp of the interesting part of it"
And that is all, no interesting excerpt, I was able to get source code of the entire page myself :) You are writing an article/tutorial. This kind of work should be in, this was my initial feedback.
Chrome has experimental support for debugging symbols in was but I've never gotten them to work. Personally I'm not going to bother with working on a project unless I can easily pit breakpoints in the original source
...IME this is a lot easier to setup than the Chrome extension (the problem in Chrome that's easy to overlook is to allow Chrome access to your source code directory, the VSCode extension doesn't require such brittle details).
The blog post I posted in a sibling comment above details how to setup VSCode so that debugging works by just pressing F5 in VSCode like it would work for natively compiled code.
TL;DR: there's a new WASM DWARF debugging extension for VSCode which allows a 'traditional' debugging experience for WASM code running either in Node.js or Chrome.
You can debug the original code by providing a map file (compiler generated) that allows you to let the WebAssembly runtime know how to map WASM bytecode to the source code. It works really well.
The old source-maps-approach never worked all too well.
Emscripten can generate DWARF debug info for a while now, and there are extensions for Chrome and VSCode which make use of this DWARF debug information and allow for a much better debugging experience.
Quick bit of feedback: Having the project's GitHub link point to your personal profile comes across as rather gauche.
If you want to refer to a collection of repositories, using a GitHub organization, even if you are the only member, prevents people from assuming you are self agrandizing.
I mean that an organization would be a lot better than what you are doing now.
Alternatively, a "central" repo linking to the others would also work.
Right now, the site says that the link leads to the project, but instead, it links to you. That's giving the impression that the project's primary goal is to raise your personal profile.
FWIW that thought (of self-promotion) didn't even cross my mind when I clicked the Github link. All the git repos on your root page are related to that project, and looking at the git history it's not a "community driven" project.
Maybe start thinking about creating an organization when there are other maintainers with push- and merge-rights, but until then keeping the subprojects under your user is completely fine.
Also: your project, your rules - just do what feels right to you :)
I would change the title to "Use Raylib in the Browser" or something like that.
Calling the linked article a tutorial on how to build a game is a _bit_ of a stretch.
I see so many posts like the OP here where somebody will just draw a rectangle with a texture on it and call it a game, whereas the real process to get to a playable game is a lot more complex than that, both technically and practically. You have to think about how the pieces will fit together, how it will be deployed, supporting multiple platforms, and much more.
Couple years ago was experimenting with portable OpenGL rendering, and, interestingly of all platforms I had to deal with the Web was the easiest target :) - thanks to the excellent emscripten largely.
If anybody is wondering "how the heck did Raylib solve the problem of running an actual render loop in the browser without a requestAnimationFrame callback", take note of the "-s ASYNCIFY" option that's passed to emcc.
I guess the WindowShouldClose() function yields control back to the browser event loop, which only works if the WASM code has been transformed into an async/await style state machine (and that's exactly what ASYNCIFY does).
I still wonder though how well this approach synchronizes with the swapchain presentation interval (which AFAIK is one advantage of using requestAnimationFrame).
Yes, but you'd want your per-frame code to be called as early as possible after a swap so that your code has as much time as possible to do work without missing the next swap (YMMV of course if there's a pipeline of buffered frames waiting for presentation - but this should be kept low to reduce button-to-screen latency).
If you rely on common game libraries and widely supported web APIs, you can get quite far with C. Here's an OpenGL and SDL2 game running in the browser that I ported (and also maintain):
Getting it to render was the easy part; I've since spent the majority of time getting it to feel native to the browser, implementing responsiveness (web dev term for adapting to viewport size), touch controls, GUI tweaks, working around fullscreen API gotchas (e.g., the Esc key/Back button is reserved), and any other small things that might remind you that this is not a native browser game.
Raylib also includes a decent Makefile template that can manage cross-platform builds (including emscripten). I've been trying out the library as I've been an SDL die-hard for several decades now. Raylib seems a little more ergonomic in places.
...and then package up the output into Redbean, and you have a single file executable that can launch a web server on Linux, Max, Windows, NetBSD, FreeBSD, OpenBSD...
oh this is neat! I've been trying to figure out a nice way to package Django + Django Unicorn into a portable app and then sync the sqlitedb to the remote server.
Are web games actually viable now? Did they ever fix WebAudio? Can I access the modifier keys, or does the user still have to carefully avoid touching the lower half of their keyboard to avoid triggering browser/os shortcuts?
I'm working on a visual novel, and I suspect 'low tech' people will enjoy playing it. I also suspect 'low tech' people don't have steam installed on their computers, but they will know how to click a link and play a game in their browser.
I'm hoping to sell the game through Stripe on my own domain as well as on Steam. Time will tell whether I finish this game and whether the Web build defeats the Steam build.
I tried plain WebAudio gamedev in 2021, making a small 2d game library with no dependencies. Web Audio was the only place where I eventually caved and broke my no deps rule and used Howler.js instead.
I forget the exact reason but I think autoplay on mobile devices was the thing I couldn't figure out, and howler had some workaround.
If I did the project again I'd just copy paste the 3 lines or whatever that Howler uses for the workaround and bring dependencies back to zero.
66 comments
[ 0.33 ms ] story [ 123 ms ] threadIt really makes Game Dev fun again. Also it has tons of bindings (you don’t have to code in C)
Another big thing is it doesn’t support iOS at the moment.
The reality is HN is filled with mediocre tech bros doing everything possible to hustle for more attention and leverage. Even though the vast majority of what they have to contribute is of little importance. There are so many people trying to get exposure to their work on HN now that anything interesting gets lost within the noise. It seems like the system now only 'works' for parties willing to cheat it. So that the people with the most friends end up with the most exposure rather than the parties whose work is the most valuable.
'Meritocracy' and other such bullshit terms that tech bros love. laughing my f-f-f-f[redacted] ass off. Guess you snowflakes can downvote this all to hell now.
It’s a lot of not that interesting code so I didn’t include it in the blog post.
And that is all, no interesting excerpt, I was able to get source code of the entire page myself :) You are writing an article/tutorial. This kind of work should be in, this was my initial feedback.
I believe hooking up a debugger to your IDE is also possible. I haven’t tried it yet though: https://emscripten.org/docs/porting/Debugging.html?
Maybe I’ll give it a go and write about it in my next post.
https://marketplace.visualstudio.com/items?itemName=ms-vscod...
...IME this is a lot easier to setup than the Chrome extension (the problem in Chrome that's easy to overlook is to allow Chrome access to your source code directory, the VSCode extension doesn't require such brittle details).
The blog post I posted in a sibling comment above details how to setup VSCode so that debugging works by just pressing F5 in VSCode like it would work for natively compiled code.
https://floooh.github.io/2023/11/11/emscripten-ide.html
TL;DR: there's a new WASM DWARF debugging extension for VSCode which allows a 'traditional' debugging experience for WASM code running either in Node.js or Chrome.
Emscripten can generate DWARF debug info for a while now, and there are extensions for Chrome and VSCode which make use of this DWARF debug information and allow for a much better debugging experience.
E.g. see here:
https://developer.chrome.com/blog/wasm-debugging-2020
...and here...:
https://marketplace.visualstudio.com/items?itemName=ms-vscod...
I put a raylib game inside both for fun and for testing the graphics layer
If you want to refer to a collection of repositories, using a GitHub organization, even if you are the only member, prevents people from assuming you are self agrandizing.
Alternatively, a "central" repo linking to the others would also work.
Right now, the site says that the link leads to the project, but instead, it links to you. That's giving the impression that the project's primary goal is to raise your personal profile.
Maybe start thinking about creating an organization when there are other maintainers with push- and merge-rights, but until then keeping the subprojects under your user is completely fine.
Also: your project, your rules - just do what feels right to you :)
Nothing like a bit of humour and thinly veiled criticism to liven up a tutorial :)
I see so many posts like the OP here where somebody will just draw a rectangle with a texture on it and call it a game, whereas the real process to get to a playable game is a lot more complex than that, both technically and practically. You have to think about how the pieces will fit together, how it will be deployed, supporting multiple platforms, and much more.
If interested, you can find the code/demo here: https://github.com/schaban/crosscore_dev (the link to the online demo is there in the README)
I guess the WindowShouldClose() function yields control back to the browser event loop, which only works if the WASM code has been transformed into an async/await style state machine (and that's exactly what ASYNCIFY does).
I still wonder though how well this approach synchronizes with the swapchain presentation interval (which AFAIK is one advantage of using requestAnimationFrame).
Asyncify docs (different from the emterpreter-async option mentioned in the comment block): https://emscripten.org/docs/porting/asyncify.html
https://play.neverball.org/
Getting it to render was the easy part; I've since spent the majority of time getting it to feel native to the browser, implementing responsiveness (web dev term for adapting to viewport size), touch controls, GUI tweaks, working around fullscreen API gotchas (e.g., the Esc key/Back button is reserved), and any other small things that might remind you that this is not a native browser game.
Source code is here: https://github.com/rrampage/skitter/tree/master/pong-raylib
It is fairly straightforward to get Raylib running in the browser. I used @flohofwoe's HTML shell file ( https://github.com/floooh/sokol-samples/blob/master/webpage/... ).
Compilation is something like: emcc -o target/pong.html -Wall -Wextra -std=c99 pong-raylib/pong.c lib/libraylibweb.a -I ./include -sUSE_GLFW=3 -sSINGLE_FILE -Oz --closure 1 -sFILESYSTEM=0 --shell-file pong-raylib/shell.html
https://redbean.dev/
I'm hoping to sell the game through Stripe on my own domain as well as on Steam. Time will tell whether I finish this game and whether the Web build defeats the Steam build.
I'm hoping Web wins.
I forget the exact reason but I think autoplay on mobile devices was the thing I couldn't figure out, and howler had some workaround.
If I did the project again I'd just copy paste the 3 lines or whatever that Howler uses for the workaround and bring dependencies back to zero.