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.

A response to Gaslamp Games’ “The Colors of Frogatto”

June 19th, 2013 by Jetrel

Quite a while back, the lead art dude over at Gaslamp Games did an article praising frogatto’s colors. Which … frankly, is just incredibly awesome. Appreciation from people whose work I admire is frankly one of the most flattering things that can happen to me. I’d been meaning to do a kickback on this for quite a while (I’ve had a half-finished draft of this post sitting around for almost a year and a half now), but never got around to it.

I figure that now is a good time, since we’ve recently done an overhaul of exactly the colors he talked about, in 1.3 (and especially since we now have something like 20+ different environment palettes where we used to have 4). Hopefully I can return the favor by getting some good discussion going, and telling what I know, for whatever it’s worth.

The state of the game as he reviewed it was the game as it appeared in 1.1 and earlier – as can be seen in these screenshots. The current look of the game can been seen in our current screenshots. I think the most striking bits were the overhaul to the seaside background and base palette.

Notice how much warmer the lighter colors are – the green and brown are pretty much the same shade of yellow at their lightest, while the stone’s gray takes on a noticeable brown tone at its highlights. On the other end, the green cools down even to the point of using a shade of blue while the stone goes toward a more neutral (and relatively cooler) gray.

The use of yellow as a (frequent) highlight color is because yellow is visually brighter than other colors – not in some touchy-feely “seems brighter” sense, but in a raw, colorimetric measurement of lumens. Our human color response is actually pretty unequal around the color wheel – it’s actually somewhat hard to use some colors like pink as a highlight, because once they go above a luminosity value (measured in L*a*b) of about 70, they start to lose their color identity, and just become a really pale grey. Green and yellow are bright choices; red and purple are a bit dark, some blues can be bright, but they collapse as you get towards indigo.

The use of a blue tone in the tree is particularly interesting. It’s actually lighter than the mid-dark green but is so much cooler that it fits with the shadowy parts of the leaves – and the blue reflects the ambient, bluer light of the sky rather than the direct yellow sunlight — the use of color in the tree tells us a lot, very subtly, about the lighting in the environment.

It’s interesting to hear the mental analysis behind this – this was actually meant to be reflected light in a classical shading-treatment of a sphere. From my perspective, the only mental analysis I was performing was “what direction is this surface facing?” That’s it – that’s the one and only thing determining how something gets shaded in frogatto. In regular drawings, one has to also consider changes in “what does that given direction point at?” when an object is in different places, but (without a real 3d simulation and some crazy shader stuff), that doesn’t apply to frogatto. In frogatto every object is shading like it’s hanging, all alone, in a sky/ground box.

Color can be used very subjectively. It doesn’t matter what exact color your color-picker displays, and it definitely doesn’t have to match the “naive” understanding of what color something is. What matters is how the color you use works in-context with the rest of the colors of the scene; Indeed, leaves can be blue.

This is probably the single most important idea, bar-none. Objects are not, by law, their “named” colors. Leaves can be blue because – in real life, under a blue sky, leaves which are facing at the right angle literally are blue. Not “I’m drawing them blue because of some artsy-fartsy personal interpretation” or some nonsense, but “you can point a colorimeter directly at them and it will read blue.”

This seriously flies in the face of human intuition – we’re tuned to think of all objects as being certain “named” colors. By intuition, grass is just always green, period. Water is always blue, wood is always brown – those just seem like immutable properties of physical materials. How can this be; if we can point a colorimeter (a scientific device which directly measures color) at a green leaf and have this machine read it as blue, how can our eyes mistake this and see it as green? The trick is that our brains are designed to speed visual-comprehension of the world by what basically amounts to “summarizing”. Our eyes take in all the input as it really is, but our brains auto-correct for the shifting of colors by changing lighting. They look at a leaf that’s got a blob of sunlight on a glossy edge, and say to us “well, under that sunlight, that’s really not yellow, it’s green”.

We’re hard-coded to react to how lighting changes so we can maintain continuity with what objects are what – our brains are finely tuned filters which ignore all the changes in the visual appearance of objects which are not changes to their basic, physical properties. This allowed our ancestors – all the way back to the very first mammals, to pick out the subtlest movements of living creatures against a backdrop of otherwise similar colors – to notice that one patch of color shifting was the movement of a creature, and not just the shifting of sunlight with the wind and the passing of clouds.

Two of the most common color distortions happen in exterior environments – there is a shift towards blue or indigo on the shaded side of objects, which is caused by being lit only by blue light from the sky, and no light from the sun (in effect like being hit only by a blue spotlight). Likewise, the yellow highlights on the sunny side of objects are because the light of the sun is yellow (since the sky filters out the blue). This dichotomy of yellow sunlight and blue skylight is a phenomenon that happens quite strongly in the real-world, and was also a favorite of impressionist artists. I think the impressionist were really marked by being the first group of artists who (whether intentionally or not) realized that most physical objects are actually lit by some pretty exotic colors, and that exaggerating those subtle effects still looked good.

[Yes, I’ve spoken out about how I don’t care for using small fixed palettes in pixel art. The upside of the practice is that it forces artists to be very conscious about their color choices, so from that perspective it promotes some artistic rigor and, on occasion, very creative use of color.]

You’ll probably find this fascinating, but the biggest advantage of pixel art to me is the exact opposite of what you suggest – pixel art allows me to be completely careless about colors until the very end.

“But wait!” you say, “How can you start drawing without picking your palette of colors?” If you’re used to basically any other kind of painting, period, you pick your colors up-front, because once they’re blended at all on the canvas, you can only apply overall photoshop-style color-adjustment filters. On a portrait, for example, your five colors of skintone smear into hundreds of indistinguishable colors which can’t be picked out and modified individually – you can modify bands of resulting colors, but the “sets of source-brushstrokes in a certain color” don’t correlate with the “sets of color selected by a photoshop filter”. You can still tweak the colors, but you lose all control over the initial ingredients.

In pixel art, because the pixels are always fully opaque, they don’t blend whilst I paint. I might blend by dithering, but the colors themselves don’t get mixed. Because of this, I can change colors “as though they had been this color from the beginning” at any time. Up to and including at the very end. Most importantly, this means that rather than picking one set of interesting color-interactions in my palette, doing a art piece with it, and only being able to do one iteration of color-experiment in the lifetime of that piece, I’m able to as many as I would like. All I have to do is hit a given color with a paintbucket click.

When I was a beginner, I used to get hung up about worrying which colors I should use, but instead, I’ve found that the only important thing to worry about is the luminosity of the colors (as measured in a color space like HSV or LAB). If I get those right – and those are the things that determine the “volume” or apparent-3d-shape of a drawing – then the piece is solid, and I can always fix the hues and saturation later. This means I can plow ahead on a piece even if I can’t figure out the colors for the life of me, because later on, I can always fix the problem.

So actually rather than being really conscious and careful about color choices, pixel-art allows me to be incredibly _careless_ about color choices, because I know I can trivially fix them later. It moves the colors from being the foundation, to being the window-dressing.

In general, warm hues bring things forward, cool hues set things back. (Sometimes I like to play with inverting this rule to make a scene look weird.)

People constantly keep teaching that, but – I’ll be a bit daring here, and say that I personally think this rule is completely bogus. I’ve done A/B testing on this and changing a sky to red doesn’t seem to change its depth-of-field at all. I think this is like many other misconceptions that highly competent people have – for example, virtually all chefs, world-class ones included, swear that searing meat seals in all the moisture, helping to make a nice, juicy steak. The best chefs in the world swear by this – and it’s utterly false (scientists have measured the moisture content, and it turns out seared steaks are actually drier, even in the middle, than steaks cooked evenly; but they seem juicier on the inside because they, unlike others, have a gradient of moisture from outside to inside – they seem wetter because their outsides are drier.). The problem is one of memetic fitness – it’s not a big deal if they’re completely wrong about this, because the food (or art, in our case) is still good. So there’s nothing driving them to correct this misconception.

I think there’s a good body of evidence in real life that this isn’t true; red skies are quite common, whether from sunsets, smog, or nighttime city lighting – and so are red landscapes, such as the deserts of Arizona, the dry grasslands of Australia, Asia, Africa, and America – and all of these within a picture recede; they’re immediately and unconsciously recognizable as backgrounds, and don’t cause people any confusion by “popping forward” and seeming to be in the foreground.

So where, then, does Depth-of-field come from in a 2D drawing? By my reckoning, it seems to come more from the luminosity gamuts of the different parts. And the emphasis there is on “gamut” – not how bright/dark something is, but how far it changes from light-to-dark, and how frequently and sharply. Foregrounds use a full gamut of brightness, whereas backgrounds, even with a clear sky, have some hazing simply because plain air itself is slightly opaque. If you’ve ever looked at distant mountains, you know what I’m talking about. It’s especially the lack of dark blacks in the backgrounds that I think “pushes them back,” visually.

And how does this relate to Dredmor? Well, Dredmor is filled with pixel art. This art does indeed have colors in it, and I apply the above concepts to greater or lesser degrees, depending on the particular application.

There is not as much depth and exuberance as Frogatto, I must admit. The reasons for this are indeed My Problem and have something to do with the setting of Dungeons of Dredmor (a series of underground rooms), the format of Dredmor’s maps (randomly generated therefore somewhat generic by-necessity),

If you don’t mind my thoughts … I actually think it’s got more to do with the variety of tile types than anything else. I’ve found that no matter what you do, even when you (as you have quite nicely) vary an individual tile type with deformation and decay, having a single tile type for each “kind” of terrain just isn’t enough for a game environment. If you look at many of the classic snes games lauded for visual richness (including chrono trigger and SD3), many of them had 3-5 tile types in any given area. They didn’t just have “grass”, and “dirt”, and then call a scene done; they had multiple varieties of grass, and 2-3 different kinds of dirt, et cetera, on top of individual variations within each type. Just having some tattered rugs and such, having scattered straw, some large pavers mixed in with the regular tiles, and maybe even some patches of bare earth, all of which could be placed “randomly” (with some simple rules, like rugs are always a rectangle, etc), and I think you would really take your terrain to the next level – without changing the style at all, and without reworking any existing art.


Frogatto comes to the Humble Store

May 15th, 2013 by Sirp

Frogatto is now available for sale for PC and Mac on the Humble Store! Go and get it here!

If you’re curious about what Frogatto is all about before purchasing, check out our trailer:

(Edit: Since a few people have been confused by this, it’s worth noting that the “Humble Indie Store” isn’t a storefront site like Amazon or Steam which you can go to and look at a whole selection of games in (despite the fact that the HIB is kinda close to being able to do this for their periodic bundles). It may become that at some point, but for now, it’s just a widget on individual game-developer’s sites which you can use to buy the game. So if you go looking for a “Humble Indie Store” to buy the game in, you won’t find one yet; instead, you’d need to go to our downloads page to get it from there.)


Chasm on Twitch.TV (Featuring Frogatto)

May 12th, 2013 by DDR

Hello everybody! We’re all excited over Chasm, and they’re having a stream over here for the next few hours! They’ve asked us to do a bit, so there’s a conversation you probably won’t want to miss. Link is: This is the last day of their kickstarter, over at

[edit] Event’s over, now. It was good. It was funny! Luckily, you can now watch the whole four and a half hour video at The bit where they play Frogatto is near the beginning, after some Castlevania. The show features an extended interview with our very own artist Jetrel; and our musician Ryan drops by about half-way through the game.


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.