Hopefully I’ll get more game development done in the Autumn, since it looks like I’ll still be quite busy during August.

The core gameplay of each game has to be fun for the game on the whole to be fun. Platformers are about jumping, shooters are about shooting and Go is about placing stones on a board. Players are going to spend most of their time playing doing this core activity; everything else is basically extra to hook players at first or keep them interested in the long run. In Artillery Brawl, core gameplay is of course shooting, and before I dwelve into anything else, I have to make shooting fun. In other words, it has to be rewarding.

Artillery Brawl isn’t fun yet. There are a couple of obvious problems I’m going to fix first and see what the results are, then decide what’s to follow. First, there’s absolutely no feedback or reward for shooting; there aren’t any kind of effects (visual or aural) when you shoot or hit something, and units simply disappear when they are destroyed. Not very fun at all. So I’m going to add some particle explosions and sound effects to help with that. Explosions are always fun, right?

Second, there’s the user interface. Currently shooting is controlled with the arrow keys and modifiers (alt and shift), but while I want to keep that, I also want to add mouse control that’s dead simple to use. It should be immediately obvious (at least after pressing the Shoot! button once or twice) what to do in the game without any kind of documentation or tutorials.

Last, but certainly not least, there’s the camera. Currently, other than automatically focusing on the current unit when a turn begins, the camera is completely manual. With the turn system I have in place; multiple tiny shells in the air, many things happening at once and many players in front of the same screen, each interested in different things, this simply won’t work at all. I have to improve the automatic behaviour of the camera, and luckily I have a couple of simple to implement improvements in mind. At the beginning of a turn, the camera should focus so that the current unit and the place the last shot landed should be visible. Between turns, the camera should zoom out, showing as much as possible. When a shell is about to land, the camera should zoom in on that. Later, I can improve it so that if multiple shells are about to land at the same time, I can use a picture-in-picture to show both at once. Also, I’m going to improve the visibility of both units and shells, and add a minimap.

If, after these improvements are in place, the game still isn’t beginning to approach fun, I’ll have to either change something dramatically or start a new project. Simple as that.

Core features

• OpenGL-accelerated 2D graphics
• Realistic physics simulation
• Procedural levels
• Real-time gameplay paused during turns
• Damage model not based on hitpoints
• Multiple game modes with different rules
• Shopping system to buy and customize units
• Hotseat multiplayer on one computer

Everything else is extra, but the above features are central to the vision.

World

The game world is a 2D terrain always viewed from the side and bounded on each side. No unit or other entity may cross the bounds; for example, artillery shells crossing the bounds are silently eliminated. To help with this, there is a “buffer zone” on each side, where no units are placed at the beginning of the game. Scale is at the unit level, with no higher level organization or lower-level detail.

Gameplay

A game consists of a number of rounds. Before a game, the players agree on a set of rules, including ending conditions for each round and the game, and how money is gained. A round might end when only one player has units left, or after a time limit. A game might end after a set number of rounds, or when only one player has money left. Before each round, the players may buy new units and customize existing units at a shop screen with their money.

Each round has a continuous timeline. When it’s not anyone’s turn, time advances in real time. Time is paused during turns, and continues again when the turn is finished. During a turn, a player may give orders to their units, but units only act between turns. A player may start a turn any time they want by pausing the game, or automatically when a unit has finished its current orders.

Style

The style of the game is semi-realistic; not terribly serious, but not “casual” either.

• Units and other equipment will be loosely based on real equivalents
• Units and other entities are affected by physics simulation, but some gameplay elements might take liberties with this
• The world is larger than usual in the genre, though not realistic; we don’t want units to be kilometers apart
• The damage model is not based on hitpoints as usual, but will be simple

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!

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.

The entity system overhaul is almost finished. Everything looks all right now, but doesn’t really behave… there must still be some bugs left in the physics system. I’ll concentrate on bug hunting and cleanup tomorrow, and hope to get to gameplay as well, next week if not tomorrow. It’s really nice to have some real progress for a change.

Architecture

As every programmer knows, or at least should know, program architecture is a hard subject. Really hard. A lot of my development time during the last couple of days has been spent thinking about the perfect architecture for parts of my entity system. I want to get this at least mostly right this time to avoid having to make huge, sweeping changes again in the future (like I’m doing now, but with a relatively small codebase). I feel I have succeeded quite well, with a couple of minor warts I’m going to remedy at some point in the future.

More issue tracking

Today, I wasted an hour or two trying to install Roundup. To my surprise, it got stuck trying to initialize the database, the same problem I had with Trac yesterday. Digging into the problem a bit deeper, it seems sqlite (or its Python bindings) is to blame! Specifically, it dies, claiming that the database is already locked. That means I might give Trac another chance if I get the sqlite problem sorted out, or maybe I should just try to use Roundup with another database backend. I gave up on issue tracking for now though, so more on that later.

Today I’ve continued work under the hood, on the entity system. Both components and entity types are now loaded using the plugin / entry point system of setuptools, which means custom components and units will be really easy to create and distribute. And much easier for me to load. I have a habit of making too many sweeping changes to code at once, and this is no exception. On the other hand, this does result in massive improvements to the entity system and especially creation of entity type files, so it’s all for the greater good.

No screenshots to show for my efforts, but see the end of the post for examples of what entity type files currently look like. This might change before these changes are completed.

Entity editor

I’ll probably have to start working on an entity editor at some point, since I recon unit and other entity creation will get quite complicated when multiple linked entities, collision shapes, etc. etc. get involved. I’m no big fan of GUI programming, especially since Python’s GUI libraries all seem kind of shoddy (though that seems to apply to other languages too, at least C# and Java). Anyway, I’ll probably use wxPython for it. Making it in-game would be cool, but too much effort at the moment.

Trac

I tried installing Trac (again) today since they just released version 0.11, and couldn’t get it working (again). After getting over a few hurdles, I was finally stumped when trac-admin hanged while trying to create the environment. Every time. I really want to like Trac, since it’s excellent when it works, but I’ve had nothing but problems trying to get it working myself. It seems I’ll have to let it go and find some other issue tracker when I really start needing one. I’d like it to integrate with Mylyn, but the (free) options there are a bit limited. We’ll see…

Entity types files

Here’s what a unit type file currently looks like. The interface for this is not fully implemented yet, but I hope I’ll get that finished during this weekend.

from artillerybrawl import component, entity
from artillerybrawl.entity import Entity
 
Unit = entity.get_class("unit")
 
class Howitzer(Unit):
    name = "howitzer"
 
    def __init__(self):
        Unit.__init__(self)
 
        self.mass = None
        self.material = None
        self.hitpoints = None
        self.resistances = None
 
        # Body
        self.body_width = None
        self.body_height = None
        self.body_texture = None
 
        self.collision_meshes = None
 
        # Turret
        self.turret_offset = None
 
        self.turret_width = None
        self.turret_height = None
        self.turret_texture = None
 
        self.turret_min_angle = None
        self.turret_max_angle = None
        self.turret_max_power = None
 
    def create(self):
        entity = Unit.create(self)
 
        # Body
        body_sprite = component.create("sprite", self.body_width,
                                       self.body_height, self.body_texture)
        body_physics = component.create("physics", self.mass,
                                         self.collision_meshes, self.material)
        body_damage = component.create("damage", self.hitpoints)
 
        body = Entity(self.name, (body_sprite, body_physics, body_damage))
 
        # Turret
        turret_transform = component.create("transform", parent=body)
        turret_sprite = component.create("sprite", self.turret_width,
                                  self.turret_height, self.turret_texture)
        turret_component = component.create("turret", self.turret_min_angle,
            self.turret_max_angle, self.turret_max_power)
 
        turret = Entity("%s_turret" % self.name,
                        (turret_transform, turret_sprite, turret_component))
 
        return body

And an actual unit base on the unit type above.

from artillerybrawl import entity
 
Howitzer = entity.get_class("howitzer")
 
class A1(Howitzer):
    name = "A1"
 
    def __init__(self):
        Howitzer.__init__(self)
 
        self.mass = 1000.0
        self.material = "metal"
 
        self.hitpoints = 100
        self.resistances = {
            "kinetic": 50.0,
        }
 
        # Body
        self.body_width = 5.0
        self.body_height = 2.5
        self.body_texture = "a1"
 
        self.collision_meshes = [
            [(0.0, 0.0), (1.0, 1.0), (0.0, 1.0), (1.0, 0.0)],
            [(0.0, 0.0), (1.0, 1.0), (0.0, 1.0), (1.0, 0.0)],
        ]
 
        # Turret
        self.turret_offset = (2.5, 2.5)
 
        self.turret_width = 5.0
        self.turret_height = 1.0
        self.turret_texture = "a1_turret"
 
        self.turret_min_angle = -5.0
        self.turret_max_angle = 85.0
        self.turret_max_power = 100.0