A quick post about some of the internals of the game that people don’t generally see, but which you’ll care about if you’re interested in making levels for frogatto (which, by the way, we’d love if you did, hint, hint. It’d be awesome if people would make levels and post them to the forums).

You will be able to lock doors without having to edit the level in a text editor, in the next release. Right now, you have to write a dense paragraph of code every time you need to lock another door, which is very annoying. In fact, right now it’s actually impossible unless you’re a programmer, able to code in our FFL language.

We’ve wanted to fix this for a long time, but we were reluctant to, because few of our solutions seemed easy enough for non-techies. One of our ideas was to have a separate kind of door, just for locked situations, that would replace itself with the regular kind, if you’d unlocked it. Other ideas had you manually entering the id of a related door to make sure it would be locked, which … ick.

It occurred to me, recently that there’s always one correlation: doors are always pretty far apart, and locks are always put on top of them. If a person editing a level places a lock on top of a door, they probably intend to lock that door. We can check if they’re overlapping, in the code. Locks, also, are always unlocked by the corresponding colored key (something we previously had to hard-code). Since we can rely on these assumptions, we’re able to generalize this; locks now automatically lock a door if you (visually) put them on top of one. (This breaks down if you do something ugly, like making two doors overlap, but because that’s ugly, we don’t have to support it.)

So now, a task that used to require cracking open a level, and editing some scary, byzantine-looking code, is something you can do in the editor.

p.s.: This post 1/2 written by Jetrel, too. Thanks, man!

Slashdotted, Reddited, Fireballed, Penny-Arcaded, whatever the term du jour is; someone popular links to your site, and it’s overwhelmed by the bandwidth. Like everyone else, we made the poor assumption that we were somehow immune or it somehow didn’t matter, and then Notch* (one of the minecraft guys) linked to us and we went offline before we knew it.

There are ways to lower the “cost” of each web access (thus multiplying the capacity of your server), but they’re a bit complicated. Lucky for us, some of the most effective ways have been rolled into a ready-made plugin called W3 Total Cache. It takes maybe 10, 20 minutes to install, and gives you something like 10 times the capacity. Just do it.

It’s worth noting (for your edification) that in our particular case, what brought us down was something that the above still might have helped with (or even prevented a total meltdown), but the root cause was something it doesn’t address; a bad setting on our part. We failed to set a reasonable limit on the number of httpd instances (this is the program that dishes out the webpage to someone asking for it). Instead of just queueing up the people asking for the page, our server launched too many copies of that program, filled its ram, and started swapping to disk like crazy (which slowed the machine down by a factor of over a 1000, for all intents and purposes as bad as crashing the machine). “What is a reasonable limit?”, you say? That depends entirely on your machine. You would need to actually measure what apache is using under a typical load, and budget the number of allowed instances accordingly. I would recommend tools for this, but not being a real webmaster myself, they’d probably be laughable. Suggestions in the comments are very welcome.

For what it’s worth, Ben (crimson_penguin) tells me our previous setting was a limit of 253 httpd processes, each using 0.3-0.5% of the memory, each. Now, we have something less than 5. Dave, our lead coder, also notes that one ‘vicious cycle’ problem with such runaway accumulation of processes is that modern OSes generally fill any unused ram with a filesystem cache, and if you spawn enough processes, they exhaust this. This causes the system to pagefault at the worst possible time.

* in the honest and non-snide sense, thanks dude. Our poor preparedness was our own problem; we really appreciated the publicity!

I’ve just finished moving the Frogatto website, svn server, email, forum, etc. to a new server. Hopefully everything went as planned, but if you notice any problems, please let us know. If you had an svn checkout, please check the source page for instructions to switch to the new URL. If you’re that one person that posted on the forum after I copied the database: the answer is, there’s a door on the left about half way up (and please post again if that doesn’t help). If you notice the email isn’t working, twitter is a good way to get ahold of us too – or a comment here.

We’ve added a long-standing omission, somewhat bizarre for how simple it is: signs. And yes, you can read the signs with that goofy “not really any real language” lettering on them, in-game.

As an aside, as wil shipley has eminently noted, you really want to completely avoid having any text “burned into” your in-game images, because it’s total hell to internationalize. Not only do you run into all sorts of messes from the images needing to change size to accommodate different languages (some languages can easily triple the length of your text), but you also run into the problem that nearly all translators are not skilled graphic-designers, and will often do a terrible job re-creating your lettering in a different language. They’ll often botch really basic stuff like kerning and balancing letter-weight across lines of symmetry, etc. So if you’re wondering why frogatto and many other games always rely on “gibberish/greeking” to do text, this is why. It’s not just artistic caprice; there’s a strategy to it. (Having text that’s procedurally rendered, on the other hand, is fine and good.)

As you probably noticed in that picture, the colors are rather different from the usual palette in the seaside chapter of the game. We’ve just added two new palettes to the seaside environment. Here’s another shot of that verdant/green one, and then a shot of the one being used in-town.

As you can see in the above, I’ve also gone around and given all the houses some interfacing between the houses and the rock beneath them. You can consult current (~1.0.3 for future reference) screenshots for a comp, but the current seam is pretty nasty. The solution was not just a matter of drawing foundations, but a matter of drawing foundations with an irregular edge, and luminosity close to that of the rocks, so that it’s not immediately obvious where the house ends, and the rocks begin. It’s that subtle bit that I didn’t really have a grip on, before.

(click to zoom in)

Finally, we’ve touched up one of our (previously unused) palettes from the cave. What makes the new one better is very subtle. Here’s some advice on doing pixel-art color ramps (note: luminosity is in units of the L*a*b color space):

1] luminosity differences less than 10 become hard to notice, except on very large surfaces that are very gradually changing their angle of incidence towards the light. Differences below 5 are almost a sure-fire waste of a color, because a human eye, at (normal) pixel-art display sizes (which range from maybe 100-30 dpi) can’t really see these very well, and having more colors tends to lose the workflow benefits of pixel art.

2] you want to space your colors such that if you were to map the luminosity of each color ramp as a graph/function, your function’s derivative would be monotonic (e.g. don’t reverse the polarity of the second derivative, e.g. don’t let the second derivative have any inflection points). Since I imagine that sentence is largely incomprehensible to non-mathematicians (sorry!), here are some examples. These are the distance between each different color, in brightness: 5,5,6,6,7,8,10,12 is good. 5,8,4,9,12,6 is bad. 5,5,6,5,7,8,6,9 is borderline. The math-speak above is an example of how math is unique in being able to directly express ideas we can only otherwise sort of “feel the outline of” via examples, but can’t directly grapple with. Cred probably goes to my old math prof Dr. Zorn for so eloquently stating that in an article of his, but it’s true. Without math, we can kinda-sorta understand these ideas intuitively, but when you can understand them explicitly, it opens whole new worlds for you. By having rules, you can reinforce things that your intuition suggests, and also make daring leaps of experimentation based on what the numbers suggest will work. (Amongst other things, I think my understanding of math/science has seriously fast-tracked my learning to draw, since things like shading were completely demystified by it. I only started drawing at all some 5 years ago.)

3] One of those aforementioned “daring leaps” is behind much of the interesting variation in my palettes. Within reason, if you hold luminosity constant, you can change the chromacity of a palette element to practically anything (as long as you don’t go completely overboard with saturation), and more often than not, it will work. Even something insane like pink highlights on a green tree. It can help to have environmental justification (such as a blue sky causing blue secondary-highlights on a tree’s branches), but it’s amazing what still works even without that, as long as you still get the luminosity correct.

4] even in a dark scene, use a wide gamut, and just bend what photoshop calls the (luminosity) “curves” downward. Darks should still be very dark, brights, bright. It’s the stuff in the middle that should get bent downward, but without breaking the relative distances between each palette element.

We just got a really nice review from these guys.

Besides feeling great about an overwhelmingly positive review, I definitely found myself agreeing with the guy’s main critique: Frogatto is way too easy for a grizzled platforming veteran. On the other hand, being easy opens us up to a huge world of people who for whatever reason just won’t (or even physically can’t) play an aggressive “nintendo hard” game. We’ve been thinking about how to solve that, and besides a risk of changing plans later and thus breaking a “promise”, there’s really no reason to keep our cards close to our chest.

We’re most likely to do a series of tiered difficulty levels, like halo has; it’s tried, true, and does exactly what we want – getting an easy and a hard version of the game. You have the exact same levels (which eliminates an unbearable burden of trying to maintain two completely different level-sets, one of which would likely get neglected in testing), but there are major changes to the enemies on the levels. Not just more enemies, but enemies with much more aggressive twists to them. For example, imagine if our ants had the sense to turn around and dart towards you. Imagine if our kitties fired spread shots. Imagine if our flying ants did dive-attacks to intercept you. Little twists like this to the AI to make sections much more aggressive. Another thing would be lifting a few cues from an ancient mac game called dark castle (which recently had a remake you ought to check out, if you’re a mac user). Specifically, they had puzzles, very reminiscent of “myst”, which would expand their possibility space on the most difficult levels. The puzzles had additional twists on “hard” that made them more challenging.

“Particle systems” are a common feature in modern videogames; they’re used to simulate a lot of natural effects, such as dust clouds, splashing water, and other effects where little chunks of solid, or puffs of gas are emitted. Wikipedia probably can save me a great deal of typing. Frogatto uses particle systems, albeit with hard-edge pixel-art sprites as the particles, for many effects in game, such as the sparks that fly off of torches, to the water spouting from a fountain, to the fireplaces inside houses.

A common problem with particle systems is that they only begin their “simulation” when the player-camera actually is pointing at them, in order to save on processing time (and likewise, they pause it after the camera shifts away). If you consider a fire that’s constantly burning, with a column of smoke coming off of it, you’d expect this column of smoke to be complete. But smoke takes several seconds to drift upwards, and if you only start “simulating” it the moment the player walks onto the screen, it will look odd- the sky above the fire will be empty, and the fire will start letting off smoke as if it was only lit the moment you walked onto the screen (since in the simulation, it was). The pausing is not a problem, since the column has fully formed, just the initial delay whilst the empty air fills with smoke.

For quick-moving particles (such as sparks flying off of a fire), this works fine, since it only takes the sparks a “blink of an eye” to fill their full range. However, we’ve kinda dragged our heels on putting smoke into the game because of how awkward it looks for smoke to only start flying the moment you walk onto the screen. This is kind of a shame, because I’ve had this smoke-emitter effect done for months now (part of it was just good old-fashioned getting forgotten amidst all the other stuff to be done, another part was speed concerns). Here’s a picture of what the smoke looks like:

So, I’ve come up with a fairly simple solution for particle systems. Since the mere simulation part of them is very gentle on performance (it’s only the actual drawing that’s expensive, unless I’m using a ridiculous number of particles), what we do is (for only the slow particle types that need it) we automatically simulate the first couple of seconds in advance. It seems to work like a charm – probably the biggest beneficiary will be the falling leaves in the forest, since they can take as long as 10-20 seconds to fall, and the player can easily leave the whole screen before they have a chance to distribute themselves across more than a tiny fraction of it. This may take a little while, since those are still being done as objects; I haven’t had time to re-implement them as a particle-system, in part because I’ll need to add the option of sinusoidal paths for the particles.

As a bizarre curiousity; neither warcraft 3, nor (quite surprisingly) even starcraft 2, seem to do this. If you pan over a burning building, the fires will begin as though it just started burning the moment you moved the camera there. I’m guessing something in the whole structure of their game makes it considerably harder to do; in frogatto this took a whopping 4 lines of code. Age of Empires 3, by comparison, does not have this problem.

We’ve redone how shadows work, so that shadows blend an even amount in all directions.

Also, for interest’s sake, here’s an image of what it looks like when our shadows are blending with just gray, instead of blending with that purple tone. It’s considerably more lifeless; grey would seem like the “safe” choice, but in nature, the color-components of lighting on a shadowed area are often different (for example, the lighted side of an exterior setting is often lit with yellowish light, and the dark side with blue+green light). Purple just looks better in this situation.

We’ve added a new tileset to the game, which is exclusive to the new “arcade mode”. Unlike our full, story-mode tilesets, which are essentially a hybrid mix of 16×16<->64×64 tiles, intermixed in lots of wacky combinations, this tileset is a strict collection of 16×16 tiles. It’s not possible to do very organic rock faces and such in this tileset; everything will feel very blocky – however, it makes for much more flexible arrangements of tiles (since quite a few up-close arrangements were not possible with our story-mode tiles). Especially for our arcade mode, which will be based on some very tight platforming challenges, this is a good fit for gameplay.

Ultimately, we decided that rather than choosing between either style of tileset, we’d choose to have both. Why not? 😀

Also, here are some updates on forest stuff; showing off some new branches, better foliage, and one of the new palette shifts. We’ve loosely decided to save the forest stuff for the update immediately after the current one, since trying to do both arcade mode and forest at the same time is just too much to juggle – it means you’ll get an update in your hands sooner.

(click to zoom in)

Polish in games often comes from subtle, almost petty tweaks to design. Here for example is a recent tweak to the interior “side archway/door” graphics. A number of people have had trouble noticing the current doors, on the left; realizing that they’re an archway to walk through, rather than some odd decoration on the wall tiles. So we threw on a light-stream coming through it, to give it some additional contrast with the regular wall tiles.

These sort of ‘snags’ add up, and can make a game difficult or obtuse to understand; often enough to outright drive people away from playing your game. Unfortunately, I don’t have a more elegant strategy, besides ‘dead reckoning/intuition’ for preemptively identifying these kind of things – the ones that will be difficult for many people to understand at first glance. I welcome any thoughts/strategies in the comments. (besides the obvious ‘testing it on other people’)

“This tileset will really come to life once we get some decorative overlays, like metal pipes, grates, and such, but those are still in the works.” – myself, a week ago.

Delivered. Also note the use of cosmetic lighting to make dark gloomy places actually dark and gloomy, and to make light sources feel much more visually important.