Frogatto has just gone on sale on the Mac AppStore! (It’s $1 at the time of this writing.) A new feature that comes from this is automatic updates, which we haven’t had before.

As a thank-you to our existing community, and because the Mac AppStore is intel-only, and Ryan and I (and others) are still on PPC, we’re going to keep a free build of the game available on this site. If you like frogatto, please support us by buying the game on the app store, or donating via our paypal link.

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!