« Return to show page
Transcript for Episode #38:
Hacking Classic Nintendo Games with Python
Brian OKKEN: Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode #38, recorded August 7th, 2017. I’m Brian Okken and we have guest hosts filling in for Michael (Kennedy) while he’s on vacation. This week we have Matt Makai from FullStack Python.
Matt MAKAI: Hey, Brian.
OKKEN: Hey. Now, you also worked with Michael on the Python entrepreneur course, right?
MAKAI: Exactly, and I’ve been on Michael’s podcast a couple times. He’s always a great interviewer.
OKKEN: Yeah, I was having trouble not grinning and laughing during that, because I’m usually waiting for Michael to get done with the intro.
Thanks a lot for stepping up and helping us with the show this week.
MAKAI: Yeah, I’m happy to help while Michael’s taking a nice little vacation. He can come back all rested and ready to go.
OKKEN: First off, I’ve got you starting, because why not. This is from a talk at PyCon, is that right?
MAKAI: Yeah. So, I was at PyCon this year. I try never to miss it but unfortunately, I missed PyCon last year and I vowed never again because it’s my favorite event every single year. I caught this talk –– this is actually my colleague Sam Agnew’s talk –– which was called, “Hacking Classic Nintendo Games with Python” and the gist here was he was using a Nintendo emulator named FCEUX. I actually don’t know if it has a better pronunciation or if people say it by the letters all the time, but he used that in order to change old school Nintendo games he was playing to interact with the audience during that PyCon talk. It was pretty awesome.
OKKEN: I missed it, so tell us a little bit more about hacking Nintendo games.
MAKAI: Sure. Same was inspired by the PyNES project. He saw that you can use Python to interact with Nintendo games. Since he grew up playing the old school NES Nintendo system, he wanted to use some of the old games that he had and basically emulate the games themselves, but also the way that the old Game Genie system worked which was by hex editing the memory of the game itself.
So, what Sam did in this talk was he created a little Lua script, which would change the hex values in memory of a game. And then he created a Python application, then attendees at the talk could text in different hex codes, and he was playing the game while attendees were changing the game on him. It was kind of like adding cheat codes to the game while he was playing. It was really cool to see how he was able to interact with the audience, but also play some games that brought out a little bit of the nostalgia factor.
OKKEN: That’s cool. I’ll have to check that out.
MAKAI: One other thing I really liked about it was he made certain topics that sound pretty intimidating, like hex editing memory values, what I think is a relatively beginner-friendly way to introduce it. It basically takes the hex memory values, explains what they do and then you can see the results when you edit the values. Definitely a talk worth checking out and he also wrote a companion blog post that explains everything about what he did throughout the talk.
OKKEN: Okay. I admit this morning I watched just a small portion of it and I just got to the point where he changed the time, there was a game running and we were watching the time left.
MAKAI: Super Mario Brothers, the first one.
OKKEN: Yeah, Super Mario Brothers. And he changed the time back down to zero and suddenly his character died and he said, ‘Okay, that’s how you hack it. The talk’s over.’
MAKAI: (Laughs) Exactly, and he did that just through editing hex memory values to change the time, which is pretty nuts.
OKKEN: There was Lua involved also. I haven’t watched the whole thing. Is the editing of the game Lua and the Python for the Flask app?
MAKAI: Yeah, so the emulator itself, there’s multiple emulators you can use or run NES games but the one that he was most comfortable with actually had embedded Lua in order to script editing the hex memory value. So, really Lua was only being used to put the hex values into the memory and then read from a file that Python was writing to. There was a file in the system where this Python application was imputing into that file, and then Lua was reading it and just shoving it into memory to change the game. So, it was basically, a file was being used as a bridge between Python and Lua.
OKKEN: Great. Cool. I love that the PyCon talks are recorded. To be honest, when I was there I didn’t go to very many talks, I just spent the year between PyCons just watching all the old ones.
MAKAI: (Laughs) That’s awesome.
OKKEN: Speaking of conferences, I wanted to bring up an article that Eric Holscher put out recently. Apparently, he brings it up at the beginning of his talks a lot and he calls it the “Pac-Man Rule at Conferences”. It’s just a short little article, I like the visual of the little Pac-Man with the little gap.
The idea, and I’m going to quote exactly what he says:
“When standing as a group of people, always leave room for one person to join your group. Leaving room for new people when standing in a group is a physical way to show an inclusive and welcoming environment.”
I started out totally as an introvert because I got into programming not because I enjoy hanging out with people. So, it is a stretch for a lot of people, including myself, to try to go up to new groups of people and join conversations. I thought this was a great tip, when you’re having a conversation in a group, to make sure your physically and visually showing that you’re welcoming new members.
MAKAI: I agree. It’s almost like pattern matching for developers when there’s room for one more person, you feel much more comfortable approaching the group and asking people what they’re talking about. I think it’s really good advice both on the side where you are in a group already, but also when you’re not in a group. There’s some people that may want to talk to you and they left you a spot at the table or where they’re standing. Eric did a great job on this.
OKKEN: Yeah, I think it’s great.
That was just a short one and you’re going to talk about something that I really haven’t had a chance to play with yet, and that’s – except for I’ve had a chance to mispronounce it on this podcast – it’s Bo-kay (Bokeh)?
MAKAI: If you take a look at the website, it actually can be pronounced two different ways. Bo-kay and Bo-ca. Chances are you pronounced it correctly, you just thought we were incorrect in our pronunciation.
OKKEN: For visuals and creating visuals in Python, the one thing I have used is matplotlib. Is there a rule of thumb of when to use generating plots on the client side versus the server side?
MAKAI: I think that’s a good question. I haven’t used matplotlib as much as Bokeh, I’ve only used it a bit in Jupyter notebooks. My rough rule of thumb – but I could be wrong so I’d love to get emails if it’s different – my general rule of thumb is Bokeh is really fantastic for creating interactive visualizations in web applications. You can certainly use it in Jupyter notebooks as well, but I see matplotlib as being sort of the quick and dirty solution to visualizing data in Jupyter notebook scripts. Though I would typically use matplotlib if I was doing something super early, doing exploratory data analysis, whereas Bokeh is building a beautiful dashboard. You want bar charts, or you want some sort of interactive visualization that you can have end users be working with.
OKKEN: Okay, I think that’s a great explanation. I’ll have to check this out.
MAKAI: Yes, and that’s Bokeh. What’s funny is, it always goes back to PyCon. I found out about this library at PyCon in 2015. Sarah Bird, who works on the core library, gave a fantastic talk where she essentially built an entire data visualization map, geo-mapping data visualization during her talk and I thought, ‘This is incredible.’ So, I got a chance to use it a little bit. I wrote a Flask tutorial on FullStack Python that uses Bokeh. That’s why I’ve been sort of, I don’t want to say evangelizing, but telling people how enjoyable it is to use this library.
OKKEN: That’s great. Cool, I’ll have to check it out more.
Well, next I’ve got another tool that I actually haven’t used yet. But I just heard about it recently and it’s a tool called Mosh, which is a mobile shell. The idea around it, it’s kind of replacing SSH, though if you have to have a connection to another instrument to run command line commands and now we live in a time where we often work on laptops and then you close your laptop and go home or go somewhere else and open it up again, that connection’s gone and you’ve got to re-establish your SSH. There’s also other problems with SSH, with keystroke, when you’re displaying the interactive-ness. Mosh is an attempt to basically, go down all the way to the protocol layer and redefine what gets transferred back and forth. There’s a YouTube video that I linked to that’s actually back from 2012 and it’s very convincing as to why we would want to do mobile applications differently than we’ve done them on the past at just the byte level.
I’m kind of wondering if people are using it, that’s just why I brought it up. It looks cool. I’ll try it. I wonder if anybody else has used it.
MAKAI: I haven’t used Mosh myself, but it seems like SSH is a protocol that is designed to disconnect every single time I’m trying to write some code in front of an audience. (Laughs)
I will definitely have to check this one out, especially when I’m doing live code demos because when your SSH connection drops in front of an audience and you’ve got to reconnect, it can be a real pain. So, this is pretty awesome.
OKKEN: This video actually is a presentation, I don’t know who’s in the presentation, but there’s a person presenting and they’re connected to another system and right in the middle of typing a command he changes his wifi connection to a different connection. And it just works, it fixes itself. It’s cool.
This is great having you on, because you’re talking about a bunch of things I’ve never used but I’ve definitely heard about.
MAKAI: Well, hopefully I get you excited enough to use them because they’re some of my favorite tools.
OKKEN: Next up is Pelican. Do you use Pelican for FullStack?
MAKAI: I do, yes. So, FullStack Python, people luckily notice that it’s pretty snappy and that’s because it has no database backend. It’s all just a bunch of flat files that are served up by a content delivery network. That’s all generated. I don’t handwritten HTML, at least not for fun. I generate that with Pelican, which is a static website generator.
So, the way that I think about it is static website generators basically have, I would say, three parts. You have your content, which might be written in reStructuredText or Markdown, some sort of Markup format. The second part would be a template engine, so most likely Jinja, a lot of people use Django or are used to the Django template engine. Pelican is kind of built out of the box with Jinja. And then you have some Python code that puts the two together and then outputs, typically, HTML. It can also be other formats, like XML or JSON, really any sort of output that you want that is a file format, but I output HTML. Then you can take those HTML files and you can host them anywhere. So, the power is you have all your content in the Markup format, so it’s not like you’re modifying HTML directly. The static site generator does all the work for you with what are called generators. The Python code takes in the input and outputs those file formats. You can host them anywhere.
The way that I think about it is it’s kind of like a throwback to the early days of the web, when everything was really snappy because you weren't connecting to databases via web application. It was because you were being served up a single file or multiple files that are basically just flat files.
OKKEN: Yeah. And maybe some Pearl on the backend…
MAKAI: (Laughs) One of the things that’s great about Pelican is that it’s in under active development. The latest release is version 3.7.1; 3.7.0 was released at the end of 2016, and that was a major bump with a lot of Python 3 compatibility. In fact, I only use Python 3.6 with Pelican now. It works fantastic. It’s ready to go Python 3 out of the box. It’s had a bunch bug fixes recently, so under active development. That’s one of the things.
There are so many static site generators out there. It’s relatively easy to create one as a side project, but this one has been around for a long time. I started using Pelican probably six or seven years ago now and I still highly recommend it. If you’re a developer and you’ve been using a tool for that long, I think it’s a pretty good sign that that’s a stable foundation.
OKKEN: Yeah, definitely. I don’t know if you remember what it was like when you first started using it though. So, if I wanted to pick it up and maybe, let’s say I wanted to create, internal to a company, I wanted to create a little site to document some process or something. And I wanted to spin up a Pelican site with a bunch of documents in it. Is that something that’s going to take a long time to learn how to use or is it quick to pick up?
So, yeah, I would say it’s relatively easy to get started with it. I write a tutorial on this, “How to Create Your First Static Site with Pelican and Jinja2” and that would actually get you up and running, probably within 20 to 30 minutes. You pip install Pelican and then Pelican will actually generate the boilerplate that you need with the Pelican quickstart program, then you have your first static site. Actually, you could probably have your first static site within five minutes and then you can start customizing it and have something that you could deploy very quickly after that.
OKKEN: Well, that’s definitely fast enough. Does the tutorial talk about – I guess it doesn’t matter which Markdown you use, if you use Markdown or reStructuredText.
MAKAI: Yeah, actually, I use Markdown on FullStack Python but on my personal site, mattmakai.com, I use reStructuredText. I kind of use each one interchangeably. In fact, you can use them interchangeably in the same site. Pelican doesn’t really care. It will say, ‘Oh, you’ve got five Markdown files, five reStructuredText.’ I think AsciiDoc is another format. You can kind of take anything as input and it will use that. It doesn’t have to be segmented by projects.
OKKEN: Does it tell by the extent file extension or something?
MAKAI: Yeah, in the configuration setting you can tell Pelican which file formats you want, so which extensions. So, if you don’t want to pick up your reStructuredText files, you can just have it pick up the Markdown ones. But you can configure all that stuff in the configuration files. It’s pretty extensive.
OKKEN: Okay, the last topic I want to talk about is something that helped me just now. So, in the last episode, I announced I’m no longer writing the book. The book being Python Testing with pytest. It’s what I’ve been working on for a year. But I was wrong, because right after we recorded that and I handed in all my documents to my editor, the pytest team came out with another version. The pytest 3.2.0. I had just, the week before, retested all of my examples in 3.1.3, so, what do I do? What I’m doing is just making sure they all work. Right now, I’m going through all of the book again and instead of having to do this every time, I’ve decided I’m going to build a set of tests that check all of the examples and make sure that the output is similar enough to the output I describe in the book, so that it doesn’t confuse somebody when they have a new version.
One of the things I’m using is a tool called pytest-watch. It’s a pytest plugin. It’s great because I’ve just got two windows open in two terminal windows while I’m editing these tests. One of the terminals is running pytest 3.1.3 and one of them is running pytest 3.2 in two different virtual environments. And I’ve got pytest-watch just looking at the directory. Every time I hit save on the tests, both of them go off and run.
Eventually, when I get all done with this, I’ll probably convert it to tox or something where I can run them all the time. But for now, interactively, pytest-watch is pretty cool.
MAKAI: That’s amazing. How much code did you have to write in order to get that to be working with both versions?
OKKEN: There’s a part of pytest that I do cover briefly in the book that’s called the pytester, and it's a plugin that is used for testing plugins, but it’s also used for the test code for pytest itself. It allows you to run a pytest session and capture the output and ask things about it like, ‘Was the string in there?’and ‘How many passes, fails, skips’ things like that are in there. So, I’m writing the tests just as if I was writing a plugin or something.
It’s not quick, but the format of each is pretty similar and it takes me a minute per example to get a test in place. But there’s 170 examples, so 170 minutes.
MAKAI: Any way to speed that up or you’re happy with it right now?
OKKEN: There probably is. The part really is just me looking at it. I could probably automate the whole thing and get it done faster, but I also want to be reading the book while I’m putting these together. Sometimes there will be something minor, but don’t really want to say I want the exact same output because if they add a period here or there, that’s not that big of a deal. But I want the gist of it to be correct.
MAKAI: Wow, nicely done.
OKKEN: So, that's that. And we’re done. Thanks a lot. Usually at the end, we touch bases with each other to say what’s going on. I just learned today that Matt, you work at Twilio.
MAKAI: Yeah, I do. So, Twilio, for folks who don’t know, makes it easier for developers to add communications, like phone calling, messaging and video, to their applications. So, if you’re working on a feature and you’'pre in the middle of a sprint and your user story says, ‘Okay, send a text message to somebody’ and you’re like, ‘How do I do that? How do I interact with a global telecom network?’ Well, you can do that easily with Twilio’s API.
So, that’s my day job. In addition to working on FullStack Python, I work at Twilio, which is really great. I’ve been there for almost four years now.
OKKEN: That’s great. And you’re also working on a project called, “Twilio Voices”.
MAKAI: Yeah, “Twilio Voices” is a new project I’ve been working on. It’s probably of interest to listeners because we pay developers $500 for each published technical blog post that they have on the Twilio Blog. So, if anyone’s listening and you want to try pytest-watch and you want to learn a new Open Source project like that. If you write some code, and you want to write a blog post about it, you can do that through “Twilio Voices” and get paid $500.
The way that I see it is the $500 is a good way to get past the procrastination stage of writing a blog post. A lot of times these blog posts can be read by tens of thousands of people. For example, there was one called “Wedding at Scale” and it was a developer who was talking about how he automated all the text messaging and communication for his wedding through a Python script that he wrote, which is a really cool story. The whole idea behind “Twilio Voices” is that people have all these awesome hacks and applications that they built. Tell us a story about and show readers how to build what you built. It doesn’t have to use Twilio, it can be any code that you created, as long as it’s a cool story or good tutorial.
OKKEN: It doesn’t have to be pushing Twilio, it can be about anything?
MAKAI: No, because we’re a company by developers for developers and we’ve always been that way. So, whether you’re using Twilio or not, we want to see the code that people have written. One thing that’s really great about this is every post goes through a rigorous review process, like an outline review, voice review, tech review to make sure all the code works, so that people who write these blog posts make sure that their output is the best they’ve ever created.
It’s been really cool to see people say, ‘I never could have written a blog post that is this polished.’ We kind of put it through the ringer to make sure it’s the highest quality post.
OKKEN: That’s pretty cool.You usually have to pay money to interact with an editor. That’s nice.
MAKAI: You should write something on testing.
OKKEN: I should write a blog post, yeah.
MAKAI: We would love to have it. What have you been up to, Brian?
OKKEN: Well, I’m not actually writing the book any more but I’m still working on book-related activities for this month because it has to go through copy editing and figuring out marketing plans and all that good stuff. I’ve got a couple podcasts for Testing Code. One came out last week and I’ll probably do weekly ones and get them out. But that’s still slow while I’m spending most of my free time on the book.
Other than that and my full-time job, that’s what I’m up to.
MAKAI: Hopefully, you get some time to sleep then.
OKKEN: Yeah. I’ve been fascinated hearing about Matt and I’m going to put him on the spot on the air and tell him he’s got to get on Testing Code and talk about FullStack sometime.
MAKAI: Sure, happy to do it.
OKKEN: Thank you for listening to Python Bytes. Follow the show on Twitter via @pythonbytes and get the full show notes and links to things we talked about on the show at PythonBytes.fm. If you have a news story you’d like featured, just visit PythonBytes.fm and send it our way. We’re always on the lookout for sharing something cool. This is Brian Okken. On behalf of myself, Michael Kennedy and Matt Makai, thank you for listening and sharing this podcast with your friends and colleagues.