Archive
Table-top Coleco
I was extremely envious of my friends who had one of these. Almost everyone who had one had only the Pac-Man version. Come to think of it, I don’t know anyone who actually had the Galaxian version.
Review: Casual Game Design: Designing Play for the Gamer in ALL of Us
Haven’t posted in a long time, so figured I’d post a review of a book I recently read. It’s no secret I’ve an interest in casual game design. The addictive simplicity of play is what appeals to me. If you think about it, one can consider the old coin-op games like Pac-Man and Tempest and all those greats, heck, even Pong, casual games. But generally the consensus is that the first real casual game to really jump-start the casual design movement is Bejeweled (speaking of which, I tried the World of Warcraft version yesterday. It was meh. I’ll stick to my iPhone version (tied in with Facebook).
The book in question? Casual Game Design: Designing Play for the Gamer in ALL of Us by Gregory Tefry. [Purchase from Amazon
What I like about this book is that it’s really good for budding game designers or those who are interested in designing casual games, which isn’t as easy as it sounds. Trefry starts with the basics: writing the game design document, what makes a game, and the like. He then goes into a myriad number of major casual game design themes (e.g. matching) and discusses what makes a game like Solitaire or Bejeweled work, not work, and examples of games that don’t quite get it. This is actually very important: one of the key factors in design is knowing what works, what doesn’t, and why, and how you can build upon this. Design is not at all about lines of code: it’s about solid concept expressed extremely well so that others one the team, from the artists to programmers etc., can work with your vision and create a solid product.
For the experienced designer, this book has benefits as well. Casual game design is different: your focus isn’t on large, complex systems, but smaller, addictive forms of game play that will inspire your game to be played by players who don’t have the time to invest in a large project. Casual Game Design’s focus on example games really helps the experienced designer looking to work on a different genre to see design differently.
I still suck at Dragon’s Lair
In 1983 I was 11 going on 12 and a video game addict. It was not unlike me to swipe laundry-bound quarters to feed my addiction. When Scholastic’s book club paper for our grade came around each month, I’d scour it for any books on video games, and there were a lot of them back in the day (mostly focused on how to beat Pac-Man). It was reading, right?
Word came to me somehow that there was a very new game on the market that was extremely exciting, with art that had never before been seen. Dragon’s Lair took a little while to make it to Ridgewood, Queens, and my friend Rob found it at some corner store on Woodward or Onderdonk a few blocks from our house. Sweet!
It cost 50 cents to play Dragon’s Lair, and Rob always seemed to have the coinage on him. I watched him play a bit, and then put my two quarters up to ensure that I’d get the next round. Not that it was needed: we were the only two kids in the entire deli. But old habits die hard, and spots is a habit I’ll probably have until the day I die.
What I had seen, which was a beautiful work of art, and what I experienced were two different things. The art and sound for Dragon’s Lair is simply amazing courtesy of the expensive laserdisk technology it was using. The game play? Oh my fucking HARD.
You are Dirk Daring out to save Princess Daphne, who’s been kidnapped by a seemingly horny dragon who lives in a castle with lots of clever traps. Your job is to quickly twitch your way around these traps while making yourself useful with nothing but a sword, or, on the coin-op machine, a controller and button.
In most games, both then and now, when you started the game, you were randomly placed in a scene in which a split second choice had to be made. If this was the first time you encountered this scene, you would probably die as you’d make the wrong choice. The same would go for the second and third time, depending upon the number of choices available to you. Timing was of the essence, and as a player you didn’t have to worry about strategy or thinking at all. Thinking was death. Choosing unwisely was death. And many a kid spent a few quarters just trying to get past the first couple of scenes.
That was me: I spent a few quarters trying to get past the first couple of scenes and then I gave up. There was simply no fun in constantly dying because of one bad decision. A lot of people around me felt the same way. Dragon’s Lair wasn’t a game; it was an investment in success. I went back to the older Ms. Pac-Man coin-op and would simply occasionally glance at Dragon’s Lair to see if anyone actually found any success at it. Five minutes with Ms. Pac-Man was four minutes, thirty seconds more than I ever spent with Dirk, and she was a cheaper date, too.
Despite my lack of success at Dragon’s Lair, I always enjoy reading about it in the history books. It’s been ported endlessly to other platforms over the years, most recently to the iPhone. It was with some reluctance that I purchased my own copy of Dragon’s Lair for my phone. I never paid attention to the ports, was never successful at the game. But finally, this morning, I did it.
And what did I find?
Yes, death, my old friend. Each and every decision outside of the initial swing sword at purple things when you fall through the bridge scene met with Dirk’s untimely but well-designed death. This is one game I think I’m simply doomed to suck at.
Designing Around Limitations
Racing the Beam
I recently finished reading Racing the Beam: The Atari Video Computer System
At the time, the VCS was really gaining popularity with kids my age. My stepmother didn’t actually realize this until I started being social and going to other kids’ house in the building to play blotchy Asteroids on their consoles. Then she remembered the dusty box in the back of the closet, and my brother and I were happy campers playing endless versions of Combat.
(A note: the VCS was not our first addiction: that would be console Pong.)
The VCS was the first extremely popular console system at a time when technology for gaming was quite young and extremely limited. The MOS 6507 CPU could only use* a whopping 8 KB of memory, and games were therefore limited to 4 KB until bank switching came to games years later. The TIA was the real star of system as it was responsible for putting the graphics on our television screens. The technology was limited, however, and it wasn’t really until Activision came on the scene that designers really pushed the limits and made beautiful games for the VCS.
Racing the Beam focuses both on the technological aspects of the VCS and how game designers worked with and overcame the limitations of the hardware. Montfort and Bogost look at six games which took advantage of and pushed the envelope of the VCS:
I’m not going to go into details about how each game was handled in the text. Mostly because I’m lazy, but also because it’s much more interesting to read how the technology inspired the design of each game by people who actually know what they are talking about rather than someone simply regurgitating what they think they know. What I am going to talk about, however, is the way in which we design around limitations, using myself (one of my favorite topics!) as an example.
I’m not a programmer. I’ve tried to learn a language here or there, but I simply can never get a handle on things. It’s like mathematics: I know 1 + 1 = 2, but if you want me to do some odd trigonometry calculation you’d probably have better luck speaking to me in Swahili. This is why, in part, I took a class in Game Programming at Hunter College last semester. The language was ActionScript, and it was taught by my Concepts In Gaming professor, Angela Ferraiolo. While I did well in the class, I was a complete and utter newbie, unable to execute my rather simple ideas into finished products.
My first project, coincidentally enough, was a port of Atari’s Outlaw, one of my favorite Atari games. I created a splash screen, a rules page, and had an easter egg page on the splash screen giving a brief history of the game. That was the easy part.
I knew how to move my avatar up and down and within the limitations of the stage, but I did not really know how to randomly move the “bad guy” up and down. At the same time, I didn’t know how to successfully fire the gun and have the bullet move across the screen, but did know how to do collision detection. I also did not know how to add sound to get an audio feedback (gun fire, gun hit, win/lose, etc.). Because of my coding limitations, I had to design my game around them. There’s a win/lose state that’s only initiated when the player clicks an object on the screen. Click yourself or the cactus and you lose. Click the bad guy and you win. In either state, you can replay the game (return to the splash home page) and start again.
Whether or not my version of Outlaw is a successful game isn’t up for debate, but what is interesting to me is how I worked with my limitations to produce some sort of product. What I didn’t do, however, is push the limits of my knowledge, nor push the limits of ActionScript’s technology to produce a viable product, but that’s understandable considering that I was only two weeks into learning the language. Racing the Beam, however, gave me food for thought regarding how many designers and programmers have to work around the limitations of whatever platform they are working in. While the Atari VCS is certainly a low end platform system that was severely limited by the technology available in its day, a slew of effective games were produced that are not only some of the most beloved games of all time, but set design standards that are still in use today. Effective game design and programming looks at the lowest common denominator and then says “okay, how can I push the envelope and make a kick ass game.” Not every game is successful in this area, but it is an extremely worthy goal to reach for, and something that I, as a designer, should keep in mind as I continue to expand and learn and develop my myriad tools (none of which should really include programming :)).
Racing the Beam is part of the Platform Studies series, published by The MIT Press
* correction submitted by Simon… thanks!
Check out….
twobitgames 