The Raspberry Pipboy
As anyone who follows my Twitter or Google+ will have seen, this year, for Hallowe’en, I attempted to make a fully functioning Pipboy-3000 to accompany my half-assed Vault Suit from the year previous. The idea was simple enough, take a Raspberry Pi, write some visually interesting Python, stick it, a battery and a screen on my arm and hey presto. The execution was obviously not as straight forward, but I was committed.
The first steps into the project came from playing around with the Open Street Map data. I fetched the XML with a simple Python script and used Pygame to render some lines for each of the paths and nodes. It was trivial enough but looked pretty good.
The software stayed mostly as just a map for most of the project. A random internet stranger jumped on the project and sent me a pull request which improved my scanlines and added some visual authenticity to it. This combined with the code now pulling the actual amenities and buildings from around Belfast, made the map look pretty cool. Next I started getting together the components for the hardware itself. The screen was an appallingly cheap car reversing monitor, with a resolution of 480×272, but it was thin and accepted RCA input so I was happy.
For the actual interaction with the software I looked at the in-game Pipboy’s operation. It had three main components, the illuminated primary section buttons on the front panel, the sub-section control dial on the left, and the up and down scroller just beside the screen. There is also suspected to be a 4th control on the back of the glove, but I decided to ignore that for this build.
I started writing the GPIO routines for controlling the primary sections, and prototyping the LED and momentary switch setup required for this. I had never done any GPIO or even really any electronics (since school), so it was slap-dash and very trial and error.
I bought a Pi Cobbler from Adafruit to assist with the prototyping and it was a godsend. Allowing me to have all the GPIO pins, labelled, going straight into the breadboard.
I was cheap and stubborn and didn’t want to buy self-contained illuminated/LED buttons, so found a cheap hacky way to mount LEDs loosely over the momentary switches and got a pretty functional, if incredibly fragile LED button. Needless to say these turned out to be a stupid idea and in the final build I moved the actual buttons to the top of the frame.
For the mould itself I was stumped. I had absolutely no idea how I was going to contain all this. At this point I had only a few weeks to Hallowe’en and I was even asking the Farset Labs directors if they could get me access to a vacuum former. Thankfully a co-worker suggested Polymorph. I never knew this stuff existed and it turned out to be the most fun I’ve ever had with a tub of white pellets in my life.
If you’re unaware of the substance, it’s a polymer that becomes very pliable and fuses with itself when immersed in water heated above 62°C. Then when it cools it becomes as rigid and tough as nylon. I immediately started playing with it and prototyped the main two components of the physical build, the bracer and faceplate (seen here with the screen in-situ).
It took a few more tries to get used to the stuff and although I think it is amazing, it’s definitely not the ideal tool for this kind of modelling, but for prototyping I can’t recommend it enough as it is cheap (enough) and reusable.
Now I had pretty much all the components ready (although the software was still iffy), so it was time to start the final build. For reference, it was now 2 days before the Hallowe’en party I was building this for.
The picture below shows the first compilation of all the components into the final casing. This was before the LED buttons gave up the ghost and had to be redone.
At this point I realised I had almost completely forgotten about powering the damn thing. The Raspberry Pi was asking for 5V 700A (min) and the screen was expecting to be in a car, so it was asking for 12V 1A (but would accept pretty much anything between 10 and 15). Thankfully I got my hands on a couple of high-voltage (3.7-4.2V) AA-form li-ions. With 3 of them I was to expect a range of ~10V to 13V. The screen was happy with this, but I ran it through a 5V regulator for the Pi, which worked, but was not great for battery life. I chopped up a few cables, attached them to my makeshift power board and we were mobile.
This is an internal shot is from around that time, with the repositioning of the buttons to the top. (WARNING TERRIBLE WIRING PRESENT).
All that was left was some final painting and finishing and we were there. I took this opportunity to tune the software, adding more sections, world map, local map, radio(!) and even the foundations of a twitter client. It was at this point, whilst testing the newest software additions, that my shoddy wiremanship (it’s a real word, ok?) led to the demise of the entire project. A loose wire shorted the power board and managed to set the screen on fire… 2 hours before the party.
Thankfully everything else survived, the Pi and components, I even branched and modded to software to operate its sound effects and radio stations blind, but it wasn’t good enough. I was heart broken and went to the party with it non-functioning. I intend to replace the screen in the new year and see it through to completion, but right now I’m still too sickened by the tragedy.
For now, here’s how I’ll remember the little trooper.
The code (without the last minute hacks for blind operations) is available here. https://bitbucket.org/grieve/pypboy/
‘Firefight’ Devblog #1: Ignition
BEGIN: Futile attempt at prolonging project motivation
Today is a fine day for beginnings, what with there being a car sized hyper-advanced laboratory just after landing safely on Mars, and so I begin work in earnest on a project I hope to see to a similar, but somewhat less dramatic, level of success.
Firefight (working title) is a combination of a few ideas I’ve had for a while. At its most basic it’s a tower defense, and whilst I do believe the entire world has enough TD’s to outlast most of our lives, I also believe that any genre, regardless of how tired or worn out it may seem, can still surprise and entertain us.
The main aspect of Firefight, after it’s TD nature, is preventing the spread of fire in a wilderness situation. Fire will threaten your lands and defenses, and will be ignited and spread by creeps as they advance in that inevitable way that creeps do. I hope to strike an interesting and tense gameplay balance between the standard build-towers-kill-creeps feedback loop and the building of non-offensive structures that can protect your townlands by stopping or slowing the spread of fire.
To achieve this, I feel it will probably require a small resource management aspect, something akin to getting better financial returns on creep kills when you have protected more townland from fiery demise. Some angles of this project clearly need investigation and fleshing out and I’ll try and update here as I bungle along towards that goal.
For now, I’ve knocked up a small fire-spread prototype. It’s written in Haxe using Haxepunk, as will the rest of the project. It’s a relatively simple affair, tile based, with ignited tiles exerting energy on adjacent tiles to slowly set them on fire too. Each tile has various properties that affect spread, including flammability, heat capacitance, ignition point and fuel amount. The equations working these into the spread are currently very unoptimized, the phrase “higgledy-piggledly” springs to mind.
Click the screenshot below to have a play around.
Glasgowbury 2012
I present to you the 2012 edition of my unofficial Glasgowbury android app. It’s a bit slicker than last year, with some new bells and whistles.
> Super detailed red line time indicator
Accurate right down to the minute!
> Drunken Rambler Mode™
Shake the phone and it’ll suggest a band that’s playing now!*
“When I Was Human” – Ludum Dare #21 Postmortem
Check (and rate) the game here:
http://www.ludumdare.com/compo/ludum-dare-21/?action=preview&uid=1947
Making a game in 48 hours is never easy, but thankfully it was less hard this time. Mainly because I decided to use tools I was more familiar with, instead of using the weekend to learn a new tool or framework.
I started the weekend with the idea of making a super-hero canabalt. Something that lends a bit of variety to the one-button run genre. A constant threat from the rear, a path that makes it difficult to stay out in front and some kind of upgrade system.
I structured my development a lot more than usual, with index cards and a vague agile methodology (and the entire living floor). I tried to sleep well during the weekend, getting 6 hours on Friday night, and 9(!) on Saturday. I also ate well, cooking rather than the usual takeaways, and only drinking one energy drink the whole weekend. (I did manage to polish off 5 pots of coffee though, which was around 25+ cups.)
What Went Right™
Organisation – I didn’t feel stressed much at all during the weekend. I managed time for music and even some graphics polishing at the end (not much mind, I’m not an artist and it’s hard to make faeces shine). All in all, I always felt like I knew what I was doing, what I had done, and what I would have to do.
Tools – I normally take a sackcloth-and-ashes approach to development: “If it can’t be done on the command line, then… you’re lying, because everything can be done on the command line. Fiend!” – But this weekend, I used FlashDevelop and worked on windows most of the time. FlashDevelop really is unparalleled when it comes to Actionscript coding.
K.I.S.S. (Keep It Simple, Stupid) – I nailed down the initial mechanics early. Platformer with tilemaps, jumping, double jumping. I did it all with multi-coloured squares too, sprites were an afterthought. I didn’t try to invent a new genre, and I didn’t try to rewrite the entirety of FlashPunk’s BitmapData handling (see: LD #19). I took a simple idea, and made it.
Asset Pipeline – I learned the workings of D.A.M.E. very early on in the weekend. Got familiar with its output format, its awkward, awkward tools, and it’s habit of refusing to write to CSV on occasion because it believes MXMLC is still holding on to the files (although this is more likely Adobe’s fault). I got much better at using Graphics Gale for initial pixel pushing and animating, and then using Photoshop to touch up and bake in some vague lighting.
Emitters! – Who doesn’t love little objects that fire random things in random directions? More Emitters, I say. More. I wish I could have Emitters every day of the week. My next game might be made entirely out of Emitters.
Guinness – Thanks to my first point, Organisation, I afforded myself an hour on Sunday for a few relaxing pints of Black. Boom.
Sunshine on the mountainside
Anyone heading up to Glasgowbury this fine weekend? Looks set to be a great one.
Any Android folks heading up the mountain can grab the little app I put together with acts, stages and times. Haven’t had time to get it cleared for the Market so you’ll have to download it yourself here.
http://ryangrieve.com/glasgowbury
If you’ve never installed an app manually before, you will have to check the “Unknown Sources” box in “Settings >> Applications”.
Enjoy!