The Right Glue
Some kind of dev blog

How to make an inaccessible game

By Dean

These comments from Anonymous perhaps need a bit of an explanation. Recently, Nick and Chad have convinced me to play League of Legends. I don't particularly like games where you have to babysit units (Warcraft 3 is shit, FYI) but I figured I liked Demigod and Monday-Night Combat (hyphen inserted for grammatical correctness) which are all broadly the same style of game. Given that League of Legends is free, it seemed like it was worth a try.

As I'm sure that in the future some Googlers will show up here, read this post and wonder why I hate the game they love so much, let me start by saying that I do not like games with significant amounts of micromanagement. I don't like there to be a lot of detail in my games; I don't like having to remember a hundred characters and each of their four abilities. I don't like having to remember the names of a hundred different items and what stats they affect and how much they cost. More to the point, I knew that I wouldn't like League of Legends going into it. So I made the call to not play the tutorial or read about the gameplay in favour of just playing it with Nick and Chad, who are good friends of mine, so that I wouldn't have to struggle through things I don't like before playing with my friends. Let's move on with the understanding that no, I didn't do the tutorial, and I'm approaching the game from the point of view of someone who cannot enjoy the gameplay without a few friends also suffering through it with me.

Defense of the Ancients is a genre of video game; League of Legends is a DOTA game. It combines some of the aspects of real-time strategy games, action games and role-playing games. Essentially, teams of five players fight each other in order to advance the front of a war between an unending supply of weak non-player characters on both sides. The players are mighty compared to the warring NPCs; their presence generally means the difference between which side wins and loses a particular battle. While this is going on, each character is gaining experience from the war, as well as money from the kills they rack up. There are also specific areas of the war zone where players can gain advantages that are outside of the normal battlegrounds. To put it shortly, there is a lot going on in this style of game at any given time, and the game's pace is very fast.

Latest comments:

Documentation can be fun

By Dean

Call me weird, but I like documentation. Like everything I do, I try to make the most of it and insert amusement into it as much as I can. You might remember the lessons I have learned when writing e-mail and if you do, good work. If you don't, you can go read that. This post isn't about e-mail, it's about the longer-lasting documentation that should live longer than your attention span and even your own fleshy memory.

It goes without saying that you write documentation so that someone (either you or someone else) will be able to read and above all comprehend what it is that you want them to understand. So you document some code because your silly hack will be completely jibberish to anyone — including yourself — within two months. You need the documentation so you can say to yourself (without lying) that this thing you've been doing is finally, truly done. You can forget about it entirely safely because if you need to do anything else with it later, you have some footnotes to explain it to you.

That's what I like the most about documentation. I can safely push things out of my mind when I know I can retrieve that knowledge later from the documentation I've written. Of course, I'd like to keep the knowledge in my head, but the way my brain tends to work only the high-level stuff stays in there and the implementation details fall out of my ears and get all over the carpet. So it's a given that I'll need my documentation.

Latest comments:

Automater's manifesto

By Dean

As programmers, it is out goal to automate whatever we can automate. It is our goal to look at work being done that doesn't require any abstract, creative thought and relieve all human minds of that burden. We will not rest until humanity no longer needs to do boring work involving memorizing arbitrary things and repetitive tasks. We strive for a world where everyone is liberated by automation.

It goes without saying that computers and human minds are vastly different things. Computers excel at doing everything they're told, without questioning it, without sleep and without fault. Computers are capable of storing data and retrieving it perfectly. They are capable of computing results from the simplest arithmetic calculation to the most convoluted hipster website and they do so flawlessly and quickly. The mind of a computer is one made up of facts, concrete definitions and rules.

The human brain excels at coming up with its own ideas, questioning everything they perceive with the curiosity that drove us to make computers in the first place. We have biological needs and we make mistakes, and our time is precious and limited. When we store data, we might not store it correctly and when we try to retrieve it it doesn't always come back. While we're capable of computing results, we're slow at it. We're more comfortable creating the convoluted hipster website in the first place than being asked to draw it every time someone new wants to see it. The human mind is made up of curiosity, abstract definitions and fuzzy rules.

Latest comments:

Algorithmic guesswork

By Dean

After a month's break I am ready to re-enter the award-winning blog-writing world with another installment of "cool stuff I have added to KevBot lately". WARNING: This post is about algorithms and math. I love algorithms and math. If you do not like algorithms or math then I will try to make this post make sense regardless but know that I am disappointed in you for not liking algorithms and math.

As you'll recall, a Markov process is one where the next state's probabilities are dependent on only the previous state that the system was in. So taking the example I've used before, a Markov process is like looking at a book by looking at every two adjacent words and coming up with the next word based solely on the current one. Depending on the book used, the results will be different: a Markov-based Harry Potter generator will write about Harry Potter, while an Old Man's War generator will be totally badass.

This is the basis to impersonation: each IRC user is treated as its own source material. So KevBot can be asked to generate a Dean-like sentence or a qed-like sentence and the results will be as different as qed is from me (which is to say his will talk a lot more about Linux and Perl while mine will bitch about accessibility). Treating each user as a different source turns out to be the key to adding statistical guesswork to KevBot's already phenomenal repertoire of functionality.

Latest comments:

Functional archeology

By Dean

An inexorable fact of software development is scope creep (which is why it's the core mechanic of Vapourware). Software systems start as one idea and over time develop layers of other functionality that push the limits of the original software specification. There are many causes of this phenomenon including developers adding things they think are cool, managers wanting their pet features added and needing to immitate competitors' products. The causes aren't important, what's important is that scope creep exists (or will exist) in all software.

As systems take on new functionality there will come a point that a new feature is so alien to the original design of the software that it actually can't be added. Using the Lego metaphor, this building a giant castle on a small turntable block. Eventually the castle will be too big to be stable and you can't add new supports because doing so will force you to lose the ability to rotate. Originally the turntable just contained a cannon turret, and the castle was just built up naturally around it. It was never meant to handle anything so big.

I feel it's important to make a distinction between scope creep — software gaining new functionality over time — and insane bugs wherein systems are merely poorly designed (i.e., the Minecraft effect). In a well designed system, new features can be added incrementally usually without affecting other features and causing nonsense bugs. Software engineers know that scope creep is inevitable and strive to write software that is capable of being changed later. In our Lego example, even though the turntable castle is unstable, it has no bearing on the giant Lego robot you've built nearby.

Latest comments:

Programming games

By Dean

Programming is fun. Now that your mind is blown let's talk about games that feature programming as a core mechanic.

As you're well aware, I love board games. One board game that I enjoy is called Robo Rally. In Robo Rally each player takes control of a robot, each of which need to reach the same set of locations on the board in the same order. Players have cards that serve as commands for their robots, and the robots can interfere with one another.

The catch is that the players have to place their commands face down before the movement phase of the game begins. They have to program their robots in advance, without knowing what the other players are programming their robots to do. Once every player is finished, their programs run simultaneously, usually with disastrous results (did I mention the robots all have lasers?). Because the robots cannot change their programming and because the game board is so hazardous to all life (artificial or otherwise), small changes in conditions can carry dire consequences for the poor robots.

Latest comment:

Co-operative competition

By Dean

I had a most wonderful experience playing Portal 2 last week. Valve has always been at the forefront of user experience in games and the lessons they've learned are highly apparent in this title. I've been yelling at everyone who hasn't played it yet to play it immediately and I'd be inconsistent if I didn't do it here, too, so PLAY PORTAL 2 RIGHT NOW HOLY CRAP

With that out of the way I'd like to talk specifically about Portal 2's co-operative mode, because it is neat. Unlike other co-operative games such as Left 4 Dead or Civilization (which is co-operative when you want it to be), Portal 2 is fundamentally a puzzle game. It's not about who can jump the highest or push around the most blocks, it's about solving the puzzle at hand and moving on.

So how does a highly competitive person (like me) derive enjoyment from it? I'm glad you asked. Luckily, you and your co-op partner can still be horribly injured in this game, leading to the best sort of competition of all: griefing.

Latest comment:


By Doug

.well it guard so ,information your of master the are You .over world the realities virtual the of depths the into peer to ,superhighway information the circumnavigate to free are you obfuscation of veil the behind safely information your With .plaything your Internet the make to able be will you disposal your at weapons these With

.completely thwarted are efforts hackers the wingdings the eschewing By .wingdings the for only look eyes keen Their .it understand to lazy too be will hackers but address e-mail obfuscated an as that recognize will friends Your .gov dot hotmail at doug become would e-mail my example for So .respectively ,"." and "@" wingdings the of place in "dot" and "at" words the out write to is this do to way best The .hacker a to not but human a to address e-mail an as recognizable it's that so out it write to need you (codes some you send to him want you that forum a on friend a telling when perhaps) forum a on it post to need do you If

.safe keep to need you that information of piece important most single the is It .over is officer information chief a as life your ,compromised is address e-mail your If .tubes the of out them slurping KevBots mechanical without Internets these on address e-mail your put to able be to need You .address e-mail your is safe keep to need you thing important Another

Latest comments:
This is some kind of footnote. This webpage is awesome and can be viewed in any browser. Even ones that suck ass like Safari and Firefox. Isn't that awesome? This site is best viewed with browsers that aren't maximized on large-resolution displays (> 1024 pixels in width). But then again, if you are running a large resolution and browsing maximized, then you're a terrible person so you don't really deserve to see this site at its finest. Jerk. I mean, seriously. I spend all this time making a nice site and your silly browsing habits ruin its look. That's really cold, man. If you're using IE6, then in order to see the cool avatar effects you need to enable JavaScript. This site conforms 100% with the laws (both known and unknown) governing physical reality. No rights reserved by Dean Whelton (who is awesome) of any of the content, images, design, backend or electrons used in this site. Steal at your convenience. None of it is worth stealing anyway, so there. I have even made an RSS feed for more efficient theft of my intellectual property. Now, don't say I'm not generous. I guess if you want to know more about me, you can visit the about page. I actually made a real about page! It's more like a FAQ, though. You can contact me, too, if you feel like it. Are you really wasting time reading this? Go outside or something.