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.

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.

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.