Welcome back! I’m very happy to be working on the game again, after the brief hiatus. I made a grid system, as shown below. Here’s the latest thing little app I made, the colors and text is all just there for making the tiles visible, otherwise it’d be a blank screen :
Hit the jump for code examples, and what my old broken version of the code was.
I’ve been meaning to make this ever since I discovered win32 stuff. It uses the .2 version of SendKey, found here, that uses ctypes, instead of the win32 stuff I think, as well as working with 64 bit Windows. Make a shortcut to it on your desktop and just run it as a .pyw file, in order to hide the terminal window that pops up. Simple stuff
Anyways, all it does is is simulate a right-click and then an ‘n’ keystroke. It’s just a quick little app, just a dozen lines long:
import win32api, win32con
import SendKeys
def click(x=-1,y=-1):
oldX, oldY = win32api.GetCursorPos()
win32api.SetCursorPos((x,y))
win32api.mouse_event(win32con.MOUSEEVENTF_RIGHTDOWN,x,y,0,0)
win32api.mouse_event(win32con.MOUSEEVENTF_RIGHTUP,x,y,0,0)
win32api.SetCursorPos((oldX, oldY))
click()
SendKeys.SendKeys('n')
Here’s just a quick update, to say that rotation is fixed, as far as mouse clicking to change the players direction. It used to have trouble with angles more than 90 degrees, but I made the rotation run until the angle between the mouse and the direction the player is facing zero rather than just trying to rotate twice, once clockwise, and again counterclockwise.
That’s really all I changed, beside tidying up some left over code from the earlier incarnation of project shooter. I’m just really happy I can use the mouse to control the dude again, rather than confined to the cardinal directions of the arrow keys.
edit: the formatting is all messed up. Sorry.
Making some progress! With the UI boxes set up, I’ve realized it’s looking a bit more like a legitimate game, which is really exciting for me. Unfortunately, it just makes it more obvious to me though that I have so much work to do! Take a look:
I decided to redo the way I draw the sprites every frame. Initially I had the sprites load from disk every frame, and then select the appropriate sprite to draw, which was fine for just one or two sprites on screen, but as I put more and more baddies on the screen, it became clear that there was a massive performance hit, and I really want this game to run as best as it can, at least for now, since there aren’t many features. To make a long story short, instead of reloading the sprites every frame, I just save the sprites to the instance class, and pull the sprites from there, which is a better idea, because the sprites aren’t going to change on disk at all, at least while the game is running.
Moving forward, I haven’t done much reading into the theory of how to design a game properly, so I’m usually doing what seems like it would work in the short term, generally putting the long term out of my mind until I get a better idea of what I’m trying to do. For example, my modules are really just split into smaller parts in no particular order; they’re just split up in a way that makes it easier for me to find the function I want to. I’m sure I’ll have to move stuff around later.
Also, I’ve fixed the bullets not rotating properly, and I added the exhaust flames to show only when the actors are moving, which I think is a nice touch.
As far as game basics left to go, I haven’t even touched AI in months, so the NPCs just sit there, facing right! I still haven’t implemented delta time (if that’s the right name for it), so if my logic starts getting slow, my whole game gets unresponsive, which isn’t good, for the obvious reasons. I’d like to implement a stats screen that you can open up on the fly too, so that means I need a way to pause the game, which means I need to implement game states. That is to say, I need to be able to tell the game when it should try to move the characters or keep ‘em still. Hopefully that won’t be too tough of an issue.
Today, I’ve created a popup dialog that will be used to display information to the player. It’s nothing to look at, but I feel like it’s important to get right, since the player will be spend a lot of their non-active gameplay time reading them, and it the popups don’t look right, then the game won’t feel as well put together as it otherwise might. I figure I’ll add an option to slowly scale it smaller and smaller, and also fadeout, just so I can broaden its use throughout my code. Once I get the scaling set, I can also start to implement damage numbers, because I once swore to myself that my game would have numbers everywhere.
In fact, this is a good time to mention that my game will have a stupid amount of stat tracking. Like everything possible will be tracked, and hopefully exported to xml or something so you can browse it yourself. I’m talking like amount of times you pressed a given key, or hit or missed something, or the average amount of experience you’ve earned in the first 5 minutes of the game. Little things like that, things that no one really thinks about, but I’m sure there’ll be one fan that is all about stats, and he’ll love it. I don’t know if it’ll drain the memory though, Python’s pretty slow already.
Hit the jump for an explanation of how I wrote my word wrapping , autosizing popup box.