15 Years!

Tools of the Trade: Inform 7

One of the earliest computer game genres was the text adventure. Perhaps the best-known text adventure game is Zork, which was published in 1980 by Infocom. Text adventure games are pretty much exactly what they sound like – adventure games featuring puzzles that consit entirely of a text parser.

Players would enter simple sentences such as, “open mailbox,” and, “read leaflet,” or even, “hit the orc with the Elvish sword,” and the game would respond with ways in which the world changed as a result of your action. Understandably, these games only understood the nouns and verbs needed for the game and don’t recognize a full range of English input.

The text adventure is alive and well today, although the community of developers and gamers who play them prefer the term _interactive fiction_ or IF for short. There are several languages and platforms for programming IF and one of the most interesting is Inform 7.

Rather than requriing you to learn a programming languauge, Inform 7 allows you to describe your game using the same language that your players will use to enjoy it – English. This doesn’t mean you can type in your short story and hope Inform 7 can figure it out. Inform 7 requires you to follow some very exacting standards so that it can interpret what you write.

Inform 7 also supports extensions, which allows you to download complex items that other people have written – such as vehicles and locks – and include them in your games.

Inform 7 runs on Linux, OSX, and Windows. It’s free to download and use and comes with very comprehensive documentation that walks you through everything you need to make your own interactive fiction game.

Inform 7 makes it possible to create engaging and dynamic game environments, even if you aren’t a programmer or an artist, and yet it still teaches you to think logically and use a more demanding language structure, hinting at what it’s like to write in a programming language.

If you’re a team with excellent writing skills, a great idea for a game, but no art or programming skills, consider being the first OGPC team to submit an interactive fiction game!


Tools of the Trade: Inkscape

This week’s TotT post is for the artists on your team. Since I’m an artist myself, and an advocate for FOSS (free and open source software), you’re going to notice more opinions in this week’s post than last week’s.

There are two types basic methods of creating 2D art on a computer – raster and vector. Raster images are commonly called bitmaps, but have multiple common file formats with different strengths and weaknesses. You’re probably already familiar with .BMP, .JPG, .GIF, and (hopefully) .PNG* file formats. These images are made of individual pixels of color and cannot be made larger without losing a lot of information.

Vector images are created by programs like Adobe Illustrator, an expensive and proprietary profesisonal-grade application, and Inkscape, a free and open-source professional-grade application. Inkscape uses proprietary file formats and Inkscape uses the SVG (scalable vector graphic) format, which is an extension of XML and can be viewed by most modern web browsers (finally).

We will make it better - with math!Vector images are created using mathematic calculations to define geometric shapes. Every time you scale a vector image the math is recalculated, meaning you always get crisp clear lines… unless you’ve applied a mathematic formula to blur the edges, in which case that gets recalculated too, so you always have a predictable amount of blur.

Many people are under the impression that vector images are only good for logos and text, but as you can see from the Inkscape screenshot to the left, a talented artist can do so much more than that with vectors.**


Now, those of you who’ve used GameMaker Studio or Stencyl before know that they allow you to import raster files, not vector. So why would you want to use Inkscape to make art for your 2D game? Scalability is the most important answer. You may decide to increase the resolution of your game and scaling all of your art assets is not going to be fun if the originals are all raster files. Inkscape easily exports to the PNG file format, so if you need a character or UI element to be larger, it’s a simple matter of re-exporting your art to a higher resolution.

Personally, I also prefer to work large and with clearly delineated forms as opposed to working small and with shades of color. Crafting 32×32 grids comprised of dots of color simply doesn’t make a lot of sense to my brain. With Inkscape, I can work in a manner that makes sense to me and still contribute meaningfully to projects that require small icons and sprites.

 Finally, if you’re working on an HTML5 game, SVG files can be used natively and programmers tend to love them, since they can open them up and edit them using a text-editor to create groups and assign item names that make sense to the code and structure of the web page, all without touching the art you so carefully crafted for them.

Inkscape is a free program that runs on Linux, OSX, and Windows. Download it today and see what you can make with it!

*As an illustrator and designer who loves crisp lines and rich color palettes along with clean transparency, .PNGs are the only raster file type I like to use for my work.

**That’s not my work, sadly. Click the Iron Man image for more examples of great vector art.

Tools of the Trade: Stencyl

If you’re a Mac user, or prefer using a Linux OS, you’ve likely discovered that Game Maker Studio (GMS) – a long-time OGPC staple – doesn’t play so nicely with those platforms. The OSX version of GMS is out of date and the current version doesn’t work under WINE, the open source application that runs many Windows applications and games on Linux.

Enter, Stencyl.

Stencyl has a lot in common with GMS. It’s a 2D game creation studio with an art-focused approach to game design. You add actors (what GMS calls objects) to scenes (rooms in GMS), edit sprites and animations, add music and sound effect, use physics, and customize actor behavior.

And while Stencyl allows you to edit code for your game using ActionScript 3.0 (an ECMAScript language similar to JavaScript), it also allows you to design your code using drop-and-drop puzzle pieces. This allows you to quickly create complex behaviors while learning common programming logic. You can also easily view the actual code you created, so more advanced programmers can easily work alongside the game designers on the team.

One of the most compelling features of Stencyl is the platform’s focus on community. Members are able to upload and share snippets of code, original art, and music to the StencylForge. Browsing the StencylForge, you’ll find kits provided by both the Stencyl team and other members that include all of the functions you need for side scrollers, RPGs, racing games, and many more gameplay styles. Members have also uploaded pre-built behaviors that you can easily include in your game. 

Under the hood, Stencyl uses popular and powerful Flash-based libraries to build your games, notably Flixel and Box2D. The current free version of Stencyl exports your games to Flash and buying a subscription allows you to export your game to iOS, taking advantage of the tilt and multi-touch controls of the iPad, iPhone, and iPod Touch. Version 3.0 – which is scheduled to be released in 2013 – will add HTML5 export to the free version and Android export for subscribers.

Learn more about and download Stencyl at www.Stencyl.com

Design Lessons

Not all game design lessons come from studying games. There are important design lessons to be found just about anywhere we interact with the world. For example, I wrote the following post in 2006 when my wife and I rescued a miniature poodle from a shelter in Philadelphia.

Game Design is Going to the Dogs

Or is that coming from the dogs? Well… dog to be precise… and my game design to be even more precise. Regardless of the linguistic finickiness, this post is sponsored by my new design-muse, (T.S.) Eliot, the Elder Snout Oopei Choop. You may recall that a little over a month ago I announced the arrival of a rescued poodle to the Attic. Although we were originally informed by the shelter that he was three years old, we’re assured by our vet that while he’s probably not eight, he’s certainly not three. There’s nothing quite like adopting an older dog. While Eliot is very clearly an intelligent animal, he’s got separation anxiety, likes to test boundaries, has stomach issues due to nerves, and clearly didn’t live in an environment which engendered trust in humans. To top it all off… he didn’t know how to play.

Dog. Not playing. Dog… not playing. Dog.

All right, then. This would not do. We have taken it upon ourselves to teach Eliot to play. While I’m at it, I’m extrapolating whatever game design principles I can from the process and it’s those observations (I’ve settled on nine of them) which will make up the remainder of this post. Incidently, these same principles apply to training the dog to perform other, less play focused, tasks as well, such as sit and stay… which we’ve also managed to turn into a fun game (mostly).

1. Be Patient Eliot doesn’t always get it right off the bat. Even when he does seem to get it, he’s not always interested in participating. Getting frustrated isn’t going to help, so patience is the keyword of the day. Likewise, while seeking feedback on a game’s design, whether via play testing, or social networking, it’s important not to loose patience with other people when your vision isn’t clear. Keeping a cool head means that ultimately, you’ll learn a lot from the miscommunication. Likewise, don’t let your game design itself rush players through the experience. There’s something to be said for frequent direction markers and vacuum plot points, but don’t grab your players by the nose and speed them through the game, let them find their own pace.

2. Be Supportive Eliot doesn’t always trust his instincts around us. It’s a new environment, we’re different people than he’s used to and we don’t react to his behavior in the same manner as his previous owners. Because of this, he’s often hesitant, or worse, he cringes if we move quickly (breaks my heart). I have to confess that he’s gotten much better and I attribute that to the supportive environment we provide him. By supportive environment, I mean that we constantly provide him with positive feedback. When he’s hesitant, we encourage him. When he cringes from a sudden movement, we take some time to hug and pet him. Likewise, have your game’s design be supportive of your players. Very few things turn me off faster than a game that mocks my need to quit and go to work, or one that triumphantly proclaims, “You loose!” when I fail at a task or mission. Let your design focus on players successes and refrain from pointing out their failures.

3. Be Reasonable With Praise This one ought to be pretty obvious and it ties in closely with the previous design rule. Together they represent a simple three word concept – Reward. Successes. Appropriately. When Eliot first started obeying simple commands, we made a big deal out of each occurrence. Once we moved on to more complex tasks, we shifted our focus and stopped making a big scene for every successful ‘sit’ performance. Otherwise, the act itself becomes minimized by the love-fest afterward. In other words, take time to praise thoroughly and well without detracting from the positive experience of accomplishment itself. Windwaker, in my opinion, has too many animations surrounding the fetching and opening of every single sunken chest. They lavish too much praise for a minor accomplishment. The music and light while opening the chest would be enough, without the triumphant pose afterwards. It’s cute the first time, but gets tedious very quickly. I think perhaps, it is better to reward the player a little too much rather than not enough, but keep in mind that most of them just want to play, without a lot of interruptions.

4. Be Filled With Joy This is one of the two sappier rules in the set. But seriously, be happy to do what you’re doing. A joyous approach to design will be reflected in your final product. A stressful, tense, unhappy experience designing a game will not do you, or your audience, any favors. Eliot reacts quite well when we’re not stressed out about his training, or his play. We we are stressed… well, it’s when he chooses to test boundaries the most.

5. Be Filled With Love This, clearly, is the second of the two sappier rules. We are teaching Eliot to play (and to obey) because we love him. We want the best for him and we want him to be happy. Setting boundaries and helping tailor behaviors out of love makes all the difference in the experience. Treat your audience with the same respect and sense of responsibility with which you’d raise an emotionally wounded poodle. It will shine through in your final design.

6. Take Breaks When Needed Eliot can only handle to much training in one day before he loses interest. We watch for the signs of this and try to quit right before he does. This keeps him interested in the training and has proven very effective. This translates into two design rules: One – take breaks when you feel your brain starting to overheat. Whether you read a book, have a conversation, listen to some music, or watch a bit of a movie, it’s important to let your brain rest every once in a great while. Two – give your players time to catch their breaths. The quiet moments immediately before or after a large challenge are some of my favorites throughout my game playing history. The exciting moments are the ones I talk about, but the quite ones are the ones I reflect on.

7. Quit When They Do The above rule can be hard to gauge correctly. So if we haven’t taken a break and Eliot quits, we do to. This works well for us, because he’s intelligent and far from lazy. I imagine that it might be different if he weren’t such a motivated dog. The gist of this rule as a design goal is simple: allow your players to save and quit… whenever they want. Now, you may need to restart them at the beginning of a level when they come back, but don’t undo their accomplishments. Save features no longer need to be limited as they once were. Save the important information and quit when they do.

You’ve seen the next two rules on this blog before, they’re not new. But, while teaching Eliot to play (we’ve been having success at this, by the way) and to obey (even better successes on this front), these two rules have proven invaluable.

8. Reward Desired Behavior Treats, joyous and love-filled praise, and plenty of petting await Eliot whenever he behaves appropriate… even when it’s accidental. Your game design should work the same way. Wether the reward system be comprised of points, character bonuses, items, or a mixture of many things, you should always reward players for exhibiting desired behavior.

9. Discourage Undesired Behavior Note that this rules doesn’t say punish or disallow, but discourage. Your game should not be a battlefield between designer and player. You should not take an adversarial stance with your audience. Remember that even negative attention is attention and gently discourage undesired behavior with non-threatening, non-harmful guidance. Die-and-repeat gameplay only appeals to a small segment of the game playing public, so give the rest of your audience plenty of gentle discouragement when they wander astray.

So there you have it. Nine quick-and-dirty design principles based on teaching a poodle to play. Most of these were not new concepts to me and probably weren’t to you. It’s merely a slightly new application of them. Still, it’s interesting to see them in effect in an area and context in which I hadn’t considered them before.