This is a greatly simplified intro to Minecraft technology – but a decent intro to some of the problems and solutions used in the Minecraft engine.
Back in the day, people learned programming by typing in BASIC programs from books and magazines. Besides the books that came with my TSR-80, if there was one book that got my programming bug off the ground, it had to be this one: Basic Fun with Adventure Games. A book I bought for $0.75 at an school book sale when I was around 5th grade.
What made this book so amazing is that it not only contains a full text adventure game you can type in, but it also teaches you how to write your own adventure game – from concept to implementation. I remember being blown away at how good this book was. Even today it holds up to teach the requirements and skills needed to program your first game. It certainly worked well enough for me as a 10-12 year old to completely write my own game about finding the deed to a castle after your rich uncle died. Highly recommend checking it out.
It was the most amazing 75 cents I spent in my entire childhood and still holds a special place in my heart. My copy still sits on my bookshelf next to the college programming textbooks.
- Complete PDF version of Basic Fun with Adventure Games
- Authors: Margaret A. Zuanich; Susan D. Lipscomb
- Publisher: HarperCollins Publishers, Avon Books
- Date: 1984
- ISBN 10: 0380874865
- ISBN 13: 9780380874866
- Alternate download location: https://spectrumcomputing.co.uk/entry/2000849/Book/BASIC_Fun_with_Adventure_Games
- Apple II version from RetroProgrammez: cia.bas (note: has a few typos and at least one syntax error mid-game that need to be fixed)
- Basic Fun with Graphics The IBM/PC Way – downloadable PDF
- Another page from RetroProgrammez that covers this book.
- Online copies of other programming books by Susan Drake Lipscomb
- Online copies of other programming books by Margaret Ann Zuanich
- Compute! magazine archive – type in your own programs from the era
There are countless image compression formats, and the world likely doesn’t need more. However, Dominic Szablewski was tinkering around with compressing RGB images and came up with his own lossless, super-fast, super-tiny compression algorithm called the Quite Ok Image compression algorithm.
While this is somewhat interesting in itself, the comments have a great discussion of how image compression has gone through a whole history of developments.
Back in the day, you had to write all your code by hand a text editor like vi or emacs, run the compiler by hand from the command line, and debuggers were also command line/text controlled horrors that were particularly notable painful experiences.
Along came programming IDE’s (Integrated Development Environments), and things started getting much better. Integrated editor, building, and visual debugging. This transformed writing software greatly, improving developer productivity and lives. Along came auto-complete and symbol lookups and yet another milestone of ease was achieved.
Google has taken things to the next level. DeepMind now powers AlphaCode – an AI trained to generate code and they claim it is almost as good as an average human programmer. I have already written about new efforts such as Github Copilot to expand autocomplete to entire code blocks using AI, but AlphaCode solves whole problems. When given coding challenges used in human competitions, it achieved an estimated rank in the top 54% of coders. Google is not alone, Microsoft is now adapting OpenAI’s GPT-3 engine to function as a coding auto-completer as well.
If you want to read about one developer’s experience using Github Copilot, check his article from Wired out.
One potential issue is that these AI engines are trained from open-source projects. Analysis shows that most of the code they generate have serious security vulnerabilities. This means that bad actors might start publishing key code blocks with known vulnerabilities in order to spread these vulnerabilities into commercial projects.
What does it take to write software that lives depend on and send rockets to space? Fast Company wrote a great article of the software engineers that delivered that software for the Space Shuttle. Particularly noteworthy is the observations of Quinn Larson, 34, had worked on shuttle software for seven years when he left to go to work for Micron Technology automating the saws that cut finished chip wafers to the right size. “It was up to me to decide what to do,” says Larson. “There were no meetings, there was no record-keeping.” He had freedom; it was a real kick. But to Larson’s way of thinking, the culture didn’t focus on, well, the right stuff. “Speed there was the biggest thing,”. Larson eventually went back at the shuttle group. “The people here are just of the highest caliber,” he said on his first day back in Clear Lake.
In interviewing the Shuttle team, they boiled down to 4 key principles that set the development team apart from other software teams:
1. The product is only as good as the plan for the product. At the on-board shuttle group, about one-third of the process of writing software happens before anyone writes a line of code. NASA and the Lockheed Martin group agree in the most minute detail about everything the new code is supposed to do — and they commit that understanding to paper, with the kind of specificity and precision usually found in blueprints. Nothing in the specs is changed without agreement and understanding from both sides. And no coder changes a single line of code without specs carefully outlining the change.
2. Within the whole software team, the team is broken into two seperate groups: the coders and the verifiers. The two outfits report to separate bosses and function under opposing marching orders. The development group is supposed to deliver completely error-free code, so perfect that the testers find no flaws at all. The testing group is supposed to pummel away at the code with flight scenarios and simulations that reveal as many flaws as possible.
3. The software consists of the code and two enormous databases. There is the software. And then there are the databases beneath the software, two enormous databases, encyclopedic in their comprehensiveness. One is the history of the code itself — with every line annotated, showing every time it was changed, why it was changed, when it was changed, what the purpose of the change was, what specifications documents detail the change. Everything that happens to the program is recorded in its master history.
The other database — the error database — stands as a kind of monument to the way the on-board shuttle group goes about its work. Here is recorded every single error ever made while writing or working on the software, going back almost 20 years. For every one of those errors, the database records when the error was discovered; what set of commands revealed the error; who discovered it; what activity was going on when it was discovered — testing, training, or flight. It tracks how the error was introduced into the program; how the error managed to slip past the filters set up at every stage to catch errors — why wasn’t it caught during design? during development inspections? during verification? Finally, the database records how the error was corrected, and whether similar errors might have slipped through the same holes.
4. Don’t just fix the mistakes — fix whatever permitted the mistake. Importantly, the group avoids blaming people for errors. The process assumes blame – and it’s the process that is analyzed to discover why and how an error got through. At the same time, accountability is a team concept: no one person is ever solely responsible for writing or inspecting code. “You don’t get punished for making errors,” says Marjorie Seiter, a senior member of the technical staff. “If I make a mistake, and others reviewed my work, then I’m not alone. I’m not being blamed for this.”
The real answer is to always use seconds since an epoch for logging – like the Unix epoch – with 64 bit integer representation (signed, if you want to allow stamps before the epoch). Any real-world time system has some non-linear, non-monotonic behaviour like leap hours or daylight savings.
Very clever idea – and I like the use of head-tracking parallax to add more interactivity.
Just a reminder that the parallax technique has been around since 2007 – and even long before that.
Until 2020, the 340 character cipher remained un-decrypted. There have been no end to the theories about the meaning of the code and the identity of its author from would-be sleuths. With the solution text now out and standing up to scrutiny, it’s a wonderful reminder that internet sleuths need to be taken with a grain of salt.
One of these sleuths, Sam Blake, decided to contact programmer David Oranchak of Roanoke, Virginia after he gave a talk on it at the annual meeting of the American Cryptogram Association. Blake was particularly intrigued by the idea of homophonic substitution where one letter might be swapped for more than one symbol and then re-arranged in a systematic way. This generated a whole host of new ways to read the cypher.
Here’s Oranchak’s talk:
Oranchak took what he’d found to Jarl van Eycke, a Belgian warehouse worker and codebreaker who’d written AZdecrypt, software used for decoding homophonic substitutions. Van Eycke used an updated version of his software to churn through the possibilities. Using misspellings and characteristics from Zodiac’s previous writings things started falling into place.
The code used a tremendous amount of computing power, power that was definitely not available in 1960’s. The techniques involved in cracking it weren’t like the ones used in modern cryptography, so it’s explains why few people have used such statistical models on what is essentially a one-off code.
Oranchak sent their solution to contacts at the FBI, and by the end of 2020, the FBI had verified the methodology and results. In March 2021, Blake wrote about how he’d used Mathematica, a math software package, for his part, and in January, van Eycke made headlines again when he cracked an unsolved 386-year-old code composed by a Dutch scientist.
JDH sits down and writes his own OS from scratch – and it runs in a VM on modern x86 hardware. But what should his OS do? How about play Tetris. With graphics, keyboard input, and even Soundblaster sound. He writes everything from scratch to handle all of this. As someone that grew up with 8086 assembly and programming old DOS based TSR programs, this was a blast from the past and definitely worth a watch.
MattKC asked himself if he could put a whole game into a QR code. He actually succeeds at it, but with some fascinating turns along the way which include changing linker settings and creating a window in assembly.
One of his other adventures is compressing the executable using an old demoscene tool: Crinkler. Crinkler is not your normal RAR, ZIP, or other self-extracting executable compressors. Crinkler replaces the linker used to generate the executable by a combined linker and compressor. The result is an EXE file which does not do any kind of dropping and decompresses into memory like a traditional executable file compressor.
It also uses context modelling, which produces a far superior compression ratio than most other compressors. The disadvantage of context modelling is that it is extremely slow and needs quite a lot of memory for decompression, but this is not usually a problem with 4k demos.
Give his adventure a watch below. Also