Yay! I've made some good progress. I finally decided to make a shooter-based maze game, and its coming along really well. So far the game has a camera, a light effect, collisions, particles, most of the basic fundamentals. :) If you want check it out, download it here.

Well, after spending quite a lot of time thinking about how the hell am I turning a boring subject into an interesting game, I said screw it and just went with the most interesting idea I had.
So I'm trying to do an on rail shooter this time. No gun or wii - mote though :).
What is interesting here is that it'll be the first game I do with actual animation. Also the robot enemies will be, to some level, procedurally generated. I don't know if I'll go full pygame.Draw or use images as parts and mix within them, but somehow I want it to be generated.
Well I hope I'll make up for the lost time thinking and have a game finished by the end of the week... Good luck everyone :)

New check in. Robot moves. Game can randomly create basic level content for testing. The art is currently in weird sizes, so I scaled all the things I need down to 20×20. Will work this out with the crew later. Still haven’t solved the lamina.clear problem for the timer — what the hell. It seems like it just isn’t fast enough to be used in a realtime app. Sigh - now I have to find an openGL gui solution. Maybe there is something I can do to finagle the openGL and sprites and get a hacked out solution. Another option might be to somehow make rabbyt do the clearing for me, as it’s clears are absolutely fine. Anyway, here is the first screenshot. The robot looks just like a drum, so you probably can’t tell where it is, but trust me, it’s there. This is a randomly generated level, and the bot can’t actually interact with it yet, so it just drives around. Also, you can see that something is ‘off’ since only the top wall is there. I suspect I’ve calculated something wrong and the other walls are off screen.

Well, we have random map/territory generation now :D
That was probably the second biggest question mark for us, behind networking :D

Right now we're going to try and get all the game-play stuff coded today so we can focus on networking, ai, music/sfx/gfx and polish the rest of the week ;)

And for those interested - maybe we can start a trend, anyone want to see what we're trying to make?:
http://code.google.com/p/hiths-pyweek6/wiki/MainIdea

Enjoy - cya later :)

It's a dance game (curse you, Richard, for polluting my mind with all those dance videos! :-), so I originally thought about doing something DDR-style where you have to hit select characters at specific times, but that seems a mite too complex for this interval, given that I can only hack on it in my spare time and I work [i]long[/i] hours.

While hacking up Snake yesterday to show someone on GameDev how easily it could be implemented by treating the snake as a list of coordinate pairs on a grid, each of which adopts its predecessor's coordinates when the snake moves, I think I nailed down my core "dance" gameplay:

Josef dances by routing power within his body from an internal producer to a consumer, causing him to adopt a position for a brief moment. Doing this repeatedly causes him to "dance" in an interesting way, even though he was never programmed to.

Yes, that's a bit obscure, but if you can read between the lines, you should be able to figure out exactly what I plan to do...

Gotta get to work now!

Having an artist on board is really cool, I have lots more time to write code. On the other hand, there's already more art assets than any of my previous games had at their conclusion.

Pictured is the animation editor I wrote today. Images from Biccy come in as Photoshop files with 30-40 layers corresponding to different body parts and stages of animation. I use ImageMagick to split each layer into a separate PNG file (this is a bit glitchy and needs careful attention; I also tried PIL but no success).

I then draw a bounding box around each layer in a 128 line pyglet program that calls ImageMagick again to do the cropping and writes the bounding boxes to a file (which can later be loaded for editing). This is just to save space on image sizes.

The pictured program is used to assemble large sprite pieces ("anims") out of individual layers. The "select" window lets the user page through all the layers and add or remove them from the current anim shown in the "composite" window. Along the bottom of the composite window is a timeline scrub; as layers and the origin are moved around with the mouse, keyframes are inserted automatically and the animation can be played back immediately. Each "anim" is named and saved into a text file that stores all animation data, bounding boxes and references to the required images.

Finally, another script picks up this text file and copies the images that were actually used into the resource directory, scaling them down along the way (we haven't decided on a sprite size yet, which is why this is so late in the pipeline).

Constructing simple idle and movement animations is proving to be quick, so I'm optimistic that the time spent setting all this up pays off in the long run.

Unfortunately I didn't get a chance to get anything done yesterday, but hopefully I can make up for that today. My best idea as of yet is to go for an RTS-style game. My idea was inspired from an episode of Futurama where there's a colony of rebelling robots who need lug nuts.

You will be building the robot colony and managing resources (hopefully there will be some element of "war" via attacking humans, but the game won't be centered around battling but rather around building). It's not going to be a "move your troops around" type game, but more of a "manage your resources and buildings" style (like sim-city).

I hacked out most of a crude engine this morning, hopefully I'll get a chance to get something uploaded tonight. I'm using PyGame and PyOpenGL for all of my rendering and blender to model some simple buildings (using "obj" loader from the PyGame recipes to render the models).

This is my first time trying to rush a game out like this, hopefully I don't waste all of my time on support code (the engine / math routines / etc).

Here's a shot of a "stand-in" (until I get better models) robot factory!

Our hero woke up with hair today. After running extensive tests, we could find no real reason for this. We released him so he could get back to doing what he does best. What does he do best? Sorry, that is top secret. I was told I could give you this picture of our hero starting his day. What bravery, what passion, what luscious locks.

Today Tinman and I began discussing the concept behind our game. We decided to attempt something along the lines of a 2d platformer equivelent of a level from Shadow of the Colossus set in a post apocalyptic wasteland with a giant robot, sorry "A Really Big KILLER ROBOT!", hopefully portraying a similar empty but epic feel.

As you can see from the uploaded concept art of mine I have absolutely no graphical skill so we decided to follow a minimalist style for visuals to avoid serious ugliness.

Tonight I will be writing the first version of the level editor as well as beginning composition of some of the music (my favourite bit). Tinman will be writing most of the engine code because of his games development experience, while I'll probably do most of the UI stuff.

Now I have a level editor! The exact API needs a bit of work so it's not checked into Cocos yet. The code is below though. It's fired whenever I press "e" and saves the XML to "editor-save.xml" when I close the tile palette window.

    @director.window.event
    def on_text(s):
        global editor
        if s == 'e':
            editor = TileEditorLayer(level, 'data/level-tiles.xml',
                'level-tiles', lambda layer: scene.remove(layer))
            scene.add(editor)
            director.window.push_handlers(editor)
            return True

class TileEditorLayer(cocos.layer.Layer):
    def __init__(self, map_layer, filename, id, on_done):
        super(TileEditorLayer, self).__init__()
        self.map_layer = map_layer
        tileset = cocos.tiles.load(filename)[id]
        tilesets = [
            (filename, ''),
        ]
        self.selector = TileSetWidget(tileset)

        @self.selector.window.event
        def on_close():
            self.map_layer.save_xml(tilesets)
            director.window.pop_handlers()
            self.selector.close()
            self.selector = None
            on_done(self)
            return True

    def on_mouse_press(self, x, y, buttons, modifiers):
        x, y = self.map_layer.get_virtual_coordinates(x, y)
        cell = self.map_layer.get(x, y)
        cell.tile = self.selector.tileset[self.selector.current.tile_id]
        self.map_layer.set_dirty()

class TileSetWidget(object):
    def __init__(self, tileset):
        self.window = pyglet.window.Window(width=64,height=256,
            style=pyglet.window.Window.WINDOW_STYLE_TOOL)
        self.window.push_handlers(self)
        self.tileset = tileset
        y = 0
        self.batch = pyglet.graphics.Batch()
        self.sprites = []
        for n, k in enumerate(tileset):
            s = pyglet.sprite.Sprite(tileset[k].image, y=y, batch=self.batch)
            if not n:
                self.current = s
                s.color = (255, 200, 200)
            s.tile_id = k
            self.sprites.append(s)
            s.scale = 32. / s.width
            y += 32

    def on_mouse_press(self, x, y, buttons, modifiers):
        for s in self.sprites:
            if x < s.x or x > s.x + s.width: continue
            if y < s.y or y > s.y + s.height: continue
            self.current.color = (255, 255, 255)
            self.current = s
            s.color = (255, 200, 200)
            return True

    def on_draw(self):
        self.batch.draw()

    def close(self):
        self.window.pop_handlers()
        self.window.close()

Oh, and see that dual-window thing going on there? pyglet rocks :)