Setris – Tetris with Sand Physics
mslivo.itch.io
mslivo.itch.io
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
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:
sudo apt install libfontconfig1 libxrender1 libxtst6
export LIBGL_ALWAYS_INDIRECT=0
./Setris-1.2
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
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.
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.
Same with the Zelda word...
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.
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 %
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.
mikaeleiman@iMac ~/D/Setris-1.2_LINUX> java -XstartOnFirstThread -jar setris-desktop-1.0-SNAPSHOT-jar-with-dependencies.jar
[LWJGL] [ThreadLocalUtil] Unsupported JNI version detected, this may result in a crash. Please inform LWJGL developers.
[30.05.23][11:52:12] Loading Assets
[30.05.23][11:52:12] Done.
[30.05.23][11:52:12] Starting UI Subsystem
[30.05.23][11:52:12] Done.
[30.05.23][11:52:12] 0 FPS | 260MB RAM | 8 Threads | Render: 13ms
mikaeleiman@iMac ~/D/Setris-1.2_LINUX>
Maybe related to the LWJGL warning?
CLASSPATH=(string join ':' (find . | grep jar | grep lwjgl)) java -XstartOnFirstThread -Xmx4G -jar setris-desktop-1.0-SNAPSHOT-jar-with-dependencies.jar
Same output and behavior, though.
Also tried with an older JDK (version 17), but that fails to even open a window.
* Now also available as a web game on CrazyGames: https://www.crazygames.com/game/sandtrix
Silly physics fun in the browser, but not a complete game (yet).
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.
One thing, I think it would look nicer if it waited until the sand settled before remove a "row".
It was like tetris but with random pieces of trash you dropped a dumpster. Heavy trash could compact lighter trash, you could find a piece of trash that would explode or burn other trash, etc..
Definitely not as elegant and perfect as Tetris but very amusing.
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.
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 :)
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 ...
It's probably 10x more efficient than a possible JS implementation, tho.
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.
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.
And you make that claim based on what?
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.
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
2023: Why can't I run it in the browser? Why can't I run it in a sandboxed environment? Because it is Java...
What's your point?
displaying at high resolutions sand physics 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.
Having made NES games for fun beforeI 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.
$ firejail ./bin
> 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
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".