It worked for me but the UI was painful - searching for presenter names didn't seem to work, and for some reason the page defaults to GDC Austin content...

Back on topic, I really like this idea, and your presentation of it is much more succinct than the talk linked on AIGameDev. I think I'll give it a try when I get to looking at ship AI for Sublight.

Thanks for taking the time to describe a neat system.

Thanks for all the great comments folks. I'm working on the sequel this very minute.

Best news I've heard all week Will you

a) Make the badger a playable character

b) Add a co-op mode where one badger works the pedals and the other steers?

Inquiring minds need to know!

Limits are good for creativity too - they help you focus on making the best of what you have. I always enjoyed Frank Miller's Batman stuff more than say Sin City, for example.

The way I like to deal with this one is to configure engine systems with budgets at init time. The systems then allocate pools from the heap with exactly enough space for the maximum numbers of (nodes, entities, etc.) requested by the budget.

I think this gives a reasonable tradeoff, and the gamecode can choose to specify fixed budgets (e.g. for small games or console games) compute budgets to suit available memory, or even load budgets from an INI file.

As Raigan points out, you should also budget your available frame time - this is typically something console games are also good at, and PC games bad at.

Yeah, but any PC game knows how much physical memory it has available as well. You just find out how much is installed in the system, divide it in (say) 2 to make room for everything else, and that's your hard ceiling. You can then allocate that block and slice it up to give you a frame-static memory picture which is right for each PC, just like you would on a console.

here an exe with enabled FSAA

That's exactly what I was thinking of, thanks so much! I really like that version but I can see why you'd want to stick to crispness for the official release.

Regarding the tutorial, I think drawing the frame around targets in red would probably have been all the clue I needed on level 1. Your ideas about bonuses, scoring and style sound like they would work really well and add lots of reasons to go back and replay levels after the initial rush of just getting to the end.

You can also make a really good game out of finding ways to effectively cheat to get to the end quickly - see the driving/puzzle Gripshift for an example of this taken to the extreme.

Will

Yay, new version works! I played up to wave 4 I think, then my desire to eyeball a target got in the way of shooting down missiles and I died.

I like it a lot, but I think now that you've got all the gameplay in, the flight controls need to be less painful. It's OK not to display target arrows, but the constant angular drift makes it very hard to make any kind of course correction with the mouse yoke. I'd suggest recentering the yoke smoothly but quickly as soon as you switch back to pointer mode, and maybe doing the same thing if the mouse stays still for a short while in yoke mode.

The target missile button is very helpful, you could have been cruel and forced people to switch contact filters to achieve this

I just wanted to point out that there are many different options and it really depends on what fits the game best.

I totally agree with your earlier post about it being acceptable (and in many real game cases desireable) to avoid dynamic allocation. But in principle I agree with the above statement even more - it doesn't do to be too dogmatic about these things: I recall reading a discussion about these things on sweng-gamedev which pointed out that Halo 2 and Stranger's Wrath were built using 'competing' methodologies but both ended up AAA games with excellent visuals, interesting gameplay with lots of entities, and good frame rates.

That said, it's always tempting to support the "beware high level features" message because there's so much "beware low level features" advice around.

I think that indie games in general are in a privileged situation - they're usually smaller games, running on relatively modern PC and Mac hardware, so many assumptions like "it's OK to allocate memory in the frame" or "it's OK to use auto-growing std::vector" or "smart pointers don't cost worthwhile performance" or "it's OK to optimise hotspots later" are perfectly valid. But if you wanted to port those games to e.g. WiiWare or DSiWare, you would likely find many situations which test or break those assumptions, requiring significant rework.

The ones to watch out for are assumptions that are used everywhere - they give you the dreaded flat graph in the profiler, because everything is slow! Sometimes you can do something systemic to fix this afterwards, but often you can't.

Will

I like having to look for things in games, although this is one of the hardest examples of that I've played - perhaps because it's hard to pick out landmarks (owing to the fisheye view?) and the ping is intermittent rather than continuous. That said I did enjoy it although like Melly I only had the stamina for two voxels...

Clever. It's like imagining motivations for the girl in Outrun instead of her being a cypher.

I'd love to see this grow as well. The basic elements are great (handling the runes and charms feels really good, amazingly solid and tactile considering it's just scaling and rotating sprites). It reminds me of several Amiga games (some from Psygnosis, some from a French developer) which mixed strategy phases with action missions - add some RPG-lite stuff (e.g. basic story, world map, currency, shops, and maybe wagon upgrades) and I think you could have a real winner.

Thinking about it, the coolest wagon upgrade would be getting bigger and more impressive fantasy beasties to pull your wagon. Start with a donkey and cart, end up raining death from a sleigh pulled by dragons!

It really felt like being an elephant.

Not what I was expecting at all. I love the combination of sliding block/physics puzzle/demolition derby/collect-em-up. I'm only sad that I lost a really big fish that I caught because there was too much crap in the way to get it into my mouth

The only minor hassle was changing between F and R seems a bit flaky - do you have to be completely stopped? But it's such a minor thing, and weighed against all the wonderment (fish physics, how can you go wrong with that!) it doesn't signify.

I have the same problem on my XP box, will try Vista again later.

Love the tune and the big right feet! I need to find someone to play this against (as well as Balloon to the Moon). Perhaps the missus will oblige...

Great colours, nice effects (trails and air particles) and a good flight model too. However I got an honest-to-god BSOD when I got close to the baddies. It was a bugcheck 1000007f, I'm guessing a driver problem of some kind but I don't know which module faulted.

I landed on my third or fourth go, lots of 7s until I got close to the ground, then 9s.

I think the minimalist title screen looks great.

The initial level reminds me of Zarch for some reason. I got confused and thought the X meant I wasn't supposed to destroy the castle, so I waited around for something to protect it from... Luckily I figured it out in the end.

The whole thing is deeply stylish, I'm glad I got to play it. I think it does suffer a bit from the ease with which you can avoid the baddies on some levels - it feels like you should be shooting but it's more efficient just to dodge them and head for the exit.

Have you tried rendering at 2x the resolution and downsampling? I have a soft spot for very low res polygonal visuals with antialiasing, and I think it'd look good on this game

Yep. Woth normal animation (forward kinematics) you animate the joints directly. With inverse kinematics you position ends of limbs and work out what the joints should do subject to various constraints.

Basically you position the hands and the IK code works out where the elbows should be so the arms don't squash/stretch. That's a nontrivial problem and your solution behaves nicely.