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:
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.