About this blog
Less boring than it's title!
Entries in this blog
Since the last update I've been working mostly on path finding. I thought I'd show an image of the pathfinding algorithm running.
The enemies (in red) show their paths (in magenta) calculated by A*. The large magenta dots show the furthest along target that the enemy can see - this is what it actually moves towards in order to take shorter, diagonal paths that A* doesn't find. You can see that the process still has some bugs in it - notice how two enemies are moving directly toward the player (in green) despite a wall being in the way.
One problem I encountered was that enemies kept on getting stuck on walls. This was due to their looking ahead and 'seeing' the waypoint just across the corner, when in actuality their non-zero radii meant that they would get trapped on the corner trying to take a diagonal path. To fix this, I used the common technique of enlarging all collision objects by the radius of the enemy before doing the line-of-sight test. Since I only use the static level geometry for line-of-sight tests, I simply make an enlarged version of it at level load.
Since the last update, I've done a couple significant changes. First, I've fixed the client version so it's actually multiplayer again (though it still only works well with very good connections, like LAN). Second, I fixed the py2exe script, which means that I'm able to release a demo again! Try it out, please. This demo also includes fancy diagonal wall tiles for added variety and complexity of levels.
This this demo, I've also been working on improved AI movement. In the demo, they are brain dead and will get stuck on the walls all the time. Now I've implemented A* pathfinding which lets them get from point A to point B easily enough, but it's fairly expensive and inelegant. Since the A* is done on the map grid while movement is continuous, they will walk an "L" shape instead of just taking the diagonal, and A* is a little too expensive to have all of them recalculate every frame, so their targets can fall behind the player's actual location. I'm working on some improvements to this. First, the enemies now scan ahead, looking for the furthest tile on the A* path which can be reached by straight-line movement. Next, I will be implementing a direct line-of-sight test on the player to see if an enemy can move directly toward the player prior to performing any A* search. Lastly, I'll need a more intelligent means of deciding when to recalculate A* paths since currently it's done randomly. Also, handling the new diagonal wall tiles for A* is tricky and currently they are simply considered entirely blocking.
I am also looking at ways of providing Mac and Linux distributions of this. I might give pyInstaller a try for a future release.
In the past couple days I've made two large changes to my project. First, I've started using Chipmunk for physics (and pymunk for Python bindings). This has been a great choice so far. Integrating Chipmunk into my game was painless and the results have been very good. I had initial difficulties getting movement of the player to work well with the physics engine, but the creator of Chipmunk pointed me towards the tanks demo project that Chipmunk ships with. It uses a dummy body bound to the actual body with a pivot joint to control velocity while respecting a maximum force to keep the physics happy. It works perfectly.
The second change, which prompted the first one, is the addition of maps to the game. For now, it's a simple grid of either open spaces or blocks, but I'll be expanding upon that as needed. Thanks to Chipmunk, it was easy to get this working with the existing game.
However, these changes have meant that I've broken multiplayer again, and the py2exe setup needs tweaking. So instead of an executable demo, I've just got this oh-so-pretty picture. Enjoy!
The new site change with free blogs has prompted me to finally try this whole blog thing out. As good a time as ever, I say! I had been quiet on the development front due to a little thing called college and all that it entails. But this new site hasn't just sparked my blogging interests, but also my programming interests. In short, I am now actively working on a game.
It's something I started out a little while ago and never really took very far. It was meant to be an introduction to networking. Now I have a small vision for this project; a multiplayer, 2D top-down shooter with Borderlands-like loot and leveling.
Since I literally have no art, I won't be posting any sweet pictures, but the game has a skeleton of functionality, so to speak. I've attached my very rudimentary working version. Run server.exe to play the game. WASD moves, mouse shoots, number keys select weapons (pistol, rifle, sniper, shotgun - in that order). Starting client.exe and giving the IP of a server version will let multiple people "play" together. Just a warning - my naive networking code means that this might not run anywhere that there is even moderate packet loss. LANs should work fine though.
Who am I kidding, no one wants to play a game with essentially no content! But I would like some feedback on the design process. I've got a good generic system for weapons with varying stats, and I want to hook into the Diablo-style stats minmaxing addictiveness. Would you prefer new weapons to be random loot (like Borderlands) or to be XP-based customizable upgrades to base weapons (like skill trees in RPGs)?