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.

Conclusion

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.

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.

47 Easy Steps to Publishing Your First Platypus HTML5 Game

There are not exactly 47 steps to completing your first game, but this is the beginning of an article I'm planning to write stream-of-consciousness style, and I'm not looking back.

Step #1 - Get Platypus!

The PBS Kids team has provided the Platypus repository here: https://github.com/PBS-KIDS/Platypus

Once you have Platypus in hand, visit /game/template.html in your browser. You should see an initial example game appear. You're done! One step! Unless, of course, the one-level example game with +Todd Lewis's incredible pixel art wasn't what you were going for... ...then continue to Step #2. Coming up next. Scroll down.

The tranquil, serene landscape of an example game.

Step #2 - Configure the Game!

There's nothing that says a picture isn't worth a
1000 words like a picture of fewer than 1000 words

Configure? Go figure. This is where you begin chewing into the code, but take small bites so we don't have to get all Heimlich on you. Check out the /game/config.json file. Go ahead, open it up. Note that we'll be doing a lot inside of the /game/ folder, because that's where the game is. The file you just opened is where most of the configuration for the game is stored (unless you just opened up a file not called "config.json"). It's a JSON-structured file with lots of settings. For this blog post, I'm going to walk through some of the changes I made to implement Breakout.

Global Settings

The first section determines some blanket settings for the whole game. You can change things like what scene the game should start on, the DOM element that should contain the game, and the framerate the game should target. While you do that, I'll change the game's aspect ratio to better fit Breakout: a nice, simple 0.7692307692307692307692.

Build Settings

This next section is an array containing settings for each build you want to create. Platypus lets you create, debug, and test the game at /game/template.html as you're working on it, but once you're ready to deploy, these settings mix up the batter, bake the game, and gently place the still-warm game files into the builds folder.

For Breakout, I'm getting rid of the "debug" build in the example so I'm down to a single build generically named "game". Nothing else really needs to be changed here, unless you don't want to use AppCache, hate compression, or want to use a custom namespace. I'm going with "platypus.breakout", but you can go crazy with the namespacing if you like: "namespace.name.space.my.awesome.game.space" We'll come back to build settings later, when we build our game at step #46 (give or take).

Game Sources

This is where the fun starts! This section is what comprises the entirety of your actual game, so let's stop all this chatterboxing about config.json and jump to the next step!

Step #3 - Create Awesome Art and Sounds!

Oi. This is where I call in professionals... ...or copy-and-paste if allowed. In either case, or if you're adept in the arts and create your own, take those awesome graphics and audio clips and drop them into /game/images/ and /game/audio/. Fortunately for Breakout, I am able to copy the art and sounds and be on my merry way.

Once they're all sitting comfortably in their new homes, you need to give them addresses so we can reach them later. Do this in config.json, in the "sources" section we jumped away from at the end of Step #2. You can copy the syntax of the example game images if you like, or just erase them all and pay attention. Images are easily specified with:

{

    "id": "image-id-that-is-used-in-the-game-code",

    "src": "images/image-name-that-is-addressed-by-id.png"

}

Audio is more complicated. You can go the easy route and use the syntax above to just target a subset of browsers, or you can brave the rough waters of HTML5 Audio support and read this more in-depth explanation. Have fun!

Step #4 - Make a Map!

Now that you have visuals, it's a great time to make a map! If you don't already have the Tiled Map Editor on your computer, go get it! It's awesome!

Tiled being awesome doing what Tiled does best: Tiling.

Got it yet? Alright, then onward! There's a whole tutorial here for all the captivating details. Once your map is ready, export it in JSON format and drop it in the /game/levels/ folder. Just like the other assets, give it an address in config.json in the "levels" section.

Things I included in Breakout are a tile and collision layer for the walls, a tile layer for the background tiles, and an object layer containing most of the entities I'll need in the game such as:

• "brick-blue" - A blue brick.
• "brick-red" - A red brick.
• "brick-orange" - An orange brick.
• "brick-green" - A green brick. Yes. I know. I could've made a single "brick" entity, but they were expecting that.
• "ball-spawner" - This entity will create new balls.
• "paddle" - The star of my little Breakout game - this fella never gets a break.
• "ball-killer" - An unseen entity hovering below the stage, awaiting to consume any unfortunate balls that fall thither.

These are just text identifiers in the map at this point, but that's soon to change!

Step #5 - Fashion Entities!

An invisible, senseless robot

Entities do all the work in a Platypus game. They're tough like that. They're like little robots with a big heart and no limbs... ...or brain... ...or even a body for that matter. They're like little invisible, senseless robots, but you get to change that! You get to give them limbs, brains, and cold metallic skin so they can change the (game) world with their big hearts!! Read on to find out how!

Platypus entities are a really, really simple JavaScript objects. What makes them come to life are components. One or more logic components are attached to the entity to give it logic that determines its behavior; one or more render components are attached to give it an appearance in the game world; and one or more collision components are attached to make it interact with other entities. There are a lot of Platypus components.

A visible, sensible... ...robot

Now that you know, take that little invisible robot with a big heart and give it some components! For the Breakout "ball-spawner", I gave it two components: "logic-spawner" (logically, to spawn stuff) and "entity-linker" (like a radio channel to communicate with other entities). Its code looks something like this:

{
    "id": "ball-spawner",
    "components":[
    {
        "type": "logic-spawner",
        "spawneeClass": "ball",
        "speed": 0.16
    },{
        "type": "entity-linker",
        "linkId": "paddle"
    }],
    "properties": {}
}

"Wait! Hold up! Where's this happening!?!" you ask. Oh, right. Check out /game/entities/ and you'll see a bunch of entities created for the example game. I can add mine here as "ball-spawner.json" (and delete a few of the example entities I have no need for). Once that's done, I'll go to config.json and add its address under the list of entities.

What if the list of components isn't long enough? What if the special ability of your superhero isn't covered by a prefab component?? What if my Breakout paddle should do more than the combined abilities of the 11 components already attached to it??? (It doesn't help that my paddle has also become something of a game manager at this point, but that's neither here nor there; moving on...)

Step #6 - Create Customized Components!

Ah, amazing alliteration. Anywho, if your entity needs a bit of non-prefab-life added to it, either to tie-up a few loose ends or to entirely define the entity's very existence, make a copy of /game/components/ec-template.js, and begin molding that component into your very own creation. Once you're finished (or probably not - that whole debugging thing always seems to crop up and turn "done" into "5% complete"), add it to the list of available components in config.json and give it an id, then turn around and update the entity with the newly-created component!

The indefatigable "paddle" entity

For Breakout, I created one custom component on the "paddle" entity called "logic-paddle". It handles special things like sending impacting balls off at the correct angle, reacting to power-ups, and handling input from the player.

Step #7 - Build the Game!

Well, that was fast! We're done... ...helped by the fact that I entirely brushed over the intricacies (which I do hope to get deeper into at some point) and left out several iterations of testing and debugging (which would make for some pretty dry copy). Now that we're finished testing everything on /game/template.html, we hop on over to /tools/ (Yay! New folder!) and hit compile.bat or compile.sh depending on your OSrientation.

You'll see a series of compilation logs scroll by. If you notice any ugly errors, it's probably incorrectly formatted JSON. A missing comma typically looks not like a missing comma:

compile-json.js(96, 4) Microsoft JScript compilation error: Expected '}'

If all goes well, you'll see a new folder called /game/ in your /builds/ folder. Visit /builds/game/ in your favorite web browser and be amazed at your beautifully-crafted HTML5 game!

Step #8 - Play!

Breaking Out

Unless you don't play games. Then don't. Maybe you can find a friend or two to play it. Unless you don't share either. Can't help you there.

Who knew? I should've said "8 Steps". There you have it. 39 fewer steps than anticipated. This has been a rather high-level overview, so be sure to check out the reference and guides in the Platypus github wiki for more in-depth information.

If you decide to give Platypus a whirl, we'd love to hear what you're making! We're also hoping to make the learning curve as easy as possible, so if you run into any hurdles where things just do not work as you would expect, let us know that too! (Or, if you're in the mood, knock down the hurdle, grind it into a bunch of broken bits, pave over it with a bucket-full of awesome, and submit a github pull request.)

Which HTML5 Game Engine Should I Use?

What's the perfect HTML5 game engine for your next game? We have our biased opinion, but we'll set that aside for the moment to talk about Breakouts. Breakouts is a really cool initiative started by Matt Greer to create a single game using multiple engines. Matt (along with several other contributing developers) has created Breakout using several different HTML5 engines. As of this post, Crafty, CreateJS, FriGame, Frozen, ImpactJS, LimeJS, MelonJS, Platypus, and Quintus all have working implementations of Breakout on the site. Oh, is Platypus bold? Whoops, I'll fix that later.

If you want to check out the code involved, the development style, and features across several HTML5 engines, Breakouts is a fantastic starting point. Also, be sure to check out the convenient feature comparison table.

Introducing the Platypus HTML5 Game Engine

(Depiction of said Platypus)

We are elated to be able to introduce Platypus! Platypus is an opensource HTML5 game engine that's ideal for platformer-style games. We've been working on this game engine in collaboration with PBS Kids for some time now, and we are excited that they have chosen to open it up for everyone to use!

What is Platypus?
It's the best HTML5 Game Engine in the entire Internet! Mainly because its namesake is a duck-billed, egg-laying, beaver-tailed, venomous mammal. It also has a lot of other great features:

1. Works across both mobile and desktop browsers.
2. Simple, JSON-based configuration.
3. Component-based development to encourage re-usable game logic.
4. Uses CreateJS as a foundation for preloading, animating, and audio.
5. Uses Tiled for easy level creation.
6. Compiler supports AppCache manifest creation, PNG optimization, JS and CSS compression, and multiple builds.
7. Most importantly; it makes some awesome games! We have a few more coming down the pipe, but check out our first release using Platypus: Monkey Mayhem! (Yes, we love animals. They're cool.)

An entire RAINFOREST running on Platypus

Where can I find it?

The folks at PBS Kids have set up the entire project on Github here: http://github.com/PBS-KIDS/Platypus

Todd and I, as well as the PBS Kids team, are eager to hear you feedback and make the engine better. If you decide to try it out, we would love to hear about your experience and check out what you make!

Wild Kratts Monkey Mayhem!

Hi everyone! We're proud to announce the release of a new HTML5 title for Wild Kratts! This game was a ton of fun to work on and we were able to do a lot of really cool stuff with Martin and Chris's Creature Power Suits. Unfortunately we weren't able to test the actual power suits in-house, but we did our best to make the in-game suits almost as fun as the real thing.

The South American Rainforest is home to all sorts of animals, and the landscape is quite puzzling.

Wild Kratts Monkey Mayhem is a puzzle-platformer that you can play from your mobile browser or your desktop computer. Navigate your way through the South American Rainforest collecting fruit, looking for wildlife, and avoiding danger! Yes, your kids can play it too, so share.

 Only 140556 possible combinations.

We designed each of the 12 levels as several interchangeable sections, so each time you (or your child) play, the environment is shuffled around a bit, with a weighted preference for more difficult puzzles if you prove yourself a skilled jungle explorer. We also built a level editor into the game that lets you shuffle sections around yourself to try something new or visit a section that may not have appeared on your playthrough.

Martin gets tough.

Puzzles require that the brothers use teamwork and their unique Creature Powers to get them both through the rainforest. Try out the game for all of the amazing animal action!

It has been great fun working with the folks at PBS KIDS and the Kratt Brothers to bring this game to life!

Entanglement Chrome App

We're excited to release the Entanglement Chrome App! This version of Entanglement has all the play of the original web app but can be played outside the confines your browser, offline, any time!

Find out more about Chrome Apps on the Google Chrome Blog.

2013.5 in Review

Today's yesterday began the second half of 2013, so with that in mind I thought I would share a bit of what Todd and I have been doing the past 6 months as well as some related news.

---

We put together an awesome parallax character biography toy for Geoff Keighley's The Final Hours of Tomb Raider iOS app. The biography segment is pure HTML5 in a webview, relying heavily on CSS transitions and transforms.

Sorry, this is a screenshot, so that inviting white arrow does nothing.

---

We've also been making Entanglement more mobile-friendly: you can now find Entanglement in the Firefox Marketplace and a beta version in the Google Play Store for Android. Sand Trap also made it into the Firefox Marketplace.

---

Entanglement also made it into Peppermint Four, a nice web-centric OS that tastes fantastic!

---

Todd and I are excited to have Scott Lewis join our team. He has over 10 years of experience in the game industry, designing and developing for several titles, including Civ 5 and Rise of Nations. He also shares Todd's birthday and Todd's last name. They're also brothers, but not twins. Not that you really cared, but it's true.

---

Lastly, we've been working on an exciting project with PBS Kids that we're eager to announce as soon as it's ready. But it's not ready, so I'll share no more.

Indies: Why Make Contract Games?

On the road from a traditional job in the game industry to full-time independent game development, we have found ourselves in the position of doing contract game development for a period of time. My initial response to the idea of contract development was less than excited. I feared that it was ultimately no more than a change of bosses rather than the life-changing adventure I was looking for. To my surprise contract game development has proven to be closer to independent development than I had expected. Working with the right companies, contract work can offer many of the benefits of independent game development and act as a stepping stone toward full-time work on your own games, while providing some of the benefits of a traditional game development job.

When you order cheese puffs in bulk, you get a developer as a prize.

Why do contract games at all, you might ask. Well, it's simple. Dependable money. The independent game scene is filled with heroic stories of cash-strapped developers mortgaging their houses, maxing out credit cards, subsisting off of cheese puffs and will-power to create their dream game. While these stories make for a great read and sometimes result in an incredible windfall for the developer, they also sound like a terrible way to live and are one-shot solutions to lack of funding. Miss the mark on your first game and all you've got is debt and regret. Our aversion to taking on debt and desire for a 'normal' lifestyle have led us to take a slow and steady approach to making games. Contract games, though they lack the potential windfall of an independent game, offer a source of dependable income like a regular job. Using this we pay ourselves and by keeping our costs down we have been socking away money until we have enough to make a game of our own. With the revenue from each independent game we release we hope to slowly work ourselves off of our dependence on contract work. In this way, contract game development provides us a (relatively) steady income, similar to a traditional game development job, while providing a path toward greater independence.

Sorry Johnny, it wasn't my call.

At the same time that contract development provides revenue it also provides much of the sense of control that I found lacking in a regular game development job. As a mid-level employee at two different game development studios, I often felt like a horse wearing blinders. The extent of my knowledge of the company's direction and my role in it was limited to the task in front of me. With such limited perspective, I've frequently been confused and surprised by company decisions. I've had projects that dragged on far longer than they should have, while others were cancelled before they were given chance. I worked on a game that had its genre changed on a near monthly basis. Reasonable ideas I suggested were rejected for unknown reasons while company heads made bizarre decisions without my input, such as shoving a poorly drawn Jack Sparrow and mini-games into an otherwise coherent mini-golf game. Working in a small studio has greatly clarified the decision process that goes into making a game. With a better understanding of the decision process has come a sense of control and in-turn fulfillment that I never had when working for a large studio. While contract work still has the limitation that parts of the project are dictated by an outside force, having an active voice in the discussion makes it easier to accept even the bizarrest decision. Additionally we've found that different companies and projects offer varying amounts of freedom, and ultimately we always have a choice of whether or not to take a project. 

Entanglement iOS, does no one love you?

Since contract work provides much of the freedom and control that comes with independent development and also provides a secure supply of revenue, it offers an excellent sandbox in which to learn how to build a company. Derek and I started Gopherwood Studios without any previous business experience. This means we've made a LOT of mistakes over the last two years. Mistakes such as promising an expansion to the iOS version of Entanglement that we ultimately couldn't provide, or giving it an art style without reflecting on the target audience for the game (we still get complaints about that). And while we still make mistakes with regularity, we're much better businessmen than we were. At the same time we've had two years to build up a base of technology and knowledge that make each new project easier. While there is something to be said for diving directly into a passion project from the get-go, there is value in taking some time to work the kinks out of a business before taking a significant risk. 

That doesn't mean that you can't take any risks if you take our route, instead contract games provide us with regular chances to take risks within the confines of a project.  Each project provides new challenges and opportunities. We take advantage of each project to try out new ideas and techniques. With each project these experiments helps us to grow as developers and prepare us for future projects.

While my initial concept of being an independent developer didn't include contract game development, I've been pleased to find that it offers many of the benefits and pleasures of independent development while still offering a path toward full independence. If you've got the ability to a more direct route to independent game development, you may find yourself there sooner than us, but for more risk adverse developers contract game development offers a viable route.

I like whitespace.

New Entanglement Maps and Free Trial!

Over the last few months we've been slowly making additions to Entanglement. Some of these have trickled out over time (e.g. saved games), but this week we finally released the flood. These additions include new levels, a free trial so you can check out the new levels before buying them, and a variety of bug fixes and interface improvements.

New Levels

This update adds eight new maps to Entanglement. Putting the total number of maps at twelve! These maps are split between two new expansion sets.

The Classic Mode Expansion offers four new maps that follow the classic Entanglement rule set. The maps look pretty simple, but you'll be surprised how the shape of each map changes your strategy.

The Tranquil Garden Expansion includes four new maps that challenge players to score as many points as possible with a limited number of tiles. Passing through sakura trees will earn you more tiles. This game mode was introduced in the Sakura Grove Expansion, but here we've explored it further with some great results!

We've also added a Combo Pack Expansion for users who want to get all twelve maps for the cheapest price possible.

In addition to the new packs, we've renamed the Sakura Grove Expansion to Expansion Sampler. Though it has a new name, it offers the same three maps with both types of gameplay.

Free Trial

For players who enjoy the game, but want to try the new maps  before they buy them, we've added a FREE one-day trial. When you start the trial you'll have access to all the maps in the game for one day.

The trial can be activated from the in-game market, accessible from the main menu under 'More Maps' or from the in-game menu on the 'Get More' tab under 'Get More Maps'. Once you're in the market just log in and select the 'Try It!' button to start your trial!

If any of these additions sound interesting, try them out here!

Saving Your Entanglement Progress

Earlier today we rolled out a new Entanglement build that includes a few new features. We'll announce the bigger additions next week (or just check out the game to see the new content), but I wanted to go ahead and note one simple addition that I think makes the game experience a bit more fluid: we auto-save your game!

I know this is not revolutionary, but, in addition to the end result, I think the implementation is cool. To accomplish this, we use the Local Storage capability of modern HTML5 browsers to store a player's moves as they are made. If the browser window is closed and opened at a later time, the same set of tiles is loaded and the game replays the stored moves to return the player's progress to its earlier state. This is especially useful for mobile devices, where interrupting a browser session is a commonplace event. Now players are able to play a few tiles at a time and still finish their game without losing their progress if they're interrupted.

The cool part? Replays. By storing a particular game's seed, we are able to re-generate the exact tiles that were used the first time the game was played. Then, the game simply swaps, rotates, and places tiles exactly as they were initially played. Once the list of moves has been replayed, the game is sitting in the exact layout it was when the player left.

Using the same logic the game can replay high score games as well... ...but that's not quite ready yet. Essentially, we do not have all the necessary information from earlier games to be able to generate and replay all of them accurately. However, we did run a replay on Fast Shocking Toucan's 5195, and it's... ...beautiful!