DISCLAIMER: This is a rather long post on the topic of random numbers, so …uh, sorry for that.

I want to talk about a couple of interesting things related to randomness and its many nuisances especially when applied to games. But before we get to that I guess I’ll introduce the basic notions for those of you who are not familiar with this whole thing. You can skip the first two sections if you know what a PRNG is, and how it works.

What is Random

Random is commonly defined as “unpredictable“. In general, when we are unable to find a pattern that would allow us to anticipate the outcome or occurrence of an event, we call it “unpredictable” and there’s a chance we will consider the event “random”.

You’ll also hear of “true randomness”, and things like natural atmospheric noise, lightning bolts, or particles falling from the space being used as sources and examples of it. But while we can’t currently predict when and where lightning will hit, events in the universe like electric discharges in clouds are most likely just a massively complicated function of a number of different factors, and not really something that happens with no rhyme or reason. It’s quite possible that if we were able to simulate each particle and sub-particle inside a group of storm clouds and their relevant vicinity, lightning would be trivial to anticipate with accuracy. This makes its “unpredictability” debatable, I guess.

Having said that, let’s not forget that “predictable” and “unpredictable” are relative to an “observer”. What we consider true random events could totally have a logic behind, but what matters is that from our -and our system’s- point of view, they are impossible to predict, and if the machine (or person) is unable to anticipate the occurrence of an event, the definition applies, regardless of the event’s “actual” predictability.

I used to have a small desk clock that I purchased for a trip. It was cheap but it had some really nice features that I quite liked. It had large digits that I could see from my bed each morning, and it was also able to measure and display the current room temperature, which I always thought was incredibly cool for a clock.

The problem is, that it required a lot of batteries to work; 4XAAA for the fancy LCD backlight and soothing RGB glowing action, and 2xLR66 (button cells) for keeping the thing ticking and actually displaying time and temperature on its LCD screen. It worked reasonably well, but it was running through the batteries way too fast, in my opinion.

I didn’t really care about the AAA batteries dying in a month, because I could always use rechargeable batteries there, but the small LR66 batteries were killing me. Replacing them each 5-6 months or less wasn’t really a pleasure, especially since it meant setting time, date and alarms all over again, every time.

So I adventured in the journey of building my own clock. My main objective was to keep the number of batteries low, while also having the nice features of my previous clock, like the big numbers and the temperature readings.

This post is a sort of sequel. I’ll talk about some of the issues and nuances I found when working on a more complex (but related) project; In this case a Composite USB Device that I had to implement on a PIC 18F4550 microcontroller.

So I’m writing a program in C that needs to interact with a custom HID device I built. This program will be running on a Raspberry Pi. This isn’t a massively complicated task but it can be daunting when there’s not a single “barebone” example or tutorial out there on how to do this. So I decided to write this sort of guide in case it may come in handy for anyone (including myself, in a future).

Compiling libhid

Libhid is an open source library designed on top of libusb to deal with HID devices, so the first step is compiling libhid. I’d say this is relatively straight-forward except for the fact that “as-is”, the library fails to build in the Pi. Luckily the problem is a single line of code in one of the examples (yes, and that prevents the whole library from being compiled and installed).

PhoneGap allows you to create apps for a wide range of devices from a single web-based (HTML+CSS+JS) project. Once you code your content in web format (a HTML5 game for instance) PhoneGap creates an app out of it. How is that done? Well, PhoneGap makes a project for your target platform that consists of a native app that launches a webview and loads your web-content there, providing also a JS bridge to some device-specific features (GPS, accelerometers, gallery, etc) creating what’s essentially called a “hybrid” app.