OpenFracas 0.6 Released

OpenFracas 0.6 "Cedric" has been released. This release marks the 1 year anniversary of OpenFracas. The most notable change in 0.6 is the new map file-format. Much of the work this release has been behind-the-scenes, making the game work with the new format.

While it may seem a trivial addition, it means that it is now possible to save and restore games in progress, as well as the maps upon which they were played. We originally inherited the map file format from Fracas 2.0, and had extended it well past what it was intended to handle in order to get it to keep up with the progress of OpenFracas. Nevertheless, it was far from an ideal solution. We didn't have support for reading and writing Fracas games-in-progress, and the file format in general wasn't suited to our goals for OpenFracas.

Additionally, a new Maps section has been added to our website at http://www.openfracas.org/maps.php where users can download maps and saved games, and can also upload their own creations to share with others.

The file format used now, .ofmap and .ofgame are based on the YAML data serialization library/format and are a much more robust file format, while still maintaining human readability.

The Map Editor has received updated code to allow it to use the new file formats, as well. The features of the Map Editor will grow in time as it matures, and the last of the code-base is brought around to using the new formats.

OpenFracas 0.6 is available on the downloads page; please feel free to contact us with any questions, concerns, or bugs on our forums.

Ubuntu users who have added our repository to their package manager will find the new version automatically available as an update.

We are proud to announce the release of OpenFracas 0.5. The most notable changes in the 0.5 release are:

• Sounds and Music
• OpenFracas now supports up to 8 players
• New troop count drawing algorithm
  • Better placement of troop counts
  • Scales troop counts to fit within smaller country
• Options to restart a game or reuse the current map
• Streamlined User Interface
• Map Editor improvements
• More player colours to choose from
  
• Help documentation, revised from Fracas help, now available
  

Perhaps most significantly of all: Since the last release, OpenFracas has undergone major changes in its internal organization and structure. This means that OpenFracas is in a better position to begin adding more advanced and complex features in future releases.

A new developer, Eric, has joined the OpenFracas team since the last release, and has produced the new troop count drawing algorithm.

OpenFracas 0.5 is available on the downloads page; please feel free to contact us with any questions, concerns, or bugs on our forums.

Ubuntu users who have added our repository to their package manager will find the new version automatically available as an update.

MapEdit picking up some much needed features.

So now the map editor has progressed to the point where I am no longer embarrassed to call it my own. Chiefly, the map editor can now open files as well as save them - so that's a big one. The ability to name the countries has long been missing from the programme, as has support for a new feature that should be included in OpenFracas 0.5, that of unplayable land. Unplayable land, with proper support from the map editor, allows for the creation of maps like this work in progress of mine

The Provinces of the Roman Empire.

The darker grey areas represent regions which cannot be conquered, and (unlike water) cannot be traversed.

Integration with the Nautilus File Browser

If .map files (the files used to store map data in the original Fracas) are associated with OpenFracas in the file manager, double-clicking a map file should open OpenFracas with that map file loaded. This has not been the case so far, and was not in our last release, but our next release (whenever that may be) should remedy this via the installation package. (at least on Linux - we're still looking into integration with Windows).

Additionally, another nice touch that we've been working on is thumbnail integration wtih nautilus. Now, when opening a nautilus file browser windows to view Fracas .map files, you will be able to see thumbnail previews of the maps. Here you can see a nautilus file browser showing thumbnails for a collection of maps from OpenFracas, and from the Homebrew Maps page taken off of the original Fracas's site.

OpenFracas 0.4 Released

We are proud to announce the next version of OpenFracas, v0.4, has been released. This release is our best yet, with exciting new features and a focus on quality.

Specifically, this new version brings the following improvements

• New drawing code, making the game board
  
• Customizable. Change text sizes, and line styles
• Faster. Game feels more responsive. Redrawing rates are improved
• Resizable. Resizing the board is now possible
• Animated. The drawing is now fast enough to have simple animations
• Teams can be created when starting a new game, allowing for more challenging and exciting gameplay
• End-of-game dialogue displays statistics and a timeline, showing the game's course
  
• Map previews are faster when creating a new map
• Map previews have been added when opening an existing map
• Basic map creator. Create maps, and export them to OpenFracas
• Default maps are included
• Eurpoe
• Risk
  
• Complete use of Tango theme on Windows to improve interface aesthetic
  
• User interface refinements and improvements
  

The new version is available on the downloads page; please feel free to contact us with any questions, concerns, or bugs on our forums.

Ubuntu users who have added our repository to their package manager will find the new version automatically available as an update.

Planning things out in advance.

We've been working on OpenFracas for about half a year now, with various degrees of activity dictated by the other parts of our lives, and now we've got the game into a playable state. A lot of the work we've been doing for the past while now (post 0.3 release) has been to experiment with new features and things that would improve the existing experience, rather than to add huge new aspects of play to the game. The option for capitals, for example, which made its way into the game with the 0.3 release, was something quite drastic. The work being done now is more ... subtle, if you will. This means that we've been working more with the existing code base than we have with new code that we're still in the process of creating.

This has already prompted one big code cleanup at the core of the game, and we're currently experimenting with overhauling the drawing code to try and speed up map rendering a little bit. The code in some sections has been growing slowly for so long, that it has become rather untidy. By untidy, I mean that when additional features were tacked on, they were not done so with any overarching pattern or approach in mind. As an example, a lot of the code designed to figure out which countries neighboured others (the part that has been rewritten already) wasn't designed to take things like harbours into consideration - they didn't exist when the code was written. We wanted to have it working asap so we could go ahead and get other important parts written as well. Recent work on adding new features prompted us to revisit this code and replace it with something cleaner and more flexible. The result is code that is more more readable, and much faster to create.

Now that the game is (for the most part) working, we need to do more of this kind of rewrite. Before we move on and add things like sound, networking, game saving, etc, we need to stop and clean up the code we have already.

Our plan, as it stands now, is to focus primarily on usability and polishing the user-related aspects of the game for our version 0.4 release. We want to have the game working very well for the 0.4 release, because we're not entirely sure how long it will be until we make another release after that. After 0.4, we're going to be doing a lot of clean-up on the our code-base. This is not the kind of work that will necessarily add new features, but is that necessary kind of work that will allow us to add new, more complex features faster in the future.

Mucking about with a map editor

It's something that OpenFracas has been missing. The ability to create custom maps is something that we'd love to give users, and eventually we will. We have no official plans for it yet, but once we have a map editor that is capable of creating these maps, we want to have a custom maps section on our web site.

All of this is jumping the gun a little bit, since the Map Editor is very new, and very lacking in features. For now, at least. The code for drawing maps in the map editor is actually where the code for the new faster map previews (mentioned earlier) comes from. This has been sitting around for a while, now, growing ever so slowly. It might not make it into the 0.4 release, as there are a number of other things that we want to get done, or need to polish, but eventually we'd really like to make map customization available.

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.