¡Ajipirijou! josé albornoz's blog

How I built my own Twitch-Plays-Pokémon: Part 3

I gave this talk at Baruco 2014.
I'm publishing it now as a series of blogposts. Make sure to check out the first part.
You can find the slides in my speakerdeck. You can also see the recording in YouTube.

Ruby Version: Advantages of having an emulator written in Ruby

So why do we care about how an emulator works?
Because we couldn't find one that does what we want, so we'll have to write our own!

WHY WOULD YOU EVER DO SUCH THING?, you might be wondering.
Because by doing that, we control exactly the way it works.

We don't need to simulate keypresses.

As we control the emulator, we control the way the real keys are emulated. That means that we don't need to simulate a keyboard anymore.

We can run on a headless server.

As we control the emulator, we can just pipe the video output to some online streaming system without having to record the screen.

We can be much closer to real time.

If we mix websockets and canvas we can stream the contents of the screen in a much more optimal way, which in theory, should remove the 20-second lag.

We control the memory!

Because the RAM of the GameBoy is not hidden from us inside an external emulator, but we actually have access to it, we can do all sort of neat things.

For starters, we can do "Version Controlling" of game plays, which means that we can

  1. Rewind gaming sessions, something people do very often
    but a bit more interesting is being able to
  2. Fork and branch gaming sessions. During the game you have to take certain decisions that affect the way you play the game.
    If we branch gaming sessions, now you can see which outcome you like the most.
    The "what would happen if...?" questions are something of the past.

Rewinding and forking are things you can still do, more or less, with the current emulators. This whole "controlling the memory" thing starts to become even more interesting when you add machine learning to the equation.

Some guy wrote a paper about integrating a machine learning algorithm with a NES emulator so super mario plays itself.
The program analyzes the memory of the emulated NES and learns what to do so the score goes up.
After a couple iterations the game is able to play itself for several levels without human intervention.
This is, at least in theory, possible for the GameBoy too!

In essence, having a Ruby version of the emulator is GREAT.

Ruby Version: Baruco Proposal

All of this is awesome.
We know the recipe, we have the ingredients, we just have to follow the instructions.
There's only one problem, though: I'm lazy as hell.

Luckily Baruco was announced and luckily I didn't have enough money to buy a ticket:
the only way of getting to the conference was by proposing a talk.

My talk got accepted and this is when the fun began.

I basically committed to give a talk about a project I had only spent a weekend working on and I didn't have a clear idea how big it would be. G-R-E-A-T!
This was a big incentive to work on the project, though.

I made a small comic to reflect how I felt: How to succeed at conferences

Ruby Version: Taking over Mimey

My friend @janogonzalez had been working for months on a project called Mimey.
Mimey is a GameBoy emulator written in Ruby, which is what we've been looking for.

The only problem is that Jano hasn't finished it.
He's actually only done 10%.

Jano was following a tutorial called GameBoy Emulation in Javascript, which seemed quite nice.

The tutorial goes through every component of a GameBoy and teaches you the basics,
so you can write the component yourself.
The end result is a working GameBoy emulator.

It should be somewhat straightforward to follow that tutorial and write a Ruby equivalent.

Armed with Dr. Pepper, I decided to take over the project.
It didn't take me long to find out that the tutorial was more along the lines of the
"How to draw an Owl" tutorial:
How to draw an Owl

It was still better than starting from scratch, so I forked Mimey and started coding.

Ruby Version: Figuring out What's a bit and a byte

There are two stories that happened during the development of the emulator that I'd like to share today.
The first one is about bits and bytes.

Very early in the development of the emulator, I saw that everything in the tutorial and in Jano's source code was referencing bits, bytes and words.

I haven't studied computer science, so I had no real reason to know what that means.
I tried to ignore it and continue the development without knowing what a bit and a byte is, but it turned out to be impossible: I was forced to learn.

I visit Travis every monday, so I asked Sven Fuchs about the difference between a bit and a byte.

Sven's reaction was: "ufff, I learned that 20 years ago".
He tried to think of a case where he had to use such knowledge, but it wasn't clear.

He's not really alone. If you're a web developer you rarely have to deal with such things, that's why I never learned it. I didn't have to.

Sven explained me the difference and I proceeded with the development.

<- Read Part 2 ... Read Part 4 ->