Pretty sure water was just a teleporter? You may be thinking about the mirror effect? I think that was a kind of a portal effect. You had to make a large empty section behind each mirror that was used by the engine to render a mirrored copy of things in front of the mirror.
You could make some weird impossible geometries by just superimposing sections. Two sections could occupy the exact same coordinates, but movement and rendering were done across edges shared by sections and did not care about if there was some other section in the same space. As long as there was never a way to see those sections at the same time.
I had to see an eye doctor at the hospital when I was ~7 and I got to do some exercises, but I never learned to cross my eyes, and then it was like it probably wasn't very important since I did not have to go to the doctor again and no one mentioned it so I just went on with my life and it seems overall like not being able to cross my eyes is not a huge problem. But I guess it may be connected to my complete inability to see 3D effects or figure out how to see anything in the images in the article.
Sweden had a series of disasters like that in recent years. A few months ago one region tried to switch from their old healthcare system to something delivered by Oracle, but quickly had to roll back to the old system.
In 2021 an expensive system for schools in Stockholm was so bad that some parents got together and wrote an open source app to not have to use the bad official UI.
The java 4k contest was fun (make a java applet game that is at most a 4096 bytes JAR, including all assets the game needs). Unfortunately I only discovered it shortly before it shut down (when no browsers supported java applets anymore). I did enter one year and it was not by coincidence that was the only time in 40 years of hobby-gamedev that I shared a game I made with people online.
It was a lot of fun to try to squeeze a game into 4 kB but I can definitely also admit that part of it was being able to use the extreme limit as an excuse for making things simpler and not have to worry about the game being ugly or not having sounds or not having a title screen and all the other 90% of stuff that would have been expected to turn it into a complete game.
I play around a bit with TIC-80. Some say it is just an open source PICO-8 and I guess it is to some extent. I paid for both but I have not spent as much time with PICO-8. I like that TIC-80 supports quite many different programming languages, but maybe PICO-8 does as well these days? There is no super obvious reason to use one or the other, so I go with the one with free source code.
Real retro gamedev is tempting, but it is difficult to find a real console that were heavily restricted while also being convenient to develop for. The fantasy consoles cheat a bit in being restricted like some early 1980's hardware while running code like some 2010's game engine. It's like the best of both worlds, but also a bit boring compared to writing something actually limited to what some old console could do.
I never was a big fan of Lua and that was something that kept me from looking closer at Löve, but a few months ago I discovered fennel (Lisp-like that transpiles to Lua) and that you can use that to write Löve games.
The "absolutely minimal Löve 2D fennel" repo was useful to me as I found the other templates a bit bloated (but possibly those are more useful for real-world projects beyond small experiments?):
I did find that startup-time was bad for Fennel om some very low-end devices, or when running even a small game using LoveDOS in DOSBox, so I set up my test-projects to pre-compile the fennel-code to Lua as part of building the .love-files and that solved that problem.
For Android you can also install the stand-alone LÖVE Loader app that can open .love files to play. Some games on itch.io comes with a .love-download (in addition to platform-specific executables), but I guess they can sometimes be extracted from other games too.
The .love-files, if provided or if they can be extracted from a game, are also useful on desktop, for playing the games in an operating system (like FreeBSD) that the game's developer did not provide binaries for.
The stand-alone app is also a fun way to do some gamedev on an Android phone. The .love file is just a ZIP, so it can be easily created from termux.
If I understand the distinction correctly, I run llamafile as a backend. I start it with the filename of a model on the command-line (might need a -M flag or something) and it will start up a chat-prompt for interaction in the terminal but also opens a port that speaks some protocol that I can connect to using a frontend (in my case usually gptel in emacs).
I have a somewhat common [email protected] and others with the same name use it pretty often. Surprisingly often it seems as if sites allow accounts to exist without email confirmation. I estimate at least 50% of the accounts out there that use my gmail is actually not me, and I like the idea of anyone trying to make sense of that data, if they can even guess that I am the Firstname Lastname that the address belongs to.
My personal observation, even if this is similar to what others already said: I found that in some (two? three?) big Java-based projects I worked on, where almost everyone used a IDE, the codebase became almost impossible to navigate or modify without using one, so I did. It was so easy to just add a method or class wherever, and it did not matter because you could just ctrl-click a name to find its implementation. It did not matter if you put 100+ methods in the same class or if you named things willy-nilly or overloaded method names.
If I was back working on a project like that, I would use whatever IDE everyone else was using. It makes no sense to fight it. But I prefer projects to not be designed for/by IDE, since that tends to make everything more readable and easy to navigate. I prefer to be able to navigate around the source-code on the command-line or use whatever generic tools to browse, and not be forced to ctrl-click my way around, and if (almost) everyone else working on the code wants that as well it is less likely that someone ruins it.
That said, I have at times also set up Emacs to use LSP or other built-in code-navigation tools, or templates (yasnippets) for generating boilerplate, for some projects. I rarely end up using it much. Usually I just jump around using built-in tools like M-x vc-git-grep or M-x rgrep. The code has to be pretty heavily designed-for-IDE to make those simple tools slow to use.
I remember downloading everything when it was released, adding it to my hoard, never using it for anything. The old Glitch site that hosted the content now just redirects to slack.com. It looked like this in 2013:
https://web.archive.org/web/20131209034741/http://www.glitch...
That is why I mentioned DOSBox. That is just one possibility, but probably currently the best one. DOS(Box) remains a fixed, known, target. Windows, even if it has impressive backwards compatibility, breaks older games often enough that it becomes annoying.
If a DOS game is distributed, as GOG does for old DOS games, with a bundled installer and DOSBox configuration, normal users would not even have to know they are playing a non-native game. We can treat it as just a generic virtual machine for games. The fact that it happens to also be backwards compatible with DOS games made 40 years ago is just a fun bonus, even if that is currently its primary purpose.
Alley Cat was one of very few old PC games that ran at a fixed speed, making it playable on higher end later PCs without having to use tools like MOSLO.
Too bad the new version was not completed for MS-DOS. If it was it would have been possible to play it on not just on Windows, but pretty much every modern and near-future (and far-future?) system.
DOSBox is a very good virtual machine for 2D games actually. It can support games far beyond what any real DOS hardware could. I wish there was support for exporting to DOS-executables included in some modern game engines, since that would provide at least a single fixed, future-safe, target platform. The closest I know of is an old DOS port of Löve 2D, but it only supports 320x200 VGA graphics. There is nothing limiting DOSBox itself to not support virtual VESA SVGA modes up to modern graphics modes (as long as x and y sizes each fit in unsigned 16-bit integers).
I searched boardgamegeek for games published in 1929. The only thing that grabbed my attention was Shambattle, the first published American miniatures wargame. It is an early, possibly the first, modern miniature wargame that used dice to resolve combat (no spring-loaded toy cannons like in Well's Little Wars for instance).
Two 16-bit numbers could be combined to form a 32-bit pointer. Used as segment<<4+offset they just form a 20-bit pointer. Feels like wasting 12 bits to me.
A bit confused by the goto and skip instructions. Why multiply by 4 in one, but not the other? Sounds reasonable that both keep the target address a valid instruction pointer (aligned to 4 words)?
Adding two words to create an address is a fun variation of segment pointers, but even more wasteful than x86 16-bit segment+offset pointers (not a complaint, just an observation).
I read an article about humanoid robots yesterday and it scared me that it seemed like the expectation is still that the robot will be 24/7 online and "thinking" using some cloud brain. The current models described more in detail all used Open AI as a brain.
Having a personal robot would be great, but they have to invent a fully offline real positronic brain before I will consider allowing one in my house.
Fully open source might be too much to hope for, but that would obviously be the ideal. If it is closed source it definitely should be offline. I can have another, carefully sandboxed, AI in my computer that can help out with tasks that require online access. No need for the two types to be built into the same device.
You could make some weird impossible geometries by just superimposing sections. Two sections could occupy the exact same coordinates, but movement and rendering were done across edges shared by sections and did not care about if there was some other section in the same space. As long as there was never a way to see those sections at the same time.