Frogatto & Friends

Frogatto sprite

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.

Frogatto is on Steam!

September 2nd, 2023 by Jetrel

At long last, we’re pleased to announce the release of Frogatto version 4, which is immediately available on Steam. We’d like to extend a huge thanks to all of the contributors who made this possible, and helped us through the long-haul to get this release out — Thank you!

This release features major additions to the game — we’ve almost doubled the total number of levels, including many new “secret levels” you can find along the way, as well as adding dozens of new enemies, three major new actbosses, and a total remaster of most of the animations in the game as well as large parts of the scenery art.

We’ve got an exciting roadmap of future releases planned, which we’re intending to release on a much faster cadence of “every several months”. Future plans involve enhancing a bunch of enemies to be much more cunning opponents, adding numerous puzzle elements to levels that don’t have them, and doing a major overhaul of player abilities and quest items.

Thanks for tagging along with us on this journey, and we hope to have lots more excitement in the time to come!

FacebooktwitterredditmailFacebooktwitterredditmail

Inventory screen progress

September 22nd, 2015 by Jetrel

(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:

vVHzHtn

And here’s what the background for the map will look like (we don’t have any of the overlay drawn on this yet).

z23htXH

FacebooktwitterredditmailFacebooktwitterredditmail

The Fruits of July

September 21st, 2015 by Jetrel

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

FacebooktwitterredditmailFacebooktwitterredditmail

Content Updates

September 21st, 2015 by Jetrel

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.

FacebooktwitterredditmailFacebooktwitterredditmail

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

FacebooktwitterredditmailFacebooktwitterredditmail

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.

FacebooktwitterredditmailFacebooktwitterredditmail

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

August 11th, 2013 by Jetrel

(Update: Kickstarter successfully funded.)

https://www.kickstarter.com/projects/523651724/legend-of-iya

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.

FacebooktwitterredditmailFacebooktwitterredditmail

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.

FacebooktwitterredditmailFacebooktwitterredditmail

Support the Musician!

May 9th, 2013 by Jetrel

DONATIONS GO HERE <-

Ryan, our music guy, is also working on another project right now, called Seyken: Crystal Kingdom. I’m going to do a post about this project sometime soon, because it’s awesome, but I’d rather not rush it and fail to do it justice.

One thing Ryan’s struggled with for the past few years is a lack of decent orchestral sound libraries to work with – he did amazing stuff, IMO, with the tools he had, but he always complained about the limitations of what he was working with (in terms of expressiveness and flexibility), and a substantial part of “doing good work with lousy tools” came from carefully avoiding the weaker instruments in the libraries he had. Which is fine some of the time, but sometimes you really want to do an epic string section, and without the right tools, you can write the best sheet music for it, but crummy midi-sounding samples just won’t do it justice. Buying better ones is tough when you’re on a shoestring budget.

So with the support of this new project, he’s doing a fundraiser to get some better orchestra samples. If you like frogatto’s music – please support him in doing this, by donating to this fundraiser!

FacebooktwitterredditmailFacebooktwitterredditmail

Platformer Enemy Design

January 3rd, 2013 by Jetrel

Just read a pretty insightful bit about what “Super Mario Bros” (the original NES title) did right. Like most wanna-be game-developers, I’ve spent quite a few years speculating about game-design; trying to shake out some set of principles that could describe why some games are good, and others are not. When we started working on frogatto, it was no surprise to me that there were quite a few crucial design points about platformers which I had never considered beforehand. As we worked on the game, we’ve noticed that a number of aspects just weren’t fun, and we’ve gradually tried to suss out … why?

This blog post nailed one of the precise design problems we’ve run into which I’ve been trying to address since 1.0; when we originally added the forest, cave and dungeon sections, we simply didn’t have enough unique gameplay to float them. We were short on both unique enemies and puzzles, and although the first part of the game advertised some enormous promise, the second 3/4 did not. But it wasn’t simply a matter of adding more monsters; they had to add that nebulous quantity of “fun”. I actually burned quite a bit of time figuring out what the hell ‘fun’ even means when you’re designing videogame enemies; there are at least 10 partly or un-animated monster designs that have been prototyped, but which we’ve wholly axed between then and now because they just weren’t fun.

I think one of the big things it started with, which is an excellent foil for exposing the mental traps that underlie almost all of the other problems was an idea that monster viability should be independent of the level around it. It was in fact a bad idea. Do not try to design creatures which can work in any possible level layout; it’s possible, but it’s enormously complex and time consuming, and it doesn’t add a lot of benefit. There are a number of reasons people fall into this trap:

If you’re also a general engine project like we have been at some points in the past, the philosophy of generality bleeds over. When you’re designing a general engine or a general game editor, you can fall into a trap of wanting to insulate against all possible “bad surprises” for your users. If a user places something, they shouldn’t have to know anything about it; it should Just Work; it should negotiate all possible mismatches/design-incompatibilities/whatever to just magically figure out its setting, adapt, and function the way the user imagines it should. This is how, for example, vector art behaves in an otherwise internally raster-based program like photoshop; it’s a square peg going into a round hole, and the glue to make it “just work” is considerable.

For one example, consider making a flying enemy with basic behavior that makes it fly from one X position, to another X position. In a generous, open space with no terrain in the way, writing this is trivial; you give it constant acceleration, and make it reverse direction once its position exceeds a certain value. Easy. It seems reasonable, from a level-designer’s standpoint, that it should always work regardless of the layout; all it’s doing is just pathfinding from point A to point B, right? So if you put it in a twisting corridor, it’ll naturally duck under the outcrops, and rise over ridges to find a path back and forth. Except actually it won’t, because in the implementation I just described, there is no pathfinding. There’s no AI; there’s just one, single line of code with two conditionals in it.

The pitfall, there, is assuming you’re catering to that imaginary user with entirely reasonable, but difficult-to-fulfill expectations. You’re not; you’re writing a game which has an almost certain probability of being edited by only one person, and in the absurdly unlikely event your game DOES become popular with a modding community, you should assume that modders will have a high correlation between cleverness and productiveness (those who are baffled when a monster doesn’t work right in certain circumstances will have a lot of difficulty getting a great deal of other things done, and aren’t likely to get anything done), you should remember that it can always be improved later, and more than anything, you should remember that there won’t be a modding community in the first place if you don’t ship a game they can become fans of.

Apart from bending over backwards to please a hypothetical user, the other idea that can lead to overbearing generality is an idea that you, yourself will benefit from being able to use that same creature everywhere. There is truth to this – one really good, really clever enemy can get some great mileage … but it depends on whether it changes gameplay from the player’s perspective. Most specifically; is the player being forced to make different decisions than usual in order to deal with this threat? At it’s most basic level, a game is a series of interesting decisions*; if you do a boatload of work on an enemy to make it work in different situations, but the basic decisions the player faces are still the same, you’ve wasted your time. The basic gameplay is still the same; you’re just jumping through hoops to provide it. At worst is when you do something enormously difficult to implement, and (perhaps due to the enemy generally being offscreen), it’s entirely invisible to the player whether you did or didn’t do it.

Perhaps most tragic is when someone has a personal vendetta against something that disappointed them in their youth; say, using a Doom level editor and finding that some creature just glitched out in some situation that never happens in the real game, but happens in the particular edit you were trying to make. As a starry-eyed kid, you think “These guys were so lazy to have not fixed this obvious flaw. By golly, when I grow up, I’m gonna do this right when I make a game!” This sort of thing typically is called a sacred cow – it’s a rule you follow and never question, but it’s a rule that you made when you were a pretty naive kid, and you didn’t base it any thought about game design; you based it on strong feelings of disappointment – even if it worked flawlessly the way it was meant to be used, and provided wonderful entertainment for you the other 99% of the time. The danger of the ‘sacred cow’ is it’s namesake – is your refusal to remove something that is very costly to you. You’re now an adult; it’s time to put away childish things.

Sacred cows can bleed out into being more general gameplay mechanics; one which we held onto for quite a while was that all creatures in the game occupied strict rectangles of solidity. Unless a creature was somehow literally ethereal (like a ghost), we intended to make sure that all creatures followed physical rules; they can’t cheat and go through walls, and if multiple instance of them are in too tight a space, they can get congested and form a traffic jam. We abandoned this ages ago (shortly after 1.0), but earlier on, this caused some enormous mental blocks. The greatest tragedy behind this was we couldn’t provide any concrete reason why ‘realistic behavior’ made the game better; we simply had a personal vendetta against the idea (perhaps it felt like cheating on the computer’s part when we first encountered it in a game?) and we were determined to avenge that slight. What a waste.

It’s basically cost/benefit analysis, with one key idea: always remember your goal is to ship this game. Not to make some modder’s paradise. Not to make the perfect system. Not to write the next GameMaker or Unity. If you’re too naive to settle for the extraordinarily impressive feat of just shipping a game, I can’t help you. But if you’re mature enough to have already settled, the mantra can’t be repeated enough, because it’s so easy to slip back into these traps.

The way this hurt frogatto ironically wasn’t because we spent a lot of time writing something astronomically complex, but it hurt us because I wrote-off a whole panoply of monster ideas as not worth pursuing because they were insufficiently general. I saw a few cases where a given design would be hopelessly, hilariously inept, and decided that if there was anything in the game that could ‘bluescreen’ a given creature, the whole design of the creature was flawed and shouldn’t be considered, period. It seems to me that almost all cases where I have some sort of writer’s block or difficulty brainstorming are because there’s some internal “governor”; some ruleset in my head which I’m not fully aware of, discarding ideas before they’re fully formed. When this is in effect, I try to brainstorm about something and it just seems like “there aren’t any good ideas to be tried”; as though the problem lies in an exhausted possibility space rather than my dismissive perception of it.

So here’s a list of things that blog post touched on which are good design points for platformers – I think the mental self-analysis above is more important for deriving these from first principles, but these are worth hashing out a list of if you’d like cliffs notes:
– monsters need only work in one well-suited level layout geared towards them; it’s entirely okay for them to glitch out or just be helpless in others. Just don’t use them there.
– allow monsters to cheat and do things like pass-through-walls (c.f. our bats) if their physical limitations stand in the way of a fun enemy design.
– monsters need to vary on multiple dimensions of behavior; it’s fine to pick a few easy-to-do behaviors like giving them more HP/Speed/Damage, but each of these can only be used once. In fact because these particular easy-to-abuse ones are incredibly common and familiar to gamers, these have very little mileage, and you should really only do one “same but better” variant. Two is pushing it.
– aim for interesting effects that can be achieved with implementation simplicity, and if possible adjust the level to keep their implementation simple.
– simple behaviors can get much better mileage with slight twists. Tweaking a shooter who’s a sitting duck on flat ground to be able to shoot down from an inaccessible, high position the player can’t retaliate towards, can grossly extend the life of your current content.
– You can make the game feel deeper; i.e. you can fake complexity, by combining similar twists with different environments; a basic idea like an enemy that jumps should be put to use on two different enemies in sufficiently different levels that the threat posed is completely different. If you make this second monster look completely different, and have different timing/etc, it will feel much more different than its implementation actually is. Ideally it may feel entirely different even though internally it’s mostly the same.
– enemies can and should be combined to make much more challenging puzzles; one enemy can provide a necessary means to defeat another enemy (tricking two enemies into shooting each other, or one enemy providing ammo to defeat the other). Another twist is that if you place enemies together, don’t just haphazardly combine them, but put enemies whose particular abilities don’t contest each other. Putting a shooter who can fire shots down at an area with a walker (making you dodge whilst you deal with the walker) is much more interesting than just two different walkers.
– make enemies which require entirely different actions to defeat. If you’re a shooter, make some enemies that are entirely immune to being shot at with any weapon whatsoever, and which instead need to be dealt with with some different gameplay verb entirely (perhaps the player has to perform some physical move in the game to them (jumping on them, or kicking another enemy at them), perhaps they have to be led into traps or pitfalls. Perhaps they have to be led to mutually destroy each other by causing them to aggress against another monster rather than the player (caused maybe by one accidentally shooting another in the back).

I expect I’ll probably need to write a follow-up to this. As it stands in the game right now, I’ve been working hard to differentiate monster designs, but there are definitely a couple early enemies (which is a bad first impression) that are painfully similar; the closest are the ants, and the beetles (both the regular and water-beetle variety). I had an idea that the former could die from being jumped on and other could bounce, but I feel like something more interesting could done (new animations like flight are on the table as an option). Fumpers and rabbits are close enough to squeak by, although I should be careful to avoid making future designs that work too much like them. Some mechanics that are dying to be exploited are mutually-destructive enemies (moth-bombers being our only example), and enemies that strictly require powerups to kill (shooting the wings off high fliers being an only current example).

Tangentially related, but there’s also another worthwhile post which is targeted at RPG design but actually applies just as well to platformers.

* (credit to Sid Meier)

FacebooktwitterredditmailFacebooktwitterredditmail