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.

The Tower 57 Post

August 23rd, 2015 by DDR

Today, we have a shout-out to Tower 57, whose kickstarter badly needs your support with roughly a week left. They’re close to meeting their goal, but your individual support could mean the difference between success and failure for their campaign. Get out there and pledge!

Tower 57!

1920s art deco. Dystopian future. Destructible scenery. Tower 57 is a twin-stick shooter where you go on an espionage mission to a rival tower, trying to keep them from declaring war on you.

Here are some pictures of it:

Grutin, incorporated, has a great art deco meets blue cybernetic look to it.

The factory. Something fishy here.

Tower 57 has 6 playable characters.

Playable characters.

A gentleman and his flamethrower. They light a turret on fire, and use it's now-fiery bullets to take out a bunch of smaller enemies.

“Smart Combat”

The art is all by Cyangmou, who has an active deviantart profile at The kickstarter is at

Frogress Report

October 2nd, 2014 by Jetrel

Work is continuing apace on the next release (version 4) of the game. The two new actbosses for the forest are in place, and we’ve done a bunch of heavy lifting on level (and monster) design for the new forest levels.

We’re working on integrating the new ability system into a much better HUD than we’ve had before – namely, one with an inventory screen (along the lines of, say, 2d zelda games) so you have some idea of which items you’ve acquired, and which will open up some new possibilities for interaction (for example, there was no way under our current setup to have consumable items).

The majority of our work from here on out is polish – we’re trying to re-connect a lot of our levels and allow lots of areas to be present which you can only reach by returning to a place later, with some ability acquired later in the game. There’s going to be a lot of work to this; the main thrust behind this is basically to transform us from a straight-through linear platformer, to what’s commonly called a “metroidvania” (a game with the non-linear player progression of something like Super Metroid, Castlevania: SotN, or Zelda: LttP). That’s not a simple job.

We’ve also been revising frogatto’s own animations, to make his motion much smoother and fluid; we’ve already done this to the walking, standing, and jumping, and we’re hoping to have a go at swimming, before too long. Our hope with the swimming is to keep the controls as they are now (which are fairly satisfactory), but to make the graphics much, much more fluid. This will also pave the way to allow us to add attack modes for the player’s alternate powers underwater.

We don’t have much heavy-lifting left for the graphics. The remaining items are: I have some stand-alone mushroom props I need to draw, I have a few forest-tree trunk segments I want to add to flesh out the flexibility of our tree props, and I need to redraw a few more seaside houses before the next release.

I estimate it’s going to be several months before the next release – we’re all doing this part-time, and most likely the level-design work is going to take quite a while. If you’d like to stay posted on things as they happen; follow our twitter @frogatto, or keep an eye on the recent commits to our github (we tend to make changes on a daily basis).

Foley for Frogatto

May 16th, 2014 by Action Jack

Hello!  My name’s Adam, and I’ve been doing sound effects for Frogatto.  About 90% of the sound effects currently being used are fresh recordings by me (the rest are made with bfxr; it’s a lovely program and a quick, easy and free way to get classic “video-gamey” sounds).  This is the first time I’ve done sound for a video game, and since the process has been absolutely fascinating for me I thought I’d share a little bit about what I’ve learned.  I’ll have a video at the bottom showing whatever specific sounds I mention here.

I fancy myself a budding foley artist.  And since telling people that usually raises more questions than it answers, “foley artist” is a term originally applied to movies for somebody who records sound effects that weren’t picked up by the camera.  However, since then the term has been extended to other media as well, so I use it to distinguish the fact that I create my own sound effects rather than pull them out of a library.  Most projects do a mix of both, but I’ve been challenging myself to get as many sounds as possible with foley to expand my range.

Foley for a video game is a completely different set of challenges from foley for a movie (or at least in this case; I imagine it would be closer if Frogatto had more cutscenes).  The majority of what movie foley artists do is footsteps.  They put on the pair of shoes they own that most closely matches what the character is wearing (I’ve had a hell of a time looking for a pair of heels that fits my size-thirteen feet) and watch the footage, walking in sync and timing their movements to match the actors’.  Not only does their rhythm need to be perfect, but since they have a microphone pointing at their feet they have to walk in place and still make it sound natural.

I don’t have to worry about any of that.  It’s impossible for every footstep in a video game to make a unique sound, because any given character will take an infinite number of steps.  So I just supplied about ten footstep sounds for each of Frogatto’s different podiatric movements (walking, running, jumping, and skidding) on each of the surfaces we have in the game.  And I didn’t have to worry about my timing, because the game just picks one sound from my collection at random every time Frogatto hits the frame of animation where his foot hits the ground.  So all I had to do was pick my favorites, crop them, and upload them.  Footsteps are the bulk of the job for a movie, but for Frogatto they only took a few hours.  It took me longer than that to clean up all the scattered bits of confetti that stuck to my feet and tracked all around my apartment after I used them for shrubbery; I was still finding pieces when I moved out.

But even though this project has allowed me to bypass what appears to be the toughest part of foley work, I’ve faced plenty of hurdles that aren’t an issue for movies.  Most of them deal with the unpredictable flow of action; while a sound well-chosen, well-edited and well-timed in a movie will be great every time you watch it, events in a video game unfold a little differently for each player.  I have to make sure my sounds meet the needs of the game under every circumstance.

Most importantly, I have to be mindful of which sounds will be heard repeatedly and make sure they won’t be annoying or overbearing.  Something that sounds cool once isn’t necessarily going to hold up over time.  I contributed a few sounds to  Cube Trains.  One of our programmers’ other side projects, as well as a beautiful demonstration of the flexibility of the Frogatto engine, Cube Trains is a puzzle game where you build a track to get trains from one side of a map to another.  The creator initially wanted me to do some big metal clang sounds for the laying of the track, but we agreed that since the player is laying track with every click of the mouse, those would grow tiresome rather quickly.  So we scrapped the clang and went with more of a clink; to get a nice snappy metal resonance without a lot of reverberation, I wound up hitting my microphone stand with a slap bracelet.  The nineties will never die.

Sometimes, I find myself needing to deliver sounds in such small pieces that I have no idea what they’ll sound like until they’re in the game.  In our next release, you’ll notice that we’ve diversified the death animations of our enemies.  As a result, many animal-type enemies now die by bursting into a flurry of bones.  Jetrel’s inspiration was a similar effect from Secret of Mana for the SNES, but whereas Secret of Mana’s enemies skeletonized with a single self-contained animation, ours do so by turning into a bunch of individual and separate bones that bounce several times along the ground.  Secret of Mana had one “bones-rattling” sound synched up to the animation, but I couldn’t do that because our animation’s timing is always different depending on the terrain.  So I did about ten takes of flicking my fingernail against the bottom of one of those plastic ramekins a restaurant gives you when you take sauce to go, and had the game play one at random every time a bone bounced.  Alone, they don’t sound like much, but in practice they make a nice little macabre symphony.

And while the coding makes it easier to sync audio with specific actions, it can also throw me some curveballs.  I feel quite blessed that even with zero programming background Frogatto Formula Language has been extremely accessible.  If I want to, say, add a sound for an enemy shooting something, I’ll just go into the enemy’s data and search for the command that creates the projectile and I can add a command to make the sound happen simultaneously, guaranteeing it will by synched each and every time.  However, as I assume is the case with any programming language, FFL will follow the letter of what I say and ignore the spirit.  For example, I made a sound play every time a particular enemy was injured.  Most of the time it sounded fine, but Frogatto also gets an acid attack that rapidly scores damage over the course of a few seconds.  If this enemy was caught in a patch of acid, the game would play my sound every time damage was sustained, which was all of the times.  So we had to put in an extra condition dictating that every time the enemy was damaged, it would check whether the sound had played within the last few seconds and decide accordingly whether to play the sound.

But implementation aside, this has mostly been a surprisingly simple process for me.  There isn’t much high concept here; I just picture what any given action would sound like and try to make that sound with whatever I’ve got on hand.  Frogatto grabs onto a wall?  Slap my hands against things.  Frogatto spits acid?  Pour some champagne and record it bubbling in the glass (as for the sound of expelling acid from one’s stomach… let’s just say I’m glad I can belch on command).

On the other hand, sometimes I need to make a sound for something that doesn’t exist in the real world and I’m shooting more for a “feel” than a re-creation.  Our forest area has giant spiders that crawl around on the ceiling and try to pounce you when you walk under them.  My microphone isn’t going to be picking up any sounds made by a spider anytime soon, so I was just looking for something sudden and startling.  I made the sound by scratching my fingers across a duffel bag, and topped it off with a little “spider chatter” by rapidly repeating the sound of two eggs clicking together.  We also have some synthetic plasticky golem-type enemies who pop when they die.  Since I didn’t have any plastic golems handy to smash, I made this sound by throwing handfuls of flour against an empty bathtub.

Other times, the real sound just isn’t as pleasing as it could be.  Our last area has spike traps that shoot out from the ground and retract.  At first, I tried to make a mechanical release sound, but it just didn’t do them justice.  So I made a few of those lovely *SHING!* sounds by scraping a hinge across the edge of a glass table.  I can’t imagine real spikes ever making a noise like that, but who’s going to complain?  If you have first-hand experience with spike traps, either your real life is way too cool for you to have any interest in video games or you’re some creepy baron in a dank castle and you probably don’t have internet access.

Here are some demonstrations of the specific sounds I mentioned:

So that about sums it up for my adventures in videogame foley.  If anyone needs me, I’ll be over here spanking an empty bottle of apple juice with a sock filled with BB’s.

Some things coming in the next release

April 15th, 2014 by Jetrel

We’ve been hard at work on the upcoming version 4 of Frogatto, which is what we intend to release on Steam. We’ve got a few things which are variously in the works, or mostly complete:

– One of the big goals in this release is to get a professional level of polish on our bosses. We’re trying to stamp out as many of the “trivial exploits” you can use to ‘cheap out’ a boss and take it down much more easily than intended. We want the bosses to fairly telegraph their moves (no random, sudden motions that aren’t predictable), but we also want the bosses to be very, very challenging. This is a really difficult balance to achieve, and it’s very time-consuming work, which is why we’ve neglected it in previous releases in favor of building out other content. There’s a reason many traditional 16-bit games had a few employees dedicated solely to writing the bosses for a given game.

– Related to this, we’ve added two new act bosses (on the same scale as Milgram) in the forest section. I’m not going to spoil them in this post, other than to say that I’m quite proud of what I’ve done.

– Frogatto now has two different paths to take through the forest. Each route route features new enemies, and also has some new and unusual platforming puzzles in it, very different from the rest of the game.

– The forest now has a town in it, called Tempo Village. You should visit it sometime, I hear it’s nice there this time of year.

– We’re trying to make monster encounters more interesting. Right now, if the player is intent on just progressing forward in the game, a lot of our monsters really aren’t very interesting. They’re similar to designs in many other games, but because Frogatto (the character) is incredibly agile and fast compared to most platforming characters, Frogatto can get past these by just jumping over them (unlike, say, Simon Belmont). It’s frustrating; we’re committed to having a really fluid, agile character, because the stiffness of many traditional game characters has always been something that bugged us. We also want to do this because we feel like it’s an obvious point-of-improvement that’s unfairly neglected; a cop-out a lot of existing games make, and an obvious point for us to innovate on – but the reason it isn’t done is exactly what vexes us: if we want to have a really agile character, we have to work much harder to make sufficiently interesting enemies. We can’t just make a goomba clone (which a surprising number of castlevania enemies were), and call it a day.

I describe “sufficiently interesting” as an enemy that arrests the player’s forward progress, and forces the player to confront the monster and either dispatch it or carefully dodge it before proceeding – something that demands the player’s attention. The guiding principle here is a classic quote by legendary game designer Sid Meier: “A great game is a series of interesting choices. (emphasis mine)” – the biggest problem we have is that jumping over an enemy, if it’s always the default fallback, isn’t an interesting choice. Choices have to be novel.

We’re doing a mix here of adding entirely new enemy types, and making the existing enemies more interesting. Quite a few existing enemies are perfectly serviceable designs, but in their existing usage, have been placed in fairly uninteresting situations. For example, a spiked, indestructible enemy is an entirely different beast when filling the breadth of a small tunnel, or when sitting on a small pedestal; as opposed to when sitting on top of flat, open ground. By not being able to move around it, you’re forced to strategize – to stop and think. Solving puzzles like that is what makes games fun; it’s the basic reward mechanism. It’s taken a while to understand this deeply enough to apply it to our own work, but our hope is that Frogatto will come out of this much more fun than it has been in the past.

– Related to this, we’ve built out a full damage-type and creature-type interaction system (similar to Pokémon and quite a few RPGs). Different kinds of damage do different things to different kinds of creatures. Part of this is that there are now secret areas in the game which you’ll only be able to access with a certain kind of damage to break through obstructions – usually a type of damage you won’t get until much later. We’ve worked these into the grab-and-spit mechanic, as well: you can grab objects, and “infuse” them with an elemental attack when you next spit them out.

Hopefully this will all add up to make Frogatto a heck of a lot better for the next release.


December 7th, 2013 by DDR

Good news, everybody! We’re greenlit, we’re coming to Steam!

Greenlight Screenshot - 26648 unique visitors over 69 days - 10687 yes votes - 49% approval rating

The Greenlight Stats Page

In more practical matters, Steam will be getting Frogatto version 4.0 and up. We expect to be able to release this in half a year or so, by the summer of 2014. The new version will feature better graphics, two new bosses, and much nicer powerup system. Stay tuned for more information via RSS or Twitter.

Vote for Frogatto & Friends on Steam Greenlight!

September 29th, 2013 by marcavis

We’re finally getting confident enough to aim for the big leagues – and Valve’s Steam platform is definitely that.

The Greenlight process for getting there has been revamped recently, and approvals are happening more quickly, but we really need your support! Please vote for us, and tell your friends! Only with your help we can reach out and become available for the biggest community of video game players in the world.


Legend of Iya Kickstarter in final stage – needs your help!

August 11th, 2013 by Jetrel

(Update: Kickstarter successfully funded.)

They’re down to just $4,500 out of $75,000, with 8 hours to go.
You can make this happen.

Legend of Iya is the personal magnum-opus (a metroidvania platformer with really, really hi-fi pixel art and animations) being cooked up by darkfalzx. Darkfalzx is a veteran of the fairly small commercial pixel-art industry, with several games under his belt from places like WayForward (an important thing I point out because it’s a healthy sign that he’ll be able to bring this to completion if funded).

Really, you should fund this, because this is one of less than maybe 5-10 “hi-fidelity” pixel art indie-projects being made out there, right now. These are rare, rare birds; there are plenty of crappy indie projects that try to cash in on the retro craze by making blocky, lo-fi art that’s basically stylized “programmer art”; stylized to try to hide the fact that the parties involved want to scrape by with the minimum effort possible, and refuse to learn to draw. There are few-to-no projects out there which try to emulate – or surpass the very best pixel art which graced the end of the 16-bit era. Really – think about all those cheap “retro indie platformers” – isn’t it a shame that none of them are in the same ballpark as titles like Metal Slug, King of Fighters, or the later Castlevanias? Weren’t games like that awesome?

Well – this is one of them. This is trying to hit that level of quality. If this doesn’t get funded, there won’t be another project like it that will pop up later. These are that rare.

I mean, seriously – look at this:

Go fund this.

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.