Tuesday, December 31, 2013

Explore the Story

A trip by mule-back makes me appreciate my '76 Datsun
We wish you a Merry Christmas and a Happy New Year! A few months ago, we worked with Forest Hill Church to bring another game to life. They just released the game the weekend before Christmas, so we wanted to share a bit about it now that it's live. We were excited about this opportunity for several reasons:

  • They're local! Interestingly all of our work until this project came along has been out-of-state or international. This meant a few more face-to-face meetings than we're accustomed to, so we shunned our caveman apparel and studiously domesticated our facial hair.
  • Another Platypus project! We designed a front-end game as well as a back-end game editor that allows the staff of Forest Hill to add new stories to the game. We used Platypus as the backbone for both of these interfaces, giving us a lot of interesting use-cases to further strengthen the engine.
  • It's Sunday School++! We loved that the church had a vision to try something new. We created the basic framework, but the Kids@FHC staff will be making the individual games, so we're excited to see the stories and experiences they create with the tools we made.

The Game

Can you find the telephone booth?
Explore the Story is a seek-and-find puzzle where children can select one of several stories to play through. Each story consists of an environment with several hidden items to find. Once an item is found, children answer a few questions about the artifact to score points.

This game is unique in that it uses photographs of the kid's auditorium as the game environment, and each artifact is physically hidden on stage for the photo-op. This presented interesting challenges while designing the game, since an artist can make art that fits a game perfectly, but photos aren't quite so flexible. For example, small hidden items in a photograph become nearly indistinguishable from a distance, so we updated our design by including close-ups. This alleviated the small artifact problem and also gave the game a deeper experience, allowing children to explore the environment in more detail.

For this game, we neglected the HTML5 canvas route we typically use for more animated experiences and strictly used the DOM and CSS. This allowed us to take advantage of hardware acceleration on many mobile devices by using 3D transforms for the visual effects.

The Editor

Archeologists uncover Goliath's armor near Charlotte, NC
In addition to the basic game framework, we created an editor through which the church staff could add new stories to the game, including pictures for the environment, artifacts, and questions to accompany the artifacts. Creating the editor was a bit of a new experience for us, since we typically work on front-end game development, but we're pleased with how it turned out.

We built in a few tools to make creating and editing a game an easy and fluid experience:

  1. We neglected the traditional page form submit in favor of a responsive XHR model. As rooms and artifacts are added and edited, a server-side JSON file is updated to reflect the current state of the story.
  2. We made soft limits on text input: if the text field content is getting too long for its respective place in the game itself, the text field background color becomes yellow or red to signify that the length may be too long.
  3. We created a visual room selection module so that picking the right room for an artifact or room-to-room navigation is intuitive, without unnecessarily naming rooms to use as references later.


Check out the game and give it a whirl. And if you live near Charlotte, NC, you can visit Forest Hill Church and see it in real life!

We would give you a link to check out the editor too, but, you know.

Friday, December 13, 2013

The Components of a Platypus: An HTML5 Engine Mid-Mortem

The Platypus engine is Gopherwood's first foray into the world of component-based design. The engine has a long life ahead of it, but as a sort of mid-mortem we thought we'd take a second to share our reasoning for going the component-based route and how we feel about the results so far.

Components. Kinda like Legos, but less painful to step on.
When we first got the go ahead to put together an HTML5 engine for PBS Kids the first thing we did was fish around for a proper design template for the engine. When a talented programmer friend recommended we look into a component-based design, we did exactly that. For those unfamiliar with the model, the idea is that game entities are made of a simple object whose functionality is fleshed out by adding a collection of objects called components. These components are designed to function independently so that they can be added/removed/replaced with impunity. After a little research into the design we were convinced by a few arguments we found.

Arguments for Components

The first argument for a component-based design was an argument against using the more popular class-based design model with JavaScript. JavaScript is not a class-based language and doesn't lend itself to a traditional class-based design model without some finagling (that's a technical term). We felt that a component-based design fit more cleanly in JavaScript's design tenants. By starting out with a design model that better matched JavaScript's nature we felt that we would benefit by doing less working against the grain.

Another benefit we saw for avoiding a class-based design was to get away from the bloatedness (another technical term) of inheritance. With engines that use inheritance, you often inherit from several standard classes when you are creating a new entity. In the process you often inherit more than you need for what you're doing. This is because each new entity has special cases that requires small revisions and additions to the standard inherited classes until eventually these classes are bloated with functionality that is useless in most situations. Component-based design is in some ways a form of hyper-multiple-inheritance, in that each piece of functionality (logic, ai, physics, etc.) is 'inherited' from a component. The difference is that each component is designed to work discretely, meaning that special cases (and the bloating they tend to cause) can be dealt with using a unique component while the rest of the components remain standard issue.

Finally, because all of an entity's functionality is found in its components, the argument stood that it would be easy to quickly assemble new entities from existing components and reuse components.

The Good Side

You mean we aren't unique?!
So did it live up to all the promises? For the most part, yes. We've been very happy with the ease of developing in the component-based model. In particular, creating new entities from existing components has made the development process considerably quicker. In some cases, such as the playable characters in Wild Kratts: Monkey Mayhem, we are able to create entire entities without a single line of unique Javascript. And in most cases, we are able to reuse existing components to add large pieces of functionality to an entity without adding more functionality than we need. Designing entities is made easier by using JSON to assemble the components that will make up an object and give initial settings for those components. All of these things add up to the ability to make lean entities efficiently.

A good example of how easy it is to put together an entity from standard components is the ant entity in Monkey Mayhem. The ants in Monkey Mayhem behave like Goombas from the Mario series. To create their behavior we use four standard components: ai-pacer, logic-directional-movement, logic-gravity, and collision-basic. Collision-basic allows us to define what the ants will collide with. Logic-gravity will cause the ants to fall when they aren't supported by terrain or a solid entity. Logic-directional-movement tells the ant how to move each game tick (in the ants case it's defined to move horizontally at a steady pace). Finally ai-pacer works in conjunction with collision-basic and logic-directional-movement to tell the ant to reverse direction whenever it collides with a wall. While this is only one example, it's easy to imagine how by swapping out one of these components with a new one we can quickly create new types of enemies.

The Challenges

While many of the promises of a component-based design have come true, that's not to say there haven't been challenges.

There have been multiple systems that have strained against the restrictions of the component-based model, particularly the limitation that components should be discrete and ignorant of the inner-workings of one another. Our collision system is an example of a system that violates this principle. We found that some components needed to be more tightly coupled than was possible in a pure component model and so we opted to violate those principles instead of creating an unnecessarily complex workaround. Deciding when and where to do this in the engine has been a recurring question. As our experience with the engine grows we feel that the answers to when to break the rules will become clearer.

Pew! Pew! Pewpew!
Another challenge was developing a means of communicating between components. It took some iteration before we found solutions that felt natural. For communication within an entity we used an event-based model. For those unfamiliar with this model it is somewhat similar to how a satellite relay works. A component that wants to send a message to another component broadcasts the message to its owner entity (the satellite). Which then rebroadcasts the messages to any listening components. This worked well for communication within an entity, but didn't scale to communicating between entities because there was no simple way to specify which entities would receive the message. Instead, we came up with a couple solutions that were useful for different situations. The first, and most direct, was to let a component listen for when other entities were added to the current scene. If an entity is of interest, the component can retain a reference and then communicate to that specific entity. A second solution was to set up a modified event-based system using our 'entity-linker' component. With this system an entity can link to a particular 'channel'. The entity will receive any messages broadcast on that channel. Similarly the entity can broadcast its own messages on the channel for other entities to receive. 

In addition to these challenges, there is also a general mental shift needed to switch from traditional inheritance oriented design to a component-based model. Thinking about each component as discrete, determining the proper means of interfacing with other components, deciding when to generalize a component or keep it specific, etc. All of these are questions that occur repeatedly as we work on Platypus. These aren't bad questions, just different.

We Like It, Now You Try It

In summing up, we are really happy with how Platypus has come together and continue to believe that going the component-based route was the right choice for the engine. If you want to form an opinion for yourself, feel free to check out the engine here on GitHub.