Someone made something fun in the tools they know and shared it with the public

Just waiting for wine to get fast enough to run Windows binaries in the browser. Last I checked, it's not quite there yet.

Your OS has its own sandbox, so it should be absolutely fine unless you run everything as administrator.

It’s shipping for Windows and Linux. Neither of these uses that kind of sandbox by default (or makes it at all easy to achieve). It could trash the user’s home directory, for example.

I beg to differ.

  $ firejail ./bin

Even the very limited default profile hides things like ~/.ssh and makes the rest read-only (with the exception of ~/.cache and such).

That doesn’t invalidate what I said. It requires going well out of your way (as do other sandboxing arrangements—I never said they didn’t exist), and it’s not a very good sandbox without a fair bit of work. (So maybe you’re blocked from trashing the home directory, but stealing all your passwords and login cookies was always more lucrative than vandalism, so making the rest read-only is small comfort.)

I have no desire to engage in one of those 50 levels deep nested arguments, so this is my last message, but you literally said:

> or makes it at all easy to achieve

firejail makes this trivial. You won't be able to steal anything of interest. Making an easy to use sandbox for desktop applications is the main goal of the project. You could have tried it out before arguing against it in what feels like bad faith.

  $ firejail bash
  -- snip --
  
  $ ls ~/.mozilla
  ls: cannot open directory '/home/foo/.mozilla': Permission denied
  
  $ ls ~/.ssh
  ls: cannot open directory '/home/foo/.ssh': Permission denied
  
  $ ls -lh passwords.kdbx
  -r-------- 1 nobody nobody 0 May 29 14:53 passwords.kdbx

And so on. (The last one is my real password database and it definitely isn't 0 bytes in size.)

I haven’t ever used Firejail, but I know a little about it. I understand that Firejail depends on you configuring things for each app, with a mixture of whitelisting and blacklisting. That’s untenable unless the default profile is safe. You said its default profile just makes the home directory read-only; I took that at face value (since I have no interest in installing it to check). If what you said was correct, then I presume that either you must have changed the default profile, or Bash is using a different profile?

Because the developer didn't want to. Instead they coded it in Java and ran with it. Personally, I love it.

It's probably 10x more efficient than a possible JS implementation, tho.

Java 10x faster than JavaScript, in 2023? No.

I didn’t say faster, I said more efficient. They are two wildly different things.

Right, but efficient can mean a lot of things.

Though Java was used, this game is inaccessible to Mac, iPhone, and Android users. Porting to all these platforms is inefficient compared to just using the web.

It also requires a 60MB download, which is not very space efficient for a relatively simple 2D game (NES Tetris fit on a 24KB ROM). People have implemented Tetris in as little as 446 bytes [1]. Full color JS versions have been done at 16KB or less [2][3]. A JS version from 2004 came in at 1.5kb [4].

Haven't done memory efficiency analysis, but willing to bet the average JS Tetris implementation has dramatically better memory efficiency as well.

[1] https://hackaday.com/2016/10/06/tetris-in-446-bytes/ [2] https://github.com/cztomczak/jstetris [3] https://codeincomplete.com/articles/javascript-tetris/ [4] https://joriszwart.nl/games/javascript-tetris-1.5kb

MacOS has official Oracle and OpenJDK distributions. The author just didn't compile an executable for them, that's all. At least, I run Eclipse on macOS, which in turn uses platform Java.

It's funny that when people say that hardware is cheap, but frown on a 60MB explicit download. Our browsers spend several 60MBs per day to show us ads, and we don't tell a word, but "a 60 MB game. Heresy!", we cry.

I'm no stranger to hyper-efficient implementations as a demo scene enthusiast, yet this is no demo, and is a cross platform game, where the author decided to code in Java. I don't understand the criticism, because I'm aware of no rule that any software we develop shall run on Big5 (iOS/macOS/Android/Linux/Windows), plus web browser and my car key fob.

Actually, when I look the files, the game is 20MB assets + 110K executable + 40MB JRE. So the developer decided to bundle the JRE to make sure it runs. That's a fair (even small) size given today's lassiez faire attitude where people chant "Hardware is cheap, network is reliable".

Yes, one might do this in 100K altogether, but, personally, I'm no judge. It's a good game, runs on my favorite OS, and enjoyable. That's enough for me.

If the idea is that good, let Setris clones show us the way.

> The author just didn't compile an executable for them, that's all

Would love to see the author's actual comment on this rather than your presumptions about it. If it's trivial to compile and run, why leave out a huge market for what you make out to be minutes of effort?

> Our browsers spend several 60MBs per day to show us ads

When I'm browsing, I run an ad blocker. As a digital nomad, I'm also regularly on 4G and hit my data caps often. I would never wait for 60MB of download for a simple game.

> yet this is no demo, and is a cross platform game

Right, I just used some examples to show how little memory a game like Tetris needs, including high quality production implementations, like the original NES version, as well as most major Tetris PC, console and handheld releases in the last 30 years.

The JS examples above are inherently cross platform. A browser based game will run on every single consumer grade device that has access to the internet.

Higher quality JS versions can be found, including the official version: https://tetris.com/play-tetris That version is 4.9MB, 2.5MB of which are MP3 files, much of the rest of it is high-quality full-color PNG assets.

Clearly the assets should be reduced in size. No need to ship a runtime if you use JS. Another benefit is it runs in a sandboxed browser environment and I don't have to worry about running an executable locally.

Again, all this is a response to your assertion that "It's probably 10x more efficient than a possible JS implementation, tho." It doesn't run on my OS, and that's part of the reason I'm complaining about it.

The assets are 13MB sound effects + 400kb png image files, the rest of the file size is due to platform natives and the bundled JRE. I know it's a lot of overhead but its java.

This seems to be such a pedantic discussion all around. Well, what did you mean by more efficient if not more performant, the usual metric?

More efficient to develope? Possible, depending on the devs skill set, but hardly relevant for the end user who want to play the game on possible low performant hardware?

Oh and I think wasm can beat java in several cases.

> This seems to be such a pedantic discussion all around.

No, as a high performance software developer, my aim was not to devolve the discussion into a pedantic "stone throw".

> Well, what did you mean by more efficient if not more performant, the usual metric?

Watt per instruction. IOW, power consumption. As a person who lives in HPC world, inefficiency is bane of my existence. Two software can be equally performant while having different power profiles. I'm focusing on power.

What does this brings, you may say. Throttling is the simple answer. If you waste more power, you'll hit the throttling wall faster, use more battery, and will lower the quality of the experience. From your phone to biggest supercomputers have thermal budgets, and none of them are unhittable.

> but hardly relevant for the end user who want to play the game on possible low performant hardware?

Not all of us have latest processors, tons of RAM, and JS microbenchmarks show that browser JS engines have wildly different performance characteristics for some loads. Using a native platform pushes these concerns out of the picture.

> Oh and I think wasm can beat java in several cases.

Have no experience with that, need to test and see.

"Using a native platform pushes these concerns out of the picture."

Well yes, but this project was made with java. And by now I don't think java is more performant or efficient than the browser. In general, as you are surely aware, if you are looking for the most efficient solution, than obviously neither java nor the web is the right plattform. But for a casual game, both is fine.

10× more computationally/power efficient while running? Not a chance. Assuming similar care put into the two, the two will probably be much of a muchness.

Heh? What world are we living in that Javascript is faster than Java?

No one claimed that. All that was claimed was “not 10× slower than Java”.

> It's probably 10x more efficient than a possible JS implementation, tho.

And you make that claim based on what?

The biggest difference in execution speed is found in the competency of the programmer, not in the choice of the language.

Also... 61MB download!

Well.. it's a game!

Smaller than most popular webpages.

x1270 of original NES Tetris! (32kb of code & 16kb of graphics)

The original wasn't built to have sand physics and to be portable on most major platforms, displaying at high resolutions...

What's your point?

let's include an entire nes emulator with it then. fceux seems to be about 8mb

  displaying at high resolutions

irrelevant

  sand physics

how much of binary that would add?

  What's your point?

My point was to highlight how much overhead modern software adds.

> irrelevant

Why?

because it wouldn't affect the binary size in meaningful way

That's not true at all. The whole reason why graphics on the original NES were so compact is because the color palette was so limited. Not only that, but tiles could only have a maximum of 4 colors within them, one of which was considered the "transparent" color if you wanted blending. So they were only 2 bits.

So yes, it does absolutely and unequivocally affect the binary size. Having made NES games for fun before, they are two completely different worlds and it's not at all fair to compare them.

I disagree. A comparison of "higher resolution" in the terms of NES would only mean an increase in nametable size, not in binary size of program. Of course if "increase in resolution" also meant increase in CHR size or sprite count, or color palette size then you would be correct.

My point in NES or in modern software, the target resolution you want wouldn't have an affect on binary size.

  Having made NES games for fun before

So I am. You are right, a more fair comparison would be a tetris.exe perhaps. But my point would still stand, 60mb (and that is zipped amount) orders of magnitude higher.

I want to ask the same question, what is your point? Are you arguing that java runtime or several dependencies OP added is not an indication of modern software bloat?

I'm saying that the capabilities of the game in question and the original Tetris are also orders of magnitude larger, you just don't see them directly because you're biased to comparing this game to the original due to its visual and gameplay style, and that comparing the two to measure the value of "bloat" is an absurd thing to do.

Sorry but sand physics is probably doable in a few kb (yes, that's kilobytes) of JS.

This is different and simpler but just 140 bytes (not k): https://codepen.io/KilledByAPixel/pen/WNGQWZG

Nothing in that game justifies being more than 1mb (being very generous...) minified as a browser app.

Of javascript. Which has a stupidly large runtime that is certainly not just a few kilobytes.

Sorry, I have to make one last snarky comment. You can probably include entire firefox along with that a few kb of js and still make it under whatever that 60mb expands to :)

Sure, let's maybe make an electron app.

Ok, was mentioning without the browser runtime obviously.

Opionated take, but I believe that the web common runtime should be part of the OS nowadays.

Even without this, Tauri is 8Mb.

You're also ignoring the fact that most of this functionality happened in chips. That's not the case with modern machines.

Modern technology usually complicates things and adds overhead, it's part of technological advancement isn't it?

"Especially since it looks this game could easily be programmed with WASM and/or vanilla JavaScript."

Looking forward for you doing and sharing it. Because then I could complain, why you did not use WebGPU, as it is so much more powerful ...

uh, vr port anyone? it is 2023 ffs

ChatGPT make me a Tetris game but with Sand Physics for the browser

I cringed when I read the 'easily' in OP. Just do it then.

Because the author owes you nothing.

Try saying that to people who trashed GNOME for more than a decade because of the file picker and when thumbnails were finally implemented they said things like "too little too late".

It's a common target. The question is more about curiosity of why the choice was made

This would sound extremely conspiratorial except this exact scenario has happened on mobile: It's a real slippery slope from everything always runs into the Google browser into everything is an app in the Google browser store.

Envision a FAANG stomping on a human face forever...

I think you're missing the point. Mobile was kind of the opposite, where instead of having source-available applications on an open platform, the mobile OS makers made it near-impossible to install anything but closed-source apps from their closed-source walled garden app stores.

Being able to run in the browser doesn't mean you have to run it in Chrome. You can use Chromium (open source), or Firefox, or Brave. You can bundle it into an electron app. You could write your own browser that runs javascript with just the APIs needed to make the game work, and deliver it in that (the standards are all open and the spec is public)

This is so much better than what we have with mobile, and much more secure than running random executables on your daily-driver OS directly

I'm going to assume this isn't a rhetorical question. This is a program written in java using libGDX, and the compiled target depends on JRE.

If you read the documentation on it, you will see that libGDX can build with web as a target, but the developer has chosen not to do this as of yet. Perhaps they might, if asked nicely. Or, since you claim for it to be easily programmed in WASM and/or vanilla JS, you could go ahead and do that.

I'm sure you didn't mean any offense, and I also don't mean any offense when saying that your apparent bewilderment (if rhetorical) comes across as entitled, and you should perhaps consider your approach here.

It looks like a fun game. I did not mean to offend. I don't think there's nothing entitled about giving suggestions for improvement and reaching a wider audience - e.g. through giving the reason why I did not try out the game personally. The sand physics simulation does not look that complex/heavy to me - probably if the author implemented it once in Java they could do it again in JavaScript + Canvas, and it could even be a fun exercise to port the game to a new platform.

You did not offend me at least. Given the stated goal, you could ask with a curious tone instead and avoid confusing you for someone rude/annoying. That said, you are right that technically, this isn't complicated. Sand physics like this is only a few lines of code. However, someone did mix concepts leading to a novel approach to an otherwise exhaustively cloned game. Tetris was huuuge in its day, and there are hundreds if not thousand commercial clones and variations. The interesting part to me is that novel combination. And, they went so far as to polish it as a game, share it for free, and all you have to do is click a couple of buttons.

So, if this inspires you to want to recreate it in canvas, have at it. It's probably a great exercise. The author can likely just build a target for the web and libGDX takes care of the rest. They might have to solve some build errors, figure out how to host it on itch, etc, and if they cannot be bothered, they don't owe anyone anything. Quite the opposite.

In summary, seemingly disregarding the novelty. Pointing out that it is simple, and that you (paraphrasing) cannot be bothered, is why I said that it could come across as entitled. In any case, have at it :)

I've been working on making a base or skeleton game engine for when I participate in Itch.io game jams that compiles from C++ to web assembly using Emscripten. It's exactly as you say no one wants to download and run an unknown binary blob; this severely limits how many people will try your game.

I'm alternately impressed that I can port C++ in this way at all, and sad at the state of the tooling still after so long. When something goes wrong with the web assembly version of the project, I can't debug it from first principles. This could be because, as an embedded and C++ programmer, I'm unfamiliar with Javascript debugging tools, but it's still unfortunate I can't single step through at the C++ source code level when debugging the web assembly build. I just want gdb for web assembly.

I've also run into silly/stupid bugs like keyboard input not working only in fullscreen, except if you leave it on overnight in which case 1 out of N tries the keyboard input comes back. I spent days trying to debug this, only to have someone on a forum answer it in about 2 seconds that it's because a Firefox change now causes keyboard input to be captured by the awesome bar during fullscreen (which of course you can't see). I could have tried this for a million years to figure out what was wrong and not had that insight. It doesn't bode well for my game engine project if things are this fragile; no other C++ compilation target is this janky.

I experienced similar frustration using Emscripten to ~port a simple C+SDL2+GLES2 game to wasm.

While it mostly worked, it wasn't a very polished environment and how well it worked depended greatly on which browser was used. And even in the best case there were still annoyances surrounding things like fullscreen handling.

It all echoed of 90s-era web development when we had to test every browser and kludge browser-specific exceptions due to incompatibilities. It's been over a decade since I cared about web stuff, so maybe this is just the way it still is in general and not just emscripten/wasm support.

Whatever the reason, it didn't inspire much confidence to rely on this pipeline for delivering native+web games to the masses in a single implementation.

While you're not wrong about the sandbox aspect, there are people like me who detest doing everything via a browser, and prefer standalone tools. I think it's tragic that I need a browser to do most things.

it's coming.

1996: Hey we made this cool language called Java, you can make applets that run in the browser. Also, it runs in a VM, this protects your system.

2023: Why can't I run it in the browser? Why can't I run it in a sandboxed environment? Because it is Java...