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.
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:
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.
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!
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.
I’m making just the basics for my top down shooter now, got just a simple moving around thing going in an open arena.
I want to add in bullets, and I can only think that bullet classes are the best way of doing it, but I’m not sure about the cost of many classes.
Early Optimization is the root of all evil though, I’m told.