A quick (but useful) update to an oldie-but-a-goodie

One of the first apps I ever wrote for Android, and certainly the first app I published to the Google Play Store, was a simple unit converter app. (My god, that was nearly six years ago!) With over 150,000 loyal users, I’d say it’s been modestly successful, especially considering the hundreds of other similar utilities that exist on the Play Store.

Anyway, I thought it’s high time that this app receives some love, so I implemented a feature in the app that I’ve been wanting to make for quite a while: Widgets! You can now drop a widget right onto the home screen of your device, so that you can perform quick unit conversions on the home screen, without having to launch a separate app! You can also drop multiple instances of the widget, if you need more than one quick conversion. Here’s what it looks like:

The steps for putting a widget on your home screen varies for different Android devices, but generally it involves pressing-and-holding within an empty area of the home screen, and selecting from the “Widgets” menu. If you have the app installed, you should see a “Convert Units” widget that you can select and place on the home screen.

After placing the widget, you can configure which units it shows by pressing the “gear” icon on the left. You can then increment and decrement the value to convert by pressing the “+” and “-” buttons, or exchange the “to” and “from” units by pressing the widget itself.

No Man’s Sky: All Breadth, No Depth

Imagine a game that shows you a random number and asks you to give that number a name, and upload it to a database. That, in a reductive nutshell, is the general idea of No Man’s Sky. The question is whether No Man’s Sky dresses up this mundane  premise in a way that makes it worth playing. The short answer, I’m afraid, is no. The game disappointed me in  several ways, which I’ll outline below, along with some lessons and recommendations for future game developers, which they are welcome to take or leave.

General disappointment

In a broad sense, the game is indeed  revolutionary, since it allows the player to roam free in a universe filled with procedurally generated planets, meaning that no two planets are exactly alike. The game allows for 18 quintillion (264) such planets, giving the player an inexhaustible supply of new worlds to visit and explore.  And make no mistake: the first impression that this game gives you is outstanding – breathtaking vistas, a world bustling with life, and seemingly unlimited possibilities for exploration.

Unfortunately, the procedurally generated elements are only a thin veneer on top of a whole lot of repetition and mundanity. After exploring a few planets, it becomes clear that while the landscapes are indeed randomly generated, the small-scale structures are pulled from a very limited selection of shapes. Things like trees, flowers, corals, crystals, geologic structures, etc. are nearly identical from planet to planet. The various animals that can be found on each planet (again, randomly generated permutations of a small selection of body part shapes) provide some amusement, but there’s nothing else to do with them except catalog and upload them to a database that no one will ever see.

Each planet is also peppered with “artificial” structures like trading posts, transmission towers, and manufacturing facilities. All of these are identical from one planet to the next. If you’ve visited one, you’ve visited them all. The same goes for space stations that are present in every star system: they look nearly identical on the outside, and exactly identical on the inside.

The intelligent aliens that you encounter along your travels look and behave identically, are completely static, and allow for a single conversation that has zero consequence, and may provide a crafting schematic that you already have.

“Star systems” are not really star systems; they are clumps of a few planets in close proximity, between which you can hop in your starship. Space itself, far from being empty, is jam-packed with asteroids that are made of starship fuel, conveniently enough.

There’s never any sense of danger, since you can crash directly  into asteroids while taking minimal damage, and the game simply won’t let you fly too close to the surface of planets. The idea of survival being one of the pillars of this game is laughable. You really have to try to get killed in this universe.

The game’s universe also feels sort of abandoned: none of the planets have any cities or settlements, except the aforementioned lone buildings, which are sparsely spread out and manned by a single alien at most. Where do these aliens come from? What do they do outside of work?

There are also  occasional starships or freighters floating around in space between the planets, whose only purpose is  to tempt you to steal their cargo. Where do these ships come from? Where are they going? Does it matter?

Occasionally, you’re attacked by hostile starships in space, or by hostile “sentinels” on the ground. They appear out of thin air, and their motivation is completely unknown. The battles unfold identically  from one instance  to the next.  The battles also have zero consequence, since you can return to your death point and retrieve your lost items, with the enemy no longer in pursuit.  And thus, the game manages to reduce something as exciting as  a battle to even more monotony.

Therefore, on the whole, the novelty of this procedurally generated universe wears off after a couple hours. After that, it becomes a tedious grind of collecting resources to power your starship and expand your inventory, with ever-diminishing reason to do so.

Specific disappointment

From the beginning of the game, the player is given the option to follow a storyline where the player embarks on the path of “the Atlas”, a mysterious force/entity that starts to guide the player towards a vague eventual goal. The storyline has a good dose of mysticism and philosophy, as well as  some nice visuals along the way. I found this storyline much more interesting than any of the procedurally generated elements in the game, which says a lot about the latter.

However, the ultimate disappointment came at the end of the Atlas storyline. The game asks the player to collect ten “Atlas stones”, which involves a time-consuming process of collecting resources, crafting new supplies, and upgrading your starship so that you can travel from one Atlas station to the next. At each Atlas station, the suspense builds, and the player expects an ever-more-grandiose payoff at the end. But instead of a grandiose payoff, we get… nothing.

When you turn in the ten Atlas stones into which you’ve invested so much time, you’re told (not shown) that you’ve fulfilled your destiny by “birthing a new star”, and that you’re now “free to explore” on your own. This is done offhandedly, in the exact same conversation interface as all other interactions in the game, and with no other visuals to make note of your accomplishment. You’re not shown this new star, there’s no cutaway scene, and there’s not even any reward in terms of upgrades, milestones, or possessions. The game simply continues, with no further information given.

At first I honestly thought that it was a bug in the game. But when the realization sank in that the storyline was over with absolutely no payoff, I was kind of appalled, and was pretty much turned off from playing the game any further.

I’ve also already read spoilers of the actual “ending” of the game (when the player reaches the center of the galaxy), which turns out to be almost equally unsatisfying. I therefore have zero interest in completing that portion of the game, either. All that’s left is to visit random planets and upload them into a database that no one will ever see. Or, more precisely, look at random numbers and give them a name. No, thank you.

Controls and user interface

The controls in the game are very frustrating. I played the PC version of the game, and it doesn’t feel like it was built for a PC; instead it feels like a back-port of the PS4 version, or some kind of lowest-common-denominator between the two. When I press a button on the keyboard, or click my mouse, I expect that action to have an immediate effect. However, the game expects you to press and hold your mouse and keyboard buttons for a split second, in order to perform  the desired action. Moreover, this scheme is inconsistent: some actions are immediate, while others are press-and-hold.  This requires users to unlearn the way they’ve interacted with PCs since the beginning of time, and adds a huge amount of unnecessary frustration.

All of the conversations with aliens and interactions with objects come with built-in  mandatory delays, to accommodate a slow animation that cannot be skipped. This is fine the first few times, but then becomes very annoying. The biggest offender in this category is the interaction for selling items on the “galactic market”, where the interface animates for a full five seconds before offering the options to buy or sell items.

Maneuvering through space in your starship works well enough, but becomes inexplicably terrible when maneuvering over a planet’s surface. At random times, your ship will pull itself to the left or right. There’s an invisible barrier that prevents you from flying too low, which takes away any excitement you might get from wanting to fly  through canyons or mountain ranges.  When taking off from the ground, your launch thruster may put you a few kilometers above ground, or it may put you into orbit, with no clear way to control it. But I digress.

The Good

The best thing I can say about No Man’s Sky is that it’s a beautiful proof of concept, and I certainly don’t regret trying it out. As a software developer, I can appreciate the tremendous  engineering skill that went into constructing this world. I can also see exactly what “happened” in the development of this game: 99% of the effort went towards building the game engine, and 1% went towards thinking about the story and the gameplay.

Nevertheless, the fact that it was executed by an indie game studio makes it doubly impressive. No Man’s Sky has laid the groundwork for a procedurally generated sci-fi adventure. To see that it’s even possible to create this kind of world is very encouraging. I look forward to the next iteration in this genre, perhaps executed by a major game studio, that might feature more meaningful procedural elements, better multiplayer interactions, and most importantly, deeper storylines.

To summarize, there’s a  brilliant little YouTube video  that captures my feelings on the game perfectly. Enjoy.

Data recovery war stories: more fun with QIC-150 backup tapes

In case you’re not aware, I offer a service for recovering data from old or obsolete storage media, such as magnetic tapes, Zip drives, floppies, etc. One of my recent cases, from a rather prominent client, was interesting enough to warrant a detailed write-up. The task was to recover a backup from a QIC-150 tape. I’m no stranger to recovering data from these tapes, so I thought that this case would be fairly routine. However, it turned out to be a bit more involved, in a number of fascinating ways.

First was the matter of hardware: my go-to drive for reading the tapes was my Archive Viper 2150S. However, when I unpackaged it from its static bag, I noticed a black goo all over it. It turned out that the rubber wheel attached to the capstan that drives the tape reels had completely melted! I must have stored the tape drive in excess heat, causing the rubber to melt, and rendering the drive unusable. I proceeded by replacing the drive with a Tandberg TDC 3600, a mere $50 on eBay. (Lesson learned: store tape drives in a cool, dry place!)

Anyway, I proceeded to attach the tape drive to my usual SCSI setup, which includes a Adaptec AHA 2940UW host adapter, which had served me well in the past, and proceeded to boot into the latest version of xubuntu (16.04), thinking that all I’d need to do is dump the tape contents by calling:

$ sudo mt -f /dev/nst0 rewind
$ sudo dd if=/dev/nst0 of=tape.bin

The above commands worked, but it only retrieved about 20MB of data, whereas my client was certain that the backup was at least 100MB (and the tape capacity is 250MB). I quickly realized that the tape contains multiple “files” worth of data. Even though tapes do not have a file system of their own, they do indeed have the notion of “files” stored sequentially along the tape stream, sometimes referred to as “records”. This tape turned out to have five of these files, each 20MB in size, totaling just over 100MB as expected. Tip: to continue reading the “next” file on the tape once the previous file is finished, it suffices to simply execute the same dd command above, with a different output file name. It’s also possible to fast-forward or rewind to any file location by calling:

Go backward one record:
$ sudo mt -f /dev/nst0 bsfm 1
Go forward one record:
$ sudo mt -f /dev/nst0 fsf 1

Having the tape contents dumped, next came the task of identifying the format of the data contained in the dumps. My client initially thought that the tapes were Unix backups saved with the tar command, which would have been convenient, but this turned out not to be the case. The binary format of the dumps was not any format that I recognized. Fortunately, after the client looked at the binary data, he guessed that the backups may have been from an old Macintosh computer, and that the backup software was Retrospect.

My thinking then was to set up an emulated Mac environment, install an old version of Retrospect on it, and try using it to “restore” the data from the binary dumps. The most robust emulator of old Mac architecture is Basilisk II, and fortunately I already had a basic pre-made emulated environment running System 7.5. I then managed to find an ancient version of Retrospect on an abandonware website, and installed it in the emulated system. However, when trying to restore data from the backup – no luck. Retrospect was actually able to read the internal name of the backup (which means that it definitely came from Retrospect), but couldn’t read its catalog contents. It was becoming clear that Retrospect must have had a special proprietary format for saving the data onto a tape. If only there was a way to “trick” the software into thinking that it was reading the backup directly from a tape drive…

After some more researching and digging, I found that Basilisk II has an extremely powerful option that makes it able to have pass-through access to the physical SCSI bus on the host machine! All it needs is to add this line to its initialization file (.basilisk_ii_prefs):

scsi0 /dev/sg2

In the above line, /dev/sg2 points to my actual tape drive, represented as a generic SCSI device in Linux. Amazingly (almost miraculously), this worked, to the point of the emulated Retrospect being able to detect the SCSI tape drive, and read the catalog contents of the backup!

However, next came the final hurdle. Although it was able to read the catalog, when I asked it to actually restore the files, it did nothing. It just sat there indefinitely. It was so close! It was literally showing me the contents of the backup, but it wouldn’t budge on actually recovering them. Is it a faulty tape drive? Is it an incompatibility between the emulated SCSI driver and the actual hardware? Is it a bug in the backup software?

I continued by recompiling Basilisk II with debug options turned on, particularly enabling debug output in the SCSI modules, since I wanted to see exactly what kind of SCSI commands the emulator was trying to send. All of the I/O was looking normal, until I made the request to restore the backup contents (which was making it hang). The emulator requested to read a block of 6MB of data from the tape. I thought, “that’s a rather large amount.” Does the emulator actually have enough RAM to hold that much data? Yes indeed, in the emulator’s configuration, I was giving it 32MB of RAM.

And then, it finally dawned on me: does the tape drive actually support returning that much data at once? Probably not… but how do I reduce the amount of data that the backup software asks for? The answer: give the emulator less RAM, which will constrain the maximum buffer size that it can request! I tried giving it 4MB, but this was too little to allow the backup software to read the catalog contents into memory. I bumped it to 6MB and… everything worked. I watched in amazement (and relief) as the restoration was really happening – emulated backup software was communicating with a real SCSI device!

All that was left was to copy the restored files out of the emulator and into my “real” PC, which is easy since Basilisk II can actually mount a Linux directory as a drive within the emulated Mac. That’s it!

During this experience, what impressed me the most was the quality of the Mac emulator (Basilisk II), and how powerful its features actually are. The author of this software deserves huge kudos for creating it, and making it available for everyone. And of course, this is further proof that my obsession with emulators sometimes pays off!

The state of emulation on Android

For whatever reason, I have a strange fascination with emulators, and making sure that I can emulate as many machines and game consoles as possible on my current PC.

The one thing I haven’t researched until now is emulating various systems on my Android device. Now that I’ve received my shiny new Galaxy S7, I figured it must be powerful enough to emulate a good fraction of older hardware. And indeed, I was pleasantly surprised by the “state” of emulation on Android.  Emulators for NES and Super NES are readily available on the Google Play Store, along with emulators for Atari and Commodore 64, and hardly require the latest hardware to run well.

But what about emulators of  actual PC hardware? Well, there’s the excellent DosBox Turbo app, which is an optimized DosBox port to Android. This is not a free app, but it’s well worth it. However, what I was looking for is a true PC emulator, such as the great bochs emulator that I’ve trusted for a long time to boot into my disk images of Windows 3.1 and Windows 95. After a bit of looking, it turns out that this is available, too!

Thanks to  some fantastic work by Pelya (for porting the SDL 1.2 library to Android, thus  making it easy to port any SDL-based application to Android) and by  Lyubomyr  (for actually adapting bochs to use pelya’s SDL port), we now have a perfectly working version of bochs for Android! Using their build instructions, I was able to build my own bochs APK, load it onto my device, along with a few disk images. And after a few configuration tweaks, I’m now able to run my emulated images nearly flawlessly:

Here it is, running Windows 3.11:

…and Windows 95:

…and Windows XP:

And here it is running one of my favorite old DOS games, Return to Zork!

Planetarium app for Samsung Gear VR!

As a fun side-project during the last few weeks, I’ve been developing a planetarium application for the Samsung Gear VR headset (one of the neater gadgets I’ve gotten my hands on this year), along the lines of Stellarium or Google Sky Map. It’s pretty rudimentary so far, but nevertheless packs most of the features you would expect from a planetarium application, such as constellations, accurate planet positions based on current time, and a selection of Messier objects.

You can “look at” any object in the virtual night sky within the app, and see a pop-up description of its name. While looking at an object, you can also tap on the trackpad on the Gear VR device to retrieve a full description of the object from Wikipedia (using Wikipedia’s new RESTBase API, which I also help develop).

The app is not yet deployed to the Oculus app store (working on it…), but you’re welcome to check it out on GitHub and build it for your own device. Here are some screenshots: