Frogatto & Friends

Frogatto sprite Avilable on the App Store

Frogatto & Friends is an action-adventure game, starring a certain quixotic frog. Give it a try!
We're trying to push 2D platforming, pixel-art, and music into uncharted territory. We hope you like the results!
Also, Frogatto has a very flexible game engine you can use to make your own creations.

Support the Musician!

May 9th, 2013 by Jetrel


Ryan, our music guy, is also working on another project right now, called Seyken: Crystal Kingdom. I’m going to do a post about this project sometime soon, because it’s awesome, but I’d rather not rush it and fail to do it justice.

One thing Ryan’s struggled with for the past few years is a lack of decent orchestral sound libraries to work with – he did amazing stuff, IMO, with the tools he had, but he always complained about the limitations of what he was working with (in terms of expressiveness and flexibility), and a substantial part of “doing good work with lousy tools” came from carefully avoiding the weaker instruments in the libraries he had. Which is fine some of the time, but sometimes you really want to do an epic string section, and without the right tools, you can write the best sheet music for it, but crummy midi-sounding samples just won’t do it justice. Buying better ones is tough when you’re on a shoestring budget.

So with the support of this new project, he’s doing a fundraiser to get some better orchestra samples. If you like frogatto’s music – please support him in doing this, by donating to this fundraiser!

Platformer Enemy Design

January 3rd, 2013 by Jetrel

Just read a pretty insightful bit about what “Super Mario Bros” (the original NES title) did right. Like most wanna-be game-developers, I’ve spent quite a few years speculating about game-design; trying to shake out some set of principles that could describe why some games are good, and others are not. When we started working on frogatto, it was no surprise to me that there were quite a few crucial design points about platformers which I had never considered beforehand. As we worked on the game, we’ve noticed that a number of aspects just weren’t fun, and we’ve gradually tried to suss out … why?

This blog post nailed one of the precise design problems we’ve run into which I’ve been trying to address since 1.0; when we originally added the forest, cave and dungeon sections, we simply didn’t have enough unique gameplay to float them. We were short on both unique enemies and puzzles, and although the first part of the game advertised some enormous promise, the second 3/4 did not. But it wasn’t simply a matter of adding more monsters; they had to add that nebulous quantity of “fun”. I actually burned quite a bit of time figuring out what the hell ‘fun’ even means when you’re designing videogame enemies; there are at least 10 partly or un-animated monster designs that have been prototyped, but which we’ve wholly axed between then and now because they just weren’t fun.

I think one of the big things it started with, which is an excellent foil for exposing the mental traps that underlie almost all of the other problems was an idea that monster viability should be independent of the level around it. It was in fact a bad idea. Do not try to design creatures which can work in any possible level layout; it’s possible, but it’s enormously complex and time consuming, and it doesn’t add a lot of benefit. There are a number of reasons people fall into this trap:

If you’re also a general engine project like we have been at some points in the past, the philosophy of generality bleeds over. When you’re designing a general engine or a general game editor, you can fall into a trap of wanting to insulate against all possible “bad surprises” for your users. If a user places something, they shouldn’t have to know anything about it; it should Just Work; it should negotiate all possible mismatches/design-incompatibilities/whatever to just magically figure out its setting, adapt, and function the way the user imagines it should. This is how, for example, vector art behaves in an otherwise internally raster-based program like photoshop; it’s a square peg going into a round hole, and the glue to make it “just work” is considerable.

For one example, consider making a flying enemy with basic behavior that makes it fly from one X position, to another X position. In a generous, open space with no terrain in the way, writing this is trivial; you give it constant acceleration, and make it reverse direction once its position exceeds a certain value. Easy. It seems reasonable, from a level-designer’s standpoint, that it should always work regardless of the layout; all it’s doing is just pathfinding from point A to point B, right? So if you put it in a twisting corridor, it’ll naturally duck under the outcrops, and rise over ridges to find a path back and forth. Except actually it won’t, because in the implementation I just described, there is no pathfinding. There’s no AI; there’s just one, single line of code with two conditionals in it.

The pitfall, there, is assuming you’re catering to that imaginary user with entirely reasonable, but difficult-to-fulfill expectations. You’re not; you’re writing a game which has an almost certain probability of being edited by only one person, and in the absurdly unlikely event your game DOES become popular with a modding community, you should assume that modders will have a high correlation between cleverness and productiveness (those who are baffled when a monster doesn’t work right in certain circumstances will have a lot of difficulty getting a great deal of other things done, and aren’t likely to get anything done), you should remember that it can always be improved later, and more than anything, you should remember that there won’t be a modding community in the first place if you don’t ship a game they can become fans of.

Apart from bending over backwards to please a hypothetical user, the other idea that can lead to overbearing generality is an idea that you, yourself will benefit from being able to use that same creature everywhere. There is truth to this – one really good, really clever enemy can get some great mileage … but it depends on whether it changes gameplay from the player’s perspective. Most specifically; is the player being forced to make different decisions than usual in order to deal with this threat? At it’s most basic level, a game is a series of interesting decisions*; if you do a boatload of work on an enemy to make it work in different situations, but the basic decisions the player faces are still the same, you’ve wasted your time. The basic gameplay is still the same; you’re just jumping through hoops to provide it. At worst is when you do something enormously difficult to implement, and (perhaps due to the enemy generally being offscreen), it’s entirely invisible to the player whether you did or didn’t do it.

Perhaps most tragic is when someone has a personal vendetta against something that disappointed them in their youth; say, using a Doom level editor and finding that some creature just glitched out in some situation that never happens in the real game, but happens in the particular edit you were trying to make. As a starry-eyed kid, you think “These guys were so lazy to have not fixed this obvious flaw. By golly, when I grow up, I’m gonna do this right when I make a game!” This sort of thing typically is called a sacred cow – it’s a rule you follow and never question, but it’s a rule that you made when you were a pretty naive kid, and you didn’t base it any thought about game design; you based it on strong feelings of disappointment – even if it worked flawlessly the way it was meant to be used, and provided wonderful entertainment for you the other 99% of the time. The danger of the ‘sacred cow’ is it’s namesake – is your refusal to remove something that is very costly to you. You’re now an adult; it’s time to put away childish things.

Sacred cows can bleed out into being more general gameplay mechanics; one which we held onto for quite a while was that all creatures in the game occupied strict rectangles of solidity. Unless a creature was somehow literally ethereal (like a ghost), we intended to make sure that all creatures followed physical rules; they can’t cheat and go through walls, and if multiple instance of them are in too tight a space, they can get congested and form a traffic jam. We abandoned this ages ago (shortly after 1.0), but earlier on, this caused some enormous mental blocks. The greatest tragedy behind this was we couldn’t provide any concrete reason why ‘realistic behavior’ made the game better; we simply had a personal vendetta against the idea (perhaps it felt like cheating on the computer’s part when we first encountered it in a game?) and we were determined to avenge that slight. What a waste.

It’s basically cost/benefit analysis, with one key idea: always remember your goal is to ship this game. Not to make some modder’s paradise. Not to make the perfect system. Not to write the next GameMaker or Unity. If you’re too naive to settle for the extraordinarily impressive feat of just shipping a game, I can’t help you. But if you’re mature enough to have already settled, the mantra can’t be repeated enough, because it’s so easy to slip back into these traps.

The way this hurt frogatto ironically wasn’t because we spent a lot of time writing something astronomically complex, but it hurt us because I wrote-off a whole panoply of monster ideas as not worth pursuing because they were insufficiently general. I saw a few cases where a given design would be hopelessly, hilariously inept, and decided that if there was anything in the game that could ‘bluescreen’ a given creature, the whole design of the creature was flawed and shouldn’t be considered, period. It seems to me that almost all cases where I have some sort of writer’s block or difficulty brainstorming are because there’s some internal “governor”; some ruleset in my head which I’m not fully aware of, discarding ideas before they’re fully formed. When this is in effect, I try to brainstorm about something and it just seems like “there aren’t any good ideas to be tried”; as though the problem lies in an exhausted possibility space rather than my dismissive perception of it.

So here’s a list of things that blog post touched on which are good design points for platformers – I think the mental self-analysis above is more important for deriving these from first principles, but these are worth hashing out a list of if you’d like cliffs notes:
– monsters need only work in one well-suited level layout geared towards them; it’s entirely okay for them to glitch out or just be helpless in others. Just don’t use them there.
– allow monsters to cheat and do things like pass-through-walls (c.f. our bats) if their physical limitations stand in the way of a fun enemy design.
– monsters need to vary on multiple dimensions of behavior; it’s fine to pick a few easy-to-do behaviors like giving them more HP/Speed/Damage, but each of these can only be used once. In fact because these particular easy-to-abuse ones are incredibly common and familiar to gamers, these have very little mileage, and you should really only do one “same but better” variant. Two is pushing it.
– aim for interesting effects that can be achieved with implementation simplicity, and if possible adjust the level to keep their implementation simple.
– simple behaviors can get much better mileage with slight twists. Tweaking a shooter who’s a sitting duck on flat ground to be able to shoot down from an inaccessible, high position the player can’t retaliate towards, can grossly extend the life of your current content.
– You can make the game feel deeper; i.e. you can fake complexity, by combining similar twists with different environments; a basic idea like an enemy that jumps should be put to use on two different enemies in sufficiently different levels that the threat posed is completely different. If you make this second monster look completely different, and have different timing/etc, it will feel much more different than its implementation actually is. Ideally it may feel entirely different even though internally it’s mostly the same.
– enemies can and should be combined to make much more challenging puzzles; one enemy can provide a necessary means to defeat another enemy (tricking two enemies into shooting each other, or one enemy providing ammo to defeat the other). Another twist is that if you place enemies together, don’t just haphazardly combine them, but put enemies whose particular abilities don’t contest each other. Putting a shooter who can fire shots down at an area with a walker (making you dodge whilst you deal with the walker) is much more interesting than just two different walkers.
– make enemies which require entirely different actions to defeat. If you’re a shooter, make some enemies that are entirely immune to being shot at with any weapon whatsoever, and which instead need to be dealt with with some different gameplay verb entirely (perhaps the player has to perform some physical move in the game to them (jumping on them, or kicking another enemy at them), perhaps they have to be led into traps or pitfalls. Perhaps they have to be led to mutually destroy each other by causing them to aggress against another monster rather than the player (caused maybe by one accidentally shooting another in the back).

I expect I’ll probably need to write a follow-up to this. As it stands in the game right now, I’ve been working hard to differentiate monster designs, but there are definitely a couple early enemies (which is a bad first impression) that are painfully similar; the closest are the ants, and the beetles (both the regular and water-beetle variety). I had an idea that the former could die from being jumped on and other could bounce, but I feel like something more interesting could done (new animations like flight are on the table as an option). Fumpers and rabbits are close enough to squeak by, although I should be careful to avoid making future designs that work too much like them. Some mechanics that are dying to be exploited are mutually-destructive enemies (moth-bombers being our only example), and enemies that strictly require powerups to kill (shooting the wings off high fliers being an only current example).

Tangentially related, but there’s also another worthwhile post which is targeted at RPG design but actually applies just as well to platformers.

* (credit to Sid Meier)

Cube Trains Released!

December 7th, 2012 by DDR

Cube Trains 1.0 is done, and available for download from It is a puzzle game about laying train tracks through a city, in 3D. It’s also free.

There is no limiting mechanism on the number of pieces you can place in a level, except for how many you can fit into a given area. While some games, like Isoball, will give you a set number of pieces to solve the level with, this merely limits the fun. Cube Trains lets you build as much as you want. Of course, there is some difficulty — it’s quite hard to actually beat a few of the levels, as there is barely enough room for you to build what you need to. In addition, each piece you use raises your score, and you may want to complete levels with the lowest score.

The game also features infinite undo and redo, along with the automatic placing of “obvious” pieces. This makes things much more convenient, in the long haul. If you’ve ever wanted to undo the last action in Sim City or Civilization, this feature is dedicated to you.

Cube Trains was made with the Frogatto engine. Because of this, it should be able to run most everywhere Frogatto runs. Currently, however, it is only really available for Mac OS X or Windows as you have to compile it yourself on Linux.

Download it here.

Update Regarding 1.3 Release Candidates

November 15th, 2012 by Jetrel

We’ve updated our most recent post with new mac and windows builds that fix a major bug that cropped up. If you started playing on challenging, the bug would end up changing the difficulty back down to casual, when you died and respawned. Since having another difficulty level is a cornerstone of this release, if you’d already downloaded the previous one and feel like challenging doesn’t change anything, you probably want to download again.

This is especially embarrassing to us since we’ve put so much time and effort into having another difficulty level. It seems that the reason we never found it is that almost every time we tested the higher difficulty, we used a special commandline option to jump-start the game on a level later into the game, with higher difficulty (allowing us to test the game in segments). Because this option internally works in slightly different way than our difficulty-selector screen, it prevented the “revert to casual” bug from happening to us. There are several lessons to be learned about software QA here. 😐

Thanks for sticking with us, sorry if that bug means you needed to download again.

Frogatto 1.3 Release Candidates

November 10th, 2012 by Jetrel

We’re almost done with 1.3 at this point, and we’ve got a mac build and a windows build ready for final testing (linux users will need to compile from source). If you’re interested in testing, please download these and post about any bugs on our forum! We don’t have the mobile versions of 1.3 done yet (we’re fixing some last few bugs that are mobile-only).

We have screenshots up for 1.3 if you’d like a peek at what’s to come. There are also several great new songs in 1.3; this is the new centerpiece for seaside (seriously, I ****ing love this song), this one kicks off the forest area, and this is the new theme for frogatto himself.

In this release candidate, we’ve included all translations, even those which are currently mostly-unfinished; we’re going to ship the final version of 1.3 without the unfinished ones. If you’d like to help out with translations, you can read a guide on helping out, and can chip in on our transifex page, which lets you look at a side-by-side listing of the original english lines, and blanks you can fill in with a translation to your language.

Thanks in advance for all your support, guys!

Shaders in Frogatto

October 28th, 2012 by Sirp

I’ve been playing around with some OpenGL shader features in Frogatto. Here are some videos showing what I’ve come up with:

Translator Quest

September 30th, 2012 by marcavis

So, over the past few weeks, we’ve been edging closer and closer to releasing a new Frogatto version.

There have been plenty of changes since the latest version – some under the hood, but also we’ve been improving the content on several fronts – better balancing, new enemies, new songs, and much more.

So, as Frogatto 1.3 is better than ever (but not as good as 1.4 will be, later on), we’d love to make the game accessible to as many people as possible. There’s only so far we can do that by ourselves, though – translations are key to let us reach a wider audience. Can you help us with that?

If you have a solid grasp of a language to which you’d like to translate Frogatto, check out our page at Transifex, which is where our translations are managed:

There are also some guidelines to the translation process in this forum post, so check it out, too.

Realtime Images

September 3rd, 2012 by DDR

Recently, we’ve added a brand-new feature to our editor. Images now get reloaded in real-time, while you’re playing the game in the editor.

If you’re an artist and you’ve spotted a tiling bug with some part of the ground, you don’t have to stop playing (and loose your position) to fix up the error. You just edit the source image, save it, and there it is in-game. This is especially useful when creating animations, since you can see the animation as it is played in its natural environment. It’s also quicker – animating with a live preview is much better than animating in a situation where you have to wait for everything to load before you can see the results of your efforts.

This also has implications if you’re prerendering your art. I’ve been working on a little project for the past few months which uses Blender 3D to render the graphics. In the following video, I demonstrate the results of telling Blender to output its rendered images to the game’s graphics folder. (The change is a bit exaggerated, but it’s to make a point.)

Although there is a bit of a delay in rendering, the time cut off having to start up the game to see the results are very nice. This technique also works with spritesheets, although the script to compile the spritesheet has to wait for all the images to be rendered before compiling the final image.

This is all free, open source software. The Blender file, the game, and the Anura engine can be found over on github. If you’d like to get started using our shiny engine, drop us a note on the forums or talk with us via internet relay chat.

An early beta of Cube Trains is available from

Graphics News #20

August 26th, 2012 by Jetrel

We’ve done a total overhaul of the forest ground tiles, similar to what was done to the cave tiles. In these screenshots you’ll also see the new foreground art, some minor enhancements to the background, and a third palette used in the forest. There’s also a much-needed overhaul of our old, ugly fountain art, which now meshes nicely with the level tiles.

Making some friends

July 1st, 2012 by Jetrel

I’ve decided to occasionally link to other indie/semi-indie games I’ve been playing and enjoying, just to share the love. Reciprocity would be cool, but honestly I wouldn’t be surprised if quite a few of these people don’t even notice the linkage. I’m just doing this for the good of the indie game scene.

This might seem odd, but I’m really not afraid of “competition” – I don’t think other indie games would stop people from playing Frogatto. The cost isn’t exclusionary on mobile games, the time taken by story-driven games leaves you with plenty of time to play the others, and I just think there’s so much more to be gained by cooperation. There’s a short supply of really well-made indie games, and I want to see our art form thrive – I want to see other teams, who’ve put their heart and soul into it, succeed.

Pizza Boy:

So the first one is a game I’ve been playing on my iPod called Pizza Boy, which is a platformer, but is really, really different from Frogatto in almost every way. It’s very much in the Mario Bros vein of things – rather similar physics, timed-levels, worlds with four stages, and a lightly-handwaved story. It also shares the mario trope of killing enemies by jumping on their heads (which we use somewhat sparingly in frogatto).

Pizza Boy is made by Acne Play, an offshoot of a Swedish design studio which seems to be increasingly branching into game development. (No, we don’t know these guys personally or anything.)

The whole game is built around some pretty tight platforming challenges, where each level is an exacting sequence of running and jumping sequences you have to figure out by trial and error, and then play back with crackerjack timing (quite unlike frogatto, which generally allows you to stop and smell the roses). Unlike mario, it’s quite forgiving because you can start at any level you’ve been on before (which probably defeats the purpose of having ‘lives’, but there they are anyhow). I like it – it’s frustrating, but frustrating in a good way.

One thing that’s great about it is a common mobile-game trope – there’s not much you have to remember (as you would in a complex, story-driven game like an rpg), so it’s really easy to get into if you’ve got a few minutes to kill. You don’t have to re-familiarize yourself with some big complex set of info (like, say, which items you’ve acquired, or which quest you’ve completed). I know from personal experience, that this can be a bit of a bugaboo if you haven’t played a game for several days or weeks (I definitely have had at least one RPG I’ve entirely started-over because I lost track of what I’d accomplished). I don’t wish all games were like this, but it really is nice for some games to be immediately accessible.

Also interesting to see another title doing the Left/Right controller scheme, rather than a full virtual Dpad. Seems to be gradually becoming an accepted/best practice for these kinds of games. We adopted it quite a while back (I believe sooziz was the title that inspired us to do so), because having up/down arrows between L/R, or having a full, plus-shaped dpad makes your touch areas for the side keys way smaller, and especially the U/D between L/R setup makes it possible to hit up or down by accident when “hat-switching” over to the opposite side – in a lot of games, this can really trip your character up.

So there’s Pizza Boy. Check it out!