I’ve started work on implementing multiplayer support for Frogatto. We think there is great potential for multiplayer in Frogatto:

• Races: levels where players must race each other to the end
• Deathmatches: levels where players must defeat/kill each other. These will probably be done with some kind of twist, such as only able to hurt the other player by picking up objects and spitting them at them.
• Co-op play: levels where players must play together, helping each other to win.

Of course, none of this can be done until we have the foundation of a solid multiplayer experience in place, so that’s what I’m working on. The big goal is to provide an experience where the game continues to run at 50 frames per second, with little or no perception of lag.

To achieve this, the connection between two machines has to have as little latency as possible. We want to use a peer-to-peer system where each machine in a game has a direct connection to other machines. To achieve this I’ve implemented UDP Hole Punching so that even machines behind firewalls can establish peer-to-peer connections.

I think that a reasonable goal is that two machines which can get a round trip ping of 100ms or less should be able to play a smooth game of Frogatto. This means that two people who are both in North America, or two people in Europe, can probably play a game, as long as they have decent connections. A trans-Atlantic ping under 100ms is unlikely though, so, players on different continents will probably have some lag. Because of this, a secondary goal of the system will be to degrade as gracefully as possible.

So what does the architecture of multiplayer look like? There are a number of ways we could implement multiplayer: one would be to send position and state information about many of the dynamic objects in the level across the network. This could be made to work quite well, but uses a lot of bandwidth, and would be somewhat laggy. It would also be significant overhead to implement: every time we add new state changes for objects, we’d have to worry about making sure they get synchronized across the network properly.

Instead, we choose a different approach: in Frogatto we’ve worked carefully to make sure that all actions taken are deterministic based on their input. That is to say, if you play a Frogatto level multiple times and press the same buttons at exactly the same times, your play through will be exactly the same.

This means that all we have to do is send the other machines the button presses we’re making on our machine and the games will remain in-sync. Of course, sending a message will take some time, so in multiplayer we can’t quite expect a key press to be instant. Fortunately, we’ve done some testing and found that if we introduce a 60ms delay before a key stroke is recognized in Frogatto, it’s bare noticeable, and if we introduce a 40ms delay, it’s not noticeable at all.

So, in multiplayer, when a keystroke is made, the game will delay the time before it is put into effect by a small amount of time. When the game is started, the peers will do some tests to estimate their latency. Based on their latency, the keystroke delay will be determined. Hopefully the delay chosen will be as small as possible while still allowing packets to arrive in time.

It’s also very important that games start in synchronization — at the same time. If one system is ahead of the other, then the system that is behind will be less likely to get its data to the other system in time. So, when the game is started, the hand shaking process does its best to co-ordinate the systems to start the game at exactly the same time.

Now, it’s always possible that packets will get lost or arrive too late. Every frame we send a packet with the keystrokes for the current frame, but we also send the packets for previous frames. Additionally, we tell the other systems the furthest data of theirs that we have confirmed, so systems know they don’t have to send data for frames earlier than this. This takes care of redundancy.

Now, there is the problem of a machine getting to frame N, and only having keystroke data from its peer for frames up to frame N-1. When this happens, the machine simply waits to calculate and render the frame until it has the data. Hopefully the data will arrive within a few milliseconds, and we could possibly catch up with little or no problem. But sometimes it doesn’t. When this happens, the machine will lag, perhaps significantly. Then of course, it will be behind the other machine, and it’s likely the other machine will have the same problem.

Because both machines will be forced to lag, if it’s due to an intermittent network problem, hopefully the problem will correct and we’ll quickly get back to an equilibrium. Of course, sometimes there might be too many problems — late and lost packets — to continue at all, in which case we timeout and the game is terminated. Most of the time though, the game may be continued in some form.

Code to do all this has been checked into SVN, and Jetrel and I played our first multiplayer game last night. Hopefully in not too many more releases, it’ll be ready for prime time! 🙂

Very dramatic upgrade to the basement tiles. They key nuance lies in the distribution of the back wall weathering; it needs to have very large, and very randomly-shaped patches of bare, unweathered concrete, with only the occasional bit of crumbling/weathering. This tileset will really come to life once we get some decorative overlays, like metal pipes, grates, and such, but those are still in the works.

For those who are wondering, we’ve switched to jet black as the interior fill color for solid tiles, in order to make our water lose those nasty visible borders you’ve likely seen in previous versions. Not merely iPhones, but many computers were lacking the blending mode we’d really wanted to use, and this allows us to use a much simpler overlay (simply a photoshop-style ‘darken’ blending mode) and still achieve the intended effect. What’s more, this solution has no corner cases, unlike the old one where a given water color would only look nice on a specific fill color, and mismatched the others.

I’ve gone over the forest canopy tiles, and made them much more organic, as well as working on some additional branch parts. Additionally, there are now underbrush tiles for the forest, although if you’ve been following progress on our forum, you’d have had that inside news already. 😉

Frogatto has been ported to Palm Pre by Wulven Game Studios (the same people who brought Wesnoth to iPhone), and is now available for sale!

We’ve also lowered the price on the App Store to only $0.99!

Frogatto 1.0.3 is released and available on the Download page for Mac and Windows (and whatever you can compile it on). This is a very minor update, but important nonetheless. It fixes a bug in 1.0.2 which caused the game to crash any time you got a partial heart capsule (thanks to Lila for reporting it). Since the bug was noticed before Apple approved 1.0.2 for iPhone, the iPhone version will skip directly to 1.0.3.

Enjoy!

There’s a new version of frogatto out, which is mostly a small set of bugfixes. It’s available for computers on our download page, and will be available for iPhone after we finish testing.

Here’s a short list of changes:
* Added customizable controls.
* Made it so you can skip dialogs sequences (by pressing escape).
* New pause screen including music and sound volume controls.
* Added half-hearts.
* Made player status not show on the titlescreen or world map.
* Made golden ants less ambiguous.
* Updated music.
* Pressing jump while in the air pressing against a wall now makes you cling to the wall.
* Improved forest background, and made it go upwards infinitely.
* Changed tilesets to make water blend better against rock/wall edges.
* Fixed bug where a dialog could repeat forever.
* Fixed crash in world map when you hold down while entering it.
* Fixed fullscreen mode.
* Fixed controlpad issues.
* Fixed a few z-order issues.
* Many small bug fixes and minor level changes.

This past several days, I’ve been engaged in polishing up the forest background. The forest background that shipped with 1.0 was unsatisfactory to me; many elements of it were barely better than sketches, and the far-distant portion of it was a boring monochrome. However, we shipped with it because it didn’t affect gameplay, only aesthetics, and we believe in RERO (release early, release often).

Here, you can see a side-by-side comparison. (Click to zoom in.)

Probably after our upcoming update, I am looking into doing some major additions to those interactible/standable trees, adding a much larger variety of branch elements, and if I have time, perhaps even adding some variants on the tree trunks (wider, thinner ones). I’m also planning to flesh out the foliage tiles a bit.

I’m well aware in writing this that I haven’t written that primer post I’ve been meaning to write describing what MTPs are. I’m going to try and pretend I’ve done so already so as not to clog up this post, and will fix that retroactively.

To sum it up, though a “multi-tile-pattern” lets you define a tile pattern that’s drawn across more than just one 16×16 tile. It allows us to draw elaborate set pieces that will be put onto a level if the underlying tiles are laid out a certain exact way. For example, it’s what allows us to draw the “obviously larger than one tile” corners of the house interiors. Remember – everything in frogatto is auto-tiled, so this means those large set-pieces will just “appear” if you arrange the tiles the right way.

A key problem we ran into was scaling for the work-time of the guy scripting them (me). These multi-tile-patterns had to have each individual tile in them, specified by hand. For a little 2×2 house corner, this was trivial. For a huge 3*5 layer of plants, with two layers of graphics, and with an alternative graphic option, this time-cost exploded exponentially. This, for example, is the tile pattern for a center section of grass (as seen in the first section of the game):

Read the rest of this entry »

One thing we’re working on for Frogatto is “arcade style” levels. Arcade style levels will be never-ending levels that are randomly generated, and which have making a high score an objective. We’re hoping this will allow for a fun alternative way to play the game.

As part of this, I’ve added some nice support for making randomized levels to the Frogatto editor. The editor allows you to split levels into segments, just like this:

The yellow segment in this screenshot is the currently selected segment, and then the red segments are all segments which can go directly after the selected segment. Then, Frogatto Formula Language commands are available which allow the level to order the segments randomly, making sure that one segment only follows another where appropriate.

Of course, in some cases we might need to augment this basic logic with a little more sophistication: making the game get harder as the player goes further, for instance. But this can always be done by adding FFL to the level.

Hopefully with this system in place we’ll be seeing some fun arcade style levels in future versions of Frogatto.

Frogatto is only $0.99 in the App Store for 3 days! Now that 1.0.1 is out, and all significant technical problems should be fixed, we’re really trying to get the word out!

The sale ends when Apple decides it’s the 11th (which might be at about 11PM EST on the 10th).

Since Frogatto started selling on the App Store, we’ve had mostly really positive feedback (which has been great!), but there’s also been a lot of complaints about the controls; ranging from “needs some work” all the way to “horrible!”. At first our reaction was along the lines of “well that’s too bad, but there’s not a whole lot we can do about it…”. A few days later though, I was looking at the code, and discovered that the active areas for the controls were not at all what we thought they were.

When a finger is touching the screen, the iPhone only tells your program about the center point of it; nothing about the area of the touch. Because of this, you generally want to make the actual active area of buttons on the screen bigger than the image that’s displayed for them (because people expect a button to work even if just the edge of their finger is touching it). We thought that we had done this, but what I discovered was that not only were the active areas of our controls not bigger than the images representing them, they were significantly smaller! Here’s a screenshot showing the control buttons, with their active areas overlaid on top (also note the much improved arrow graphics):

One person said it seemed like we hadn’t even tried the game before submitting it to the App Store, but in fact, the opposite is true: we tested it so much that we all got used to it and thought it was fine. Another person said that it seemed like we got lazy near the end of development, which is almost true, but not quite – we didn’t get lazy, we just rushed it a bit. It had been over 2 years, and we just really wanted to get the game out there. We fully intended to release updates after 1.0 though, and that’s what we’ve done; last Friday (July 29th) we submitted a minor update, 1.0.1, which Apple will hopefully approve soon.

As you can see, the active areas in 1.0.1 are much bigger, which should make them a whole lot easier to use. The water controls have also been improved a lot. They look the same, but the active area of the circle is now 2.4x the size of the circle you see, and once you put your thumb down inside it, it will work until you lift it up again, no matter where you move it to (suggested by howiedeano on the Touch Arcade forum).

Besides the controls, a lot of people complained about lack of auto-saving. We did actually make auto-saving (we agree, it’s important!), but none of us have a device new enough to support iOS4’s multi-tasking, and it turns out it didn’t work with multi-tasking. This should be fixed in 1.0.1 as well (by simply disabling multi-tasking for Frogatto), along with a bunch of other less significant bugs. Hopefully this will fix all the significant technical issues, and we can get back to improving the rest of the game!

Update (08/06/2010): 1.0.1 is on the App Store now!