Things we’ve been working on over the last month:

– cleaning up lots of little things in gameplay.

– scads of optimizations here and there (the game is liquid-fast on any modern PC, but handhelds like the iPhone are effectively like a decade-old desktop computer, and some aspects of the game needed to be rewritten to run quickly on that). An upside of this is that it considerably widens the scope of computers that can run this – practically anything with just basic OpenGL support, 40mb of free ram, and a >500mhz processor can run it just fine.

– additional cave and forest levels, mostly thanks to “shadowmaster”.

– some additional monster designs

– making locks into visible objects, and adding functionality to have to physically grab a key and drag it to the lock to unlock it.

– working on a few new cutscenes, and polishing up the game’s ability to handle boss battles.

– a new basement tileset (Attentive pixel-artists will note that this hasn’t been cleaned up to tile nicely, yet, especially on the background wall.)

– Last but not least, we’ve overhauled how we do dialogue – rather than having portraits for individual characters, we’ve switched to animating their sprites to convey emotion. We now zoom-in the game screen to make the animations visible, and we’ve changed the speech boxes to (stylized) speech bubbles to indicate the speaker.

We’ve upgraded the world-map’s logic; it’s now got text-labels on each of the locations, and rather than (in debug style) being accessible from the main screen, the map is accessed as we’d intended it – there are a series of magic pedestals you can stand on to be whisked away to the map; these offer a network of shortcuts between key points in the game, so that if you need to backtrack to finish a side-quest, or collect a special item, you can do so.

These are currently accessible by default, right off the bat, but we intend to make them something you have to unlock by completing a quest in the game.

We’ve cleaned up a bunch of the movement mechanics with ants, and frogatto spitting them – they now sit stunned on the ground for a bit, and flash when they’re about to recover.

We’ve also removed the “exploitable” behaviour wherein spitting an enemy into a wall at point-blank range would kill it – now, it simply reflects backwards, passing through the player. We’d put that in to handle that edge case, but (as we feared) it was such a convenient way to kill them that it was being used more often than the normal methods.

Long, rambling aside on game design:
Some designers might not care, but exploits like that, in my opinion, tend to break the ‘immersion’ of a game, because they’re a jarring reminder that it is just a videogame. They’re a bit like “a glitch in the matrix”, if you will. Most games have issues like this, and one or two won’t kill a game, but they do add up, and enough of them will cheapen the experience.

This example in frogatto was a fairly weak one; a much stronger one might be a classic RPG which happened to allow you to toss items from your inventory at enemies – and in which by whatever accident, tossing a shoe did more damage than the intended spears or knives. It’d be amusing, sure, but the key problem is that it robs the game of the intended experience, which is fighting with actual weapons. (I’ll leave arguing whether sticking to the intended experience is a good or bad thing to another post; generally speaking it tends to be bad, because it tends to have very shallow assets to it – the creators didn’t expect it, and therefore didn’t create art/scripting/custom-interactions/etc for it. It may happen to work, but it’s usually buggy, ugly, and sometimes outright able to crash a game.)

Another argument against it is that – if some exploit causes something the programmers and artists invested a bunch of work making, to get completely neglected, then their work on that thing is wasted.

On the flip side of things, accidental gameplay exploits like this can be an excellent way to discover emergent gameplay. Designers tend to have a kneejerk reaction of disparaging/correcting anything that didn’t fit their initial plan, but the ultimate goal of gamemaking is to have fun gameplay and “fun” is notoriously hard to invent. If you stumble across something that’s really fun, by accident, it might be worth changing the plan to accommodate it.

We have a cave background now. Woohoo.

This brings us most of the way towards having the cave environment done, although we have essentially no enemies/traps for it at the time being.

Like most things parallax, a still screenshot doesn’t quite do this justice; it doesn’t convey the sense of depth this has ingame.

Edit: I also drew a new font. The old font was quite typographically schizophrenic and just plain amateur; this font tries to actually follow rules like having consistent x-heights, and consistent ascender/descender lengths. The previous one was just a quick hack job to finish any small font at all, so we could implement the text-label object (which lets us place arbitrary text labels on levels).

It’s an overdue category, really, since there have been a couple of things I could well have blogged about in the past that’d fit it like a glove.

Recently, we’ve added several levels to the latter half of the seaside environment; these go right before the town. (Cred goes to a friend of ours by the nick “shadowmaster” for doing some of the heavy-lifting there.) These flesh out the area to be decently interesting to play in, and have a number of puzzles and secret areas in them, unlike the prior levels which are significantly (and deliberately) simpler.

Right before the town, we’ve also added a shop, with items you can purchase; the list of purchasable items is not considered final, because although they’re neat ideas, some of them might be destructive to puzzles and such. If so, they’ll be replaced.

We’re also hard at work putting together the town; we’ve already got a small “miniboss” fight working, where you square off against some of the henchmen of Milgram (known as the “Milgramen”), who (as you’d know if you’ve played our previous releases) has taken the town hostage. These soldiers are guarding the gate to the town, and ambush you as you try to talk your way in.

The town itself is also being worked on; the whole environment will be very different from the relatively free-exploring, fight-with-random monsters levels that led up to it; it’ll have doors to unlock, and puzzles involving the rescue of various townspeople (a term which is understandably used quite loosely). At the end of the town, you’ll be treated to the very first boss fight of the game. 😀

We’ve added an alpha-version of a world map to frogatto. Like in many classic games, you’ll be able to use this to also teleport yourself to the listed locations on the map. The graphics in this are really an alpha ‘sketch’ of what the final version will look like, but the programmed motion of the camera feels quite nice already.  Here’s a video of it thus far, on youtube:

We’ve updated the forest tree trunks to look considerably more organic, and to have more tiling possibilities for branches. As a result, we’re now starting to work on actual forest levels.

The new interiors mentioned earlier are in the game, now.

After a bunch of work, we have a useable set of ground tiles for the forest, which means (pending some additional branches for platforms) we can go ahead with making all the forest levels soon.  Here’s a preview of what it looks like:

Frogatto implements a common feature in modern tile-based games, called “auto-tiling.”  For those who aren’t familiar, here’s a quick description.

a typical 8-bit brick tile

The earliest tile-based games, usually 8-bit or pre-8-bit games like super-mario brothers, had very simple tiles.  For a given kind of tile, they typically only had a single image.  They didn’t have borders, they didn’t have edges; no variations.  Just one, single image which would get repeated over and over again.  This was about all they could achieve with the limited graphics and memory on ancient systems; with the few colors available onscreen, and with tools to make game graphics in their infancy, it was more of an achievement to ship a game at all, than to try the herculean task of trying to make it look good.

Borders:

some early, bordered tiles from frogatto

The next obvious step was making tiles that had visible borders  Rather than drawing just one tile, you would draw a set of tiles that had a visible edge on them.  The set of possible arrangements of one tile next to the surrounding 8 is finite, and can be completely drawn;  the set of common arrangements is even smaller, and if you choose to draw only those, it actually becomes trivial (perhaps only some dozen unique tiles to provide all the common arrangement).  After that, perhaps you would make a few unique variations of common tiles; alternate versions of a tile to be randomly used to make something more organic.

The problem:

To anyone who has worked on creating levels for a videogame, this creates a great deal more work, not merely in making the graphics, but in editing the levels.  Editing the levels is much like using a simple bitmap graphics program (like ms-paint), you select a type of tile to place, and you click to ‘draw’ them with a pencil tool.  The problem is each different border tile gets treated as a separate thing you have to choose to place.  Where before you had only one ‘brick’ tile, you now have over a dozen of them, each representing a possible border arrangement.  You have to constantly flick back and forth between your palette of tiles and the level you’re placing them on, whereas before you could just select one tile, and freely paint a whole section filled with it.  It’s a classical “efficiency expert’s” nightmare.

The Solution:

What autotiling automates.

The first thought that popped into anyone’s mind, frustrated by this, was “geez, can’t we program a computer to do this for us?”  Given the simple, mathematical nature of the problem, the answer was “yes”.  Autotiling is exactly that.  It is a system where, as you draw tiles onto a level, the game automatically checks the surrounding tiles and places the border tile appropriate to that spot.  All you have to do is select a general type of tile, such as brick, or grey stone, and draw in the arrangement you would like;  the game automagically picks the correct arrangement of borders appropriate for what you placed.

An set of the components needed to freely arrange borders.

In an upcoming post, I’ll describe how frogatto’s auto-tiling system works from the programmer’s point of view.

Neorice made some new interior graphics; these will replace the current ones in-game, once I deal with the joys of figuring out the tiling logic.

We also have a new set of scaffolding tiles in the game already:

This is an example of just how flexible these new scaffold pieces are: