Day 1 is progressing nicely. Gord has a handle on the engine and I think I've got the look sorted out. Here's our character with a walk cycle. Stupid programs I used for animating her kept eating my frames, throwing away roughly 3 hours work. Rawr.

And the admittedly barren level mockup. With the walk cycle done I should be able to populate this thing with a few more objects.

So Day 1 ends in about 30 minutes and I'm about to turn go to sleep after marathoning through this day. Here's what I think I've learned from day 1.

Pre-pyweek preparations are very important! Learning the technologies we use in pyweek before hand is great for code velocity. So code wise we did pretty well. Theme preparation wasn't too good for us though. We got caught off guard by Piece of String winning, I think we got too enamoured with our idea for Flatpacked that we didn't consider the other themes as much. Another place we could have done better (well, I could have done better) is in preparing the workflow. Was a bit rusty with 2d animations and I did not familiarize myself with my animation tools leading to much frustration on my side as I clumsily fought against the apps. Asset people should beef up on their pipeline too.

Since this is a weeklong competition there is also a question of having the stamina to see it through the week. I'm lucky being in the middle of school semesters so I can dedicate the whole week to this. However, I do not think I can sustain what I have done on the first day throughout the whole week, which is basically stay up the whole day working on the game. Got to pace myself instead of flaming out.

I think this especially applies towards touching the codebase. Tired programmers will tend to introduce more problems to the code rather than moving it forward, so thats kinda... no.

Asset velocity is another concern. I'm creating the art too slowly, I probably need to drop some frames from animations or just be outright lazy and use filters/effects. I also should have thought of using flash to draw the keyframes instead of struggling with photoshop/painter which are not primarily meant for animation.

Share your thoughts on what you've learned so far in the competition!

I made a contribution to the code and gord made a contribution to the art! As you might guess we've been doing valve style placeholder art. It's orange... all the way down. The platform is kinda dark because of the lighting gord has coded up, and that background is 2 parallax scrolling layers. Can't wait till gord slaps on the shaders.

Most of the animation for Devika (thats the name of our character) is done and the engine is about 60-80% there so we'll be focusing on making some game play pretty soon. Gord's made an inkscape based level editor, go him! Trying to transition my brain into code-mode although I still have assets to make, I think more coding is needed to get us tweaking gameplay sooner rather than later.

Day 3! We're looking real shiny on the engine and art asset side, but we're still asking ourselves where the gameplay is though. Most important thing and we're still not there. We also don't have a name for the game yet but I think we're tying it to the theme with the Indian Rope Trick. Don't hold me to that though, we haven't even found the gameplay yet! It did suggest the art direction of the game to me though so I'm pretty happy with that.

Assets! I might be trying to intentionally give people nightmares with my assets. First Devika's joker-esque smile and now these two guys:

Due to PyODE's trimesh support being broken in Ubuntu, our levels are made up of mostly boxes and spheres. This limitation gave gord an inspired idea to use inkscape as our level editor. He had this thing running on the second day but it's more feature packed now.

Saving the best for last, here's gord's uber bloom and sketch shader. It looks really great in motion!

It started off as being a generic world engine based on the open dynamics engine (using a 2d plane to clamp all the objects to 2d) and the early builds had nice ODE simulated boxes that you could push over as a stick man type person, the further we got into development the less important the physical dynamics were though, at this point in time the only thing thats physically simulated is our actor object, everything else just uses ODE to perform collision detection (ODE is smashingly good at that!)

the graphics engine is a custom built one that basically uses sprites to draw the most basic of things, quad polygons. i aimed the engine to be able to be playable on pretty much all machines, the most advanced thing it uses is GLSL fragment shaders but those are auto-deactivated for machines that can't handle it.

the actual engine uses three distinct object types, actors, props and geometries, actors 'do stuff', props are dumb objects that are physically simulated and geometries mearly provide collision detection most of the time. the only real problem we had was making it able to pass certain geometries (platforms when climbing up a rope) but that was solved pretty easly in the end, the whole thing has been really easy to code. its great! woo python.

oh and of course heres an obligitory screenshot, this ones from a way early alpha!

Well its friday, only today and tommorow left. we pretty much have the game done now, just finishing up some of the levels and writing some code to tie up the story at the end of the game.

there are a bunch of optimisations i can do in the engine yet but that can wait till the game is properly finished and playable from start to end. at the moment it looks like the target machine spec for this game is about a 1.8ghz processor (no multi-threading so you dual core people need to have fast cores) with an opengl 2.0 compatable gpu (speed isn't much of an issue gpu wise, i have a nvidia 6200). you should be able to run it on systems with a lower spec than that, technically it should work on any graphics chip though. we'll have to see in the testing phase tommorow weather that actually holds up :x slower cpu's should be able to handle it with no gpu shaders also.

Whew. Had a pretty good but exhausting PyWeek I reckon. Teaming up with gord has been the best thing evar. I'll update the entry page with the proper game description but for now please bear this sleep deprived description of the game.

The Littlest Goddess v1.0.1. If you managed to get v1.0, please get the patch for level five

You're Devika, a little goddess and you've lost your pet! Follow the trail of string left behind to find your pet.

It's a puzzle platformer so theres not much in the way of baddies,the challenge is in navigating the levels. All in all we feel we've produced a nice game, very visual and quite challenging. We still have some bugs running around but nothing too game breaking. We did put in a reset key though, just in case. We can has a normal life again!

Screenshots follow below.

Well pyweek is over and i thought i would illustrate some of the aspects of coding a game in a week that i think are important in my experiance, some do's an don'ts if you will.

Pyode - ode is a fantastic physics engine, its really quick, its really flexable and its wonderful, but we just didn't *need* to use a physics engine in our game, if i could do it all again i would of used some basic velocities to push the player around and use pyode's collision system, i think some of our stranger bugs could of been weeded out better that way. the gameplay movement dynamics could of been tweeked more as well, as they are they are very 'realistic'

pyOpengl - I'm an opengl coder, its what i do, i love it. pyopengl however is a bit.. special. whereas with C/C++ you just have this basic api where you can load extra function calls, in pyopengl it all falls apart into this python importing fiasco, add to that the fact that pyopengl isn't extreamly well maintained and you get a bit of a mess. a lot of the blackscreen/fullscreen bugs have been caused by that unfortunatly. i would still use pyopengl again as there are no other alternatives (all others use it by proxy) but i would spend more time pre-pyweek figuring out its strangeness.

Inkscape - Using inkscape to design your levels is the best idea anyone could ever have, its a *perfect* 2d layout engine it really really is. the fact that it produces nice xml means that its fairly easy to parse the .svg it produces and load it stright into your game. if it wasn't for the trimesh ode bug in ubuntu we could of done some crazy stuff with convex polgons and everything. if we hadn't of used inkscape we plain couldn't of made our game, thats a fact!

Game dynamics - We didn't figure out our game dynamics until about wednesday and even then its a fairly loose platformer. the string theme took us for a ride a bit as we wern't expecting it. i wrote down some ideas for the various themes before the week started and for the string idea i just had "string physics? endless string that you follow? not much you can do with string physics, its basically as much fun as playing with a bit of string" - so we were sure something else would get picked. booo all you people that voted for string! - if i could do that again i would almost definatly create a smaller gameplay idea and focus on that, a smaller more intimate game with a nice dynamic :)