About Frozen Fractal (twitter: @frozenfractal)

Hi! I’m Thomas ten Cate, a Dutch indie game developer who goes by the name of Frozen Fractal. I have been developing games as a hobby since I was a child, tried to do it for a living after finishing university in 2009, failed, and got a day job at Google in 2011. Then, late 2015, I felt sufficiently more experienced and motivated to give it another try, so I’m now developing games fulltime again.

Though mainly a programmer, I’m a jack of all trades: I do my own game design, programming, graphics, publishing and marketing. Only music and to some degree sound effects are left to dedicated professionals.

My focus is on small, innovative games in a variety of styles. Target platforms are currently web and mobile, but my ambition is to eventually get enough experience to build a PC game with a bigger scope.


Ludum Dare 36
Ludum Dare 35
October Challenge 2015
Ludum Dare 33
Ludum Dare 32
Ludum Dare 31
Ludum Dare 27
Ludum Dare 26
Ludum Dare 25
Ludum Dare 24
Ludum Dare 22

Frozen Fractal's Trophies

Frozen Fractal's Archive

Leonardo’s Painting Machine

Posted by (twitter: @frozenfractal)
Monday, August 29th, 2016 5:06 am

This… is Leonardo’s Painting Machine!

Leonardo's Painting Machine

The Painting Machine is one of Leonardo da Vinci’s lesser known inventions. In fact, before this game was released, nobody had ever heard about it.

This ancient machine is programmed using up to three punch cards, and the aim of the game is to reproduce some of Da Vinci’s most famous abstract pointillist paintings. It starts out easy, but the difficulty ramps up quickly, and the later puzzles can easily take an hour or more to solve.

The basic instruction set features movement and painting commands. Each punch card paints in a different colour. For control flow, you have jumps, conditionals and two numeric registers that can be incremented and decremented. Is it Turing-complete? No idea!

The game is playable in the browser, so what are you waiting for?

Something wrong with the coolness system?

Posted by (twitter: @frozenfractal)
Sunday, April 24th, 2016 4:36 am

This is weird:


My game received 71 votes so far, even though I’ve only found the time to cast 17, more than 4 times as much as you’d expect! The game doesn’t appear on any external sites, YouTube videos, or “best of” posts, as far as I could find. So how are so many people discovering and rating it?

One theory I have is related to the new search shortcuts bar:


Note how it says “HTML5” even though the submission form prefills the word “Web” by default. So maybe it’s because my game has “HTML5” in its description?

If this is causing this huge vote skew, something should be done about that, because this seems pretty unfair to people who happen to work on less accessible platforms. Ideally, of course, we’d have a dropdown for platform selection, but I’m sure PoV is working on that in the new version :)

The search function could use synonyms, so that a search for either term would also come up with the other (throw in “WebGL”, “browser” and maybe “JavaScript” while you’re at it). If that’s hard to do, I’d suggest to change the search shortcut to “Web”.

Mighty Morphing Princess Maria (postmortem)

Posted by (twitter: @frozenfractal)
Thursday, April 21st, 2016 9:37 am

Princesses, snakes, and bears, oh my! In the form of Princess Maria, or some other form, make your way through 10 levels to save your fiancé, Plumber Pete, from the claws of an evil monster! Taking inspiration from The Talos Principle, Portal, Sokoban and a certain classic platformer, Morphing Maria is a top-down puzzle game in which you change shape to accomplish your goals. Each shape brings unique abilities that help you reach the exit.



I had a slow start on Saturday, because two other ideas were kicking around in my head. Initially, I wanted to make a murder mystery in which the murder appears to have been committed by a werewolf, and your task (as the detective) is to find out who it is – except that it would turn out that werewolves are superstitious nonsense, and the actual murderer just made it look like that to pass the blame on to someone else. But I realised after an hour or two of drawing up characters and plot elements that this idea was too risky for the Ludum Dare compo, because it’s an all-or-nothing affair. If even just one clue is missing, or the ending is missing, or basically anything else is missing, you have nothing at all. And it couldn’t be a text-only Twine story either, because that tends to make every clue way too obvious, unless I buried it in heaps of useless details for which there was no time.

Plan B was a platformer in which you change shape between a robot and a car, like an Autobot. As a car, you can go faster so you can use ramps for jumping. But it turned out none of the tools/frameworks I was willing to use would support these kinds of physics, and I would have to figure out a non-Tiled workflow (probably Overlap2D) to boot.

Then Plan C popped into my mind, which was basically what you see above: a puzzler where each shape confers particular abilities and limitations.

It was a perfect test case for learning more about HaxeFlixel, which I’d so far only used for a Hello World project, but want to get more familiar with because of its supposedly great portability to the web and mobile platforms alike. So the programming took a bit more time than usual, but by the end of Saturday the core game was basically feature-complete.

Artwork was all done in Gimp. I would love to have a better tool some day, especially when it comes to animations. I’m still not great at pixel art, so I’m sorry if the bear looks like a hamster. I’m pretty happy with how the princess turned out though.

I also learned a thing or two about level design. A quick, iterative workflow is essential here! I set it up so that I could save the map in Tiled, and a quick and dirty inotify shell script would rebuild the assets behind the scene, so I could just keep the game running and click Restart to reload the new file. The tower on the right began its life as a level switcher for debugging, but when I settled on the tower theme, I decided to give it a first class spot in the game.

Sounds were all done in jfxr, without any postprocessing or editing. They could be better, but I’m not that big on “8-bit” sounds anyway (ironic, since I wrote jfxr), so I didn’t spend much time polishing them. Instead, I decided to use the last few remaining hours to add a proper ending, as well as an opening cutscene:



Want to know how that will turn out? Go play and rate!

Crummy graphics, solid gameplay

Posted by (twitter: @frozenfractal)
Saturday, April 16th, 2016 2:54 pm

Mine will be a 2D top-down puzzle game, inspired by The Talos Principle, Portal and of course Sokoban. The idea is that you can only perform particular actions when you’re in a certain shape (sorry about the squeezed GIF):


All the gameplay mechanics are in place: player movement, keys and doors, crate pushing, and of course shapeshifting! (Well, colour shifting at the moment.) The game gives you hints about what you can and cannot do.

There’s even a progress tracker / level switcher, which also lets me reload levels on the fly, which took just a few minutes to build but will save me so many restart cycles.

I have 5 levels so far, and I’m planning to have at least 5 more, for a total of hopefully 15 or so. This is my first time working with Haxe and HaxeFlixel, so I’m happy with my progress, but I’m still a bit nervous about still having over half the levels, a storyline, graphics, sound effects and music to be done tomorrow. But gameplay-wise, I think this is pretty solid already.

From Glauron to Dragon Attack

Posted by (twitter: @frozenfractal)
Tuesday, December 8th, 2015 8:48 am

Cross-posted (with minor edits) from my devblog. The original is here. If you like it, please subscribe!

I’ve been a fulltime indie for about a week now. I launched Rocket Mail for Android. More about that in a later post. So what’s next?

Next is a better version of my last Ludum Dare entry, Glauron. I sent that version to an HTML5 games portal (GamePix), where it’s now trickling in some beer money. However, some other portals refused it because it wasn’t performant enough, especially on mobile – and they were right. It seems that collision detection in Crafty.js is not exactly fast.

So I spent most of the past week porting the game to LibGDX, under the name Dragon Attack. It’s about 70% of the way towards being on par with the Ludum Dare version, and I’m making some things better as I go. In particular, Crafty.js doesn’t let you do additive blending, so drawing proper fire is nearly impossible:

Old fire in Glauron

The fire in Dragon Attack looks about a zillion times better:

New fire in Dragon Attack

Naturally, since this isn’t a game jam, and I plan to extend the game quite a bit, the code needs to be more solid and extensible. That’s part of the reason why the port is taking longer than the original. The other reason is that I’m learning Ashley as I go. This is the first time I use an entity component system (ECS), so naturally there’s a learning curve. It’s not rocket science, but figuring out the most effective way to get the job done still takes time.

You may also have noticed in the animations that the dragon moves differently. In Glauron, the dragon was controlled entirely from its head, and its body sort of trailed behind. This is why the head movement is so jerky. In Dragon Attack on the other hand, the dragon is controlled from the place its wings are attached. This makes for a smoother movement of the head (no sudden angle changes that break up the stream of fire), but does make him look a bit stiff. I loved the fluidity of the old dragon, so I will have to address that at some point, but this’ll do for now.

After I hit feature parity with Glauron, the plan is to add more content:

  • more enemies (crossbowmen, catapults, ballistas)
  • more buildings (towers, castles, cathedrals)
  • more powerups (hint: what was Smaug’s main defense in The Hobbit?)
  • more terrain types (plains, hills, mountains)
  • more decoration (trees, cattle)
  • more backdrops (night, storm, dawn)

This looks like a lot, but thanks to Ashley the engine is very modular, so I can create new things with little to no code, just by snapping components together. (In fact, maybe I will make it so that it doesn’t take any code, just JSON files.) The main effort will be in the artwork and the balancing. And hey, I can work on this fulltime now!

I’m planning to group this content into three or four “episodes”. The first will be free (and also published to browser game portals); the others will be available via in-app purchases. There may also be achievements and social integration (e.g. leaderboards shared with your Facebook friends).

That’ll keep me busy for a while!

Glauron post-mortem

Posted by (twitter: @frozenfractal)
Wednesday, August 26th, 2015 11:09 am

(Cross-posted to my blog at frozenfractal.com.)

This is Glauron, my Compo entry for Ludum Dare 33, themed You Are The Monster:

This was my eighth time participating in Ludum Dare, and I feel it’s my best yet. I’m very happy with what I got done, and there was even time left on Sunday for a relaxed dinner and quiet evening with my girlfriend.

All my LD entries have been in JavaScript, because I want the barrier for players to be as low as possible. Further tools I use are TypeScript for rapid feedback, Inkscape or Gimp for graphics, and jfxr and/or Audacity for audio. I also have a simple Ruby server script that rebuilds assets when I refresh the page, although I didn’t use it this time.

One change was that I used CraftyJS for the first time. It’s a simple 2D game engine focused on simple and quick development. It probably saved me hours in figuring out rendering, collision detection and asset loading.


Having learned from previous projects, where I got stuck with a nice looking tech demo that was no fun, I decided to focus on gameplay first of all. Crafty makes it super easy to render coloured boxes, so that’s what I started with. This screenshot is from Saturday, around 6 PM:



I’ve been reading the book Game Mechanics: Advanced Game Design lately, and it talks a lot about resources and feedback loops. The theory applies here nicely. Speed towards the ground is a “resource” in the sense that it allows you to breathe fire downwards and hit your enemies. However, having speed towards the ground drains another “resource”, namely altitude, and when that hits 0 it’s game over. So there is an interesting tradeoff here, and there are actually different strategies possible: swooping down from on high for easy targeting but risking a crash, or staying low to the ground, safer from crashing but making it a bit harder to hit anything. I think this tradeoff is a large part of what makes the game fun (although this is an after-the-fact rationalization, and I didn’t think about it in these terms while I was designing it).

Notice how the dragon already has a tail here. I added that because I initially didn’t have hilly terrain, so it was hard to gauge your horizonal velocity relative to the ground. At first, these were simply boxes that were delayed by 5, 10, 15, … frames relative to the “head”, which of course meant that the dragon would stretch when it moved faster.

The game turned out to be pretty monotonous with a flat ground, so I added the hills. It instantly looked much better and was much more interesting to play. The terrain consists of a chain of sections, each section having a slope computed from the previous section roughly like this:

slopeNext = 0.5 * slopePrevious + randomFloat(-30, 30)

So it tends to bend towards the horizontal, but shakes it up with 30° of randomness. There is a bit more to it (to avoid getting too high or too low) but that’s the basic idea.

This version also already had arrows getting stuck in the dragon’s body. It took me all of two minutes to code, because Crafty lets you reparent entities without having to do coordinate transformations, but I think it adds a nice touch. (Arrows falling back out when you pick up hearts came later; I had to do that to make the dragon not look like a porcupine after a few levels.)


Being happy with the gameplay, I turned to graphics. First up was of course our protagonist, the dragon. I liked the look of the tail and wanted to keep that dynamic aspect. So I first drew a dragon, taking care to keep its body on a straight line, and annotating it with red circles where I wanted to make it flex:


Then I cut it into little pieces to form the individual sprites:


Each piece has two “pivot points” where it connects with the previous and next pieces. The red circles are made black here again, and duplicated to both of the connecting pieces to cover up any gaps between them. Physics and player input are actually applied only to the head; the tail simply follows, by moving the pieces into place from front to back whenever the head is moved. Simple enough to do, but very effective.

I wanted to make the archers move as well, tracking the dragon with their bow, so I did something similar by splitting off the upper part of their body:


The terrain is also made out of a chain of sprites, which look like this:


The “skirts” on the sides are again to cover up holes between the sprites where the terrain curves upwards. Below each of these sprites, a black rectangle is added that goes to the bottom of the screen. Working with silhouettes is so convenient!

The dragon’s fire was the last thing I tackled. Surprisingly, it almost looked better as orange boxes than as fire! The problem was that it consists of distinct “fireballs” rather than a continuous stream. I tried making it a continuous wall of fire simply by spawning more fireballs, but this made the game far too easy! So I stuck with the fireballs and made them look somewhat good. It may be hard to notice, but they “cool down” as they fly: first the white core fades, then the yellow, and finally the orange and red.


Since the look of the game is fairly realistic, I didn’t want to settle for generated sound effects, so I used Audacity to record some from the microphone. Most of the sound was just me grunting, yelling and making swooshing noises, with shifted pitch and/or tempo, and the occasional reverb thrown in. The sound of the hearts was made by tapping a crystal champagne glass.

I’m not super happy with the soundscape, but I have too little knowledge and experience to do a better job. It’s still better than total silence, I’m sure.

Playtesting and tweaking

At this point, the game looked and felt done, but there wasn’t much of a sense of progression. A friend suggested that I needed more feedback, so I added the score counter at the top, and implemented a multiplier (where kills in rapid succession get you ×2, ×3, … the points for each next kill).

For variety, I also added the silver arrows (which cannot be burned by the dragon’s fire), and churches which spawn three hearts.

But if you got good enough, you could still just play forever, so I added some levels of increasing difficulty. The level definitions look something like this:

{archer: 4, house: 4, village: 2},
{archer: 2, longbowman: 1, house: 3, village: 2, army: 2},

So on the first level, the game will spawn four archers, four houses and two villages (a group of houses defended by archers). These do spawn in a random order, and the exact number of buildings and archers in a cluster varies, so it still wasn’t designed by hand down to the last detail.

This made the game more interesting, and hard enough that most people can’t get past level 5 or 6 (out of 10). This was good, because the game didn’t have an ending. After Level 10, the level counter keeps increasing, but all you get is repeats of level 10 which consists solely of large armies and no way to replenish your health.

CraftyJS gripes

Overall, I found working with CraftyJS very productive. The entity system is particularly great, and exploits the dynamic nature of JavaScript to the maximum. The API is well documented and held few surprises. But there were a few issues that I ran into:

  • Audio support sucks, because it uses the <audio> element. There are plans to move to the WebAudio API, but it hasn’t happened yet. When I noticed that most of my sounds weren’t being played, I switched over to Howler.js which always works great.
  • You have no control over the rendering engine. Any post-processing effects are out of the question (but aren’t supported by canvas2d anyway). Additive blending (which would really have helped to spice up the fire effects) is not supported.
  • There is only a single camera (“viewport”). If you want your game world to scroll but your HUD to stay put, you have to move your HUD inside the game world.
  • Parent-child relationships between entities are pretty weird. Instead of a proper tree, there is a flat list of entities, and the child registers an event listener to update its own position when the parent moves. As a result, you cannot specify child coordinates within the parent’s reference frame; you have to convert to world coordinates first.
  • There is no mention of performance anywhere in the documentation. I imagine that Crafty’s model breaks down at a smaller number of entities than most other engines.


Thanks for reading this far! I hope you enjoyed this look behind the scenes even half as much as I enjoyed making it. Now go play and rate the game!


Glauron is done!

Posted by (twitter: @frozenfractal)
Sunday, August 23rd, 2015 2:08 pm


It’s only 9 PM, but I can’t think of much else to add or change, so I’m just submitting this and calling it a day. Here’s the entry page, where you can play!

What’s there:

  • gameplay
  • silhouette sprites, animations, particles, dragon physics™
  • procedural terrain
  • two types of enemies, two types of buildings, one type of powerup
  • eight partially randomized configurations in which you can encounter them
  • 10 levels (I’ve only ever made it to level 5, but higher levels seem achievable)
  • scores, with multipliers for successive kills
  • sound effects

I have some ideas for other enemies, buildings and powerups, but I don’t think they would make the game substantially better at this point. In fact, I’m extremely happy with how it turned out; I think this is my best Ludum Dare entry yet.

But now, time for some R&R. All the best to those who are still working hard on their games. You can do it!


Graphics are done, it seems

Posted by (twitter: @frozenfractal)
Sunday, August 23rd, 2015 7:17 am

glauron(Click the image to play!)

Next up: sound effects. Then: more types of enemies, maybe some tweaking of the difficulty ramp, and if there’s time left, some more work on the dragon flight physics.


“Glauron” after day one

Posted by (twitter: @frozenfractal)
Saturday, August 22nd, 2015 2:35 pm

Behold Glauron, son of Glaurung, First of the Winged Dragons!


Well, okay, the wings aren’t there yet, and neither are most of the other sprites… but I’m extremely happy with how my dragon turned out.

You have to see it in motion to appreciate it, but I don’t have time to figure out how to make a GIF. So you’ll just have to try it out for yourself. Feedback welcome, via the comments or via Twitter!

I know what the theme will be!

Posted by (twitter: @frozenfractal)
Friday, August 21st, 2015 1:37 pm

OK, kidding. Just practicing my clickbait skills. But seriously, I wonder if you can just look at the most positive winner from the first four rounds:

  • Round 1: Can’t Stop Moving 1337 – 1093 = 244
  • Round 2: A World In The Skies 1329 – 1085 = 325
  • Round 3: Death Is Not The End 1231 – 1080 = 151
  • Round 4: Alone In The World 1131 – 1034 = 97 (by the way, didn’t we once have Alone already?)

So it would seem that sentiment is most positive towards A World In The Skies. Tomorrow we’ll see if I’m right…

Has anyone looked at the vote data from past LDs to check whether the result of past rounds is a good predictor?

Little warmup exercise

Posted by (twitter: @frozenfractal)
Tuesday, August 18th, 2015 1:36 pm

I’m in, and because I felt like trying something new, I had a look at Crafty.js. My friends behind the Dining Philosopher account seem to be quite happy with it. So I timeboxed myself to two hours this evening to make a little procedural Canabalt clone.


Play it here! It should get harder over time, both because your speed increases, and because the jumps become more difficult.

The source is on GitHub. The generation algorithm could use some tweaking and I suspect there is a bug somewhere, but I’m pretty happy with how it turned out in just two hours.

I made it to level 4 so far. To what level can you get?

Calling this done!

Posted by (twitter: @frozenfractal)
Sunday, April 19th, 2015 3:12 pm

My entry, Discharge, is finally done. Click the screenshot to play!

Screenshot from 2015-04-19 21:58:06


It’s my first Ludum Dare game in 3D. It’s also my first Three.js project, so there are probably memory leaks and such. But I did find that it was quite productive. I managed to cram in:

  • a custom infinite procedural terrain based on fractal Brownian motion,
  • procedurally spawned trees,
  • tree seeds that you can use to plant new trees,
  • procedural lightning, also based on fBm, with a custom shader,
  • an enemy with moderately crappy AI,
  • a skybox with custom sky shader,
  • shadows and light effects,
  • particle effects,
  • a HUD,
  • 3D positional sound effects,
  • heck, even some gameplay!

Give it a play and let me know what you think!

Discharge in progress

Posted by (twitter: @frozenfractal)
Saturday, April 18th, 2015 2:53 pm

Screenshot from 2015-04-18 21:48:49

The idea: your enemy (the cloud thing) is trying to use an Unconventional Weapon (lightning) on you. You can plant trees to attract lightning, but tree seeds can only be found by going near existing trees, which of course is dangerous in a thunderstorm!

Playable online (although there’s little gameplay just yet).

Source code on GitHub.

What makes a good theme?

Posted by (twitter: @frozenfractal)
Tuesday, April 14th, 2015 12:04 am

As always, there is a lot of discussion going on on the theme voting post around the current set of themes. So here’s my take on what makes a good theme.

  • A good theme is specific. By which I mean: it has to exclude some possible games. The theme must not be a carte blanche to make any game you can think of; otherwise, why have a theme at all?

    “Connected worlds” is great because it has to be about worlds – plural – and they have to be connected. That sounds vague, but look at any random game and you’ll probably find that it does not fit this theme. “Alone” was similarly good: specific, but not prescriptive.

    “Entire game on one screen” is a perfect counterexample: almost by definition, every game takes place on one screen, except Nintendo DS games. Sure, you can take this to mean “one level” or “no scrolling”, but then it’s your choice to narrow it down. “Minimalism” was similarly bad, because Ludum Dare games are made in a weekend, so they are minimalist by definition.

  • A good theme is ambiguous. By which I mean: it has to be open to interpretation. This sounds contrary to being specific, and indeed it is. We want to limit the spectrum at both ends: not too generic, but not too specific either.

    “Connected worlds” again fits this criterion. What are these worlds? Are they planets? Parallel dimensions? Imaginary worlds inside people’s heads? And how are they connected?

    Fortunately, most of the non-ambiguous themes did not survive the Slaughter, but “Two enter one leaves” and “Take one, leave the rest” are some counterexamples from the current set.

  • A good theme does not prescribe or suggest a mechanic. Different LD participants have different skills, use different tools and have different preferences, so if only platformers reasonably fit the theme, the vast majority will be disappointed and we get less fun games as a result.

    “10 seconds” is my counterexample here. It takes a lot of imagination to create a game that doesn’t use some kind of 10-second timer. I did consider making a game about a very big dinner with lots of second helpings, but since I couldn’t come up with a suitable mechanic, I ended up making a timer game like everyone else. Many other themes assume some kind of combat or at least conflict, such as “Enemies as weapons”. We are also seeing a wave of time-related suggestions,

As a lithmus test, I get the sense that themes with fewer words are generally better. With too many words, you quickly descend into the overly specific.

Some themes in the current voting rounds that don’t fit all of these criteria, and that I downvoted as a result: “An unconventional weapon” (implies combat mechanic), “Indirect control” (seems to be purely about the mechanic), “Time loop” (not sufficiently ambiguous), “Limited resources” (not specific enough, could apply to any game).

But I’m also seeing some great themes. Some of my favourites so far: “Discovery”, “Day and night”, “Four elements” and “Infinity”. Let’s hope one of the good ones wins!

Spinning cube! I mean, I’m in

Posted by (twitter: @frozenfractal)
Monday, April 13th, 2015 12:20 pm

Behold my amazing spinning cube!


This is from my base code, using Three.js and can be found here on GitHub (until I rename the repository to whatever my game’s name is going to be).

My previous games were all 2D, done with hand-rolled engines of various degrees of sophistication. None of them came close to the power of Three.js.

I’m hoping I’ll be able to make an actual 3D game this time, but because I haven’t used Blender in over five years, it’ll probably be mostly cubes, spheres and octahedrons. (Mmm, octahedrons.) But with fog and DoF and god rays and all the other bells and whistles that Three.js offers, I bet I can make it look good.

Complete tool suite:

  • Typescript. Seeing compile errors as soon as you save the file will be a huge time saver.
  • Three.js, as mentioned.
  • Howler.js for playing sound effects. Or I might use a Three.js plugin for 3D audio.
  • jfxr for creating sound effects. Or I might yell/burp/fart into a microphone.
  • Inkscape for vector graphics, if I want them.
  • Krita for artsy graphics, if I want them. I’m somewhat new to Krita, but it seems to resemble Photoshop closely enough that I can figure it out.
  • vim.

Calling this done!

Posted by (twitter: @frozenfractal)
Sunday, December 7th, 2014 2:53 pm








This is Toytown, my city builder game! For most of the weekend, I was really concerned that I’d bitten off more than I could chew. The simulation would not behave the way I wanted, I tweaked it here and another gameplay problem popped up there, and I felt the whole thing needed about a week of additional playtesting and tweaking.

But then I went off on a tangent, added the trees, and rediscovered the fun in this game. Really, what a surprise a bit of green can make! I finished by adding a tutorial, and am now calling it a wrap. Features:

  • Isometric graphics on HTML canvas.
  • Different building stages. How many? Find out!
  • Sound effects (from jfxr).
  • Pretty sophisticated simulation engine, including employment, pathfinding, traffic, commute length, pollution, desirability and taxes.
  • In-game tutorial.

Final thought on the theme, after mulling it over: I didn’t like it. Themes should be constraining or inspiring. This was neither. Still, I’m quite happy with what I made in the end, and it’s once again up a notch from my previous LD entries. How big a town can you make?

[cache: storing page]