FInale

devon on 2009/09/06 01:20 of 3chidna

Well, I got something done, and it has an end state and a few really cool things going on and a few really horrible things!  It pales in comparison to the original vision me and John had, but I got some decent art and music in there.

Things I wish i would've done before pyweek (A post mortem):

learn cocos2d :) I spent the first half of the week trying to get the window resized correctly and the second half trying to keep track of all of my transformation anchors... at the end of the week crunch time made for some messy code with no rhyme or reason to which class was in which class' business.
The cocos animation editor would've been great to use too, if I could figure the darn thing out.

Made a platformer. I realized after I started that I really hadn't made a platformer before... bad idea for getting something done, but it was a great learning experience.

Created a framework for loading images. It's just a mess right now, especially with all the calls to set each image to use GL_NEAREST for scaling. I couldn't find a way to not have to touch every texture loaded and manually set the scaling for pixel art. 

Understand physics and framerate independent movement better. Right now moving left and right and up is fps independent based on dt, but falling down slows with the framerate... could not for the life of me get it to behave right so I had to keep it this way (my movement is a little complicated, especially since the movement mechanics and sprite  dimensions change frequently).

But I'm still a little proud what I did get done, especially since the bulk of the art and all of the programming duties were on my shoulders.  Thanks again to Ian for the awesome retro music and sound effects and the funny NPC NPC sprites, and John for coming up with the longicorn mechanic/character idea and original spirit wolf concept ;)

Maybe I'll finish this for pyggy with some kangaroo mice which were supposed to be in there instead of the Indian, and a spirit wolf boss that actually does something, not to mention some sort of risk in the game besides missing a jump would do gads to improve its enjoyability...

Oh well, congrats to all who finished!

(log in to comment)

Comments

gcewing on 2009/09/06 03:58:

Right now moving left and right and up is fps independent based on dt, but falling down slows with the framerate...

How are you updating your position and velocity? If it's something like

    y += vy * dt
    vy += ay * dt

then you will get errors that worsen with increasing dt. A more accurate way to update y is

    y += vy * dt + 0.5 * ay * dt ** 2

If ay is constant over the time interval, then this is exact.

adragon on 2009/09/07 19:49:

I am unable to start the game on Ubuntu 9.04
...
  File "/home/adragon/games/NaN_BirdStrike/lepton/__init__.py", line 6, in <module>
    from group import ParticleGroup
ImportError: /home/adragon/games/NaN_BirdStrike/lepton/group.so: invalid ELF header

adragon on 2009/09/07 19:51:

Sorry for the misleading post, different game :(

cyhawk on 2009/09/09 22:22:

I've enjoyed this game a lot! Discovering the flight mechanic and the goal of the game was rewarding, and the whole game is so surreal.

devon on 2009/09/11 19:11:

thanks cyhawk @gcewing I believe you are correct, although I don't know why exactly you have to square the dt of acceleration :)? do you have a link to the math behind it? however, trying to implement the way you describe seems to be causing other problems so I have to do more refactoring than I thought.

Cosmologicon on 2009/09/11 21:12:

One way to look at it is that you want the change in y to be equal to the average velocity times dt. The velocity over the time interval starts at vy, and ends at (vy + a dt). So the average of these two is

(vy + vy + a dt) / 2
= vy + 1/2 a dt

So multiply through by dt, and you get vy dt + 1/2 a dt^2.

However, for most reasonable values of dt, I would be surprised if this change makes a noticeable difference in a video game. I suspect there's something else going on.

piman on 2009/09/11 21:19:

There's a good discussion of the math behind the various methods, including a more accurate one, at http://www.gamedev.net/reference/programming/features/verlet/.

Cosmologicon on 2009/09/11 21:55:

Well, the Verlet method is only more accurate when you have a changing acceleration. When a is constant, both it and gcewing's formulas should give exact results.

gcewing on 2009/09/12 00:07:

However, for most reasonable values of dt, I would be surprised if this change makes a noticeable difference in a video game

It could account for fall rates varying with dt. Since you're missing the 0.5*a*dt**2 term, you're underestimating the change in y with each frame, by an amount that depends on dt. The bigger dt is, the faster the approximate trajectory diverges from the true one.

For reasons like this, I prefer not to use a variable dt. I use a fixed time step per physics update, and if I want to vary the update rate to account for different frame rates, I use a variable number of steps per frame. That way the physics remains deterministic.