With some wonderful help and support from Research in Motion, we’ve ported Frogatto to the Blackberry Playbook. The Playbook is the perfect size for playing Frogatto, fitting snugly into one’s hands with the controls within perfect reach.

Frogatto is going to be demonstrated by Research in Motion this week at the Game Developer’s Conference.

Porting to the Playbook has been remarkably easy. It should be available on the Playbook’s app store soon!

A friend of ours made some sweet fan art. I’m actually gonna split this into at least two posts, just to spread things out, since he made us a series of 5 pics(!) :D. The fellow in question is Emilien Rotival, (aliases being variously “The Arty Squid” and within wesnoth, “LordBob”), who’s a terrific illustrator, and all-around great guy to work with (rarely have I seen such a high ratio of skill:ego thrown around). He’s easily been the nicest, and one of the best illustrators I’ve worked with. If you’re looking to hire or commission someone, I can’t recommend him enough.

We ran into him on our sister-project Battle for Wesnoth – if you’re at all familiar with the game, he’s responsible for something like half the portraits in the game – in fact simply going to the homepage at the time of this writing is likely to have two or three of his in the randomly-chosen pool of them that decorates the main page.

So I linked him to frogatto a little while back, and then he did something very cool – a series of three cartoon-style illustrations of scenes from the game (click to zoom in):

THE GREEN ONE HUNGERS!

Oh, you sneaky town elder, you...

It never pays to get up early in the morning.

Stay tuned, because an upcoming post will have some additional bits he made. 🙂

In the upcoming release, v1.3, we’re overhauling how our powerups work, trying to solve a major design flaw in the current system. As it stands now, the way our powerups work is: 1] you have to kill an enemy to cause it to “drop” some powerup. 2] you then have to tag this powerup, which moves around and can be hard to get, and 3] once acquired, it only lasts for a tiny window of time. These rules didn’t add up very well inside frogatto, because of our pacing. It took a while to figure out what was wrong, and here are our thoughts on the subject:

The drop-and-grab design is really common in flying shooters like Raiden, or Gradius, where there is always a constant and numerous stream of enemies coming at you. In the story mode of frogatto*, this isn’t remotely the case. There isn’t a constant stream of enemies, and that’s a deep and very intentional part of our design – a central part of gameplay in frogatto is confronting some jumping puzzle, killing off the enemies around it so you’re not interrupted whilst you try to pass it, and then passing it. What generally happened in frogatto was that you would kill an enemy, acquire a powerup, and usually, most of the powerup’s duration would expire before you had a chance to really use it. In engineering-speak, this was a “perverse” design – not just a bad sequence, but the “worst possible” sequence we could have chosen. The best possible sequence with a setup like that would be “acquire the powerup, and then conveniently encounter a constant stream of enemies during the powerup’s duration”. That “best possible” sequence really could have only been managed by either making the powerups themselves cause the monsters to appear**, or by ensuring there are always a constant stream of enemies, and neither of these were really feasible.

What we’ve chosen to do, is to switch most of our powerups to a “mana” system; rather like zelda. Powerups are permanently acquired abilities (which will generally be quest rewards), and tapping a “switch” key (currently “D”) toggles between them. This ensures they now have optimal availability during the times when they’d be fun to use. Mana regenerates slowly, and the blue cubes (which used to boost powerup duration) now recharge a bunch of mana, quickly.

This also allows us more flexibility in designs, since quite a few designs work terribly with “timed duration”. We’re adding a few basic powers to the next version of the game – we’ve reconfigured the energy shot as one of them, and there’s a new, very short-range fire-breath. Any ideas you have would be welcome in the comments, or on the forums. We’re not removing time-limited powerups completely, but we’re likely to limit them to a scant few items like “invincibility” or “time-slowing” – and we’re likely to make them taggable items sitting on a level, rather than dropped items from enemies.

An example of what the new HUD looks like, with the energyshot as the active power:

* Our arcade mode is a LOT more like those shooters – you’re constantly forced onwards, and on a few levels, you run into a constant stream of enemies. Of course, you never could unlock the powerups before entering the arcade levels in the past. We might consider having a few “time-limited” powerups on the arcade levels, or flagging all the character’s mana-based powers as active before starting the level. One fun idea might be treating the mana-based powers you acquire in-game as achievements, and only unlocking them in the arcade levels if at some point you’ve unlocked them in the story mode, in the past.

** this actually isn’t completely crazy – in a game where there’s some inherent reward for killing monsters (like XP and EQ in diablo 2), spawning some unique monster could be a good thing – they did that with shrines. Doing some combo with a shrine that gave you a time-limited powerup, and spawned an enemy vulnerable to that, might be a cool idea, but in frogatto, we don’t have special rewards for killing random monsters. Monsters are just an obstruction, in frogatto, not an end in themselves.

I really hate having anything to do with politics mentioned on this blog, but this is so bad that attention needs to be drawn to it.

There are two bills going through congress that will allow America’s government to censor websites exactly like China and Iran do – via a new blacklist of “bad sites”. The reason argued for this is to stop piracy by allowing copyright holders to call for any site which they think is infringing, to be immediately taken off the net without proof. We feel that nothing can justify taking away free speech. The very thing that has made the internet such a powerful force for good in the world is its absolute freedom of speech. People can expose the wrongdoings of those in power, and the internet is a tool that for the first time in history, prevents their voice from being silenced. The last thing we need is america, the “land of the free”, to establish a dangerous precedent of censorship as a default – a precedent which other countries are certain to follow.

Furthermore, because there is no “due process”, that is, because sites would be taken down immediately without having a chance to prove they’re innocent, this would destroy innovation on the internet. Because there’s no due process, it doesn’t matter if you’re guilty or not; if some competitor with more money just doesn’t like you, they can get you taken off the net by making a false accusation. That’s fatal for any internet company – it turns off their entire business and income instantaneously, and could be repeated as many times as necessary to drive them bankrupt. Virtually every internet service we use today; google, facebook, youtube, twitter, deviantart, itunes, netflix, anything – could not have started up in an environment with these kinds of laws on the books. Some better-heeled company that didn’t like them, would have shut them down. In fact, all of these companies did receive severe legal threats from the entertainment industry as they matured – the MPAA and RIAA have repeatedly stated that they wish these companies/services didn’t exist (especially Youtube and iTunes). They only survived because there were no laws like this on the books.

At the time of this writing, these bills have received some temporary setbacks, but they are not dead yet. Do whatever you can to destroy them – free speech for the human race, and everything you like about the internet, is at stake. You can read more about these bills, and what you can do to stop them, on wikipedia. And yes, you can do stuff about them even if you don’t live in the US – follow that link.

It’s up on the iTunes store for iOS, and the release has been tagged in our source tree. We’re delayed on the mac and windows releases because, respectively, there’s a bug in SDL that breaks our fullscreen support in 10.7 (which we think we’ll probably have a solution for in a few days), and as for windows, I don’t even know what we’re gonna do, because across our entire team, I’m not sure we have a single guy who can compile for windows at the moment.

We’re quite open to outside help on that. If you’re good at compiling software for windows, we’d love your help (if you can do a really good job, and solve our ongoing compatibility problems, there might be a business opportunity there).

We’re hoping to have this upcoming release done in less than a week. Dave just fixed a killer bug that was holding us back, so now the only holdup is one last round of testing, and a call for any last-minute translation updates. In our previous release, we had: Brazilian Portuguese, Chinese, French, Italian, and Japanese. At the moment, chinese and japanese will need some heavy-lifting to update themselves for 1.2, and of course we’re happy to support any other languages people are willing to translate (at this point, we probably want to switch to some system of stable/unstable releases, so that unstable ones can be fully translated).

To quote marcavis’ earlier post: “If you have some good knowledge of your language, and feel like helping (we know you do), register on www.transifex.net, and either request to join the translation team of your language, or to create one if it doesn’t exist already. Frogatto’s page is here. There’s also some further instructions on how to do the translation work in this forum post, so be sure to check it out!”

So what’s new in this release?

* Complete redo of attack logic; frogatto now is free to walk around whilst he attacks, and in general is much more responsive.
* Frogatto’s tongue-grabbing is MUCH more forgiving
* Complete rewrite of damage handling; much more consistent now, and categorically eliminates some bugs where damage wouldn’t get dealt.
* Reworked some tilesets to eliminate tiling errors.
* Further enhancements to dungeon wall graphics (added edges).
* New, more readable dialogue font.
* Lots of small graphical tweaks.
* Maps are now strewn with spittable props within easy reach.
* Rewrote most of the dialogue.
* Collectible items like coins can be collected by being touched by the tongue, besides just frogatto’s body.
* Redrew the world map.
* Added a few new monsters, like the red hornbugs, and completely rewrote how bats behave.

We’ve also been working on a ton of other stuff that won’t make it into this release, because it couldn’t be finished in time. Most of this is a huge rewrite of the forest area; adding a boatload of new monsters and puzzles to it, and also giving it an actual story and boss battles to make it as rich as the seaside section. Also a bunch of sweet new music ryan has made which I can’t wait to have a home for. It’s going to be a lot more work before we’re done with that, so we wanted to get the things that are polished-off to you sooner rather than later.

Over the past few months, we’ve been trying to address all the little bits of weirdness in frogatto’s gameplay. We’ve had a whole bunch of little corner cases in our gameplay that are each kind of minor in themselves, but taken as a whole, can make the game frustrating enough to ruin the fun for some people. Why we waited so long to fix them came down to cost/benefits being really poor for each of them, individually. Each of these was a tiny problem, but fixing it was a huge, sweeping overhaul, so we ended up working on other, more important stuff earlier on.

Some of the examples include:

– when you spit out an enemy, it was not possible to grab the enemy again whilst it’s in the air – or for some enemy shots like acorns or the thrown metal balls, to ever grab them again after spitting them. Now you can.

– there were odd situations in which enemies would “cancel out” of certain states; where behavior from one state of a multi-state object would “leak” into another state by the object running into some trigger that almost never got called in normal circumstances, but could very rarely ‘derail’ the object into some other state. For example, a flier bumping into ground might start walking, or might get stuck. A swimmer might fly if for whatever reason it escaped from the water. A frequent one was thrown enemies canceling their stun early.

– related to thrown stuff, it was possible at times for enemies to fail to set their team correctly, resulting in an enemy becoming permanently harmless; or sometimes resulting in frogatto being hurt by his own projectile. The fix for both these and the state issues is described further on in this post, under “States:”.

– frogatto couldn’t jump on top of enemies during his post-hit invincibility; he was completely intangible the whole time. Now, he’s intangible only until he’s outside of the enemy’s solid-area.

– when thrown enemies, or enemies in general, landed in awkward spots (such as slightly overlapping the player, or enemies getting stuck), we usually did a cop-out where they just died. We’ve come up with a few “escape systems” which try to find some way to shove/bounce them out of that situation without having to kill them. Quite a number of these “just kill it” cop-outs were so common that they were exploitable as a way to predictably kill the enemy.

– frogatto’s tongue tip had to directly touch an enemy to grab it, which is fine for anything that stays still, vertically speaking, but for bouncing projectiles (acorns, metal balls), it was insanely hard to catch them, and there are a number of new enemies we’ve been working on that were also similarly hard to grab. It was just no fun, and we needed it to be much more forgiving – now it is.

– rare situations could trigger two additive effects that made frogatto go up, both frogatto jumping, and frogatto bouncing at the same time. Other situations could result in a jump being robbed of almost all it’s upward velocity. We found what caused this and fixed it.

– Frogatto’s tongue now can attack in all 8 cardinal + diagonal directions. More importantly, it now extends in all of them with upgradeable length. The reason this took a while was that it wasn’t until recently that we had support for non-vertical/horizontal objects that could stretch like ropes. Our code to draw the tongue, as it was before, only functioned horizontally; the up-attack was just a hand-drawn animation, baked into frogatto’s sprite – it wasn’t something with a stretchable part.

– We removed the one instance we knew of where frogatto’s attack was “locking”. Locking is an annoyance seen in some videogames where you begin to perform an action, and whilst the action plays, you’re unable to perform other actions. In frogatto, whilst you attacked, you were unable to walk forward – if you were in the midst of walking, it stopped you and pinned you there until the move ended (technically, a few actions like jumping or walking the other way could escape this, but they had a different problem).

– Said different problem has also been fixed, at a graphical cost that we’ll work to correct: if you jumped or turned, your tongue disappeared – this was a bad thing if you did it a frame too soon, before the tongue touched some oncoming enemy. Attacks in games often act like a “parry”, you launch an attack, and expect it to nullify some oncoming threat. For example, if frogatto’s tongue just disappears halfways to an oncoming ant, suddenly that ant isn’t going to get removed, and suddenly, you’re going to take damage you thought you’d protected yourself from. This felt especially wrong in frogatto, because, sure, we had a reason why we didn’t do it (the tongue, facing in the now-opposite direction, would need to complete its course and retract, which might look odd), but in any shooter game, this is never a problem. Shots would leave the main character’s gun, and the main character would neither be locked in place to fire them, nor would they ever have to worry about the shot randomly disappearing and leaving them vulnerable to something incoming. Frogatto’s tongue feels like it should follow the same rules; now it does.

The graphical problem we get out of this is that we now do frogatto’s head, modularly (sometimes). Under circumstances of quickly changing animations, you’ll sometimes see it persist a frame or so longer than it should; it looks a little like a motion blur, so it really doesn’t look too bad, and we think it’s a problem worth introducing to get the gameplay right. We’ll see what we can do about fixing it, though.

Locking:

On the subject of locking, I’ve noticed two games that were at the opposite ends of the spectrum in this regard – the original price of persia, from the 80s, had almost every animation/action in the game be locking; if you entered a walk animation, you were stuck until it finished – I found it incredibly stiff and frustrating. On the flip side, because it has almost no real player-animations to speak of (a 2-frame walk cycle, and just some directional aiming-frames), the famous “cave story” features almost no locking whatsoever – I think this is one of the bigger factors in how appealing its controls were; the player-character always responded when you pressed the controls. Period. You never felt like the game had unfairly trapped your character when you tried to dodge something.

Fear of graphical-interpolation issues were, I think, the source of Prince-of-Persia’s design flaw. They didn’t have interpolations between every possible state, and because their animations were slow and long, interrupting them and snapping into a different one looked ugly enough that they decided not to allow it. This also solved the “disappearing attack” problem mentioned above. I imagine the reason they didn’t do interpolation was that having full interpolations between every possible animation in a game with large sprites is not just a lot of work to draw the graphics, but to write the logic, it’s a combinatorial nightmare.

States:

The state issues were a big strategic change, because most of these were done with variables; when you entered a state, you set a variable, and when you exited the state, you had to clear it. What was bad about this was that these variables sometimes wouldn’t get set at all, and then mismatched the appearance of the game. For example, if something doesn’t get set at the right time, one of frogatto’s projectiles could end up being completely harmless to an enemy. This breaks the absolute basics of videogaming – gamers form a mental model of what the rules are supposed to be in your game, and this makes out like the rules randomly don’t apply sometimes. No reason for it, no predictability, just “hey, that didn’t deal damage when I spat that enemy out… what the heck?”

The problem we had is that we’re a physics-based game, and by design, we’ve got more code-paths than we could ever anticipate. The player can execute moves largely in whatever sequence they want – usually the more freedom, the better. They can bump into things, do all sorts of crazy combinations of stuff we could never foresee. Now, we could try to play “whack a mole” and slap these variable-changers on each and every possible switch between modes, but it’s a bad idea because it takes a ton of time and effort to nail every last one, and the moment we change anything or add any new moves, there’s breakage because we’ve just added new paths.

Instead, it’d be ideal if we didn’t need to track those paths at all. If we didn’t have to set “state-tracking-variables”. It occurred to us: “hey, if we’re establishing a contract with the player where certain appearances are supposed to indicate certain states… why don’t we directly check the appearance?” So for a lot of things now, rather than storing our states, we try to make every state in the game “derived”, and we treat the appearance itself as the storage (or in some cases, the underlying physics; like what velocity something has). We do this now for what team something is on (who they’re able to hurt, that is), how much damage they deal, etc. It rocks, because it doesn’t matter how you get into, or leave a state; if you’re in it, you get the right settings during it.

Leaks:

Leaking behavior, such as “random ways stuff could get out of a stun early” was another big problem. We fixed these with a new system where objects change type during certain states. Changing type means swapping out the object’s entire bank of logic to remove all the stuff we don’t want to happen. In the past, for example, an object like the “water beetle” had all of it’s “land mode” and “water mode” code in the same file. All of those “behavior patterns” for the land-mode were sitting there just waiting to be triggered by some weird thing we didn’t anticipate, and thus didn’t turn off, underwater. Now, those are in two separate sets. Once something is underwater, all those little logic/behavior hooks from when it was a walker, are just gone. There’s no way they can trigger by accident.

The most frequent time when objects currently change type is for their thrown state. Walking objects tend to have tons of hooks in them that return them to their walk animation, and it was extremely common for enemies to escape a stun early by just having some other enemy bump into them, or something.

Hooks:

Another primary motivation of all this was to cut out any instances of code duplication, and to set up our damage system so that all of the different parts of dealing damage (the knockback, the cooldown, the amount of damage dealt, the named ‘type’ of the damage, the graphical effects from it, etc) were all split into separate functions, so that each of these could be overridden (a bit like subclassing) individually without clobbering all the rest. This keeps all our monster behavior more consistent (we had about 3-5 inconsistent implementations of things like flashing-after-getting-hit, for example, because every time we overrode one thing, we had to override everything), but it also paves the way for future additions. One thing we have in mind is a much more interesting powerup system; but we couldn’t do it without a clean framework to build off of.

Plans/Wishlist:

We’ve still got a bunch of little bits we’re not so happy with.

– frogatto’s tongue should grab the acquirable goodies, like coins and such. One of many easy things we haven’t gotten around to.

– some enemy projectiles that are slow when fired by the enemy (because otherwise they’d be unfair) are strange to remain slow when frogatto spits them. Acorns and metal balls come to mind. Should be an easy fix.

– the general mechanics (especially the vertical limitation that keeps you from climbing without a column to bounce back and forth in) of the walljump are as we want, but there are a few things we don’t like about it. Far and away the worst, I think, is how it breaks the flow by “reflecting” horizontal movement if you miss a jump, and hit a wall. This is especially bad if you just barely miss the lip of a ledge. Because of our controls, you usually leap in the opposite direction. I don’t know how we want to address this.

– the walljump’s downward slide is also a little frustrating, and I’m not sure it needs to be present at all.

– frogatto’s enhanced spit power changes the trajectory in ways that make previously easy shots hard. Upgrading the spit power seems like an easy idea on paper, but in practice, I’m not sure it’s a good idea to have the upgrade at all. (We’d probably consider replacing it with something equally rewarding, but less awkward, such as something that increases how much damage spat enemies deal.)

Hey there:

Is there anything in the gameplay that currently bugs you, but we haven’t mentioned? Anything we have mentioned, and you also are dying to see? Please leave a comment!

I’ve removed a bunch of the white outlines that just created visual noise, and I’ve also removed a bunch of the chartjunk. Should be much cleaner and more readable, sorry about not doing it right the first time; I have to make mistakes to learn what not to do.

You’ll also note the giant download button that’s now easy to find for a change. We’re hoping to do a mozilla-style “make that link right to your platform’s binary” deal, with a little “other versions” link underneath, but that’ll wait till we have time to figure out the browser detection script, etc. If anyone knows how to do that, and has some javascript for it, by all means, please leave a comment. Anything that can expedite my having to do the research would be great.

Frogatto recently got reviewed by a Serbian web/tv show called “Interfejs” (e.g. Interface). (Forgive us for any inaccuracies, since we know nothing about the language.) Seems to be a good review, from what we could cipher out through google translate. You can view the original review here, or if you’re like us, you might need the help of the google-translated version.

Thanks guys!