Category Archives: Source Code

Posts in this category have source code that you can download.

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.

Natural Language Interpretation

A.I. is one of those sweet spots for me; I’ve unfortunately never really had the opportunity to extensively dig into a singular project, but I’ve always enjoyed working with it whenever I can.  Unfortunately, one of the side effects of being more interested in a process and its results is that you can lose track of details  – somewhat ironically “not seeing the trees for the forest.”  As such, I’ve benefited a lot from taking discrete math this year and learning about some of the more simplistic algorithms behind graph theory and data analysis.  At the risk of inviting scorn from the more educated, I have to admit I still get a higher enjoyment out of AI that focuses on behaviors and motivations, rather than simply trying to get computers ‘smart.’  Some of the most convincing AIs are those that imitate our flaws as well as our strengths and for better or worse I tend to treat AI as a philosophical exercise as much as a mathematical one.

Anyway, I guess what I’m trying to say is that this project was a lot of fun, in spite of, or perhaps because of, its differences from what my goals usually are.  Natural language interpretation (of this scale) is about as basic as you can get without getting into the really low level stuff like analyzing tick tack toe.  Nevertheless, I’m finding there’s a certain charm to it; having to rethink my sentence structures, parts of speech, and basic word meaning is, well, fascinating to say the least; and is only eclipsed by the process of communicating that type of thinking into some type of really basic structure that C# can understand completely.  There’s a certain type of reverse-engineering vibe to the entire process of taking something as complicated as a sentence and turning it into one or two very specific ideas.

Not that this code does anything so complicated as all of that though.  This is a pretty simple algorithm for breaking apart verbs and  subjects and matching them together into a queue of actions.  There’s not much to say about it really.  It’s quite forgiving (try leaving out the word ‘and’); I’ve always been a big proponent for not artificially restricting users to conventions unless they actually matter.  Let people hack.

Back to more the interesting stuff, self analysis!  This code was written on top of the work of both Prof. David Schwartz and Sela Davis.  It’s re-posted here with the permission of Prof. Schwartz; Ms Davis’s portions are currently under ownership of the Rochester Institute of Technology.  I’ve been unable to contact Ms. Davis and get her permission just as a matter of principle, but you can’t have everything in life I guess.

Working with other people’s code is a new experience for me since coming to college and I must say I’m enjoying it, although it does carry its share of frustrations.  There’s always a learning period where everything just looks frustratingly obtuse, and you find yourself wishing that everyone else thought exactly the same way you do.  Abstraction can help with this simply by removing some of the more frustrating details, and that’s awesome, but it’s also sort of counter-intuitive: the more you know about a system, the better you’ll be at working with it.  None of this is to say that you should abandon abstraction, but eventually you’ll need a better solution, and that is to simply drop your ego.  Different people write in different styles, and you can’t expect them to always use the same conventions as you.  In the same sense, you can’t expect yourself to always adapt to them – don’t be afraid of implementing new ideas or changing old architecture out of the fear of stepping on someone’s toes (within reason).  The main principle here is that people are different; even smart people do stupid things and even stupid people do smart things, and part of working with other people (and with other people’s work) is accepting that it’s OK for both you and other people to not be perfect.

Moving past all of that, I took a much more organic approach to writing this code than I normally do.  It’s a lot of fun to just sit down and hack something together, although the results usually show that you just, to put it bluntly, sat down and hacked something together.  There’s a lot to be said for being able to come up with solutions quickly; it’s an important skill; but more often than not you’ll want to sit down and think through a process simply because the results will be better.  But there’s nothing unique here to coding, so there’s little point jabbering on about it – I’m reminded of back when I used to seriously play saxophone: there’s a sort of push and pull behind how fun it is to just sight-read music and how bad sight-reading is for actually learning music.

Source below –

Parsing language

Copyright information : You may feel free to reuse my portions of code, but still must obtain permission before reusing or referencing any portion of code written by another person.  All rights remain to the original authors.

Hit-Test Generator

This is from a while back; somewhere around mid-11th or early 12th grade, back when Actionscript 2.0 and TI-83 basic were the only languages I knew.  As with my other code samples, I’ve left it in unaltered from its original state when I dug it back out of Dropbox.  Actionscript 2.0 does have methods to allow for pixel level collision detection between different objects, but, as I’m sure you can imagine, it’s wildly expensive (and at the time I had no idea how to do it).  The alternative was to do perfect pixel based collision against singular points, which ran into accuracy issues.  This was my first experiment into the wild world of automatic code generation, and the basic idea is that one would load in a sprite, position specific points to test against, and then export all of the code necessary to run the collision in one function.  This code could be simply pasted into the original project you were working with.

 Bear in mind that at this point in my programming career I was running on entirely self taught knowledge, so issues start to crop up.  But, as with anything, else, these afford opportunities to learn general principles about programming and development.  I’m surprised to see how much of my code is commented and formatted; this brings back memories of me wrestling with Flash 8′s IDE to allow me to space out blocks of code.  Maintaining readable code isn’t just for group projects, if you do large projects by yourself you’ll need to get into that habit, or else you simply won’t be able to understand what’s happening when you go back.  Commenting code can become an organic process if you work at it hard enough, and I feel like I’ve lost some of that since coming to college and slightly shifting from large projects to more rushed class assignments.

This also speaks of the way that coding styles and conventions can evolve quite naturally over time, even if, like me at the time, you’ve never really seen anyone’s code but your own before (and some internet tutorials) and are unaware of how it ‘should’ look.  I’m of the firm belief that thrown into a basic enough environment and given enough time to muck about, most students will self-invent a large portion of the conventions that they could learn from textbooks, and they’ll have a better understanding of the practices for it.  Of course, you run the risk of picking up bad habits; case in point the way I bind most of my code to other MovieClips and embedded timelines.  As a side note, I’ve long argued that this practice wasn’t really quite as evil as Adobe made it out to be; you can sometimes make quite intuitive visualizations with it, and it does seem to be in line with the ‘object-oriented’ design model.

Whenever you self teach yourself, you start to run into the rather interesting dilemma of having to try and unify what can quickly become a dichotomy of skills – meaning that you’ll be very good at some things and very bad at others.  To further complicate matters, it can be difficult to tell which group is which.  Looking back, I’m fairly proud of my coding style, but somewhat less impressed with some of the logic I’m implementing, which is nearly opposite of my previous opinions.  If nothing else, it is somewhat amusing that I’ve been dynamically generating collision detection algorithms but, until the beginning of my first semester of college, didn’t know what pointers/objects were.

Anyway, just to really emphasize how powerful natural progression can be, I’ve included my previous version, HitTest Generator .9, which shows several dramatic differences with its future version.  These were developed almost one-after-another; I spent less than two or three weeks off before jumping into version 2 (or 1.0 as the case may be).  Even in this short time though, you’ll notice that, for instance, the amount of commenting of my code increases – most likely the result of trying to re-decipher my old code.  There’s only so much of that crap you can take in high school, especially if you’re the cause.

HitTest Generator was intended primarily for personal use, although I did have fleeting fantasies that I might someday release it in an actually useful format if I could put more time into its development and feature set.  The advent of Actionscript 3.0 has rendered it quite obsolete, but not quite solved the problems it was attempting to address.

You can see a demo of the predecessor (Version .9) here.

Source Below -

Version .9

Version 1.0

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.

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.