It would be worthwhile to phrase this more constructively. They built something cool and they want to share it. The author is gaining nothing by posting this, and owes us nothing.
But, if you're trying to be a decent person you might want to encourage others to keep making cooling things rather than discourage them by saying "this free thing isn't good enough".
I just went down a rabbit hole with this excellent blog post on using data structures, search algorithms, and maybe some machine learning to try to beat the previous world record of 66 lines: https://hallofdreams.org/posts/hatetris/
One word of caution, I wouldn't mention the word Tetris anywhere, just use "falling block classic game" or whatever else, as it's one of the most trigger happy IP I know of after Nintendo.
That said it's so far detached from the original you might be fine.
There used to be a Tetris clone for Mac called Quinn. The web site for the game said: "Quinn is an implementation of a popular falling-blocks game which, according to the Tetris Company, must not be named here."
A dmca counter claim takes at least 14 long days to respond with. In the meantime, your vitality will dry up.
Trademark infringement is a bit different, since there’s no analogue to the dmca process. But it’s pretty reasonable to want to avoid the hassle by just changing a few words.
(What is the expected litigation route for trademark claims anyway? Can they knock a project offline, or just send a strongly worded lawyer letter?)
> (What is the expected litigation route for trademark claims anyway? Can they knock a project offline, or just send a strongly worded lawyer letter?)
IANAL, but I would expect a cease-and-desist letter or the national equivalent depending on the country you're living in. Usually you have a short delay to remediate, or risk getting sued.
> so your advice is basically, go ahead and make your derivative tetris game but just call it something else?
Every game is derivative.
Almost every human thought and action is.
The language you speak. Your opinions. Even your preferences are shaped by things you've seen and copied.
If you said that every game (or whatever) must pay the predecessors for every mechanic they reused, we'd be left with nothing but taxes to be paid to the dead and retired. Those no longer carrying the torch forward.
I don't think that many thoughts are derivative. One certainly doesn't learn thinking by imitation, at least in early childhood and not directly in later life stages. Yes, many "library-like" algorithms (those for simple and narrow, well-understood tasks) are derivative, but there is much other thinking - "fluid" thinking as a whole, and also many particular small tricks / heuristics that are discovered independently by many smart individuals.
Just looking at the gameplay video, they have a bit of work to do to avoid a DMCA request from maybe both The Tetris Company (I think that’s the name) and Nintendo.
The game lifts a lot of design elements from the Game Boy version of Tetris. Clearly to evoke the nostalgia. Down to specific graphical elements like the style of the blocks and fonts used.
The Tetris Company would have a point here. The game wants you to think of a very specific version of Tetris. I forget where Nintendo exactly was involved in the game, but it’s possible they hold some rights to the Game Boy version as well.
I’d strip out all the Game Boy elements. I doubt you’d get by on a parody claim.
Tetris has become so universal that it feels like a generic term, similar to how we usually say Kleenex instead of tissue and chapstick instead of lip balm. "Setris" sounds fine as name of the game, although I also like "Sandtris", which sounds less similar to Tetris, and probably less likely for IP issue.
It's interesting that you chose Kleenex and Chapstick, because both are still protected trademarks in the US. Competitors to Kleenex still market themselves as tissues and competitors to Chapstick still use lip balm. If you try using the brand names on your Amazon listing or what have you, you'll get a cease and desist letter.
Played for some fifteen minutes. It feels like there is way too much luck involved. On one run I was able to keep the field almost empty apart from the lower corners as I kept getting colors in nice streaks, and on others I just seemed to get a rainbow of layers.
Due to the sand mechanics you can't just stash pieces to the side and without enough information on upcoming pieces it's just too risky to attempt bridging the edges.
If you like games in which RNG punishes you in ten out of nine runs and then gives you a free pass, this might be for you.
Depends how it's backed, how static it is, and so on.
The lisp runtime may fit in 20 MB, but not every language's runtime is so compressible. It may be smaller if one used something like C#/.NET where it's reasonable to assume, on windows, that everyone has specific common versions of the runtime laying around.
And then there are things like libraries. How dependent on the state of the OS do you want to be? Do you bring your own copy of SDL, or do you rely on it being installed? Even choice of graphics library can make a big difference, did you use something like DirectX which the OS will have all ready for you (assuming it supports it of course), or do you use something like OpenGL/Vulkan and invariably have to bring your own copies of various things like shader compilers and texture compression libraries.
In this case it's because it packages it's own copy of the JRE (which makes up more than 2/3rds of the contents). Which makes plain the greatest failure of Java, it was never a universal execution environment. Which is why every program ships their own copy of it and users no longer complain about "Update Java" notifications, or dealing with incompatible Java environments.
Custom Java runtimes can be generated using jlink [1] which take a fraction of the space needed for a “full” JRE. I have some applications packaged like this and the Windows installer exe, generated using NSIS, is under 15 MB.
Sure, but then you have to add back all the Java libraries they then used ontop of it. I assume the developer also used a tool like this to cut it down, the issue of bundling the custom Java runtime was never the size, it's that java was never supposed to need to do it this way (not that that is the end user developers fault of course).
(I use WSL as a more powerful sandbox to run things. Windows Sandbox is, unfortunately, not capable enough to run graphics-heavy stuff as it seems to use RDP.)
WSLg (Microsoft's implementation of graphical programs for WSL) also uses RDP internally. So I wouldn't think that is the issue with the Sandbox, unless you set up some other way of X forwarding. WSLg is still hardware accelerated and Sandbox might not be, however.
The sand is going down. Each tick one bit of sand falls from the top left to the bottom of that valley. Over many ticks the sand from the top accumulates up the side of the valley, from over the "cliff". The strange bit is the pieces teleport in one tick one at a time. No matter how you do it you'll end up with some sort of tradeoff like that when using pixel grids instead of particles.
Any chance of macos support?
I tried running the jar, but didn't get very far, the jar seems to include binaries macos binaries for both x86 and arm, but it didn't want to start.
I had to add the start on first thread flag to prevent errors and start a launch. I do get stuck after `Starting UI Subsystem` gets logged but I havent put any real effort into trying to debug that yet.
I know little of how Java works, and especially how to override libs, but I did try downloading lwjgl's latest release and put all its jars in the classpath:
Perhaps someone can sponsor access to a macOS VM? Renting a Mac Mini M1 is $0.11 per hour at Scaleway.com (by the way, their launch video is hilarious https://youtu.be/jZJnrKjfA3s )
The yellow section in the video dissolved a bit earlier than I anticipated, around 0:23, but I noticed that there are a few missing pixels on the left edge. It could be due to lower resolution or the need for clearer indications. Perhaps improving either the resolution or providing clearer visual cues, such as eliminating shaded edges on the border, could enhance the experience. But sitll, I find this variation of Tetris with sand elements to be quite fascinating and a unique twist on the traditional game. Great job bro!
This looks like a lot of fun. I'm curious, where did inspiration come from? I love playing creative versions of classic games like that and if something inspired you to build this, I'd like to try it too :)
This reminded me of a physics-based Tetris that a friend of mine built many years ago: http://phystris.pi-dev.com/
The author mentions that they used LibGDX. It's been a decade since I've done anything with it, but I do recall LibGDX can be transpiled with GWT with a bit of work:
Why doesn't this run in the browser? :( It's 2023 - and no offence intended - but I would rather not download a binary blob from a random Internet page to execute it outside the browser's sandbox. Especially since it looks this game could easily be programmed with WASM and/or vanilla JavaScript.
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, 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 :)
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.
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.
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 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.
> 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.
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.
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.
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?
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".
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.
You always have to keep in mind, that the majority of commentors, did not had a project yet, that made it to the front page. But at least that smart criticism can make it top comment for a while ..
194 comments
[ 0.19 ms ] story [ 255 ms ] threadBut, if you're trying to be a decent person you might want to encourage others to keep making cooling things rather than discourage them by saying "this free thing isn't good enough".
Silly physics fun in the browser, but not a complete game (yet).
One word of caution, I wouldn't mention the word Tetris anywhere, just use "falling block classic game" or whatever else, as it's one of the most trigger happy IP I know of after Nintendo.
That said it's so far detached from the original you might be fine.
Same with the Zelda word...
https://www.youtube.com/watch?v=hWTFG3J1CP8
Trademark infringement is a bit different, since there’s no analogue to the dmca process. But it’s pretty reasonable to want to avoid the hassle by just changing a few words.
(What is the expected litigation route for trademark claims anyway? Can they knock a project offline, or just send a strongly worded lawyer letter?)
IANAL, but I would expect a cease-and-desist letter or the national equivalent depending on the country you're living in. Usually you have a short delay to remediate, or risk getting sued.
Every game is derivative.
Almost every human thought and action is.
The language you speak. Your opinions. Even your preferences are shaped by things you've seen and copied.
If you said that every game (or whatever) must pay the predecessors for every mechanic they reused, we'd be left with nothing but taxes to be paid to the dead and retired. Those no longer carrying the torch forward.
The game lifts a lot of design elements from the Game Boy version of Tetris. Clearly to evoke the nostalgia. Down to specific graphical elements like the style of the blocks and fonts used.
The Tetris Company would have a point here. The game wants you to think of a very specific version of Tetris. I forget where Nintendo exactly was involved in the game, but it’s possible they hold some rights to the Game Boy version as well.
I’d strip out all the Game Boy elements. I doubt you’d get by on a parody claim.
Due to the sand mechanics you can't just stash pieces to the side and without enough information on upcoming pieces it's just too risky to attempt bridging the edges.
If you like games in which RNG punishes you in ten out of nine runs and then gives you a free pass, this might be for you.
https://youtu.be/Hp4nV4EjLgM?t=122
The lisp runtime may fit in 20 MB, but not every language's runtime is so compressible. It may be smaller if one used something like C#/.NET where it's reasonable to assume, on windows, that everyone has specific common versions of the runtime laying around.
And then there are things like libraries. How dependent on the state of the OS do you want to be? Do you bring your own copy of SDL, or do you rely on it being installed? Even choice of graphics library can make a big difference, did you use something like DirectX which the OS will have all ready for you (assuming it supports it of course), or do you use something like OpenGL/Vulkan and invariably have to bring your own copies of various things like shader compilers and texture compression libraries.
In this case it's because it packages it's own copy of the JRE (which makes up more than 2/3rds of the contents). Which makes plain the greatest failure of Java, it was never a universal execution environment. Which is why every program ships their own copy of it and users no longer complain about "Update Java" notifications, or dealing with incompatible Java environments.
[1]: https://docs.oracle.com/en/java/javase/11/tools/jlink.html
The sound effects were pretty good, but I can't find a gameplay video.
https://www.squakenet.com/game/x-tetris/
If you are trying to get it running on Linux (e.g. in WSL), you need libfontconfig, libxrender and libxtst installed. This worked for me on Ubuntu:
(I use WSL as a more powerful sandbox to run things. Windows Sandbox is, unfortunately, not capable enough to run graphics-heavy stuff as it seems to use RDP.)One thing that looks a bit off is that part of the physics engine runs in reverse -
When a piece touch the high part of a pile, the sand is going UP from the bottom of the valley to the top, instead of from the top DOWN to the bottom
When the process finishes the end result is the same, it's just a bit strange :)
Example in https://youtu.be/Hp4nV4EjLgM?t=133
I had to add the start on first thread flag to prevent errors and start a launch. I do get stuck after `Starting UI Subsystem` gets logged but I havent put any real effort into trying to debug that yet.
Maybe related to the LWJGL warning?
Same output and behavior, though.
Also tried with an older JDK (version 17), but that fails to even open a window.
Setris-1.2_LINUX % java -version openjdk version "17.0.7" 2023-04-18 OpenJDK Runtime Environment Temurin-17.0.7+7 (build 17.0.7+7) OpenJDK 64-Bit Server VM Temurin-17.0.7+7 (build 17.0.7+7, mixed mode, sharing)
Setris-1.2_LINUX % java -XstartOnFirstThread -jar setris-desktop-1.0-SNAPSHOT-jar-with-dependencies.jar [30.05.23][12:16:41] Loading Assets [30.05.23][12:16:41] Done. [30.05.23][12:16:41] Starting UI Subsystem ^C% Setris-1.2_LINUX %
One thing, I think it would look nicer if it waited until the sand settled before remove a "row".
This reminded me of a physics-based Tetris that a friend of mine built many years ago: http://phystris.pi-dev.com/
I like how it looks and how hard it seems.
I see that you're into Java, so I was thinking maybe you could look into transpiring your game into JavaScript so it can be embedded on a website.
Checkout GWT for that: https://github.com/gwtproject/gwt
https://libgdx.com/wiki/html5-backend-and-gwt-specifics
¹) https://stabyourself.net/nottetris2
What's your point?
Why?
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.
My point in NES or in modern software, the target resolution you want wouldn't have an affect on binary size.
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?
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.
Opionated take, but I believe that the web common runtime should be part of the OS nowadays.
Even without this, Tauri is 8Mb.
It's probably 10x more efficient than a possible JS implementation, tho.
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.
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.
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.
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
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.
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.
And you make that claim based on what?
> 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.
And so on. (The last one is my real password database and it definitely isn't 0 bytes in size.)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 ...
Envision a FAANG stomping on a human face forever...
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
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.
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'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.
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.
2023: Why can't I run it in the browser? Why can't I run it in a sandboxed environment? Because it is Java...