I really love this idea. I had my daughter watch the video as well, and she absolutely fell in love with it immediately. It literally brought smiles to our faces.
Yup, that's the design for now. This may not scale well in the future, and I've already experienced issues with performance, but the simplicity of this approach is what makes me want to find a way to make it work. If it becomes something that I have to improve in the future, I'd probably opt for trying to use views, or some kind of magic with indexes. Or possibly even modifying the database engine itself. The whole idea of using a database engine is that you don't have to write your own special optimized storage format, and if the db engine can't figure out how to optimize the performance of a simple table like this, then I think it's the db engine that needs improving.
@@RobertElderSoftwareFor simple tiles, does it really need to be that optimized? I've been working on a mining game that just uses 2 byte values for "blocks" and it still takes absolutely ages to take up any meaningful amount of space. Even cut it down by 2/3rds if you compress the files because there's so much repeating information
Curious, did you actually try it on a real VT220 physical terminal? I don't have any hardware like that to test it on. If I did, it probably wouldn't be too hard to get it to work. I'm not sure which escape sequences the VT220 supports, but if it can do cursor changes and requests, then it should probably be able to work. The game will detect the terminal size at startup, so it should work automatically for any terminal size. BTW, you can use the '--restricted-graphics' to use the mostly ASCII view (although, I forgot to replace the frame characters in this view, I'll do that in the next version).
For the second time in as many days I find myself once again wondering, why Java? For that matter, which runtime do you use? OpenJDK or Oracle's runtime?
Probably a better question would be: Which language *other than* Java would be best? Python is more for smaller prototyping projects, and its dynamic typing is great for iterating fast on smaller problems, but becomes a huge problem for large projects. C or C++ is not a good choice for this project IMHO because a game like this will require lots of string operations and garbage collection, neither of which are strong points of C/C++. C or C++ is better for stuff that *requires* it, like interfacing with the kernel API or doing spooky interrupt/signal stuff etc. In fact, I have some C++ in this project for the JNI library. Rust is a language I've looked at in the past, but the syntax of it seems to get more complicated every time I look into the language, and the benefits don't seem that significant. Haskel is a language I've wanted to learn, but it's also not widely used and difficult to find developers for. I could go on, but on balance, Java seems like a pretty decent choice.
@@RobertElderSoftware I'm not too keen on functional programming languages, but I am curious as to why it would matter if you could find other developers for Haskell. I can agree with your reasoning for Rust and Python, and add that Python completely ignores type hinting in every case but like one. However, I mostly disagree with regards to C and string handling. If you're talking about from scratch then that's somewhat understandable, but you're not doing that in Java. A long-lived and well-tested library for C is as reliable as most languages' standard libraries, and there's plenty of choices in C for string handling, even for Unicode. And if you really need GC, which I doubt you do, there is always the Boehm GC. Of course, I'd advocate for using an arena allocator instead. Although, I wasn't attempting to steer you towards any given language, I was just curious as to why Java, because I am kind of averse to verbosity when programming, even if not when writing prose.
@@anon_y_mousse IMHO, the verbosity of java is not just wasted space, you're actually getting something in exchange for all the extra typing. Also, I wrote an (incomplete, but fairly functional) C compiler that could compile itself and a small microkernel. Drawing on this experience, I have concluded that for anything where there's a lot of string operations it makes sense to not use C or C++.
@@RobertElderSoftware Interesting, but I've written multiple compilers and interpreters in my career and I've found C to be the ideal choice for writing a parser. You might make an argument that I've had a lot of practice and thus have a different viewpoint on things, as my first parser I wrote in high school using Pascal, but when it comes to manipulating strings, I find that using two and three character symbols to access bits of a string is far easier than writing out whole function calls. Of course, if you feel it necessary to do that in C, as I've said, there are many libraries which do things in that way. I really didn't mean for this conversation to turn into some evangelical promotion of any given programming language, but I've used a *LOT* of different programming languages over the years and they've mostly done string handling in a way that I find quite horrible.
Terminal Block Mining Simulation Game is _my favourite_ terminal block mining simulation game
This is my favourite comment.
I really love this idea. I had my daughter watch the video as well, and she absolutely fell in love with it immediately. It literally brought smiles to our faces.
That's a very endearing reaction to this game idea, and I'm glad to hear that it can make that impression on people!
I was going to subscribe and then I realized I was already subscribed.
Cool technical overview! Really impressive programming skills.
terminal games are underrated , i wish it was more acceptable to release full featured games in the terminal
That's awesome, my block turned out great!
Thank you Robert!
Keep up the great work.
It's been a while since I've looked at my favorite Linux game, it's come a long way! Looks wonderful, keep up the great work!
wooah, using emojis is so smart! that's an incredibly simple solution for unique graphics... it's a really cool mixture of old and new.
Nice thumbnail
That's a great project! You start mining blocks and you end up killing zombies in Cataclysm! 😂 😂
when add kitty terminal graphics protocol
hello RobertElderSoftware
hello kaslmineer7999
``hello kaslmineer7999`` is my favorite repliy
It contains M. S. G.!!
I want someone to please recreate Give Up Robot 🥺
It's all really cool, but... every block is stored as its own row in the database????
Yup, that's the design for now. This may not scale well in the future, and I've already experienced issues with performance, but the simplicity of this approach is what makes me want to find a way to make it work. If it becomes something that I have to improve in the future, I'd probably opt for trying to use views, or some kind of magic with indexes. Or possibly even modifying the database engine itself. The whole idea of using a database engine is that you don't have to write your own special optimized storage format, and if the db engine can't figure out how to optimize the performance of a simple table like this, then I think it's the db engine that needs improving.
@@RobertElderSoftwareFor simple tiles, does it really need to be that optimized? I've been working on a mining game that just uses 2 byte values for "blocks" and it still takes absolutely ages to take up any meaningful amount of space. Even cut it down by 2/3rds if you compress the files because there's so much repeating information
@@RobertElderSoftware Maybe Neo4j?
Meh does not run on a physical terminal (e.g. DEC VT220) - Any chance for a 80x24 ANSI/ASCII version?
Curious, did you actually try it on a real VT220 physical terminal? I don't have any hardware like that to test it on. If I did, it probably wouldn't be too hard to get it to work. I'm not sure which escape sequences the VT220 supports, but if it can do cursor changes and requests, then it should probably be able to work. The game will detect the terminal size at startup, so it should work automatically for any terminal size. BTW, you can use the '--restricted-graphics' to use the mostly ASCII view (although, I forgot to replace the frame characters in this view, I'll do that in the next version).
Yknow, I'm wondering how well it would run in the Windows terminal app since it is made with java
That's a really impressive work. My applause , lml
thanks, you literally destroyed by computer
Imagine its just squares because you dont have a font that has emojis
I bet you that making that license file required more effort than writing the whole game.
For the second time in as many days I find myself once again wondering, why Java? For that matter, which runtime do you use? OpenJDK or Oracle's runtime?
Probably a better question would be: Which language *other than* Java would be best? Python is more for smaller prototyping projects, and its dynamic typing is great for iterating fast on smaller problems, but becomes a huge problem for large projects. C or C++ is not a good choice for this project IMHO because a game like this will require lots of string operations and garbage collection, neither of which are strong points of C/C++. C or C++ is better for stuff that *requires* it, like interfacing with the kernel API or doing spooky interrupt/signal stuff etc. In fact, I have some C++ in this project for the JNI library. Rust is a language I've looked at in the past, but the syntax of it seems to get more complicated every time I look into the language, and the benefits don't seem that significant. Haskel is a language I've wanted to learn, but it's also not widely used and difficult to find developers for. I could go on, but on balance, Java seems like a pretty decent choice.
And also, I just use openjdk.
@@RobertElderSoftware I'm not too keen on functional programming languages, but I am curious as to why it would matter if you could find other developers for Haskell. I can agree with your reasoning for Rust and Python, and add that Python completely ignores type hinting in every case but like one. However, I mostly disagree with regards to C and string handling. If you're talking about from scratch then that's somewhat understandable, but you're not doing that in Java. A long-lived and well-tested library for C is as reliable as most languages' standard libraries, and there's plenty of choices in C for string handling, even for Unicode. And if you really need GC, which I doubt you do, there is always the Boehm GC. Of course, I'd advocate for using an arena allocator instead. Although, I wasn't attempting to steer you towards any given language, I was just curious as to why Java, because I am kind of averse to verbosity when programming, even if not when writing prose.
@@anon_y_mousse IMHO, the verbosity of java is not just wasted space, you're actually getting something in exchange for all the extra typing. Also, I wrote an (incomplete, but fairly functional) C compiler that could compile itself and a small microkernel. Drawing on this experience, I have concluded that for anything where there's a lot of string operations it makes sense to not use C or C++.
@@RobertElderSoftware Interesting, but I've written multiple compilers and interpreters in my career and I've found C to be the ideal choice for writing a parser. You might make an argument that I've had a lot of practice and thus have a different viewpoint on things, as my first parser I wrote in high school using Pascal, but when it comes to manipulating strings, I find that using two and three character symbols to access bits of a string is far easier than writing out whole function calls. Of course, if you feel it necessary to do that in C, as I've said, there are many libraries which do things in that way. I really didn't mean for this conversation to turn into some evangelical promotion of any given programming language, but I've used a *LOT* of different programming languages over the years and they've mostly done string handling in a way that I find quite horrible.
zuper
minecraft with terminal cancer
in java??? ew