Simple test of OpenGL sprite engine. This is nothing like what my final game will look like. The character is just a guy I had drawn some time ago.
Twisted Caverns
Awards
Files
File | Uploader | Date |
---|---|---|
07_09_04_rotating_sprite.jpg
Simple test of OpenGL sprite engine. This is nothing like what my final game will look like. The character is just a guy I had drawn some time ago. |
ArmchairArmada | 2007/09/04 05:06 |
Diary Entries
First Day
I have known about PyWeek for a few years, but this is the first time I have decided to participate. Although I have experience with C++ programming, this is the first larger scale Python project that I am attempting.
My first day began on Monday, so I missed a full days worth of work. However, today I was able to accomplish a fair amount. I have the start of a basic PyGame/pyOpenGL game engine.
There may already exist an OpenGL based game library, but I decided to try to bang out the basics of what I need.
At the moment the program can:
- Create the window
- Load and manage textures
- Animate and draw sprites
- Use a simple scene node hierarchy for rotating, translating, and managing child objects
Tomorrow I plan on working on the following:
- Object/Object collision detection
- Object/bitmask collision
- Collision with rotating bitmasks (actually, it will be implemented so that the bitmask will stay stationary while the gravity vector rotates)
- Creating surface normals from bitmasks (these may be precompiled into an array)
Some future work that needs to be done includes:
- Parsing XML based levels
- Player controls
- An object interaction system
- Menus and displays
- Sound and Music
Wow, this is getting tiresome!
At the start of this project I had a pretty grand vision as to what this game will be like. I may have bitten off a little more than I could chew ... but I'm going to press on anyhow.
I used a few unconventional techniques, which I have to wonder if they would be the best way of going about things. For example, I decided to try to convert a black and white pixel map into a normal map describing the surface of the terrain at each point. I ended up spending all day yesterday writing the conversion program. It works ... though the normals are a little noisy and a few places on the map don't have as good of normals as I would have liked, but it'll have to do.
If you are wondering why I am typing this instead of working, it's because, after a few days straight of programming I feel I need a little break ... which I cannot afford to take.
Well, I should get back to the old grind stone. I still don't have anything that's really playable yet, but I expect to have a player controlled character by the end of the day.
I think I'm going to drop out.
The game idea that I had may have been a little too ambitious for one week's worth of work. If it were PyMonth I could have completed it, but one week is a very short period of time.
Actually, my original idea wasn't much like the game I started working on. My brother sort of convinced me to ditch my previous idea in favor for his. I was going to make a game similar to the Super Nintendo game "Mo Hawk and Headphone Jack." I'm not sure how many of you know the game, but it was a platform game where the ground has interesting gravity that pointed towards the nearest surface -- which means you can orbit chunks of ground and when you are running around the whole screen rotates around. I actually had it all worked out in my mind how I wanted to accomplish it, but my brother had other ideas.
I may have been able to come much closer to completing the game if I hadn't made a few stupid design decisions a few days ago. I thought that using a collision map with surface normal vectors would have been a good idea, since I could simply check the current pixel to find whether an object is colliding with a surface and what that surface's normal would be. Line segments would have been a much better idea.
One of the main reasons I avoided the use of line segments was because I thought I would have had to manually build the collision information for the terrain, and I thought that would involve having to write a tool to be able to edit start and end points of each line segment -- not something I wanted to do (however, oddly enough, the thought of not wanting to waste ten hours writing a program to process a black and white image to create normal vectors never really crossed my mind.)
The really sad thing, though, was that yesterday I thought about it again and realized that Inkscape's trace bitmap feature is very good at creating a collection of line segments from a black and white image. I could have exported that data to a scalable vector graphic then processed that file to create the list of line segments for my terrain. If I were to do this now, however, I would have to throw away fifteen hours of work and rewrite large portions of my game -- thus the urge to quit.
What went rightThis PyWeek wasn't a total loss, though. I learned a lot that I didn't previously know. I created a simple scene graph for handling the location & rotation of objects and child objects. I created a quadtree class for handling collision detection (though I didn't yet integrate it into the actual game engine yet.) I figured out how to extract information from OpenGL matrices, such as world position and world rotation. Aside from terrain collision I had a pretty good game engine.
Watch out everyone, next year I'll be unstoppable. You won't know what hit ya. Kapow! What was that? Oh, it was my game smacking you upside the head! Yeah. It'll be that good, just wait.