I decided that I will talk about my basic gameplan before the competition begins. I plan to create a 3D game that, I hope, will be rather diverse with the interactions, goals, and world designs. This will be quite a challenge, but I am confident that I can do it.

I will be creating a simple 3D game engine from scratch, which is something I had quite reasonably been able to accomplish during the last Ludum Dare -- though I didn't have much time after those two days to complete the actual game.

Some may be wondering why I am not using something like Panda or Soya. This basic reason is because I want people to be able to play the game from source with a minimal number of dependencies -- just PyGame, PyOpenGL, PyOde, possibly NumPy, and the standard modules. When I tried to test out Panda it actually didn't work on my machine. I didn't bother to spend anytime trying to get it working, but I figure I might not be the only one to run into problems using it.

I expect the PyOde physics and collision detection to be the most complicated aspect of the game's development. I originally did not want to bother with using PyOde, but considering Python's speed I think it might be the only reasonable way to go. Back in the last Ludum Dare I rather successfully implemented ray-triangle intersection tests and were able to test about 60 intersections per frame at 60 frames per second -- which was somewhat reasonable. However there is only so far you can go with simple ray-triangle intersections (for example my character's head and upper body would pass through low ceilings.)

As far as the actual game design goes, I decided that I will not wait for inspiration. I will immediately begin programming the sort engine that I want to use. I would inevitably come up with at least a few good ideas of how to put it to good use. My brother, of course, would no doubt also come up with a few ideas of what I could do with it -- though I will be doing pretty much all the work.

The first day will be used for programming the actual 3D engine part. By the end of the day I expect to have animated 3D meshes and a basic scene graph up and running. The animation will be achieved by simply swapping out meshes (either display lists or vertex arrays) for each frame. I considered using simple vertex interpolation, but my initial tests were not too promising -- the slow down was unacceptable.

The engine will have next to no optimizations. Instead of geometry culling I will simply be using low-resolution meshes and textures with graphical detail roughly on par with the PlayStation 2. Worlds may be divided out into rooms or areas connected by doorways or paths (similar to The Legend of Zelda: Ocarina of Time and many other Nintendo games.) This will provide, I believe, sufficient optimization for what I would want to accomplish. The lower mesh and texture resolutions should also help speed up the graphic design work.

Here is a basic run down of my planned schedule:

1. 3D graphics up on the screen with basic animation and scene graph. Music selection.
2. Game states, and beginnings of Ode based game entities. Testing and tweaking Ode.
3. Character controllers, entity interactions, simple effects, music and sound effects, etc.
4. Finishing programming. Beginning graphics.
5. 3D Graphics, textures, animations, world designs, etc. Integration of content into game. Testing.
6. 3D Graphics, textures, animations, world designs, etc. Integration of content into game. Testing.
7. Tweaks, adjustments, final bug fixes, final testing, polish, etc. Release.

Even with not getting a good night's sleep yesterday I was able to accomplish everything I wanted to do today. I still don't know what kind of game I will be making, but at least I have a nice start on a 3D engine that can be put to use in creating something interesting.

I have been listening to music with Creative Commons licensing. There is a lot of great music. I will have to figure out what music to select and to ask if the artists would be ok with them being used in a video game competition -- which I doubt there will be too many problems with.

Unbeknownst to me, PyODe has a bug that throws a major monkey wrench in my plans! Using a TriMesh causes a segmentation fault when you try to call space.collide in Ubuntu! I was planning on using a trimesh for the world geometry my characters and objects would move around in, but I might have to change my plans. The only solution I could think of is to maybe use a collection of other collision primitives ... but this doesn't sound very appealing to me.

You can read more about the bug here: https://bugs.launchpad.net/ubuntu/+source/pyode/+bug/258131

Because of an over ambitious project idea, a PyODE bug, an engine not too well suited for anything too grand, and a severe shortage of time, I decided to go with a much simpler game idea. This morning I made myself a cup of coffee using one of those singles bags and I thought to myself, "Hey, this has a string!" So now my game will be about making tea and coffee.

Teacups and coffee cups will go along three conveyor belts. Pressing 1, 2, or 3 will lower the low, middle, or high conveyor belt's tea bag into the the cup. Try not to miss any cups, and don't put any tea in coffee cups. When the coffee mugs reach the end of the conveyor belt you have to press the space bar to fill them with coffee (or something like that, I'm not sure yet.)

Odd idea? Yes, but at least I don't need to mess with physics, animation, or anything too complex. Right now I just have the graphics for a coffee cup, a tea cup, and a tea bag. I might be able to pull this off.

I'm not really in the mood to continue, so I think I might just quit. I probably could make the game before the deadline, but I think I might rather relax a little instead. I really thought this was going to be the PyWeek that I actually end up making something, but I guess I'll have to try again next time. Here are the teacups, mugs, and teabags that I made yesterday:

One of these days I will actually have something to show people. When? I'm not sure. I can comment on a few things I learned from this PyWeek, the last Ludum Dare, the Mini Ludum Dare two months ago, and a few other previous competitions.

The first observation I could make is that even though Ludum Dare is only two days long, both times I accomplished a lot more than I ever had during any of my PyWeek attempts. This may be due to the following reasons:

• With the Ludum Dares I quickly came up with a game idea and just went with it. I didn't worry about whether it was good or not because if they were bad it would have been only two days wasted. With PyWeek I struggled for a long time trying to come up with an idea I liked, and didn't really come up with anything I felt was good enough.
• Having more time seems to make me more lazy. It's easy to think, "I have a week, that's more than enough time." On the other hand, when I have only a short amount of time I'm thinking, "This has to get done NOW!"
• Going along with the above two points, having less time and a more definite idea kept me more focused. I spent most of my time this PyWeek rather idly tinkering with a graphics engine -- which I didn't really have to do.
• Although making 3D graphics and animation is fun, 2D can be quicker (depending on a lot of factors, of course.) I was more satisfied with the side scrolling platformer I tried making during the Mini Ludum Dare than with any of the other competition attempts -- it was fun, easy, and fairly quick to make. Oddly enough more was accomplished during the 3D Ludum Dare attempt than during this PyWeek (though they very similar designs.) I think it's easier to overlook an engine's design problems when there is too little time to worry about it (though there were really only a few problems, namely compiling OpenGL display lists seemed very slow and I didn't have any text capabilities.)
• Not being able to use PyODE the way I wanted to had taken a lot of wind out of my sails. Simpler game dynamics seems to allow for more rapid development.

Some things I will try to remember when the next PyWeek rolls around:

• Come up with a game idea immediately! It doesn't matter if it's a great idea, it just has to be clearly defined. I need to know what I'm working towards. I didn't come up with a real idea for PyWeek until Thursday.
• It might be good to stick with 2D. Though I enjoy making 3D models and animation, the programming aspect seems more difficult, time consuming, and error prone -- especially if collision detection is involved.
• I should not write a graphics or physics engine. Going along with the above point, a lot more could have been accomplished if I simply used pyglet -- especially when it comes to menus and text. Trying to write my own text engine in OpenGL feels like a waste of time.
• Get working gameplay up and running before anything else -- hopefully on the first day even. It's too easy to work on other little things (graphics, engine features, etc.) and keep pushing back actual gameplay development. If every day there's a working game then when the deadline finally arrives I would not be stuck with something unplayable.
• Remember to have fun. A couple of times over the past week programming just felt like too much of a chore. I think it was mainly because I did not have a clear goal to focus on, but, as a whole, the process of creating should be fun. I don't have to worry about whether or not anybody would enjoy my game -- I should just enjoy making it.