Frogatto & Friends is an action-adventure platformer game, starring a certain quixotic frog.
We're an open-source community project, and welcome contributions!
We also have a very flexible editor and engine you can use to make your own creations.
With one notable exception, the last few weeks have been a lot of odds-and-ends; the less exciting bucketload of piecemeal feature completion that leads to working software. (Added a few objects, fixed some bugs, made some other objects work right, etc…)
The big item, though, is something we can fortunately show off here in its partly-complete state; most of the art for this is done-ish, and most of the code is a little over halfways there (the difficult parts have been broken down, but there’s still a lot of tedious busywork left to eat up time.
We’re working on a multi-pane inventory/etc screen that pauses the game when it comes up. (If this doesn’t make sense, think along the lines of the 2d “zelda” titles).
This will be broken into multiple, modular panes – basically, we’ll be able to make the different parts of this into items you acquire in the game (for example, there will be a magic ‘automap’ you can get to see the layout of the current level – you’ll actually ‘get’ this as a quest reward, rather than having it from the get-go). Another nice side-effect of this is that if we have additional ideas in the future (or really – as we get the work done) we can slot in whole new panes as we go. We’re planning to have a bestiary that lists out all the different creatures you’ve encountered, and their different vulnerabilities/strengths.
Here’s a shot of what the core screen looks like:
And here’s what the background for the map will look like (we don’t have any of the overlay drawn on this yet).
New enemy:
We came up with this wily fellow. I spent way too much time fighting with this guy’s animations, but I’m quite happy as to how he came out.
We’ve still got a few more enemies planned for in the next release; more enemies for the swamps are definitely going to be a prime focus. This fellow gets us that much closer. 🙂
Compound objects:
The biggest thing I’ve been working on recently has been a system to do compound sprites. Compound sprites are when you use multiple sprites to create the appearance of a single, larger object – in the old days of sega/nintendo, these were just used for size, since even seemingly ‘small’ characters like mario or sonic were actually a multiple of the native square-sprite size of the machine they ran on. These days, we don’t have any meaningful size limitations on sprites, so instead we use compound sprites for positioning or animation. For example, a clock face would easily be done with one sprite for the dial, and separate sprite for the hands – the purpose being that if the clock-hand sprites are separate, you can freely rotate them, programmatically, meaning you can have a full, 360° of rotation without any new drawings being necessary on the artist’s part.
We’ve wanted to have these in the game for quite a while; technically, we’ve been able to do them since the early alpha versions of our engine (Anura), but in practice they’ve been a buggy mess. The system I’ve come up with is no holy grail (there are a number of fancy animation-scripting things that still have to be done by hand), but it’s very, very clean, and should stay fairly bug-free. One of our main goals was to have these sprites, to the player’s eye, seem like a seamless extension of the core object they were a part of. Any damage-contact applied to any part of these should act like they’re one, indivisible object; any visual effects like color-flashing should affect the entire thing, without any inter-frame delays. Chiefly, we’re also worried about orphaning these child objects – if the core enemy they’re attached to, dies, we need to have a reliable system for getting rid of them.
Bug-free designs are really our top priority at this point; we had some compound enemies in the past and I’ve actually ended up mothballing a few of them because it was too much work to keep them running as they broke over and over due to other changes in the game. A tough lesson I’ve learned in game-design has been to resist the siren song of new features that I can’t quite come up with a rigorous way to handle; they might not take any longer to prototype than anything else, but I can’t treat a working prototype as a “bird in the hand”. I have to treat the real cost of features as the full, lifecycle cost of all the future bugs its going to incur as it interfaces with other elements in the game. Thus, I need to focus on things that have a way lower lifecycle cost – which is usually down to ‘devil in the details’ planning of how they work. It’s less about what I do, so much as it is about holding off unless I’ve got a really clean way to do something. There are plenty of “cool 2d platformer tropes” we’re leaving on the shelf unless they can meet this requirement, but the result is we’ll actually ship the damn game, so it’s a small price to pay.
As for the new compound-object system; there are several specific things that finally made it viable. Most of it had to do with some major, structural improvements to our “hittable” class (a long, ongoing project over the last year or so). Most of these have been down to a transition away from a type/recipient-blind “event-driven” system, and instead moving to a pure-functional, strict typed means of triggering behavior. A lot of this has been enabled by some huge upgrades to Anura’s scripting language, making it strictly typed – most especially with regards to non-null containers, and object access – we now can have hard, static-analysis guarantees that if we’re operating on some set of links to other objects (like, say, compound object parts) that we’re guaranteed to be pointing at a real, object, and not something that had been deallocated earlier. A big benefit here is that our hittable code has a very limited set of entry points; we’ve got one place where hit-triggering behavior gets captured, and this can safely redirect calls for being hit to a parent object (and thus make sure the full suite of damage-receiving code gets triggered correctly).
Hopefully this will bulletproof the few enemies we have based on compound objects, and let us gradually ease into doing more in the future.
We’ve been making some update posts over on our steam greenlight page for a while now, without cross-posting them here. I’m going to start backporting a few of them to here, and try to keep up with consistently cross-posting them in the future.
New flight animations:
A long-running project we’ve had going has been upgrading the animations on all of our older monsters. New monsters we’ve been making from scratch have high frame counts from the get-go; we had several older creatures which didn’t (In the pending release, we’ve just about doubled the number of creatures in the game).
Like a lot of indie game projects, frogatto has been one of those where we’ve been “learning as we go” – our older art was cheaper because my skillset was a lot weaker when I made it. Two of the points of cheapness were that most of the animations had a very low frame-count (about 3 or 4 frames for most “cyclical” animations like walking and flapping), and most of the old monsters were “clones” of each other – they were a similar base body design, recolored, with a few cosmetic bits tweaked to make them look “different enough” whilst allowing most of the animations to be copy-pasteable (with similar recoloring tricks, etc).
The problem with cloning like that is it becomes noticeable after a while – do it too much and even the less aesthetically-inclined players start to notice and it cheapens the experience. Fortunately there were few enough of them that I don’t think we need to actually rip them out – instead, we just needed to draw a line in the sand and say “let’s make sure all of the new ones we add are brand-new designs”. The upside of keeping these existing ones is that if I upgrade one of the core animations for them (like the ant walk cycle, or the flying-ant flap cycle), I can copy over the improvements to all of the other clones and get a lot of bang for the buck – get dramatically better animations on a bunch of creatures for fairly little effort.
So in the last few weeks, I took the flying ant’s core animation and applied it to about 4 other creatures which are seen in the seaside chapter of the game, and a couple creatures seen in the cave chapter of the game.
This post has a comparison of our older flap animations against the new ones:
http://steamcommunity.com/sharedfiles/filedetails/updates/181850301/1427435374
New miniboss fights:
I don’t want to give any story spoilers on this, so forgive me if this sounds a bit analytical and antiseptic…
If you’re familiar with the earlier releases of the game, we’ve got one lonely miniboss fight – one stage where you’re locked in a room and have to fight against 4 regular “kitty” enemies. In that particular fight’s case, it’s a fairly easy battle used to introduce one of the main enemy types in the game, and force the player to familiarize themselves with how the enemies work. We’re going to be adding something like 5 or 6 more such fights in the coming release.
I like these because by putting a simple twist on how a creature is presented in its environment, an existing monster’s challenge-factor can be radically changed (A metaphor I frequently use to explain this is that a sniper in the middle of an empty parking lot is a lot less dangerous than a sniper in a cluttered urban setting). Not only is it good for mixing things up gameplaywise, it’s also good for forcing the player to learn-by-doing, and it’s great for narrative cycles; for adding climax and surprise to different chapters of the game. It’s a shame we haven’t done this before; a number of sections we’ve had in the game prior have been completely devoid of boss-fights, and it really made them feel flat. This, as well as the two new actbosses we’ve finished are really going to help spice things up.
So far we’ve got two of these two miniboss fights mostly done, and we’re got a third one well on its way.
Seaside level enhancements:
Some of the earlier seaside levels date back to the beta of the game – they’ve been reskinned as we’ve redone our graphics, but their basic layout remains the game – especially in the flaw of being a pretty straight-shot linear run from left to right.
I’ve gone over a couple of them (the levels “Splash Hop”, and “Burn and Bubble”) and added some major puzzles to them (where there were no puzzles, before), and I’ve greatly increased the size of them, vertically, adding additional paths you can take through the level, each with its own unique challenges. I’m also in the process of re-adding a great old level we used to have called “Stonepipe Flats” which was made during the beta and got dropped for no really good reason other than me being too lazy to reskin it after one of the big graphical makeovers. It’s high time it had a moment in the spotlight, since it’s a fairly nice level with a few good puzzles on it.
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.
