We'll see how this goes. One of my goals with this entry is to add more content and make it less abstract than I did in the last couple of compos. This might be difficult, as I can't draw.

fledgling is a game about a baby bird that doesn't yet have its feathers.

I'm signing off for the night, and with work tomorrow I won't be back until day #3, so here is an in-game mock-up. That little white thing there? Yes, that is our hero...

Got halfway through pixel collision code, and found Tristam MacDonald's very nice collision module released over at his repository some time ago, so why not, I'm running with that. Was very easy to include. So what's on the screen are three sprites, the player bird, the tree, and the ground, against the background. Going to try to do this without tiles. Next up is a camera to scroll a bit around the level, and then more to add to it.

Not a whole lot done tonight other than playing for an hour with a camera for some scrolling. I'm a little unsure of a good way to go about it actually, since the x and y properties of pyglet sprites are expressed in window coordinates. When the player presses a key they change the sprite's world coordinates in absolute terms, but to make the camera work then the world coordinates of all the sprites need to be translated to the window coordinates. However, without keeping track of world and window coordinates separately, it seems I need to reverse translate the sprite's x and y at the beginning of the next update back to world coordinates, before applying another transformation to window coordintes. If that makes any sense. It seems like adding a new pair of properties for world xy could be a good choice.

(this got really long -- it really is a diary entry! Read on if you like long rambling diary entries.)

It happened, I got inspired to learn more OpenGL to handle the scrolling about the level, and spent all of the night on it. Getting it going was fast, but I'm still dealing with some problems. One of the reasons I went from Pygame to pyglet was to learn OpenGL in fact, but up to now I've only used the most basic functions, so this process has been really fun! Some of this stuff is like magic. At the same time it seems like everyone does their GL a little differently so to speak, so it's difficult to get a straight answer from any of the billions of forum posts and tutorials out there to fix a problem. Luckily there are billions of places to look, so with a little digging things get clearer.

The problems seem to be that the sprites are not being drawn to the 'right' place on the viewport. It's a little hard to explain (as I'm not really sure what's going on ;) ). I've set the view to follow the player sprite, and as I track the player.x variable for example to the left in the debug window, it does collide where it should on the x axis and stop moving. But in the viewport the object the player collides with is still a little farther to the left than where it should be.

A second problem is that I can't figure out how to center the view on the player sprite; it's always off to the side a bit. There must be somewhere I can set a point to be half the window width and height, so I just have to figure that out. For example, every on_draw() I call gluLookAt like this:

        gluLookAt(
            self.x, self.y, +1.0,
            self.x, self.y, -1.0,
            sin(self.angle), cos(self.angle), 0.0)

This is from tartley's excellent slideshow and demo code. Self.x and self.y eventually converge on the player's position, so when the player moves the view 'floats' following the sprite. Basically then gluLookAt's eye point and reference point is the player position. However I haven't successfully added the 'center' of the screen to gluLookAt...maybe this isn't the function to define the center?

A third problem is that one of the sprites (strangely just the sprite that is the ground) sometimes shows a flickering black line at its top border (in the field of the screen where you can see it basically, as the sides and bottom are the window border). This problem cropped up only when I started using OpenGL for the scrolling (it wasn't a problem when I was scrolling before with a homemade pair of offset variables applied to the world coordinates).

I feel pretty good that I can take care of these issues, and tomorrow night is the first night I have a full uninterrupted stretch to work, so I'm hoping to make some progress.

As these things go I didn't get a fraction of the stuff done tonight as I wanted. Friends over for dinner and too tired to stay up late again tonight, so I'm turning in early. However, I did fix all outstanding problems, like the scrolling and the flickering, and except for some sketchy collisions progress is forward once again! The next couple of days I need to:

* create the rest of the level and the enemies
* title, menu, restart
* sound and music
* everything else, in other words...the game basically 8).
* a couple more levels if things are going good

I've got a little more done, but I have so much to do I think I'm going to take it easy and take a dnf. I got an enemy walking,



and worked on a soundtrack in lmms, which is a lot of fun, but really hard! Definitely inspires me to get better at it anyway.

The main roadblock this week was lack of time and lack of focus, I didn't have a crystal clear idea like I had last time, which at least enabled me to get the concept down fast. Fledgling was more of an idea and a feeling, but not concrete...it does have promise for the future though.

At least I get more time now to play betas :D.