Archive for the ‘LD #15 – Caverns – 2009’ Category
ok, I’m a whole compo behind, but here’s an update for my LD15 entry (Caverns). For that compo I hacked the game out in two 4h sessions, so it was missing a couple of vital elements: sound, and the ability to shoot physhaxey bullets at the attacking circles. There’s also a little bonus tune when you finish the game (thanks to Flash Module Player). Hope you enjoy it!
Also, I should have posted this earlier but the organizers of Sense of Wonder Night (TGS) have uploaded the presentations on youtube. You can see my one on Swarm Racer (LD08) here
I plugged LD in the Q&A section, but they cut that part ):
So, I finished Excavatorrr today. There’s now even an online highscoreboard included!
Download from here
Ludum Dare #15 is over, and I already wrote that the results are in. Aside from placing well in Community, which shows how much I love participating in LD48, I also saw my overall ranking come in at around the 40 percentile. I was ranked #63, which sounds good, but there were a number of ties for previous rankings. Out of 144 entries, Mineral Miner was 87th. It’s much better than coming in almost dead last in the previous Ludum Dare (and not completely last only by virtue of two other entries not getting rated at all), but I’ve done better.
Let’s look back on this project and see what happened. First, let’s go over a summary of the game. Mineral Miner turned out to be a puzzle game in which you drive around a cavern in a tank, getting out to collect minerals. You can only collect one mineral at a time, so you need to drop off collected minerals in your tank to collect more. If you are near a monster lair and not inside the safety of your tank, a monster will come out and chase you. If a monster catches you, you lose. If you collect all the minerals, you can leave the level and win.
What Went Right:
- Rapid Prototyping on Paper I took a free, online game design course at GameDesignConcepts.wordpress.com, and I was able to put use those skills to great effect. During the competition, I posted about my prototypes. With only 48 hours, it can feel painfully slow, but I iterated through the design, adding a new mechanic, trying it out, and deciding whether to keep or remove it, and then repeating until I had something I thought might be fun. Painfully slow? It took me almost no time at all. In previous LD48s, I’ve been known to add mechanics at the last minute in an attempt to make a game out of the code I was writing. This time, I knew exactly what mechanics I needed, and there were no real surprises here. The finished game ended up playing exactly how I hoped it would.
- Quick ‘n Dirty Graphics I’m not terribly familiar with art tools, such as The Gimp, and so every LD48 I find myself looking up how to use it to create what ends up being ugly art for my games anyway. I decided that this time, I wouldn’t try to make anything fancy. If I have any images that need text, I will use the basic text tool instead of the script-fu that creates cool looking logos if you tweak parameters just right. The tank? A square with a dot to let you know which way is the front. The driver? A yellow circle. Hey, it worked for Pac-man. I was able to focus more of my time on making the game because I wasn’t frustrating myself with trying to create halfway decent artwork.
- I Made Sound Effects This is my fifth Ludum Dare, and only the second time that a game I made had sound effects. Because I had a game that pretty much worked the way I expected it to, I had time for some polish. I made a list of sound effects I thought I would need, used sfxr to create the beeps and boops, and wrote the code to tie it all together. Adding sound really makes a big difference to a game, and I was glad that I could do so for this one.
- Faster Build Times and Lighter Distributables Because I had been doing some work on my Vampire Game, work that involves using TDD from the first line of code, I also did some work on my build scripts. Going from a 10 minute build time with a distributable that is already 10+MB due to including source libraries to a build that finishes in seconds and is less than 2MB is amazing for productivity, especially as it comes down to the final hour of the competition. Everything happened so much faster, keeping me focused on game development instead of getting distracted as I waited for a build to finish. Now, it isn’t as if my builds always took 10 minutes, but going from checked out source code to a complete build would. Once the libraries were built with my old system, compiling and linking would still take some time, much longer than the time it took with my new build scripts. Plus, one of the complaints I would get from previous competitions is that my game package was so large, so that’s one complaint I did not see this time around. B-)
- Simple AI Goes a Long Way I remember taking a few minutes to think about how I wanted the monsters to interact with the level. Should they obey the walls and other obstacles, like the player has to? If so, that would take a bit of AI programming. I don’t have much experience with AI, and I didn’t want to take the time to learn it for this LD48, so what did I do? I made the monster head towards the player every step, ignoring the environment. I could explain it away. It’s a monster. Maybe it climbs walls like crazy? The big surprise was how well it looked. Besides making it move towards the player, I also made the monster randomly move horizontally or vertically to do so. Combined with the sound effect when it comes out of its lair, the twitchy looking monster moving really fast at the player actually feels scary.
What Went Wrong:
- Distractions I have two cats, and both of them have been featured in previous LD48s, so I won’t focus on their antics too much. My home office wasn’t in a usable state, so I was out in the kitchen or living room. The cats love distracting me from productivity, and LD#15 was no exception. The one thing I did my hardest to control was external obligations. Anytime someone wanted to make plans with me for the weekend of LD48, I would politely tell them that I was busy. And it worked! I was able to focus almost entirely on eating, sleeping, and LD48ing…except for the Chicago Fire game.
I won tickets to the Fire vs D.C. United game, which happened to be the same weekend. They were really good tickets, too, and so I made an exception. In practical terms, I lost a good chunk of Saturday. I was able to get the game finished, but having an extra hour or two would have been good for tightening up the graphics and audio. On top of knowing that, the Fire lost, so it wasn’t even as fun a game to watch from the 2nd row as it could have been.
- The Sound Effects Were Very Rough By far the biggest complaint from people playing my game is that the audio hurts. I was able to get audio in within the last hour of the competition, but I didn’t have time to adjust it. I knew that some of the sound effects were loud and obnoxious, especially the one that plays when you bump into walls, but I couldn’t dedicate the time to tweaking it. The deadline was looming, and I still had a few more programming tasks to complete.
- There’s Only One Level Right before the end, I realized that I did not have a victory condition. I had programmed a way to lose if a monster caught you and also if you tried to leave the level without collecting all of the minerals, but someone will eventually collect all of them. What then? Ideally, I would have added code to load the next level, created that level, and kept going. In fact, Level 2 is in the distributed game, although it is a copy of Level 1 and there is no code that knows about it. I was thinking about taking Level 1 and breaking it up into at least three levels, with each level introducing new puzzles and getting progressively more difficult. Three doesn’t sound much better than one, but it would have made a big difference. The player would have felt that progress was being made, and the later levels could introduce the trickier ways to deal with monster lairs.
- Level Loading Bug I could not figure it out in time for the deadline, and I still haven’t looked at it since, but every so often, the level loading code would choke on the data, bringing the game to a halt. Sometimes shutting down the game and rerunning it would work. The data came from a text file, and my code is supposed to load a single character at a time, mapping the value to a tile. Sometimes, however, it would choke because a single character variable would have a value that is two characters long. For a time, I was dedicated to fixing it, but with only 48 hours, a good chunk of which I couldn’t make use of, I decided that since it wasn’t a show-stopper, I would keep going. I really wish I could have figured out why that bug was there. Besides ruining the perceived integrity of the game, I know at least one person didn’t review it due to this crash.
- Making a Puzzle Game I didn’t set out to make a puzzle game. I didn’t want to worry about creating a lot of content. One level might not be such a problem if the level was varied and fresh each time you played. I could have created a procedural level generator, but I never built one before. I didn’t want to spend time learning how to do so, nor did I want to spend the time tweaking the algorithm to make nicer levels even if I did end up accomplishing it. Out of all of the ideas I came up with, the game I liked the most ended up being a puzzle game, which unfortunately meant I was either going to spend a lot of time making clever levels or finish a game with hardly any levels. It ended up being the latter.
What I Learned:
- Rapid Paper Prototypes Work My game design skills are sorely lacking, but I’ve been able to practice what I learned in the game design concepts course, and it really paid off with Mineral Miner. I’m not claiming that it’s a fantastic game, but it did rank #45 in the Fun category, putting it in the top 50%, and #27 in the Innovation category, which puts it in the top quarter! It feels good to know that the game design I prototyped early on before writing a single line of code came together, and the comments for my entry showed that people saw a lot of potential in my game. Everything I wanted to put into the game, I learned from minutes of drawing on paper and messing around with tokens. I didn’t need to have a game engine coded up to explore, discard, and introduce mechanics, which means I saved a lot of time that would otherwise have been wasted on code that would get thrown away and changed needlessly.
- Quick ‘n Dirty Graphics and Audio Can’t Be Permanent My art and audio work was minimal and saved me a lot of time, allowing me to work quickly at getting the game play up and running. Unfortunately, my overall rating got hurt here. I was near the bottom in the Graphics category at #104 and surprisingly a little better in the Audio category at #77. I was hoping for time near the end to replace crude art and sounds with better ones, but it didn’t happen. On that note, even if it did happen, it wouldn’t be more than marginally better since I don’t have the practice and skill with my art tools. One suggestion was to use images of my prototype work, and I agree, the drawings look much nicer.
- My Pacing Still Needs Work I felt much more confident about my entry this time around, but I still found myself finishing the game at the last minute. There’s very little time for polish when the complete game forms only an hour before the deadline! It’s especially a concern since I decided to go with quick and low-quality art in order to get the game running as quickly as possible. I probably could have set mini-deadlines for myself. 48 hours sounds like an incredibly compressed period of time to make a game, and it is, but it’s still enough time to flounder. Early on, I have two whole days to worry about everything. In the last 5 hours, I’m in crunch mode. I could stand to manage my time and prioritize my tasks much better.
If I could do LD#15 over again, I would try to manage my time better. I could have had the prototype work done much earlier on, leaving me with more time to do the actual programming and arting. I might have been able to get more levels and variety in if I didn’t waste 5 or 10 or 20 minutes at a time wondering what to do. Still, even though Mineral Miner wasn’t a winner of Ludum Dare, I felt it was a success. I designed early on paper instead of designing with hard-to-change code, and I was able to focus on making the game I felt had a chance of being fun. People said they enjoyed the game and wished there were more levels. It was a complete game, meaning that aside from the level loading bug I mentioned above, everything that happens in the game happens because I designed it that way. In 48 hours, a complete game that provided some entertainment for others is a good accomplishment.
I’ve released a post compo version of Cave Ninja. Nothing exciting, it just fixes two bugs:
1. Win check for last level corrected.
2. Divide by zero error fixed that occurred for certain OpenGL implementations.
To be honest, for most people there’s no reason to update. But for those that got the divide by zero (might also seem like it just shutdown at once), it might be worth it.
Windows binary (should run fine in Wine).
I did make some updates to Xue after the compo, which I spun into my “game of the week” for this past week.
I’m not really super pleased with the result (in the end, I think the game still has too much “oooo… parallax” and not enough “wow, that was fun!”), but I also don’t have a clear direction that I’d want to push the idea in at this point, so I’m letting it stand as is for now. Maybe someday when / if I get a better sense of exactly what I want people to do in those caverns I’ll spin off a different game based on the entry.
Anyway, heres an updated screenshot (once LD was over, I immediately and shamelessly plugged in some graphics from LostGarden.com):
It’s playable online here: http://www.thewasabiproject.com/flash-games/play/play-xue/
As Kobel suggested in the comments on the entry, I did use a color matrix to tweak the background layers (actually, the original entry did that too, but it only darkened them, so it wasn’t much of an interesting effect). There are a few different “atmospheres” that the game uses for the caves, each of which fiddle with the colors of the background layers in different ways.
Gameplay-wise, I added some fireball spewing monsters, along with items that restore fuel. I also fiddled with the controls for the player’s ship (and actually I’m still fiddling with them, even with the game already released online), and adjusted the way the crystals spawn.
The map is also completely enclosed now, so there shouldn’t be any more invisible walls, and there’s no longer a way to fly off into space off the top of the map. Technically the map generation got tweaked a bit too, but nothing terribly interesting (the maps start out at half size and get scaled up, which both speeds up the generation a bit and cuts down on some annoying small-scale features).
I’m always happy to get feedback (though on this one, like I said, I’m not sure if I’ll stick my fingers into it again for a while unless a really compelling new direction for it comes up).
I also realized when I was getting ready to write this post that I never posted the updated version of my LD14 entry — so I hope nobody will mind if I tack it on here!
That entry was Crushing Pressure, and it turned into this little Flash game:
You can give it a whirl here, if you like: http://www.thewasabiproject.com/flash-games/play/play-crushing-pressure/
The original entry for LD14 had the same basic goal (rescue the little people while avoiding the walls), but it didn’t have any other obstacles to avoid (the updated version adds the DoomCubes and WhizBlades). The released version also added music, and little extras like an honest-to-goodness score counter and some quick transitions between levels. It’s still a pretty simple game, but there are a few minutes worth of gameplay hiding in there, I think.
Thanks for the feedback everyone left on both the original entries!
Well, I placed 91st overall… Woohoo, eh? I expected to at least place somewhere in audio… Anyways, time for a postmortem of what went well and what didn’t.
I created a roadmap of what I *wanted* to do, that was realistic for the given time
I rapidly got the framework running
I got the basic generation of the caves going in the first night, albeit, I had to tweak it the next day.
I was satisfied with the music, considering it was done in the last 10 minutes of the competition. ;P
The song should have been MUCH longer
The AI never did get worked on at all. That was to be the main playing point – the enemy would chase the player through the maze and create a sense of urgency. I can still see the original vision for this in my head, a suspenseful somewhat scary chase in a cave
I had VERY LITTLE time commited. Of course, something major had to go on that weekend. My sister and nephew moved down from Duluth, MN that weekend back to our house, so I had to help with that and put up with a 2.5 year old running around, when I wasn’t used to that. Otherwise, I may have gotten my top priority at the end, AI, implemented.
Movement speed was very slow in the game.
The cave did not look natural at all. It looked like a maze (Was made of rectangular prisms…)
The cave was very rarely continuous (Players HAD to use the wall-glitch)
The Goal was unclear in my description.
Textures wound up ugly
Some people had issues with framerate and the like. I’m sorry, but I couldn’t account for that.
I could go on and on, but those are the major issues. Next time, I’ll have a whole, undisturbed weekend to work.
Ludum Dare 15 voting has finally ended, and the results are now available.
For the press, we have a special link just for you. If you want to know who “won” Ludum Dare 15, go here for the top 10 games (expandable to the full 144).
“Winners” are decided by the Overall category. To our surprise, we had two ties in the top 10. Neat!
Categorical Top 5′s
For us LD folk, the full categorical breakdown of winners.
*NOTE*: Click on the titles of the categories for Top 10 style lists per category.
Ludum Dare 15 as Screen Shots
And since it looks cool, the full list of 144 entries, as screenshots.
Our next major competition (Ludum Dare 16) will be in December. The exact date we’ll know as the month approaches. To keep informed of the latest news, you can sign up for our mailing list here:
You can also follow us on Twitter:
Or alternatively, you can watch user news‘s RSS feed.
Can’t get enough? Then stop by next month for MiniLD #13 hosted by nilsf.
If you have any suggestions for the compo, we’re collecting them in the comments here:
Thanks everyone for coming out and making Ludum Dare 15 such a huge success.
- Mike Kasprzak (PoV)
I made some changes based on the feedbacks !
- fixed animation, to animate only when the char was in movement
- add some instrunctions of how to fire
- increase the distance of the border of the screen to avoid zombie-suprises
- changed the torch throw to allow multiple torches
- fixed level 3 and add a level 4
- criated a windows exe
- fixed some screen flickering
- reduce the maximum speed of the zombies
- generated some random textures for the ground
thanks all for the feedbacks !! this helped a lot to enhance the Java engine that Im building.
Well it’s the last weekend before voting ends. Also, in less than 30 minutes from now, MiniLD #12 begins. So here’s your last minute update from me.
First things first, hey voters! I’ve tried to collect a list of people that submitted Windows ports or stability/compatibility fixes late. If you previously rated these games without a working version, please take a 2nd look at them. And any other entrants with some time, we’d appreciate it if you could take a look at them too.
Also, I ran across a game with *only* a Mac version. If anyone with a Mac could take a look, that’d be great as well.
If I missed you earlier, post a comment and I’ll add you to the list.
Also, these people currently sit at less than 20 votes. If you could give them a bump (and by bump, I mean actually play them and not “can’t play” vote them), it’d be much appreciated.
That’s it for now. I turn the show over now to GirlFlash and MiniLD #12.
- Mike Kasprzak (aka: PoV)
PS: Prior post here.
I’ve been working on my game, and it’s come a long way. It now looks better, the character moves faster, and there are 5 levels that were not in the competition version. I think the new levels present some interesting puzzles.
I still need to work on making the wall collision less sticky. Also, I’d like to animate my character and explosion sprites.
EDIT: Oh jeez, I thought it ended on Friday!
So I’m finally getting around to writing a post-mortem for Mole Cave Tactics. I know it’s better to do it fresh off development, but I needed a break.
Since it seems to work pretty well for a lot of other people, I’ll go with the time-honored format of
- The concept: I had my concept in mind for this theme (and the many related themes on the list) since well before the theme voting wrapped up. In fact, I had been bouncing ideas for some sort of tactical rpg around in my head for quite some time prior to the compo.
- I finished: The game didn’t have nearly as much content as I had included in the concept, but it was pretty obvious that that would be the case from the beginning, anyway. Given that this is my first LD, I’m pretty happy I managed to upload a game which runs, has things for the player to do, and has defined ways to win and lose.
- The graphics: Ok, so it could be reasonably argued that my sprites would be better classified as ‘bad’ or ‘ugly’, but, I’ve never done any graphics from scratch by myself before, and I actually rather like how the moles turned out. They need some tweaking, but I think they’re pretty good. The terrain I’m less happy with.
- Mismanaged time: I kinda knew from the start that this was going to be too ambitious for a first time LD entrant, but above and beyond that I did a poor job prioritizing different aspects of the game. In particular, I spent way, way too much time on AI. I didn’t really appreciate just how difficult a problem doing AI for this kind of game is, I went for way too much sophistication, and as a result I didn’t pull it off at all. I should have known immediately I was doing something wrong when I started writing code to have the AI units look ahead multiple turns in planning their movement. Random walk may not have been very satisfying, but it would have been more than compensated for by the extra stuff I could code in the time I saved.
- No readme: I didn’t ever get around to writing a readme or even specifying a license, so the player is kinda left on their own to figure out what to do.
- Only one map: This game could *really* have used multiple maps, or a random map generator. This is one of those important things that didn’t get done because I was tinkering with the AI.
- The interface: Oh, God, is the interface bad. I should have taken it more seriously when I started adding undocumented keyboard shortcuts for nearly every mouse action in the game. I didn’t think the interface through very well at all during the competition. Having thought it through after reading the complaints, I think that if I want a mouse-driven interface, a radial menu centered on the unit under consideration (think NWN) would be best. Alternatively, just ditch the mouse and switch to all keyboard.
- The Windows port: for some reason, the Windows port was incredibly painful to make this time. For a long time I actually somehow managed to have a build posted which wouldn’t even run on the machine I built it on. I love Ruby, but packaging Ruby applications is a terrible, ridiculous mess. Next time, I’m going to look into Crate.
All that said, I had a huge amount of fun doing this compo, and I definitely intend to enter again. I also plan to rework and expand Mole Cave Tactics into a full-fledged game, when I have some time to sit-down and code again. Don’t expect a release soon, though: my other game, Operation Lambda (shameless plug) took half a year to complete; it’ll take a few more LDs before I’m able to crank out games of any appreciable quality in a short time period.
So I’ve tried again, and this time I think I’ve finally managed to wrestle a working Windows build into place: download it here. For some reason I had a much easier time packaging my last (non-LD) game. Suffice it to say, it is probably best for everyone involved if you don’t ask why it’s necessary to distribute SDL_mixer.dll with a game that has no sound.
I’m going to do a last call post some time tomorrow.
If your game previously didn’t work on Windows, but you made fixes after several “it doesn’t work” comments, leave a comment here. I’ll collect up a list and try to make them nice and visible to everyone. Hopefully that will give all the neglected people more proper/updated votes.
Also, we’re short 1 Windows port from the port request posting. Details and a link to the source can be found in the comments here:
Someone suggested that if I write a postmortem for my entry, it might complement the joke.. as long as it’s done subtly.
What went right:
- Um. At least some people seem to like it.
What went wrong:
- Should have included a getch() in the end so that people who click the game to start it have a chance of seeing the ending.
This was my first Ludum Dare, and I was really looking forward to it. Well, I did have fun making a game, but there’s one major problem: I don’t have Windows, I don’t have access to Windows, and I couldn’t find anyone to port my game to Windows. So I kind of feel left out. Not only can nobody play my game, but I can’t play most of the other people’s games.
I always have such a great time with PyWeek I thought for sure I’d like this too. But I really have to consider whether Ludum Dare is for me. If I needed Windows to participate, I would easily choose not to participate. But maybe that’s not necessary. I could write in C++ instead of Python, and maybe more people could run my source. Or I could learn Flash or something highly portable. I still couldn’t play most of the other games, but it’s a step up. We’ll see.
Anyway, it’s been enlightening. And at the very least, I enjoyed making something, so it’s not for nothing.
Thank you to all the people that have played and commented on my entry, much obliged. I left it alone for a week, wanting to come back to it with a bit of a fresh head and hopefully fresh eyes. In replaying it a bit there are a few particular points I think are worth talking about, important aspects of the game which I fell I either did or didn’t get right.
In playing through people’s entries I found a lot of them just jump straight into the game and stop when you win or lose. This is a post intended to inform anyone who doesn’t know how, about a quick and dirty way to create a simple ‘start screen’ -> ‘game’ -> ‘end’ -> ‘reset’ loop in thier game. I’ve no idea if there is a more ‘proper’ way to do this, but this is quick, dirty, and works. There may be some differences depending on how your game is structured, but you can fit the idea to most.
Made by myself, Matthew Hyndman.
I present: Cave Bounce version 1.1 (Windows executable, 1.8MB)
The premise is simple: there are two superimposed caves on top of each other, and you can change which is active at any given time. By doing so you must navigate through puzzles, collect coins, and dodge missiles.
A pretty screenshot: (the player just died and was reset to the start of the level point, hence the seemingly floating)
-drawing the thin outline of the back layer in front of the frontmost layer, so you have an idea of the shape of the back layer.
-a color indication (light/dark green) of whetehr or not the player is currently able to change layers.
-Several minor changes, including slight tweaking of missile speeds and such; they’re still roughly the same, but they are a little slower/turrets fire a bit less often.
-A subtle gradient background (before it was solid black)
-More levels! I scrapped and redesigned some of the ‘boring’ older levels, and added more new exciting levels, some of which are puzzle only and some of which are missile oriented. There are now 25 levels to the old 20. Some of the coin locations are now more realisticly obtainable (the staircase screen should be doable for 100% coins now), and there are some new difficult to obtain coins.
-Before, as long as the centre of the player was not a wall on the back layer you can switch, which caused curious half of the player is in a wall situations. I added in a quick feature so that if this is the case, the player should be popped a little bit over to be out of the wall.
-I added some more HUD ocunter stuffs: you now see the FPS and how far you have progressed. seeing that you are on screen 22/25 is more motivation to finish than just knowing that you’re 20 some out of who knows how many
-When the player dies, he is reset to the start of teh screen. Before this did not change the layer, so it could potentially stick him in a wall, so it now also reverts the active layer to the layer of incoming.
-I reduced the number of particles somewhat so things will run a bit faster (not a lot), while still looking the same.
Postmortem stuff: (After Death?)
Woo! This was my first LD ever, and I loved it, came out great. I’ve entered another 48 hour comp before, but I was less experienced and more or less failed at that one. ( We made a game, it just wasn’t very deep)
no big problems, I had a fairly cool idea and it all seemed to flow.
Missiles and coins were both last minute additions, and yet the game would’ve been pretty boring without them. I’m quite glad they ended up there.
I made a game. in 48 hours. that is fun to play. I’m happy.
No music or sound effects. They are, at the moment, somethign that I do not do. Sorry all.
I overused particles a bit, and so it runs slowly on weaker machines. this slowness can cause bugs like skipping through walls in extreme cases.
the art really wasn’t great (the player is a circle), although it did end up being fairly stylish.
Map design was somewhat rushed, and so wasn’t great (although it’s still good)
Difficulty level is a bit high and intimidates some. Unfortunately for them, I like action games as well as puzzlers, so this is likely still the case. Fear not, it is all quite doable, and there are several screens that are missile free.
I had fun and am looking forward to future LDs
Edit: I’ve gotten the GoogleCode page up!
I’ve decided to keep working on Byte Vs. GNOME.
I’ve recieved some encouraging comments, and feel that it could become something really nice with some polish.
I’ve got the following planned:
- Actually making the random world generator
- Multiple weapons, including a machine gun and a rocket launcher
- Multiple types of enemy, including bosses
- Activators including doors, retractable bridges, and switches
- The game-type bits that were missing from the compo version, like a health bar and a score counter
- User-configured key bindings
- And perhaps even more as it evolves
I’m currently tearing my code apart to allow it to be extended. This is the most troublesome part, after which Good Things can happen.
I’ll be making a GoogleCode page. Once it has gotten reasonably nice, I will likely make a SourceForge page.
Here’s to having a good idea in a crucible, and then refining it into a jewel.