Good news everybody

I guess I got a bit hasty, and instead of doing the responsible thing, I just erased some complicated forward thinking functions I had implemented, and now everything is going to be dealt with as if it was normalized. I had to change a bunch of code, but the entire code base is still less than 1k lines, so it wasn’t too too bad.

Currently trying to integrate a new window/frame with tkinter so I can monitor certain stats, debug or otherwise, without printing ’em. Hopefully I’ll figure it out, otherwise I’m sure pyGame has some sort of window option.

Possible rewrite incoming…

Well this is unfortunate. I’ve realized that I have neglected to use either normalized vectors or un-normalized vectors all over. So essentially I’m always scrambling to figure out what a given vector really is.

Not to mention that I’ve got my code split into components within itself, that is a unit has itself, then under it, it has its AI and Shooter component. I’m mixing and matching name variables and methods everywhere, it’s getting very easy to get lost.

I imagine if I ever get around to rewriting, I’m going to have to create a class for vectors, with all the methods I can think of, such as length, distance, dot, cross product, atan and all that kind of stuff.

I’m trying to get a cone of vision going, but it’s all zany sized, which makes me think it’s the un/normalized vectors messing with me. I can’t be sure.

Thinking about putting up a link to this blog soon though.

Update Oct 25th 2011

Lines 776, files 1

Alright, so I’m at a point where I’ve begun showing it off to a few friends. It’s cool enough to see for my first project. It’s got just enough to be a minimal app. It’s basically moving and shooting still targets now.

What I’ve got is :

  • Basic movements down with mouse and KB+KP
  • Shooting with hit detection. Plus shrapnel streams off the side in a perpendicular way.
  • Can change sprite, I call frame, on the fly with 0-9 keys, if you hit an enemy, they cycle through the frames I’ve got made.
  • FPS is shown at the stop, but I took that from someone else, but it’s a fairly basic:

frame_count += 1

if frame_count % 15 == 0:
t1 = time.clock()
frame_rate = 15 / (t1-t0)
t0 = t1

  • No walls or boundaries for movement, but there is for bullets, because they need to be limited for memory’s sake.
Here’s an image: Here's my first SS

What I’m looking to do now is add a basic AI, where it moves for a second and aims for another 1/2, then decides to fire if it can see an enemy.

Balls though, my math has never really been that great, but it’s sure as shit challenging using all the sine and cosine and atan2 stuff.

I’m also struggling with using PyGame’s Rects properly.

Success!

Turns out the .jpg compression was throwing in some odd pixels even at 100% quality, now I’m using PNGs.

Anyways, my latest victory was using the A* wiki page as an example and making a working, slow, pathfinder! Here’s the script for a working model, but it’s dirty as all hell. I’m really proud of it, the biggest hurdle was obviously learning A*, and what heuristics and admissible were and all that.  After that though, it was tough just turning the pseudocode into python, but I got there!

Now I just gotta use that binary heap to speed it up, and I can move up the scale!

Problem with PyGame and it’s blitting.

I’ve made a post about it on reddit, but the gist is that if I set my colorkey to WHITE (255,255,255) the resulting image that gets blitted is all messed up and black.

Turns out I had a hidden extra surface created just for blitting, so that was how I spent the last 3 days coding. Heh heh.

Anyways, my issue is now there are spots that aren’t being drawn correctly, as if there are non WHITE spots… curious.

A blog about gamedev and vim