(Backported from Steam Greenlight.)

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).

(Backported from Steam Greenlight.)

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.