Posts Tagged ‘pong’

Review: Casual Game Design: Designing Play for the Gamer in ALL of Us

11 July 2010 1 comment

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.


Designing Around Limitations

21 March 2009 1 comment
Racing the Beam

Racing the Beam

I recently finished reading Racing the Beam: The Atari Video Computer System by Nick Montfort and Ian Bogost. I have a passion for classic gaming, so of course I’m always interested in reading up about the old Atari VCS, which I first came across back in 1981 I think. My first stepmother’s ex-husband had actually purchased one shortly after it came to market, and she won it, as well as an organ and his machete, in the divorce (actually, I think he just left most of his stuff in the apartment and took off for less stricter pastures, but that’s a story in and of itself).

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