Friday, March 28, 2008

The end of a cofounder

Mike quit last weekend. He got into Harvard Business School; he actually wanted to continue part-time, but we both agreed that it's not really practical to work part-time on a startup and go to B-school at the same time.

That leaves me a single founder, at least for now. I do wanna recruit someone else to join me, but I'm not sure there're all that many prospects. I don't want to join up with someone I haven't worked with before...that usually tends to be a recipe for disaster.

I'm going to keep going, at least for now. The technical end of things is actually going fairly well...we have our first cut at initial archetypes done, they're mostly playable (except I don't have arc collisions done, which makes Brickbats and pong a little impractical), all tests pass, and our backend is basically fairly robust. Been working on the JavaScript runtime, and soon I'll get back to the editor.

It just struck me though how lonely it is without a cofounder. I'd been pretty lonely before, being the sole developer, but at least Mike and I were in this together. Now it's just me, and I dunno if I can do this.

Monday, March 17, 2008


I'm reading Dreaming in Code, the history of the Chandler project, and there's an ominous quote from Linus Torvalds:

Nobody should start to undertake a large project. You start with a small trivial project, and you should never expect it to get large. If you do, you'll just overdesign and generally think it is more important than it likely is at that stage. Or, worse, you might be scared away by the sheer size of the work you envision. So start small and think about the details. Don't think about some big picture and fancy design. If it doesn't solve some fairly immediate need, it's almost certainly overdesigned.

I worry that this describes us far too much. We've tried to ground things in real games whenever possible, but I still have this feeling that we're developing too much based on an idea and not enough based on real needs. Game creation sounds great in theory, but we have no idea whether it'll be appealing when people sit down at a computer and choose what site to visit.

The big problem at my last employer was that they were building this huge all-encompassing platform, and then only later using it to build applications. Of course, when we built the applications, we found that all our design assumptions of the platform were wrong, and it was just holding us back. We never had the will to rewrite the whole platform, so we just dragged around all this code that slowed us down.

Friday, March 14, 2008

First archetypes

So, I completed the first archetypes a week ago. Blank game, editor test, and pong. It's kinda neat having something up on screen, with some real, movable shapes up. I added some vector-graphics shapes, because many simple archetypes (pong, brickbats) use plain old colored rectangles or circles for sprites, and even more complicated ones (shooters, etc.) may use circles for bullets and such.

We also needed shapes for collisions - I got halfway through Pong and then realized it was unplayable without some sort of radial collision detection; otherwise the ball just bounces back and forth in a straight line. So that's what I'm working on now, and it's fairly slow going - just having rectangles, ovals, and arcs means 6 different cases to test against, each of which has several different cases depending on which axis, which direction the shape is facing, relative positions, etc.

Been avoiding it by watching basically all of Medium Season 1 & 2. Unfortunately, it's not that great a TV show, so I've run out of worthwhile things to watch (if any of them were really worthwhile to begin with). Guess it's back to coding.

I'm curious what other problems having real, working archetypes will turn up. I'm very glad we did a minimal "game" and then did the half the editor, because many of our assumptions for data structures were very much wrong, and if we'd done the full game compiler we would've had to rewrite it all. But now that we're returning to the compiler & runtime, we get to see how many of our assumptions in the editor were wrong, and I'm guessing there are quite a few. We've already had to add shapes, shape arguments (eg. arc direction), vector graphics, and more complicated collision detection, and likely will need to change how we handle bounce & friction (making them parameters of the collision and not separate actions, for instance). And some aspects - like victory conditions - need a lot more attention.

Sometime I should write a post about all our assumptions and how they've been proven wrong and how we've kinda "spiraled" up into understanding, but I think we need a bit more understanding before I can write about it.

Monday, March 3, 2008

The game compiler

Just finished the game element in the revised compiler, which, being the topmost abstraction in a bottom-up hierarchy, means I've mostly finished the revised game compiler. Well, module some hard stuff like the collision run-time which I'm putting off till later. And some easy stuff like background scrolling & images that I just stubbed out and will also do later. And testing - games and sprites are both untested, though I've been testing out the lower-level abstractions as I build them. I guess that means I'm not really finished at all. That's okay; I didn't really expect to be.

Right now, I feel completely and utterly drained of any coding mojo, and wanna go off and become a fantasy novelist or something. It doesn't really help that I just looked at Sploder and GameBrix, and they've both launched and are actually sorta moving now. (Well, technically they'd launched when we started, but we didn't see any movement.) Now it feels like we're behind and shooting at a moving target. This is frustrating because I know that if we had working software, I could move faster than they're moving now; after all, I've moved significantly faster on every other project I've worked on (well, except the ones that never got to working software). But first we have to get there.

A word of advice to anyone that ends up reading this: pick a problem that you can solve within the first month or two, and then release something. Your initial enthusiasm will burn out within about 2-3 months, and if you don't have something working with users to spur you on, you aren't going to finish. When Mike first presented GameClay to me, I thought "cool, a project that's at the edge of my abilities, this'll be an interesting challenge." And it was - the problem is, people (namely myself) always overestimate their abilities, and so something that's at the edge of their abilities is actually just beyond their abilities.

Actually, we did release something within the first couple months - 2 somethings. Unfortunately they don't have legs; there was nothing to grow from them. So we needed an idea with more depth, so we did GameClay, which may have too much depth. Which I guess illustrates the entrepreneur's dilemma perfectly: the easy stuff isn't all that useful, and the useful stuff isn't all that easy.