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.

We’re finally getting confident enough to aim for the big leagues – and Valve’s Steam platform is definitely that.

The Greenlight process for getting there has been revamped recently, and approvals are happening more quickly, but we really need your support! Please vote for us, and tell your friends! Only with your help we can reach out and become available for the biggest community of video game players in the world.

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

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.

Frogatto is now available for sale for PC and Mac on the Humble Store! Go and get it here!

If you’re curious about what Frogatto is all about before purchasing, check out our trailer:

(Edit: Since a few people have been confused by this, it’s worth noting that the “Humble Indie Store” isn’t a storefront site like Amazon or Steam which you can go to and look at a whole selection of games in (despite the fact that the HIB is kinda close to being able to do this for their periodic bundles). It may become that at some point, but for now, it’s just a widget on individual game-developer’s sites which you can use to buy the game. So if you go looking for a “Humble Indie Store” to buy the game in, you won’t find one yet; instead, you’d need to go to our downloads page to get it from there.)

Hello everybody! We’re all excited over Chasm, and they’re having a stream over here for the next few hours! They’ve asked us to do a bit, so there’s a conversation you probably won’t want to miss. Link is: http://www.twitch.tv/discordgames. This is the last day of their kickstarter, over at http://www.kickstarter.com/projects/discordgames/chasm.

[edit] Event’s over, now. It was good. It was funny! Luckily, you can now watch the whole four and a half hour video at http://www.twitch.tv/discordgames/b/402407399. The bit where they play Frogatto is near the beginning, after some Castlevania. The show features an extended interview with our very own artist Jetrel; and our musician Ryan drops by about half-way through the game.

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!

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)

Cube Trains 1.0 is done, and available for download from http://cubetrains.com. It is a puzzle game about laying train tracks through a city, in 3D. It’s also free.

There is no limiting mechanism on the number of pieces you can place in a level, except for how many you can fit into a given area. While some games, like Isoball, will give you a set number of pieces to solve the level with, this merely limits the fun. Cube Trains lets you build as much as you want. Of course, there is some difficulty — it’s quite hard to actually beat a few of the levels, as there is barely enough room for you to build what you need to. In addition, each piece you use raises your score, and you may want to complete levels with the lowest score.

The game also features infinite undo and redo, along with the automatic placing of “obvious” pieces. This makes things much more convenient, in the long haul. If you’ve ever wanted to undo the last action in Sim City or Civilization, this feature is dedicated to you.

Cube Trains was made with the Frogatto engine. Because of this, it should be able to run most everywhere Frogatto runs. Currently, however, it is only really available for Mac OS X or Windows as you have to compile it yourself on Linux.

Download it here.