Brainfold

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!

Tags: Artillery Brawl, Box2d, graduation, physics, plugins, pymunk, setuptools

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.

Tags: Artillery Brawl, Box2d, entity system, physics, pymunk

As promised, I actually did some game development this week for a change. First I upgraded to Pyglet 1.1 (beta 1) and pymunk 0.7.1. After that, I finally implemented a better camera for the artillery game. It’s really nice now, smooth scrolling and zooming with constraints so you can’t move or zoom “beyond” the playing area. Unfortunately, none of the improvements can be seen in static screenshots. Next thing I’ll probably add is some kind of a background so it’s not so easy to get lost while moving around. After that, I need better controls. I should also try and take advantage of Pyglet 1.1’s new features.

But unfortunately, now I have to concentrate on Prolog programming to get rid of a university course. I have the exam for Logic programming next week, and I have to do a couple of bigger excercises before that. But after that, probably more game programming, so stay tuned!

Tags: Artillery Brawl, Pyglet, pymunk

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

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.

Tags: Artillery Brawl, physics, pymunk, screenshots

Ok, I’m all ready to start development for today. Today I’m going to focus on gameplay and playing around with physics assisted by Chipmunk. But first I’m going to write a bit about my plans for the game.

There are two major gameplay features and one programming technique I want to emphasize. Let’s get the dull technical one out of the way first. I wrote about component-based entities back in December but never got far enough with my “main project” to get anything actually implemented. I’m going to remedy that with this game and experiment with component-based entities. It’ll be a very useful experience for future projects and hopefully some readers. But more on that later as I start implementing that stuff.

And now the interesting stuff. The feature I most liked about my old artillery game was its modular weapon system I wrote about in my memoirs. I want to create something similar, but of course better this time. Maybe I could even let the players customize their weapons, we’ll see… The other feature is not really a feature, but a kind of a fixation of mine. In addition to sci-fi, I’ve always liked “pseudorealism”. Not simulation-level realism, but I’ve always liked stories and games that are not pure fantasy. In the artillery game, this was manifested as separate kinetic and explosive damage, drag for the artillery shells and other features more complex than usual for the genre. I have also always dreamt of writing a pseudorealistic shmup (shoot’em’up), so maybe that will be my next project…

And now, back to work!

Tags: Artillery Brawl, entity system, gameplay, pymunk

Ok, so I didn’t actually update during the day and didn’t get an actual playable game prototype done today, but I’m damn pleased with my progress in any case. And I don’t remember programming being this satisfying for a long, long time!

Anyway, I got randomized, heightmap-based terrain and basic units implemented. You can also freely scroll and zoom the camera using the mouse. I started on gameplay but didn’t get any actual game mechanics done yet. The basic groundwork is already there, but I need some kind of “game physics” going on next. I’m not sure if I should just make a quick hack or use something like Chipmunk right from the beginning (I’m going to eventually use physics simulation anyway). The code isn’t a horrible mess, but I have avoided getting bogged down perfecting a design. Instead, I’ve done what needs to be done to get a feature up and running, then structured it better afterwards.

Here are the promised screenshots anyway, testing 200 units randomly scattered around. I found the images / textures on Google and have no idea about their copyright, but this is just a prototype after all. Zooming isn’t constrained in any way yet. The units are actually resting on terrain, not floating above it, but the texture has a bit of empty space at the bottom and there’s no concept of offset for the units yet.

Tomorrow I’m going to write a bit about what I have in mind regarding the design of the game, and of course continue actually programming. Stay tuned!

Tags: Artillery Brawl, pymunk, screenshots