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.

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.

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):

To help people visualize, this is the tile sheet being drawn. We’re drawing the stuff inside the red boxes. The very short boxes are a foreground overlay – everything else is behind frogatto. Because frogatto’s feet never reach below a specific height, we only needed a 1tile tall overlay. The bottom two boxes are “alternates”; at times, they’ll be randomly used instead of the first set of boxes, to make stuff less repetitive and more organic.

This whole pattern will get used when the game detects a grass tile at the left end of of a row of grass tiles. It gets drawn slightly-offcenter, over that tile.

[multi_tile_pattern]
chance=100
pattern=" ->tile1 , ->tile2 , ->tile3 ,
->tile4->tile4fg, ngs->tile5->tile5fg, ngs->tile6->tile6fg, ngs
->tile7 , ->tile8 , ->tile9 ,
->tile10 , ->tile11 , ->tile12 , "

[tile1]
image=tiles/plants.png
tiles=00
zorder=-4
[/tile1]
[tile2]
image=tiles/plants.png
tiles=01
zorder=-4
[/tile2]
[tile3]
image=tiles/plants.png
tiles=02
zorder=-4
[/tile3]

[tile10]
image=tiles/plants.png
tiles=90
[/tile10]
[tile11]
image=tiles/plants.png
tiles=91
[/tile11]
[tile12]
image=tiles/plants.png
tiles=92
[/tile12]
[/alternative]
[/multi_tile_pattern]

Yeah. This makes it a pain in the ass to change stuff. And it’s dumb, because in “plain english”, all we’re doing is telling the game to “draw this single, large rectangular section of 12 tiles from our tileset.”

So we made a shorthand to do precisely that:

[multi_tile_pattern]
chance=100
pattern=" ->tile1 , ->tile2 , ->tile3 ,
->tile4->tile4fg, ngs->tile5->tile5fg, ngs->tile6->tile6fg, ngs
->tile7 , ->tile8 , ->tile9 ,
->tile10 , ->tile11 , ->tile12 , "

[range]
image=tiles/plants.png
from=tile4
to=tile6
tiles=a0
[/range]
[/alternative]
[/multi_tile_pattern]


Much better.

The specific meanings of the FML keys there are:
from= and to= indicate the upper-left and lower-right tiles in the pattern=”"

tiles= indicates a position in the tilesheet. The first character indicates row, the second, column (reverse of the usual order). They’re written in (IIRC) base-52, so that indicating a position is only one character long. The position indicated here is the upper-left-corner of the range; the lower-right corner is derived, you don’t need to (indeed, can’t) specify it.

The other FML keys will get covered in my primer on MTPs.

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.

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

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!

Seen at http://www.apple.com/downloads/macosx/games/

In fact, holy smokes, it’s even on http://www.apple.com/downloads/

If anyone involved in making that happen is reading this – THANK YOU! You guys kick ass!

We’re having an introductory sale with 60% off the planned regular price, so get in fast!


[animation]
id=lookup
rect=37,233,68,265
frames=1
duration=3
reverse=yes
[/animation]


FML, like WML, works very nicely for describing data. However, in Frogatto we really wanted objects to have very flexible behavior — for instance, consider all the complexities of an object as simple as an ant in Frogatto. It has to walk back and forth, fall off cliffs for a red ant, but turn back for a black ant. Then when it is spat out it has to fly through the air, bounce off surfaces, finally ending up on its back and then spring back onto its front.

Describing behavior like this in FML would be far too awkward, at least without hard wiring a lot of core behavior into the engine, and we really wanted Frogatto’s engine to be a very general engine.

So, in addition to FML, Frogatto has an embedded language called Frogatto Formula Language (FFL). FFL is designed to work like a mathematical formula. That is, a formula has inputs, makes calculations, and then results in outputs. A formula itself can’t actually do anything — that is, it can’t modify the environment around it — it can only return a result. Just like a mathematical formula.

Let’s jump into an example of how this works in Frogatto. You know those big metal balls that are thrown by the psychotic bunnies? Here is a (slightly simplified) code snippet which controls what happens when they collide with a wall:


on_collide="set(velocity_x, -velocity_x/2)"


This is taken from the metal_ball.cfg file which defines the metal balls. Now, the first thing I want to note is that the on_collide=”…” part that surrounds this is FML. ONLY the part that is inside the quotation marks is a formula; a formula written in FFL. This defines the event handler that is run whenever the object receives a “collide” event.

What the formula is designed to do is cause the ball to be reflected off the wall, but its velocity dampened by half. One important thing to understand is that the formula itself does not modify the object’s velocity: a formula itself cannot modify its environment. Rather, the formula is evaluated and returns a command object. The game engine executes the command that the formula returns. In technical terms, this makes FFL a pure functional language.

There is an entire API of functions that are exposed to the formula system that will create different commands to return to the engine. The set() function, which creates a command to set the value of an object property, is probably the most useful, however there are a whole host of functions such as spawn(), which spawns a new object (useful, for instance, for an object which shoots projectiles), a teleport() function which allows teleporting the player to a different level, and so forth. The game engine actually comes with a utility that outputs all of the available functions.

Of course, in addition to functions that can create commands, to do useful things we need to be able to inspect the state of the game. For instance, in the above formula we had to read the object’s “velocity_x” property to find its horizontal velocity. When an event handling formula is executed, it gains access to all of the properties of the object receiving the event. Objects are pretty complex entities, and they have properties ranging from their velocity and location, to their hitpoints, current animation, a store of user-defined variables, the level they are located in — from where you can access all the other objects in the level — and so forth. Fortunately we have documented all the available object properties.

Now that we’ve seen the basics of formulas, let’s look at a slightly more complex example. This is how the Frogatto object handles collision with a wall:


on_collide="[set(velocity_x, 0),
if((animation in ['jump', 'fall']) and can_slide(self) and abs(velocity_x) > 200,
[animation('slide'), set(velocity_y, 0)])]"


First things first: this formula returns a list of commands to execute rather than a single command. Lists in FFL are delimited by [ and ]. The first thing this formula does is simply sets Frogatto’s horizontal velocity to 0 when he collides with a wall — if you run into a wall with Frogatto he simply stops rather than bouncing off.

The second part of the formula is to handle Frogatto’s ability to grab onto walls if you jump into them. It makes use of the if() function which is a built-in FFL function. if(cond, x, y) will evaluate to x if cond is true, and y otherwise. You can also use simply if(cond, x) which results to null if cond is false.

We can see that Frogatto will only cling onto a wall under certain conditions — if he’s in a jumping or falling animation, if a custom function defined as “can_slide” is true, and if his horizontal velocity has a magnitude greater than 200. If the criteria to cling onto the wall is met, we will return a command for him to enter his slide animation, and a command to set his vertical velocity to 0.

As we can see, FFL is fairly powerful, but hopefully not too difficult to understand. Using it, we can define objects which have all kinds of sophisticated behavior. Of course, another key element is understanding what events are triggered on an object. We have events that are triggered automatically, periodically, events that are triggered upon collisions of different types, events triggered when the level is loaded, when the player first approaches an object, and so forth. All the events are documented here.

I’ll give one more example of the kinds of things FFL can do:


timer_frequency=50
on_timer="[set(brightness, brightness*4), schedule(5, set(brightness, brightness))]"


This makes it so a ‘timer’ event is received by the object every second. (Frogatto runs at 50FPS). On this timer event, the object is made to be four times as bright as normal for a tenth of a second (five cycles). Note that use of the schedule() function. What schedule does is takes commands and schedules them to be run some number of cycles in the future, rather than right now. So, we are setting brightness to 4x what is it now, and then scheduling it to be set back to its current value 5 cycles in the future.

Note how the entire formula is evaluated, and THEN the commands are evaluated.

FFL is a general formula language, and though its main use in Frogatto is for object events, that’s not its only use. It is also used, for instance, to draw the HUD which shows Frogatto’s status, health, coins, score, and so on. In that context, FFL is still used but it has access to a different set of properties and a different API — an API designed for drawing elements of the screen rather than controlling objects. It’s also used to allow custom scripts that can be used in the Frogatto editor. One can write a script in FFL that applies some effect or another on a level — such as rounding out a cave level, or adding trees to a grassy level. One could even write FFL to try to make an automatic level generator!

I’m hoping this gives a good overall view of FFL, and what it can do. The Frogatto engine is very moddable, and we’re hoping people will try to develop their own concepts — from fixing bugs in Frogatto, to adding new features, such as new objects or better behavior of existing objects. But one could also implement a completely new and different game. We very much welcome people trying to develop their own game concepts with FFL — if you do please come and share them with us on the forum. Good exercises would be to implement a game in the vein of Pong or Space Invaders of Pac Man.

Frogatto also contains a fully functional editor that allows you to create your own fun levels or edit existing levels. The engine is heavily moddable, and as an Open Source game we welcome new talented contributors.

After trying Frogatto, consider visiting our forum to discuss the game.