Read my book for free, because it has Iron Man in it. Sort of.
What with the Iron Man movie coming out I thought it would be a good time to release my novel as a free pdf. Why now? Because Iron Man is something of a central metaphor, much as the Fantastic Four are a central metaphor in Rick Moody's The Ice Storm. So, if you've been wanting to read my book, and the only thing stopping you was the price - go for it.
And, if you haven't been wanting to read my book - why not? It won an honorable mention in the Writer's Digest Annual Self-Published Fiction awards. It still has a five star average rating on Amazon. So...it must be good.
Random side note - a friend of mine read it a few months ago and said to me, "It's a lot like Freaks and Geeks." I'd never seen Freaks and Geeks, so I watched it, and - yeah. A hell of a lot in common. Geeks wanting to be burnouts. Burnouts wanting to be geeks. Eighties pop culture references. So...if you liked Freaks and Geeks, you should give this a shot. Especially now that it's free.
May 1st, to be precise.
If you want to give a talk at the IGDA Leadership Forum in San Francisco on November 13 & 14...submit it now!
Proposal requirements are very informal: a few paragraphs might suffice, but a list of key takeaways or an outline will help.
Slay is what happens if you take a strategy game along the lines of Civ or Wesnoth or Homm3 and remove features until the absolute minimum is left.
Which brings me to one of my pet-peeves. A lot of people, including game reviewers, say 'depth' when they mean 'breadth'. "This game only has one button? Where's the depth?" Breadth usually comes from adding verbs, things to choose from, things that make nice bullet points in your marketing materials; depth comes when the small number of verbs you have, combined, create their own variation. Go is a game with almost no breadth - there's only one type of unit - and insane depth. Your typical fighting game with a hundred moves, only one of which you use because it's an exploit, is the opposite.
Breadth can be the enemy of depth. Anytime you give a player a new option to choose from you run the risk that you've created an exploit that makes all your other choices meaningless.
Slay is an old game - been around since Treyarch was half-a-dozen guys in a condo in Venice - and I didn't think too much of it back then, because it seemed too easy. You had to really look to find one of the randomly generated countries that was challenging. Well, maybe back then I had the AI set on a low level and didn't realize it, or maybe I've gotten stupider, or maybe Sean O'Connor has been working on the AI over the last ten years, because now it's pretty tough to beat. I just managed to claw my way to victory on one of the small islands, and there's a whole lot left.
That said, the AI isn't on par with your typical chess AI. You can leave a weak unit out where a stronger unit can get him, or lower your defenses, as bait, and then cut the strong unit's support. Which is terribly satisfying! If the AI was better, the game might be less fun...almost like the AI in a stealth game.
Hey, I'm back. I'll have some news about Schizoid soon, and I have the energy to blog again.
A thing about drag. I forgot one of the most important ways to mitigate drag, which is: Don't Start From Scratch. Almost nobody does, anymore - one of the first questions you ask yourself when beginning a game project is "What engine am I going to use?" The main reason to do this is because it saves you a lot of work. But another reason it's helpful is because you schedule more accurately - to keep using the snowball metaphor, the snowball you're rolling uphill is already nice and big: progress starts slow and doesn't get that much slower. In fact, a question I was asked at my IGDA talk went along these lines: "We just do content drops into an existing engine - does this really apply to us?" I fumbled the question at the talk, but now I'd agree and say, yes, although there will always be at least a little increase in drag as a project evolves, it may be so little as to be immaterial.
- Use when you started the project as a starting point, and your current point as the end point: this always gives you an overly optimistic estimate.
- Use your instantaneous velocity. This gives you a wildly fluctuating estimate. One day, you're going to finish tomorrow. The next day (after a slip), you're never going to finish.
- Use some amount of history. But how much? Something that would have been fairly good for us, though still too optimistic, would be to use the last half of the project.
I tried a bunch of stuff - moving averages, fitting curves, nothing hit. But my math skills in this area are weak. If someone out there can take a graph like the one above and find a good approximating/predicting curve, please let me know how. I did ask my brother-in-law, a financial analyst, if he could use stock market momentum measuring tricks to do it, and he wasn't able to help.
In the end, my best guide was actually my eyeballs. When we were in December, and hoping we'd be finished in January, I was able to say - "Just look at the graph. We're looking at the end of March."
That turned out to be on the money - the first time we hit the zero bug line. Of course, we still weren't finished yet; a little more testing and we were right back in the red again.