June 17th, 2011
I’ve completed a fairly decent amount of the game engine at this point, despite numerous setbacks. I spent almost an entire day trying to come up with a way to rotate a rectangular bitmap around a point without it taking a couple years to render before I realized that the game library I’m using has a function that does just that. Many times I had something working fine, and then something else I’d implement would require me to go back and completely redo the original piece of code. Not to mention the physical setback when I managed to hurt myself pretty badly on a stairwell; I ended up with a pretty decent head injury that required some stitches, painkillers, and most of a day of bedrest. As for coding, this is what I have so far:
Auto-scrolling, WASD movement in addition to arrow keys, an enemy interpreter that works with melee and ranged enemies with unique behaviors, a projectile interpreter that works with both player-originated and enemy-originated projectiles, a completely finished collision detection including ramps (also applicable to enemy movement). I also spent some time compartmentalizing a lot of my code into functions and subroutines that are a lot easier to modify than what I had before. I know the next-most-efficient thing would be to create classes for some of the objects I’m simply using arrays for right now, but I’m not as comfortable creating classes in Python as I was in C++. Besides, my arrays work pretty well; the only real advantage would be readability for anyone who would be modifying my code after me. And since I don’t intend to let anyone else take a crack at it, readability isn’t a concern of mine.
The only ongoing bug is the fact that projectiles actually display their sprite twice per frame, which will get fixed as soon as I implement sprite animation, which unfortunately needs to happen next. I know I had weapons next on the list, but the longer I put off animations, the more convoluted and bastardized my coding is going to become. It’s already going to require a bit of a redesign to get things working the way I want them to in the first place; I can’t afford to have too much more to change. I just need to suck it up and make it happen; I already have a good idea of some methods to try out.
Nick Pawlowski
June 12th, 2011
The collision detection is complete; walls, ramps, jumping and falling. I’ve gotten the friction, gravity, and velocity-increment values tweaked to my liking. It flows about as smoothly as I can see it ever being. It’s time for the next step, which I’m not looking forward to at all.
1) Physics and Collision
2) Scrolling levels <--
3) Sprite Animation
4) Enemy Behavior
5) Weapons and items
6) Dialogues and unique event handlers
After all of that has been finished, I should be able to call the game engine complete, and start actually working on level design. I’ve been toying with the idea of making an actual level editor, like from Aquaria- something to make the actual creation of levels easier than opening up a text file and filling it out with 1’s and 0’s. Maybe I can make actual tiles to use? But that takes away from my original idea of having everything implemented with invisible blocks, and the actual back- and fore-grounds static non-tiled artwork. That’s still a long ways from now, though. Burn that bridge when I get there. For now I need to focus on scrolling. The easiest way to do it is to move the level around the guy when pressing the arrow keys, but that’s so completely backwards from what I have right now, it would require a complete redesign. I’m hoping that the way pygame handles screens can help me out.
Edit:
I found a way to implement scrolling, but it forced me to go back and fix a really hacked-together piece of code that controlled the character’s movement. I then spent almost 3 hours trying to figure out why my ramps suddenly wouldn’t work before I realized that when you round() to 0 places in python, it still leaves a trailing .0 on the end, which was screwing around with my other calculations. I got all that fixed, and now I need to track down the reason that the character sometimes falls right through blocks if he has some sideways momentum. Not to mention that I need to finish up scrolling; it’s all manual now, controlled with WASD, but it needs to keep the screen centered on the character as he moves through the level. I don’t foresee many issues there, but this collision detection problem will likely take me a while. I’ve been sitting in front of my laptop coding for about 13 hours now, and luckily work is about to provide me with a mandated 6-hour break while I go stand watch. After that, I should probably consider getting some sleep before another 6 hours of watch. I’ve made pretty ridiculous progress just over the past two days, and I still have 6 months to go; I can afford to slow down.
June 10th, 2011
I finally managed to download the correct version of the compiler that I needed and get it installed. There were a few incompatibilities, but nothing that I couldn’t work around. I’ve started out trying to translate the platformer I wrote using the built-in Microsoft Visual Basic engine in Microsoft Access on the ship’s LAN. I’ve run into a couple snags, though I suspect that they’re more based on my lack of understanding regarding Python than any sort of software issues. Progress is being made, albeit remarkably slowly.
May 13th, 2011
Day three of deployment, and I’ve hit a brick wall. It seems that I installed the 64-bit version of the python compiler, while I downloaded the 32-bit version of the graphics/game library. Zero compatibility.
I thought I hit a breakthrough when I started looking through my C++ files and found an example that used an OpenGL library, but upon opening the library, I found ZERO documentation. At the top was a comment that said “refer to readme.txt for help,” and of course there is no readme.txt to be found. The subroutines all take user-defined data types as arguments whose purposes I cannot divine. In fact, the entire thing looks pretty mystical; I can’t seem to make any sense of it. The closest I came was learning how to load a bitmap and move it around, though I don’t know what sort of event to listen for when waiting for mouse input. Or how to draw anything other than bitmaps.
This is not going to work. I also found another python library called tkinter that looked promising, but again, no documentation. I might play around with that for a while before giving up. Only three days in… this is not looking good.
Some concept art/sketches for enemies in the game. While getting everything ready to take with me on deployment, I feel a second wind coming on, as far as motivation goes. I finally managed to get the entire script written, and a couple plot points worked out. I revamped some stuff about the final level, to make it flow a little easier. I can see right now that graphics are going to be an issue while I’m gone; I can’t draw worth a shit. I think I’ll leave most of the graphics as simple little pixelly sprites and line art until I get back. As long as I have a working engine and game, I can deal with art and music whenever I feel like it.
This is likely to be the last post for a ridiculously long while. However, if all goes according to plan, when I return, the game should be nearly complete. If I remember to, I’ll try and make little journal entries about my work, and I’ll post those when I return.