This book sits firmly at the intersection of gaming nerdiness and typographical geekery. It’s a deep-dive into the heavily constrained but creative world of the typefaces of 70s, 80s, and 90s arcade games.
Toshi Omagari’s book is a combination of glossy coffee table experience and reference manual, with both full-colour screenshots and the fonts themselves, laid out in their raw 8×8 gridded glory.
There are plenty of screenshots of the fonts being used in-situ in classic games, as well as more esoteric ones like Yu Suzuki’s lesser known work Dynamite Dux. There are also some interesting historic tidbits about the development of the fonts – including the lineage; how fonts were “borrowed” and adapted by various arcade machine manufacturers rather than being created from scratch.
The book is organised around font styles rather than decades or genres, so all the serif typefaces are in their own section, for example. Other groups include decorative, slanted and horizontally accented fonts. However if you do want to find a particular game, you can use the index to locate it. There are around 250 by my reckoning, picked from the around 4,500 that Omagari included in his research.
It’s great to see a book like this delve so deeply into one specific aspect of video game design. It uses a set of constraints to restrict the subject matter (8×8, monospaced, pixel-based, arcade games only), but then revels in exploring all the ways in which artists and developers found to squeeze value from those 64 precious pixels. It’s geeky and fascinating.
Arcade Game Typography: The Art of Pixel Type, by Toshi Omagari, published by Thames and Hudson (associate link, or do what I did and buy from here and support your local bookshop).
Star Wars has been very much in my thoughts lately. Like pretty much everyone in the world, probably, given the huge marketing push behind The Force Awakens. So I couldn’t help but stop and stare when, in the window of a sleepy toy shop in a quiet corner of the UK where my Dad lives, I saw a large, impressive-looking Lego Millennium Falcon. I peered closer, then recoiled in horror at the price tag: £189.99! Whoa.
So like any sensible person, I turned to the internet to see if this beauty was available anywhere else at a more reasonable price. And that’s when I fell into the rabbit hole of Lego Millennium Falcons: rare ultimate collector editions, custom-builds, retired models, 10179s, BrickLinks and MOCs. Oh my. Continue reading Lego Millennium Falcon – Buy or Build?→
When we’re thinking about the impact of good and bad UX on the experience of using software there are a large group of people who are often overlooked. They’re not the discretionary consumers, who may be put off completing a purchase by requiring an extra click or form field, but a those who are forced to use in-house developed software required to complete their day-to-day work.
These apps are often clunky, with awkward UX, interaction foibles and bugs. They’ve quite possibly been “”designed”” by programmers, rather than UX specialists. But people have no choice but to use them day-in and day-out. So how is this likely to affect their attitude to the application?
An interaction can be so bad, so awkward to execute, that it feels almost painful. Maybe not when performed in isolation, but when repeated over and over it can become mentally (and even physically) wearing.
The application has them captive, and sets about bending them to its will.
But then a strange thing happens. The users start to think it’s OK.
Maybe it doesn’t feel quite as bad as it used to. It’s not really so awkward that it works that way. In fact, it feels right to do it this way.
Actually, why would it be done any other way!?
Wait a second, what just happened?
Despite the terrible treatment meted out, and partly due to the captor showing some small kindness – giving the ability to do their job, however awkwardly – the hostages have fallen in love with the application, their cruel, heartless captor. Continue reading Bad UX and Stockholm Syndrome→
I am sick of non-deterministic memory management. So sick. This was the big promise of .NET wasn’t it, way back in the 00s? No more having to worry about reference counting, double-frees or leaks. Well all we’ve done is switched it for worrying about event handlers, garbage collector pauses and weak dictionaries.
If you don’t have to worry about memory in .NET applications, then why are there so many commercial tools for solving memory-related problems? I’m starting to yearn for the days of being able to put an instance on the stack for the length of a curly-bracketed scope, and knowing that after that, it’s gone. Continue reading Heisenmemory→
I have recently entered a new, strange and exciting phase of my gaming life: Dad Gaming.
To put this in context, I’ve been playing games for a long time. I Mutant Camel’d through primary school, Sonic’d through the student days, PaRappa’d through my early career and Mario’d into marriage.
But at all of those points I was playing with peers. Consenting adults, fully aware of gaming tropes and vernacular, able to hold down several buttons and a trigger simultaneously while loosing off a round of sniper fire.
Nowadays, my gaming partners are 2 girls under 10 and my outlook and attitude to gaming has completely changed. Vast swathes of the electronic landscape are off limits, and to be honest, I’m enjoying the change of scenery.
Oh man, I just wasted too many hours of my life trying to figure out why calls to glBlitFramebuffer in my iOS app were returning GL_INVALID_OPERATION. I was targeting iOS 7, so I should’ve been able to use OpenGL ES 3.0 calls, and after all, I’d built against the v3 headers and everything else was compiling and working… right?
Wrong. Well, I really should’ve RTFM. It turns out that ES 3.0 use is not determined just by the OS version, but by the hardware. So even if you’re running iOS 7, you can only use ES 3.0 if you’re on the latest gen: iPhone 5S, iPad Air etc. Check out the full compatibility matrix here.
Here are a few extra tips to help you avoid wasting your time like I did if you’re explicitly targeting OpenGL ES 3.0:
As well as running on the right hardware, you can also use the simulator, which supports emulation of v3.0.
Call glGetString(GL_VERSION) to get a report of which version you’re actually running.
Pass the appropriate parameter to EAGLContext initWithAPI, if you’re using it.
It’s pretty frustrating that you get no indication that the function’s not supported, as opposed to just having being passed bad state. But I guess that’s par-for-the-course with a bare-bones, down-to-the-metal API like Open GL.
On my recent iOS puzzler Wordz, I decided not to reinvent the wheel, and instead use an off-the-shelf 2d game framework. I settled on Cocos2d. It makes it very easy to put together sprite-based games or apps by providing all the basic pieces like a scene graph, animations and integration with a couple of physics engines. It’s built on OpenGL but, happily, hides all that away from you – unless you need it.
No sooner had I released it, than Apple came out and announced a new framework for 2d games: SpriteKit. And it’s remarkably similar to Cocos2d. Here I’ll take a look at a few places where they differ, so you know what to look out for if you’re considering migrating to SpriteKit. Continue reading SpriteKit for Cocos2D developers→
The push button. It’s truly the blunt instrument of UI design. While most other controls provide some indication of the type of operation they’re performing – sliders are adjusting a value, a switch is moving between two states – buttons just mean “do something”. What? The only way to tell is to press it and see. But this shouldn’t be the case. Continue reading A short (and round) history of the button→