Archive for the tag 'physics'

Box of horrors

Today I adapted the nice setuptools-based plugin module from Spineless to more easily support different physics toolkits in my code, and played around a bit trying to write a Box2D plugin. Frankly, I don’t like the Box2D API design at all, and I like the pyBox2D API even less, as it’s a direct port of the C++ API and doesn’t even try to be Pythonic. Eww. Seems I’ll have to try fake sweeping collision detection and other tweaks to pymunk next to fix the collision problems I wrote about.

In other news, starting tomorrow I’ll try to finish two university courses that are really long overdue and that I want out of the way before September. I have one short paper to write and one coding project to do, so game development progress will probably be a bit slower again for a while. But every finished course takes me closer to graduation (which I’m planning to do next year), so yay for that!

Bullet through the wall

My work with the entity system is pretty much finished for now. Everything seems to be finally working and the code is reasonably clean. I don’t want to get stuck polishing the code while it’s still missing most of the planned features. I didn’t get to gameplay / user interface stuff yet, but I hope to do so next week. Time to get something concrete done for a change.

I did run into some problems with collision detection though. Shells that are fired travel relatively fast compared to their size, which leads to the infamous bullet-through-wall effect when they collide with ground. In other words: they go straight through it. I tried fixing this both by making the terrain collision shape consist of polygons instead of line segments, and decreasing the step size so that shells wouldn’t jump over the line segments. Both of these were too much for pymunk though, and the game ground to a halt. Note this isn’t a problem with Python either, since all the physics number crunching is done in C code.

I now have a couple of options. First, I’ll try pyBox2d, based on the Box2D physics library (which chipmunk is based on, which pymunk is based on…) Box2D has continuous collision detection, meaning that objects can’t jump through each other between steps, but the pyBox2d bindings are based on SWIG, which is much slower than ctypes, so it might have performance problems of its own… Additionally, I just (literally a minute ago) stumbled on Elements, which is another Python 2D physics library based on Box2D, so I’ll take a look at that as well. A backup plan is faking continuous collision detection by making the collision shapes of shells longer than they actually are. Because the action in Artillery Brawl isn’t very dynamic, this shouldn’t cause any noticable errors in collision detection, but I’ll have to see about that if I’m not satisfied with pyBox2d.

EDIT: At least these results look promising for Box2d.

Day two

Like yesterday, I didn’t get what I wanted to done, but did get as much done as I wanted to. :) Summary of today’s accomplishments:

  • Physics simulation for all objects, thanks to Chipmunk (see screenshot #1 below)
  • Units can now shoot, but turns don’t change yet (screenshot #2)
  • Input mapping is done in a really nice, general and configurable way, though still needs more work, but that will be for later (this took quite a while to write)
  • Lots and lots of structuring and cleanup of code

arty3.png arty4.png

I’m really, really enjoying working on this project. Most problems feel bite-sized unlike the hurdles I was facing with complex 3D graphics. My current plan is to continue making smaller projects to ease my way to more complex projects. Along the way, I can start collecting and consolidating common pieces of code for the games, and hopefully end up with a much better game engine than the one I used to work on. For the next project I’m probably going to use at least some 3D graphics. After that… who knows. But first I will, of course, finish this one. I want to show I can get at least something released after too many years. :)

One feature I was going to write about this morning but forgot is the turn system. I’m not going to implement a traditional I-go-you-go (alternating turns) system, but not a we-go (simultaneous turns) system either. What I have in mind is very similar to what I’ve only seen one game, Titans of Steel do. The idea is that each action takes some amount of time, and you get a turn each time your action is done. What this means in practice is that if player A has a light tank capable of shooting one round per second with its light gun, and player B has a heavy tank firing one round per five seconds with its heavy gun, player A gets five times as many turns as player B. On the other hand, player B’s gun will probably do a lot more damage and create much bigger explosions than player A’s gun. And Player A’s tank is probably faster. This should give you some alternative strategies to choose from, and heavier tanks will not be absolutely better.

Tomorrow will probably be a bit slower on the gamedev front as I have people to meet and other things to do, but I’ll still probably get at least something done. And keep you updated, of course.