And slowly, but surely, they drew their plans against us...

OpenFracas includes a few features that the original Fracas doesn't have; resizable gameboard and maps of any size are two that come immediately to mind. These features are relatively trivial, though. Sure, they make the game more usable, but they don't really place OpenFracas above the original in a significant way.

What we've wanted to have for a while now are features that impact gameplay that Fracas never had; features that feel natural for this style of game and make the game different. Making capitals optional was one such feature; teams is now another. We're excited to have added this feature, since it helps to distinguish us from the original game, and was something that was surprisingly easy to implement...for the most part.

Initially, teams confused the AI to no end; they would keep attacking other players they were allied with. At least, they tried to. The game wouldn't let them get away with it, and they'd get thrown into a never ending loop trying to attack their friends. A surprising amount of effort had to go in to getting the AI to work in teams. It had to stop 'fearing' nearby troops owned by allies, and start recognizing them as allies.

Now that the AIs are able to work with allies, it presents an interesting cop-out. Our AI is bad, and we know it. The truth is that its a very complicated thing, getting an AI to play well, and we have too many other things that still need doing to give it the attention it deserves. But what would playing against 5 AIs, all on one team be like? I can't say that I've tried that - yet, but I suspect that it might just be a little bit harder than when they're all on their own. Perhaps that is one way for human players to get a little bit more entertainment out of the AIs when playing against other humans isn't an option.

Creating a Mac OS X Port of OpenFracas

During the course of development of OpenFracas, we have returned again and again to the idea of distributing the game for OS X. It was our original goal to support all 3 of the major operating systems: Linux, Windows, and OS X.

OpenFracas has been developed using fairly open and portable technologies (Ruby and the GTK) and so the idea was good in theory, but in practice it proved more difficult. OpenFracas was developed first for Linux, with a Windows port being quite easy to make. We both have a free legal copy of Windows XP provided to us, so porting the game to Windows wasn't a problem. Mac OS X, on the other hand, is proving to be more difficult.

Creating the port for OS X requires access to OS X, which in turn requires a Mac, since that is all that OS X will run on. We think that we have a complicated series of instructions that, if followed, will allow the game to run on OS X, but without a Mac, we cannot verify these steps. Without trying these steps, we cannot move beyond it to a more seamless installer for our programme.

Neither of us are really up to spending the kind of money required to buy a new computer just to create the Mac port of OpenFracas. So we're asking anyone reading this who is interested in helping us out, give us a shout - we'd love to hear from you, and hopefully we'll be able to get the game up and running with your help.

Gameboard Size

In all of our releases, from our initial preview release up to and including our 0.3.x series, the gameboard has been a fixed size. We tried to choose a size that was large enough to be easily visible and still be small enough to fit on everyone's monitors. An assumption that we made is that everyone will be using, at a minimum, 1024x768 as their screen resolution. The size of the gameboard was adjusted to match that assumption.

While this assumption is probably true, we should not be taking it as a given. There could be people who still use 800x600, or even lower. Conversley, there also could be people with very large displays; sizes of 1600x1200 and 1920x1200 are not unheard of these days, and the gameboard would appear rather small on those monitors.

I'm still rather new at using the GTK to create user interfaces, and I'm still learning the ropes of custom widget creation. Until now, despite extensive google-ing, I have not been able to determine how to detect the actual assigned size of a widget.

A little bit of an explaination might be in order. In the GTK, you have the option of requesting a fixed size for your widgets, but that is not the most desirable approach. There are certain controls that act as containers. These controls allow you to add other controls to areas inside of them. Once you have added these controls, it will automatically size them for you, based on preference selections you make. As such, there is no fixed size for a widget, and the programmer's code usually never explicitly sets the widget size; there is no work left to be done. Because of this, I had no way of knowing how large the widget would be if I allowed it to scale freely.

And then I found it. It had looked dillegently, but had - in the end - given up. self.allocation.height and self.allocation.width allow you to determine the real height of your custom widget in pixels. With this information, the map can be made scalable. Can be, and has been. There is no tickbox to tick or slider to slide; just resize the window, and the gameboard should scale with it.

In addition to being scalable, there are two new preferences that can now be set; outline thickness and troop text size.

Resizing still takes a little bit of machine power, as a lot of memory space has to be adjusted to fit the new sizes, but we've been able to cut that down some already. Obviously there are still some practical restrictions on how small the map can be, and for now, there are also speed-related problems with gameboards that are exceedingly large. Even if we can't move beyond those problems, though, I think that this is still a nice improvement over the old fixed-size board.

The scaling gameboard means that in the future (hopefully by our 0.4 release), the gameboard will not have a rigid fixed size like it does now.

Cairo and the GTK in Ruby. Creating Custom Widgets.

This post is more about programming than it is about OpenFracas.

When I was trying to learn how to use cairo to create custom widgets in the GTK with ruby, I ran into a real lack of documentation online. There were lists of functions and all, but lists of functions just don't compare to samples, as far as I'm concerned. So I've decided to put together a little bit of code that can be used as a how-to or as a starting point for someone else's projects

The following Ruby code is an example of a custom GTK control created using the RCairo SVG library (cairo is built into GTK 2.8+) by extending the Gtk::DrawingArea class.



#we need to include these for obvious reasons
require 'gtk2'
require 'cairo'

#This class extends Gtk::DrawingArea
class CustomWidget < Gtk::DrawingArea

def initialize

#call Gtk::DrawingArea's constructor first
super()

#connect the expose event
#(means drawing is needed)
#to the fRedraw function
self.signal_connect("expose_event") do

fRedraw

end

end

#called when we get an expose event
def fRedraw

#create our drawing context.#whatever we draw on this ends up on the screen #self.window is a Gdk::Window
context = self.window.create_cairo_context

#get the actual height/width of this control
height = self.allocation.height.to_f
width = self.allocation.width.to_f

#make drawing occur offscreen (double-buffering)
rect = Gdk::Rectangle.new(0, 0, self.allocation.width, self.allocation.height)
self.window.begin_paint(rect)

#set the colour and flood the region
c.set_source_rgba(0.5, 0.4, 0.6, 0.9)
c.paint

#set the colour and draw a line
c.set_source_rgba(0, 0, 0, 0.9)
c.move_to(height / 2.0, width / 2.0)
c.rel_line_to(height, width)
c.stroke

self.window.end_paint

end

end

That is a very basic example. From what I understand, it would be a good idea to try and buffer it by using an ImageSurface and creating a graphics context for it, then drawing to the ImageSurface's context. Once you're done, you can set the window context's source to the ImageSurface, and .fill the area.

for example, to create the image

@image = Cairo::ImageSurface.new(Cairo::FORMAT_ARGB32, height, width) @imageContext = Cairo::Context.new(@image)

Then in the fRedraw function where context is the window's context

context.set_source(@image, 0, 0)
context.paint

You'll still need to add this control to a parent control such as a window or a layout container. You'll also need to .show it for it to be visible.

For drawing things with a fixed scale, you can use the .scale command to scale a context down to a specific size. There's a really good tutorial for using cairo for drawing here. It's in Python, but it's still very helpful.

New faster map previews

With the recent release of OpenFracas v0.3.0, I thought that it might be a good idea to start a development journal to track our progress, and to document and discuss some of the new things that we're working on for the next few versions.

The first thing that I'll mention is the new open map dialogue. Until now, we've been using the same control that draws the main gameboard to draw the map previews when starting a new game. This is somewhat unnecessary, as we don't need the same level of detail for map previews.

We've now replaced that control with a much leaner one, taken from a version of the programme from way back when - when drawing was being done in a much simpler manner.

Since this new control draws map previews much faster, we can be a little more liberal in displaying them. Now, when in the process of opening an existing map, a preview of the highlighted file will be displayed. Should the file not be readable by our import code (eg. not a map), no preview will be displayed.

The larger, more detailed map control that we use to draw the main gameboard is faster for general redrawing and making small changes to the map like who owns a country, but it incurs a significant time penalty when first starting up. This one-time cost is not an issue with the simpler gameboard now used for small previews; hopefully, this will not only allow us to have previews of maps while opening them, but also also result in quicker responses from the dialogues used to start a new game.