First Experiments with OpenGL

I got tired of how slow some drawing operations were recently and started to learn OpenGL. I’m rewriting large parts of the game now–about half of the C++ code will be replaced with Scheme, and the other half will be broken out and made a separate part.The game logic itself is fine and does not need to be rewritten. I’m keeping the SVG parser, but making it a separate utility that exports the data into my own format.

The rewrite will solve lots of problems and reduce dependencies on other software: I’m getting rid of Gtk and won’t require Libxml at enduser’s machines anymore. SDL is a new dependency, though.

The output quality doesn’t come close to what I got with Cairo, at least not with the naive approach I tried. Maybe I did something wrong. I know it can be solved because Qt, Amanith and various other libraries can render pretty SVG graphics using OpenGL. Maybe they use fragment shaders or some other technique that’s too advanced for someone who started with OpenGL just a few days ago. I’ll get there eventually, but right now I plan to use Cairo to render textures that I can map to rectangles with OpenGL. That should give me both quality and speed, at the cost of texture memory.

The partial rewrite means I won’t have a prototype to show at the end of the summer as I had hoped, but once it’s done I should have a much better foundation and be able to work faster than before. Working with the new code base is already more fun, which may be enough to increase my output after the rewrite, since it could mean I end up putting more hours into the project.

Even Bigger Map

I increased the size of the map again. I’ve included a scaled down version (15% of the normal view size) of the map as it looks right now below. As you can see it’s far from complete, but I think this will be the final extent of this scenario.

I’m not sure exactly what the scenario will be, but something like an attack on Denmark with Sweden getting drawn in. The south of Sweden was pretty much undefended (we had prepared for the war between the Soviet Union and Finland to spread to the north of Sweden, not for war with Germany), but the Swedish navy could probably have helped the Danes a bit.

I haven’t done much programming this weekend, but I experimented some more with the Antlr parser generator. I can now recognize field access expressions like foo.bar.baz and transform them into (slot-ref (slot-ref foo ‘bar) ‘baz). I detest having to type all that garbage just to access some fields, so anything that can rid me of that is welcome even if it means writing a preprocessor. More about that later. I’ll need to work more on it before I have something that can be used.

Illustrating Farmlands

I’ve been experimenting with the look of cultivated areas today. I’m quite happy with the result so far–it’s much better than the flat yellow surface I use in most places, that’s for sure.

The lines and dots in the fields are all vector data.. Maybe I should use bitmap textures for these things instead? I’m completely inexperienced with vector graphics design work, so I don’t know how people usually handle this kind of stuff.

I also added shadows underneath the tanks, to place them more firmly onto the ground.

Submarines

I took a break from coding and worked a bit on the graphics instead. The map is much bigger now and stretches from the west coast of Denmark to the east coast of Sweden. Here’s a screenshot of a new u-boat outside the German coast:

Proactive Air Defense

Anti-aircraft units are now much better at defending their area, since they get to shoot first–during the enemy’s turn. Things are a bit confusing now, though, because the chain of events isn’t made manifest to the player. If you lose concentration and accidentally move a plane into the range of an hostile anti-aircraft unit you may be surprised to find your unit suddenly half as strong as it used to be. If you’re really unlucky the whole unit may disappear, with no indication of who fired at it.

In short, this change makes animation a requirement, and not just a feature that would be nice to have. I probably won’t take care of that right now, though.

Automatic Reactions

I haven’t completed any new functionality yet, but I’m working on a framework for managing automatic reactions. This is needed by anti-aircraft guns for instance, since they must be able to react immediately to defend their area effectively. Before an attacking plane is allowed to drop any bombs, all air defense units in range will get a chance to shoot it down.

To make this work I need to decouple the request for an action from actually performing the action, so that other units get a chance to intercept. When the user tries to attack an enemy unit, I now send an attack request to an arbiter object running in another (lightweight) thread. The arbiter asks enemy units nearby if they want to counter the action, and schedules the resulting actions. The schedule is then executed and the results broadcasted to everyone who can see them.

These changes not only enable automatic reactions; They also bring me closer to having networked play and fog of war (which refers to the inability to see where all the enemy’s units are).

Crosshairs

Finally, after a lot of internal changes, you can tell if a unit can be attacked by holding the mouse pointer over it. A red crosshair will appear over it until you move the pointer away again. Here is a screenshot:

The mouse pointer doesn’t appear in the screenshot for some reason, but I was holding it over the crosshair. The selected unit is indicated by a sharp border around its hexagon, and the hexes it can move to are highlighted, just like before. The tank isn’t really supposed to be able to cross the strait in one turn, but I haven’t yet bothered to update the terrain graph completely after I made changes to the hex grid.

Another change that can be seen in the screenshot is an anti-aircraft unit, near Copenhagen. I haven’t written any code for it yet though, so it behaves like a tank

To accommodate the crosshair functionality I wrote a simple quadtree implementation which can map mouse clicks to scene graph nodes quickly. The new code is about 700 times faster than the old one, which searched through the entire scene graph including terrain and all. Working at this made me realize a lot of things about scene graphs and how they should interact with other parts, which will probably help when I set out to speed things up later. Currently there’s an annoying lag when you do many things that require updating the window, because I redraw too much stuff.

A Year has Passed

It has been a year since I posted the first screenshot (on another blog), which is the earliest recorded sign of activity on the game. I can not say exactly when I started, but it seems I have been working on it for about a year now. I have been pretty serious about the game since my vacation last July, much of which I spent coding. That was when the tinkering transformed into an attempt to write a complete game–a product.

Here is the old screenshot along with a fresh one for comparison (click for full size). I’ve come a long way since then.

I have fixed many bugs and shortcomings in the SVG parser recently. Editing the graphics is now much more comfortable, since you can use more SVG features and don’t have to trick Inkscape out of using previously unsupported features such as transformation matrices.

The source code is now 6435 lines, of which 3983 lines are C++. The rest is Scheme code. The count includes comments and blank lines, but not header files. There’s some dead code too that could be deleted, but not much.

Progress and Plans

I have improved some more interface details. Now, when you select a unit, the borders of its hex become thicker until the unit is deselected again. Another change is that units now turn in the direction you move them, so a tank that has just been moved from west to east will face east, for instance.

I’ve been thinking about announcing an early preview version of the game on some Internet forums for feedback, and which features should be included in that case. I don’t want to send out a crappy game with a bunch of half-finished features, but I don’t want to wait until everything is perfect either. Right now, I’m leaning towards trying to get something simple out late this summer.

The features I think must be included in the preview are:

• One relatively large and good-looking map, of let’s say Denmark, with shifting terrain etc.
• There must be some visual indication that a unit can be attacked by the currently selected unit. Panzer General put a cross hair around it if I recall correctly.
• Deployment and movement of lots of units must work flawlessly since you will be doing it a lot.
• The bombers must be counterbalanced by for instance air defense units.
• I must either adjust the hex grid to the terrain or the terrain to the hex grid so that it is always clear if a hex is a land or a sea hex, for instance.

That is it, I think. The other stuff either works already or is not essential. I may be forced to include zoom too when I increase the size of the map if it becomes too hard to get an overview of the field.

The preview version probably wont be much fun to play without sound, animations or surprises, but at least I’ll have something to show. There won’t be anyone to play against anyway, since there is no AI and no server You will have to sit next to your opponent.

Bombers can now Bomb

I’m back to hacking on the game again. I’ve made the bombers able to attack and polished some small things, like how units and flags are arranged inside hexagons.

As you can see, the map is also bigger now, and the panel is placed at the top of the window and contains more buttons. The “toggle view mode” button changes between air mode and ground mode, ie which unit is scaled down when an aircraft shares hex with a surface unit. I know the buttons look awful but fixing that can wait.