Rough Sea Games

Singletons the curse and blessing of many coding projects. Among other pitfalls, you’ll basically introduce a global variable in your system, making UnitTests much harder.

Why Singletons?

Despite the possible problems they can present, they are just so darn handy sometimes. If there is some part of your code that needs to be accessed from almost anywhere in the system (like the sound system, or a global error text console and such) there is hardly a better way to achieve that.

Alternatives?
A global messages system to communicate between objects can achieve the same effect. We used to make heavy use of such a system system. However, according to our experience, maintaining that system is fairly time consuming for it gets more and more complicated over time. Besides, if a messaging system allows queing, you’ll never really now where and why a message was sent because you loose the stacktrace. So, right know we are reducing the work-load done by the message system, handing it over to direct singletons access. By this, we increased debugability and clearity of data transfer. Besides, using singleton access is much faster than routing it through our messaging system.

How to Do It?
The web already offers a bunch of solutions (1). Most of them boil down to implement the singleton code over and over again in each singleton. We didn’t like that and tried to come up with a better solution. When we define a singleton it looks like that:

/**
* Accesing this class somewhere in the code looks like this:
* cSomeController.GetInstance().DoSomething();
*/

public class cSomeController extends cSingleton
{
    public static function GetInstance():cSomeController
    {
        return cSingleton.GetInstance(cSomeController);
    }

    public function DoSomething()
    {
        trace("Yes, I can.")
    }
}

That is much simpler than copying&pasting the complete singleton code over and over. The corresponsing cSingleton-class looks like that:

package rsengine.patterns
{
    import flash.utils.Dictionary;

    /**
    * Singleton base class
    */

    public class cSingleton
    {
        private static var m_instances:Dictionary = new Dictionary();
        private static var m_unlockConstructor:Boolean = false;            

        public function cSingleton()
        {
          if (m_unlockConstructor == false)

          throw Error("You cannot create an instance of a singleton."
          + "Use GetInstance instead!");
        }

    /**
    * Returns an instance of the specified class
    * @param _class class
    * @return instance of specified class
    */

    public static function GetInstance(_class:Class) : *
    {
      if (m_instances[_class] == null)
      {
        m_unlockConstructor = true;
        m_instances[_class] = new _class();
        m_unlockConstructor = false;
      }
      return m_instances[_class] ;
    }
  }
}

Our singleton implementation significantly reduced the amount of code you have to copy&paste compared to the other singleton implementations out there on the net. We do know that our implementation of GetInstance() is a little slower (because of the Dictionary look up). Since you shouldn’t have too many calls to the GetInstance method this is probably nothing to worry about too much. Nevertheless, you could cache the result of GetInstance() if you do need to access the singleton more than once (e.g. in a loop).

Have fun and happy coding
Manuel

AS3: Singletons, ActionScript 3 Singleton Redux, google

Popularity: 17% [?]

Something I really missed in Actionscript 3 were enums. If you need ascending unique numeric ids ( e.g. for naming array indexes ), enums are your friend.

For our current project we programmed a messaging system. The system uses unique numeric ids for message types and message channels. The list of messages and channels grew over time and right now each list contains more than a hundred entries. In the beginning we did the numbering ourselves like that:

    public static const MSG_OPEN_WINDOW:int = 0;
    public static const MSG_CLOSE_WINDOW:int = 1;
    public static const MSG_REGISTER_TIMER:int = 2;
    // .. and so on

For code beauty we were always trying to group related message ids, which often meant to re-index dozens of entries if we inserted an id somewhere in between. This was a pain!

The net already has assembled quiet some wisdom about “fake enums ins as3″¹, which do fit different needs (like some have type safety) but unfortunately not ours. Most of them are String based, which is what we did not want. So after putting in some thought we came up with a solution that worked for us. Now we can define our enums like this:

    public static const MSG_OPEN_WINDOW:int = cEnum.Enum(0);
    public static const MSG_CLOSE_WINDOW:int = cEnum.inc;
    public static const MSG_REGISTER_TIMER:int = cEnum.inc;
    // .. and so on

Now, by using static methods and a static counter we can create an arbitrary amount of coherent numeric values, which comes in very handy from time to time! Re-indexing is in the past now!

We want to share our little enum class with the web, so here it comes:

public class cEnum
{
	private static var m_currentIncrement:int = 0;

	/**
	 * Adds an enum value to the collection
	 */

	public static function Enum(_v:int) : int
	{
		m_currentIncrement = _v;
		return m_currentIncrement;
	}

	/**
	 * returns the next increment
	 */

	public static function get inc():int
	{
		return ++m_currentIncrement;
	}
}

Bottom line, if you need a neat way to maintain a list of static coherent numeric entries while type safety is not a big issue … this is an fairly easy way to do it. May this help you out there as much as it helped us.

Have fun and happy coding
Manuel

¹ Further readings on AS3 enums can be found here: e.g. http://www.herrodius.com/blog/87,
http://scottbilas.com/blog/faking-enums-in-as3/
or http://blog.petermolgaard.com/2008/11/02/actionscript-3-enums/

Popularity: 29% [?]

Designing an appealing and huge game world from scratch will take even really fast designers a looooong time: valuable time that can be spent in better ways. This is where generated content comes in handy. With the push of a button a designer can create a whole world (oceans, land, forests, deserts, mountains, cities, … ) in an instant. So this is what we decided to do for our game … and here is how we got to the finish line:

On the bumpy road to an actual working map generator we decided to split all map generation tasks into small modules: heightmap generator, water generator, forest generator, desert generator, and so on. In the map-generator GUI the designer can put these modules into a task list and define the order in which they are executed. Each module also has parameters that affect the characteristics of the generated map. Even though it is supposed to be a random map generator it is especially important to have deterministic behavior. Consequently, each module that actually generates content has at least a “seed” parameter for the random number generator. With the same seed the generator will create the same results every time. Changing the seeds will create a different map.

In the little animation above you can see the output of some of the modules.

Heightmap Generator
At first we create a heightmap. We use Perlin noise since it is built into the AS3 BitmapData class and it is amazingly fast. In the beginning we experimented with our own implementation of the diamond-square algorithm, but it was way too slow.

Water Fill
In the next step we apply water to the world. We simply declare everything below a certain height level as being under water.

Mountains
By looking for local peaks we detect mountains and flag the areas accordingly.

Humidity Map
By defining a water contingent that grows over water and decreases over land we can flag dry and wet zones on the continents. To make things easier we define our whole world as a west-wind zone. The centers of most bigger continents will be dry (yellow), coast regions will be mostly humid (green) and continental areas lying east of a big stretch of water will be very humid (dark green).

Climate Zones
Next we define climate zones in the world: tropical areas, temperate zones and polar regions. With this information we can easily place polar caps in the world.

Forest Generator
Using the information from the climate zones and the humidity map makes it possible to place different types of forests into the world. Jungle (purple) will be found in the hot and wet regions around the equator, while coniferous forests will be found close to the polar caps.

Desert Generator
The desert generator also uses the information from the humidity map to detect dry regions and place desert areas into them.

Well, now you had a look at some of the modules in our map generator. They are not only capable of creating earth-like maps (like the small sample map above) but also completely different maps by changing the parameters: a lake landscape, a waste land, a desert or whatever our games may need. With this we are able to quickly create new game content of any size for the players to explore.

Cheers,
Manuel

Popularity: 100% [?]

To compare the performance of different approaches for handling large data I wrote a small test suite.

This application contains one test class (cDataHandlingTest) that writes to and reads from an abstract data class (iData). Each data class offers an unified interface but is implemented in different ways. The test class repeats each test several times, records initialization times and accessing times and then calculates the average for each data class. If you want to have a closer look on the code, you can download the FlashDevelop-project here. You can check out the test application at the end of the post.

Three-Dimensional Array (cDataArray3D)

This data class uses a three-dimensional array to store the data. Initialization takes a very long time because you need to cycle through several nested loops allocating the data. Access times are ok.

Linear Array (cDataArray1D)

Here I used a linear array for the data. Initialization for a linear area is lightning fast. The draw-back is the access, though. Calculating the offset of the data in the array is pretty complex:

var index:int = (((_y * m_width ) + _x) * m_entries) + _entryType;


This makes working with a linear array really slow if you cannot predict in what order you will access the data. If you will usually access the data in the exact order it is stored in the array, you would actually be really fast. Unfortunately, this is usually not the case. The linear array is about 10 times slower than the three-dimensional one on random access.

ByteArray Int-Based Access (cDataArrayByte)

In this example I used a ByteArray. The position is calculated in the exact same way as in the linear array example. Data is extracted by using a readInt() command on the stream, data is written by using the writeInt() command. I expected this approach to be really slow. Well it isn’t! On my computer it already outperforms the three-dimensional array in all areas. (It might not on others, though).

ByteArray Byte-Based Access (cDataArrayByteOpt)

If you only need values between 0 and 255 you can use the array operator [ ] of the ByteArray class. This is the fastest way to access the data. Initialization times are really good and access is on my computer about 25% faster than the three-dimensional array.

Test Application

This is the test. Click into the window to start. Be careful, it needs a lot of resources. If you have significantly less then 2GHz per core or only one core I recommend not to try it because it will lock up your computer for too long to be convenient.

Popularity: 7% [?]

In game development, state machines are the most common way to structure the behavior of code.  Wikipedia defines a state machine as :

A state machine is a model of behavior composed of a finite number of states, transitions between those states, and actions.

Probably every game programmer has worked with or even created a state machine that turned into debugging mayhem. The road there is short and simple: Game programmers usually do not bother with planning a state machine carefully before starting to code. They usually just create an object, add the obviously needed states and add more states and functionality as needed over time. After a while, the code is full of “set state” calls mingling the states and creating a most complex structure, whose behaviour becomes almost impossible to predict.

We believe in the DRY principle propagated in the book “The Pragmatic Programmer” by Andrew Hunt and David Thomas. DRY is short for “Don’t Repeat Yourself”.  It simply means that duplication of information should be avoided. Creating a state-machine diagram and an implementation is an duplication of information already.

How can the DRY principle be applied to state machines?

Our answer is: Include the state-machine diagram in the code! Using such an in-code diagram makes it really easy to understand how an object works and how states are connected. This transparency is gained by triggering the state changes through observing changes in the internal data rather than using external stimuli. To make this possible we completely eliminated the use of the “set state” method (except for setting the initial state of an object).

Let’s get practical: We declare our state-machines in the constructor of our objects. First, we define all the needed states. States consist of a state method (reference to a member function) and a state id (constant integer value). Each state can have an arbitrary number of transitions. Each transition contains a reference to a transition-trigger method and a target-state id.  (A transition trigger returns true if a state-change condition is fulfilled, false if not.)

 1 // set up state- machine diagram
 2 m_sm = new cStatemachine(NUMBER_OF_STATES);
 3
 4 m_sm.AddState(ST_ANCHORING, StateAnchoring);
 5 m_sm.AddTransition(ST_ANCHORING, IsAnchorUp, ST_FLOATING);
 6
 7 m_sm.AddState(ST_FLOATING, StateFloating);
 8 m_sm.AddTransition(ST_FLOATING, IsSailOut, ST_SAILING);
 9 m_sm.AddTransition(ST_FLOATING, IsAnchorDown, ST_ANCHORING);
10
11 m_sm.AddState(ST_SAILING, StateSailing);
12 m_sm.AddTransition(ST_FLOATING, IsSailIn, ST_FLOATING);
13
14 // set initial state
15 m_statemachine.SetState(STATE_ANCHORING);

Let’s have a closer look at the example (Look here for a more extensive version): There you see the state machine of the object “Boat”. It starts in the state “STATE_ANCHORING” (line 15). As soon as the method “IsAnchorUp()” returns true, the corresponding transition kicks in and it changes the state to “STATE_FLOATING” (line 5). If the sailors should decide to lower the anchor again, the second transition of the floating state will cause the boat to return into “STATE_ANCHORING” (line 9) again. You are now surely able to easily understand what the other states do and how they interact.

Besides all the good things this approach brings into your project, it also has its downside: It is simply a bit of more work. The programmer has to think about the design of the state machine constantly while programming. It only works if you design your states well. In addition, a little bit more code is needed to implement a particular functionality, too.

Still, the benefits you can gain from this methodology are well worth it. This especially applies to a distributed multi-programmer environment like ours where you need to understand other people’s code fast.
Happy coding!

Popularity: 7% [?]

Hello, welcome back and a happy new year to all readers from me as well!

Today, we are going to shed some light on our unit-testing process. It is one of our vital safety parts to ensure that our development process is still on track and that we are not breaking anything.

Before we started the project, I did some research on unit testing with AS3 on the web. I stumbled upon AsUnit at http://www.asunit.org by Luke Bayes and Ali Mills. I integrated their framework into our newly set-up project and we were able to start coding right away. Just now I realized that the  tutorial to set up AsUnit with FlashDevelop disappeared from the web. So, I decided to quickly assemble a new tutorial. You can find it at my web page http://www.ruelke.net.

When we started using it in real-life, we discovered a few minor issues. Consequently, I added and changed a couple of things over time, which transformed AsUnit into our very own version.

1. Process: Run tests first: if one fails do not start project code
2. Extension: Our Asserts can be checked
3. Extension: Controlling the debug output

Ok, let’s explore these things a little further:

1. Run Tests First: If One Fails Do Not Start Project Code

Out of the box, AsUnit just doesn’t do anything after it has finished the tests. We all are regular game programmers that have used C++ before. So our unit-testing experience revolves around UnitTest++. I tried to get AsUnit to behave as similarly as possible. Accordingly, AsUnit needs to do the following:
- Start and Run the tests
- Check the result
- Continue with the game code if everything was correct

To do this, I extended the TestRunner-constructor with another parameter: a function pointer (callback). The callback is called within the TestRunner’s testCompleteHandler-function if the unit tests passed successfully. Then the callback takes care of continuing with the game — starting the game loop, loading assets and so on.

2. Our Asserts Can Be Checked

It is important to integrate our assert-handling into the testing process. You may remember my posts about assert-handling a while back (http://blog.rough-sea.com/category/methodology/). It is possible to use our debug class’ HasAsserts()-method, which returns true if an assertion failed, to check if an assertion actually fails as expected in a test case. The AsUnit framework has a class called Assert, which contains all checking methods used in the tests. By using what’s already there (like the assertTrue method), I could realize the check for assertions in a very simple way :

/**
 * Asserts assertions.
 * Usage: assertError(m_object.ErroneousMethod())
 * If assertion does not fail an AssertionFailedError is thrown
 * with the given message.
 */
static public function assertError(...args:Array):void
{
    assertTrue("Assertion failed to fail!", Debug.HasAsserts());
    // clear the asserts so there is
    // no interference with other tests
    Debug.ClearAsserts();
}

3. Controlling The Debug Output

A lot of our classes, especially the state machines, contain automated debug output. When running our tests, this debug output is overwhelming … and useless as well. All of the console output goes through our Debug class. So I added a flag that is able to disable the sending of messages to the console. This flag is activated right before the tests and deactivated right after. The spam was history.

Alrighty, these are the three most important changes I did to the AsUnit framework to make it suit our needs. Well, you have reached the end of my little trilogy. Don’t worry, I still have stuff to talk about.
So see you next time and happy coding!

Popularity: 13% [?]

Hello, again! We’re back with another episode of “Asserting the Basics”. Last time we talked about our assertive philosophy on error handling. Today, we go into the dirty little details: the coding of asserts.

Asserts are not something that Actionscript3 offers naturally. Consequently, I added an Assert-method to our Debug class (remember from my first post?). Its job is (of course) to check whether a Boolean expression is true, and, if not, to eventually communicate this fact. Rather than showing all failed asserts directly, our method only stores them. I want to have control over when the asserts are shown, since there are times when you actually want asserts to fail: for instance when you want to try out your error handling in Unit Tests. Thus, there is another method to take care of displaying them, which can be called at an appropriate time. So our assert framework looks like this:

private static var m_asserts:Array;
/**
 * Asserts that a condition is met
 * @param    _statement condition to check
 * @param    _msg Message to describe the assert
 * @return true if the assert failed
 */
public static function Assert(_statement:Boolean, _msg:String):Boolean
{
    if (_statement != true)
    {
        var msg:String = "****************************\n "
            + "ASSERT FAILED!!\n "+_msg+"\n"+GetStackTrace()+"\n"
            + "****************************\n ";
        // record assert
        if (m_asserts == null)
            m_asserts = new Array();
        m_asserts.push(msg);
        Debug.Out(msg);
        return true;
    }
    return false;
}
public static function ShowAsserts(_stage:Stage) : void
{
    if (m_asserts == null)
        return;
    var assertBox:TextField = new TextField();
    assertBox.autoSize = TextFieldAutoSize.LEFT;
    assertBox.width = _stage.stageWidth;
    assertBox.textColor = 0xFF0000;
    assertBox.backgroundColor = 0x000000;
    assertBox.background = true;
    assertBox.wordWrap = true;
    assertBox.text = "";
    for (var i:int = 0; i < m_asserts.length; i++) {
        var assertString:String = m_asserts[i];
        assertBox.appendText(assertString + "\n");
    }
    _stage.addChild(assertBox);
}

You may have noticed that our assert method has a Boolean return value, returning true if the assert fails. This way we can use the method to exit early from a function that would crash otherwise. Since we cannot simply take the asserts back out, we might as well use them in a bigger context.

In our code the use of these asserts look like this:

public function Load(_path:String) : void {
    if (Debug.Assert(m_fileName != null, "Filename is null!!"))
        return;
    if (Debug.Assert(m_fileName.length != 0, "Filename is empty!!"))
        return;
    // yada yada … more code
}

To give our asserts even more value, I did some research on how to get stack traces. I found out that if you throw an error and catch it in a debug player, you can retrieve a stack trace from the error object, as seen here:

/**
 * Returns the stack trace (filtered)
 * @return stack trace
 */
public static function GetStackTrace() : String {
    if (Capabilities.isDebugger == true) {
        try { throw new Error(); }
        catch (e:Error) { return FilterStackTrace(e.getStackTrace()); }
        return "";
    }
    else
        return "Stack trace not available in non-debugger version.";
}

Unfortunately, the stack trace you get this way is really extensive and hard to read. Every line in the trace contains the complete path to the corresponding file on the local machine. So, I added a filtering function to remove the unnecessary path info. This method turns e.g. this:

tests::TestDynamicTextManager.TestTextEdit()Trace:
AssertionFailedError
	at tests::TestDynamicTextManager/TestTextEdit()
	[D:\projects\programming\bgame\svn\FlashComponents
	\client\src\tests\TestDynamicTextManager.as:15]

into this:

tests::TestDynamicTextManager.TestTextEdit()Trace:
AssertionFailedError
	at tests::TestDynamicTextManager/TestTextEdit() [line:15]

Here is the filter function:

public static function FilterStackTrace(stack:String):String {
    var lines:Array = stack.split("\n");
    // remove the path
    // it's too long and we can get the info from the method trace
    var regEx:RegExp = /\w:[\\\/]([\w-]+[\\\/])*\w+.as/ig;
    var newStack:String = new String("\n");
    for (var i:int = 0; i < lines.length; i++) {
        var line:String = lines[i];
        line = line.replace(regEx, "");
        line = line.replace("[:", " [line:");
        newStack = newStack + line + "\n";
    }
    return newStack;
}

Alrighty, now you’re set to do your own asserts. Next time, I’ll talk about unit testing and Actionscript3.
So, see you in a bit for a new episode of “Asserting the Basics”.

Happy coding, Manuel

Popularity: 12% [?]

Welcome back! Today, let’s talk about the probably most sensitive part of programming: error handling. This is a really big topic, so I made two articles out of it. This time I am going to tell you about our philosophy on that. Next time, I’ll show you how we turned our vision into reality.

Back to business: A project without proper error handling is doomed to fail after it has passed a certain level of complexity. Actionscript3 offers exceptions as a standard answer on the topic of how to deal with errors. Exceptions are for exceptional problems, but not for your little everyday error check. So, for us at Rough Sea Games exceptions are simply not enough. We like to be able to do what “The Pragmatic Programmer” [1] calls “assertive programming.” We add a lot of checks to our code to make sure we are still safe. If something goes haywire, our asserts make sure we crash early. That really helps to find the bug(ger) quickly. In addition, we like to ensure that “contracts” between methods are kept. That means, for instance, that if a method requires one of the parameters passed to it not to be null, we want to assert this to make sure it won’t happen. And if it does, we want an immediate feedback and not a some ambiguous crash further down the road.

Despite being a great help for the programmer, assertions can be a problem when it comes to performance.

Performance Issues

I did some performance tests while ago: I took out the assert method just leaving an empty stub. Oddly, this did not have a significant impact on the performance. So, the method itself is not very greedy. That’s good, but still, when I took out a couple of asserts the performance went up. How can that be? I found out that calling the method was the problem. Our assert method takes a string as one of its parameters. In some places we employed some heavy string operations to include values in that message.

When you do something like that inside an important loop you may be surprised about the great loss of performance. By refactoring some of those critical asserts, I could speed things up quite a bit without having to take the asserts out. So, if you are careful, asserts do not have to be a performance killer.

Better Production Code

Of course, taking the asserts out will produce slightly faster code, but since there is no simple way to actually take them out in a reversible manner (like using a preprocessor), we may as well leave them in for good. Some people may perceive them as a debug-only facility, but having them in production code might not be such a bad idea. We want to debug and improve our product constantly after release. A consumer that is able to tell us which assert exactly failed, helps us to find bugs a lot easier.

Well, I could go on about assertions forever … but time is scarce, so I’ll close for now. Next time, we’ll get our hands dirty and dive into our assertion code.

So, stay tuned and happy coding, Manuel

[1] The Pragmatic Programmer; Andrew Hunt, David Thomas, Addison-Wesley
ISBN 02161622X (http://www.pragmaticprogrammer.com)

Popularity: 11% [?]

Although it’s not the hardest language to learn, Actionscript3 does provide a couple of traps that may lead an inexperienced Padawan astray. In a series of blog entries I would like to describe my own first steps on these new grounds, hoping that I can provide some aid for other programmers who also want to join the scripted side of the action.

Usually, the first thing I do in a new language is to ensure to have at least the following things at hand:

• a possibility to print out text
• an assert mechanism
• and unit tests

These ingredients provide at least a minimum of safety while progressing through the uncharted territories of a new language and this is what I want to talk about. Let’s start on the first topic:

The beauty of text output

My very first project as a professional programmer was a racing game in C++ for Symbian OS 6 (an operating system on Nokia cellphones). Back then, the Symbian SDK consisted pretty much only of compilers and packagers, … and one funny little emulator. This bad boy did not have a text console to print to, and, even worse, there was no support for a real-time debugger. I pretty much felt like being blindfolded. It was then, when I realized how important a simple text console can be! Traumatized by this experience, I started our game engine by writing a Debug class with its first method being an output function for text messages.

Some may say: “Heck, why didn’t he just use trace() everywhere”. This has several reasons: For one, trace() simply does not work with non-debug Flash players and secondly I wanted to have one interface for all the debug messages. This way, implementing the possibility to switch off printing of messages is a piece of cake, and later adding a logger for all messages would be just the piece of cake next to the one I have just mentioned.

Now, this is what our very first method(s) looks like:

    private static var m_sendDebugInfo:Boolean = true;

    public static function EnableDebugInfo(_debugInfo: Boolean) : void
    {
        m_sendDebugInfo = _debugInfo;
    }

    /**
     * Sends a message to the console of flash develop
     * @param    _msg message to send
     */
    public static function Out(_msg:String): void
    {
        if (m_sendDebugInfo == true)
        {
            fscommand("trace", _msg); // for normal player
            trace(_msg); // for debug player
        }
    }

Alright, this is pretty basic stuff, I know. Anyway, I did have to fiddle around with the text console to get it working in all players, especially with the non-debug player. So I thought, why not starting simple? I can always get more complicated later … and maybe this info can save some of somebody else’s time.

So, we just reached the end of the first entry of my series. Next time, I’m going to discuss the topic of assertions. So stay tuned for another episode of “Asserting the Basics”.

Happy coding,  Manuel

Popularity: 4% [?]

There shall be Flash coders!

Hello there, my name is Manuel Ruelke. I’m responsible for large parts of the Flash coding (done in ActionScript 3) for our game.

Games have been a great passion of mine since early childhood. My parents bought an Amiga 500 for me when I was 11 and since then I’m hooked. I started developing my own games during my time at university. Together with a good friend of mine, I founded the hobby developer group “dalama” (www.dalama.de). In about four years we produced about a dozen freeware games. In 2005 we received the “German Developer Award” as “Best Newcomer”, which I always kinda like to brag about. *hehe*

After finishing university, I became a professional game programmer. Until today, I have been involved in a couple of j2me games, as well as console productions for NDS, PSP and Wii.

Besides programming, I enjoy composing music once in while. You can check out some of my music on my webpage at www.ruelke.net or on www.zak2.org (I am that Heimdall-guy).

Cheers, mates!

Manuel

Popularity: 4% [?]