Rough Sea Games

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: 31% [?]

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% [?]

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% [?]

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% [?]