Category Archives: Personal

Halloween Point and Click Postmortem

Halloween was a mid quarter project for college I designed and put together over the course of about two weeks.  It represents some of my first attempts to design lighter game experiences, and to tailor those designs to young audiences.  It also represents the first real flash development I’ve done since eleventh to early twelfth grade, so that’s all very exciting.

As usual, all of the code and documentation you’ll get here has been unaltered in any way from the original submitted version; so all of the successes and failures are on display if you’re into that kind of thing.

I like to try and connect my school assignments to the real world whenever possible.  The specifications for my project required a point and click style “greeting card”, make of that term what you wish.  I more directly took inspiration from my niece’s iPad and some of the gorgeous point-and-click apps that she loves.

One of the things that bothers me with our approach to toddler development in the game industry is that we rarely focus on multi-step exploration or problem solving.  We have a lot of really amazing, well designed experiences that allow young kids to play with the world and have it respond to them, but they usually focus on breadth of choice rather than depth of choice.

I decided to go for the opposite approach; rather than have a lot of things that you could click on, I would focus on affecting the state of the world.

You can see a screenshot of some of the (limited) results below:

Light on
 Light off

With only around two weeks to formulate the design and code, there weren’t a huge number of behaviors I could implement.  In the download, you can see my submitted design doc which runs over the entire list of features.  In the interest of some brevity, I won’t run over most of them, but I will touch on one decision in particular before I go into the code analysis and lessons I learned.

Halloween is designed to be used with a touch interface; project requirements necessitated that I provide rollover effects for the pumpkin, and they’re also the reason for the somewhat awkward credits and intro screen.  All of these (and a few other things) will be removed or redesigned before my niece gets her hands on the finished version.

One of the things I noticed about my niece’s interaction with iPads in the past was that she liked to click around the screen almost at random.  I wanted to give her an avenue to do that in a predictable way, no matter what state the screen was in.

The leaves filled this function: they fall continuously, and the user can click on them at any point to crumple them up, drag them around the screen, and then release them to watch them fall through to the bottom of the screen.  No matter what is happening on the screen, this is always possible.  It’s an extremely shallow mechanic that actually adds a lot of feel to the scene, hunting and pecking feels almost like a game in and of itself.

This fit into my philosophy of exploration over puzzle solving.  I didn’t want this to be a frustrating experience, so I designed the elements (all of them that I had time to get to) such that they would always react to touch in some way, regardless of what’s going on around the screen.  There’s more I could say about this, but if you’re interested I go into more detail in the final design doc that’s up for download below.

I wrote a lot of hacky in-the-moment code this quarter, just like I’ve done a lot of hacky in-the-moment design, a result of me overloading on classes and having to budget my time more effectively than normal.  This project is a good example.

There are two lines of thought that run through my head when I get into situations like this: One is that coding is a means to an end, and if the final game is bug-free (it is) and plays well, bad code is, while not ideal, also not a tragedy.  Secondly, as a person who gets very worked up about making intuitive class structures, I don’t really believe any of that, at least not on an emotional level.  Bad code is often necessary; it’s sometimes quicker.  But I’m not sure it’s ever a good thing.  It’s a matter of priority, sometimes it’s just a loss you have to take.  Case in point, going back and redesigning this project from the ground up would be a nightmare.  There are a lot of things that came out really well, the code structure… eh. Not so much.

Cutting my losses isn’t something I’m usually happy to do.  I like to know that I’ve done my best on a project in all areas.  Learning that this isn’t always possible is a valuable lesson, but it’s a bitter pill to swallow, especially when it comes in an area like the design of a program, which I feel I do fairly well. If anything, I wanted to sacrifice the details of how the actual code worked.  My class hierarchy wasn’t supposed to be a problem.

 In many ways, this entire quarter has been a lesson to me in scoping and polish.  I tend to think of scope as a matter of ambition and project size, but what I’ve been learning is that for many of my projects, even if they’re small, is that I’ll always wish I could have invested more time and thought into decisions.  For many of these projects (like this) I now have the opportunity to go back after class and fix the designs before I release final versions.  That isn’t always usually case though, especially as I move on to other projects.  It’s frustrating, but it’s something I need to learn to deal with.

On a more encouraging note, I got a chance mid-way through the quarter to demo this project at a local museum.  I got a lot of kids to come around my laptop and mess with my touchpad trying to crumple up leaves, and that was really really special for me.

It was extremely interesting for me to see the way they approached the whole experience.  There wasn’t a large amount of time for them to explore, so I walked each child through the different interactions.  What engaged them in most cases was something that I’ve taken to somewhat ignorantly calling Emergent Narrative.  Namely, they liked that I gave them motivations and personalities to project into the situation.  There’s a man that refills the candy dish when you knock on the door.  I told users that he was afraid of the dark, and that turning off the light would cause the man to slam the door in fear and not come out, and the kids were really amused by this.  I was kind of surprised how easily they saw an arm as a person, and how willing they were to attach narrative and personality to that individual.  This is worth exploring more.

Downloads and copyright information below -

You may feel free to reuse this code for any purpose, commercial and proprietary included.  The nice thing to do would be to credit me, but I’m not going to get mad at you if you don’t.

You are not free to reuse or adapt mechanics, artwork or design documentation without written permission from me.  In the event that I’ve forgotten a contributor to this project, all rights of that contributor remain.  Font used is Ubuntu; all rights remain with Carnonical under their original license.

Bedbugs Part 1 : Coding Standards (or) The Rule is a Lie

If you think of coding as an art form for too long, you’ll start to get moral about it.  That’s kind of a mistake, because it’s easy to become moral about the wrong things.

I’m going to spend the next couple of posts talking about an AI simulation I created near the middle of my 12th grade year in high school for the TI-83+ calculator, entitled Bedbugs because the behaviors were designed to simulate the way bugs will line the underside of an infested bed.  When you lift up the mattress supposedly, you’ll see a huge number of dead bugs and some live ones just kind of wandering around in the corpses.  Morbid, but interesting, so I tried to get the same pattern going on in my code.  You’d set the simulation to run, come back in an hour, and then try and trace the route that the population had taken in that time, and pick out the occasional slow moving bug amidst the many dead bodies.  Shut up, I’m fine.

Anyway, I spent a good deal of time working on this project and most of that time was spent optimizing the code.  In this post, I want to talk about coding standards, and when it’s proper or improper to break those standards.

There are three points I took away from Bedbugs on code in general –

Number 1: Code is a means to an end.  If you do take the view that well written code is beautiful, as I do, then the only logical conclusion to draw from this is –

Number 2. When coding, beauty can not trump function because function is beauty.  This implies –

Number 3. Coding rules are heuristics, not commandments.

I’ll try and explain this in a better way.  Back when I was a good musician and did silly things like practice and learn theory, I used to take issue with theory ‘rules’ and when they could be broken.  My idea was that if these rules were relative, they weren’t worth learning.  Why restrict yourself to a rule that can be broken at any time?

What I didn’t understand is that theory rules are actually heuristics: rules of thumb.  They’re tools that describe what behavior or situation is most likely to occur at any given moment.  So for someone like me who holds an extremely objective philosophy on life, theory would never make sense because I interpret rules as a concrete standard that should always be followed.

The point of this is that coding standards aren’t really that different.  Rules, in the traditional sense, are the incorrect word to use.  Like theory, we have several different levels going on when we talk about coding standards.

On the top level, coding standards help us communicate with each other (note, I’m not talking about commenting here, but actual coding practices).  If you have a lot of different people working on the same project, you need to be able to make assumptions about how code is going to be structured.

That’s mainly a give and take between the different members, and while there are common formats that everyone uses, it’s mostly just an interaction between individuals.  You need to learn how to throw exceptions because your other coders will try to field them if they’re messing up (most of the time).  That’s all well and good and easy to understand.  Rules end up being social conventions, and it’s relatively easy, if hard in practice, to see when they should be followed and when they shouldn’t be followed.

The second layer is when you start to get ‘moral’ about your code.  Coding is a standard in itself.  Hard-coded values are bad.  You shouldn’t use them.  Not because it’s confusing for other people, but because it’s a bad idea in and of itself.  This is where it’s really easy to get off track.

None of this is to say that coding standards are abstract or that there aren’t good reasons to use them.  There are.  Hard-coded values are usually a bad idea.  But…. the decision not to use them isn’t a ‘rule’, at least not in the traditional sense.  It’s a heuristic, or to translate more literally -

This is a method you can use to make your life easier when you code.  It has a high probability of making your code more efficient and easier to maintain.

So, suppose, theoretically, you’re creating a simulator on a limited platform with a set number of available variables and a high lookup time for those variables.  Is it still bad practice to hard code your values?  I was able to drastically increase the performance of my slow simulation by resorting to them, but does the performance gain justify the rule-breaking?

And again, this is where getting moral about your code can trip you up.  Jump all the way up to the top again and reread statement 2.  Code isn’t beautiful in itself, it’s beautiful because it works.  Rules of thumb are not universal standards. I don’t mean that coding standards aren’t important; they can and do improve your code if you use them.  They are, most of the time, the right thing to do.  But… just like in music or literature, sometimes you need to break rules to do interesting things or work with a particular medium.  And it’s not somehow immoral to do so, as long as you understand the rules and as long as you understand why you’re breaking them.

The only rule in code is whether or not your program works.  Everything else, literally everything, is a suggestion, albeit often a very one which you’d better have a darn good reason to ignore.

Emotion in Media

This is an essay I wrote in collaboration with my college roommate, Robert Adams.  It’s a sixteen page discussion on art and manipulation that, if nothing else, sums up some of my most fundamental views on game-design, and some of the reasons why I find the field so compelling.  It’s not the most polished paper (it was written on a minimal amount of sleep), but this is a topic that interested both Rob and me immensely, and that we both kind of just jumped into with a rather reckless bravado, despite its depth.  We’d both like to keep expanding on it some day, although that’s pretty distant in the future right now.

PDF embed below: Feel free to link/quote, but please don’t republish or reuse without permission from all of the authors.  Plagiarism is bad.

Peanut Gallery : A Portal 2 map

I made a Portal 2 map!  These things have been exploding ever since Valve released the level editor; for me it’s been like Christmas, both as a gamer and a designer.

There are so many great puzzles on here.  Portal was really the first game to convince me to start actually looking at how beautiful a good brain teaser could be, and now I have hundreds and hundreds of people who are really good at making puzzles and have no problem letting me see their work and deconstructing it.  Rudolf Kremer’s Level Design, has taught me a huge amount about level design, but I’ve learned almost just as much just playing through Valve’s developer commentaries.  Now I get an opportunity to practice and learn from others.

If you want to play through the puzzle without getting it all spoiled, you can download it here or search for it on Steam under the name Peanut Gallery.  I’ll talk a little bit about the creation process and what I tried to do with it below, then finally I’ll devote a paragraph or two to some elements I feel I got wrong.

I’m of the opinion that, just like narrative, a puzzle should tell a story, and that story should represent some type of ideology or purpose.  In a narrative structure that story revolves around very concrete and personal ideas; the moral of the story, or, if we’re getting away from that trope, some type of philosophy or perspective that you hadn’t considered before.  In a puzzle, that should instead relate to the way you view and interact with the world.  To lead someone through a puzzle is to make abstract concepts real.

In this way, puzzles are an educational concept: it’s not just about solving them, it’s about what happens when you do.  I tried to design Peanut Gallery around two different types of puzzles: the ‘aha’ moment, when you learn a new concept, and flow, when you reinforce concepts you already know in a new way.

The ‘aha’ moment comes about when you internalize an idea, or connect two or more ideas in a way that forms a new one, and realize not just the workings behind it, but the implications as well.  Puzzles do this best when they allow you to understand clearly how different things work before they ask you to combine them.  You shouldn’t have to guess what will happen if you try something.  The player examines the situation and tries one or two (failing) solutions.  At this point, the player will need to ask themselves “what am I missing?”  If, by repeating this process enough times, and by dropping enough subtle clues, the player can be prodded into figuring this out on their own, the entire process will be worth it.  It’s important that they actually figure it out though, and don’t just get it by guessing.  Leading a player through the process of inspiration leads into the concept of puzzle flow.

Hopefully I’m not the only one who’s had the pleasure of playing through a puzzle that just goes quickly and gracefully.  Puzzles like this allow you to demonstrate concepts you’ve already learned, to combine them and iterate on them, and to, generally speaking, show off to yourself how good you are.  That’s what I mean by flow: balancing between problems that aren’t trivial to solve, but that are solvable almost instantaneously, or at least with only a few seconds of thought.  If the previous situation had players asking “what am I missing?”, flow has them asking “What was that trick again?”  You can get the player into a pattern of constantly needing to think and constantly getting a clever solution out of that thought process, and if you put players through this enough, the concepts that were once ‘aha’ moments will become second nature, just like walking or jumping.

To engage flow in my puzzle, I first settled on the idea of using portals to cover great distances quickly.  I start the player out by trapping them behind two panes of glass and a couple of turrets.  Making the player immediately solve a puzzle serves two purposes: one, it gets them used to a couple of key concepts that they’ll need to employ throughout the rest of the puzzle, and two, it forces them to examine and take in the room, particularly the exit, which gives them time to formulate a clear path through the level.  In order to escape the turrets, the player must place a portal on the ceiling, marked by glowing lights (hopefully suggesting at least subconsciously that well-lit areas are important, which helps me push ideas at them later on in the puzzle), and by placing a second portal on a surface revealed via a switch.

The idea of placing a portal on one wall and exiting through another wall isn’t new to an experienced player, but by forcing them to actively reveal the portalable surface on their own, I reinforce the idea that this option can be employed even in situations when it’s not obvious that it is allowed or intended.  Throughout the puzzle, players will need to traverse the room almost entirely via this method, (running around will get you killed quickly) so it’s important that even before starting out that they are comfortable with the idea.  To further enforce this, I leave an opening for the player to attempt to run past the turrets.  It’s impossible to get through this way, of course, but hopefully it leaves the player with the idea that navigation through skill alone is not only unnecessary, but often impossible.

I next drop players next behind cover, and allow them the opportunity to click a switch that removes said cover.  I do this, again for two reasons.  The first is that I save their progress before they enter the cover, and I want them to die and know that I’ve done that, and will be doing it throughout the level.  Secondly, I want the player to understand that switches often have different uses than what is at first apparent.  This will become more important for the final ‘aha’ moment of the puzzle, in which the player will be forced to reinterpret the uses of a falling sphere from the sphere itself to the momentum of said sphere.  The switch that exposes the player’s presence to the turrets also shields another part of the map, and by portaling over to that place (again, use portals to travel large distances quickly), the player can reach the next switch.

The next portion serves mostly as exposition to the actual puzzle itself.  A redirection cube (which would enable the player to open the exit door) is dropped on one of two parallel towers.  The player can use their own momentum (a common Portal concept) to almost reach the cube, but unfortunately it eludes their grasp.  By using this same momentum however the player can reach a switch which drops a metal sphere onto an aerial faith plate which then propels the sphere into a wall.

At this point, at least during the limited playtests I did, the player usually attempts to retrieve the sphere, which rolls around the level in a fairly random fashion.  And at this point, ideally, the player reaches a wall.  Portal rarely gives you useless items, and the popular view that people embrace is that, “if it’s there, it must matter.”  The idea is, however, that while items are never useless, the use is often quite different than the item suggests.  This is, hopefully, an application of the previous player experience with the second switch they pressed that exposed them to turrets.  In this case, the sphere itself is important, not because it is a sphere, but because it has huge amounts of momentum.  By placing a portal on the wall where the sphere hits and another on the tower across from the cube (the real object being to reach this) the players can use the sphere to knock the cube to the ground, enforcing all of the concepts they’ve learned so far: the dual use for objects, the usage of portals to cross large distances (at this point allowing objects to cross large distances rather than themselves) and by solving puzzles through thought and not skill (not allowing them to propel across the gap themselves).

Once the player has realized this, the puzzle becomes trivial, although it isn’t over quite yet.

Extra Credits has an excellent video talking about pacing in games that suggests that you should always try to follow a curve with the pacing of a level or game that you design: exposition, rising action, climax, and falling action.  I took this to heart and decided that it was important not to let the player end on a climax.  Rather, I give them one more chance to internalize the lesson (and engage in a little player-rewarding) by allowing  them (requiring really) to kill the turrets that have been attacking them all this time. To do this, they’ll use the same cube that activates the door.

Using redirection cubes to fry turrets isn’t a new concept to anyone who’s played portal, so as soon as the player realizes that the turrets must be killed, they shouldn’t have much difficulty realizing that, before opening the door, they can redirect the laser through several portals and clear a pathway for themselves.  It’s one last chance to apply the concepts on a smaller scale.  Portals bridge the gap between lasers and turrets, no skill is required to evade the turrets, and the cube that they knocked off originally just to open the door now allows them to reach that door and get some revenge in the process.  Once completed, players can use the same faith plate that they used to send the sphere into the cube, to propel them to the exit (one final reinforcement that objects have multiple usages).  This part of the puzzle can be solved at the player’s leisure though.  Once the turrets are gone, players have an opportunity to explore the level and freely roam, hopefully giving a sense of openness to a previously restrictive and harmful environment.

There are other things going on of course, but those are the main ideas.  Several elements ended up working against me here, some puzzles are breakable with just enough timing (bridging the gap is extremely rare, but can be accomplished if one uses turret fire to propel themselves; and turrets themselves have one too many opportunities to hit you (ideally, you should be able to go through the entire level without getting hit).  Save points could use some adjusting and smarter placement, visual cues are sometimes not quite obvious enough to signal what the player needs to do next.  I’m sure there’s other stuff I’m missing.  Finally though, I wish I had come up with a secondary usage for the metal sphere, or some surefire way of destroying it once it’s used.  Most of the rest of the puzzle is efficient, but the ball just rolls around for forever while you solve the rest of the puzzle.  It’s just taking up space.

Review of Rudolf Kremers’ Level Design

I did this essay a little while back in review of a section of Rudolf Kremers’ book, Level Design, which is a fantastic read.  I have an affinity for writing like Kremers because I tend to make many of the same mistakes in my own; In a way, you could make a point about glass houses, especially since Kremers does definitely win out on the ‘readability’ front.

PDF embed below: Feel free to link/quote, but please don’t republish or reuse without my permission.  Plagiarism is bad.

Source Code – Pong Clone

I uploaded this to Facebook a while back (how pathetic can you get, right :) ).
It’s a class project on making a Pong clone (does this count as fair use?) that somewhat turned into me experimenting with XNA’s render engine; specifically with rendering to textures instead of to the main screen.
This was the first time I’d ever done anything like this in XNA, so I tried to see how far I could go with the new trick.  I used Color arrays to store data, which is almost criminally inefficient; I’ve been able to choke up even school computers with this code.  However, as a learning exercise, I did get a lot out of this.  If I were to go back, I’d probably try and switch out some of these effects with Shaders, they’re going to end up being my next graphical topic to go crazy with.

As a pure code example, there’s not much to be overly proud of here – I’ve left it in the exact state it was turned in, which is somewhat under-commented and certainly not bug-tested.  In particular, you’ll find when hooking up an xbox controller that menu controls are actually inverted.
This is, however, an example of just how dangerous it can be to grab onto a certain point or block of code and make it your pet, even to the point where you sacrifice bug-testing and cleanup time to pushing that even farther.  The end result isn’t even that impressive, I’ve been told the graphics are potentially seizure inducing.  There were several game modes that were planned out but never executed because of this, and it makes me wonder how many other mainstream games suffer from the same issues.

There’s also some interesting menu structure in here, although it needs a fair amount of tweaking.

Source below –

Source – Pong Clone

Copyright information : you may feel free to reuse this code for any purpose, commercial and proprietary included.  The nice thing to do would be to credit me, but I’m not going to get mad at you if you don’t.