Rough Sea Games » Methodology

Some facts about Usability – and why you should care about it

Kathrin — Tue, 24 Aug 2010 11:22:28 +0000

The research field of human-computer interaction, which also includes explorations of the interaction with digital games, has put forth two main concepts which contribute to a user-centered design: Usability and User Experience. First of all, I would like to introduce you to the essential ideas that are concealed behind the term “Usability”:

Usability deals with the question whether a software can be intuitively and effectively used to accomplish the tasks it is designed for.

Usability is mainly a psychological issue. When evaluating the ease of use of an application this automatically means taking into account the user’s cognitive requirements, too: limits in human memory, perception and attention, the user’s expectation and his abilities all contribute to the way he interacts with the software. Too many information on a screen, for example, might overwhelm the user’s brain abilities as he is only capable of comprehending 7 +/- 2 pieces of information simultaneously. Of course, this does not mean we can conclude that we can realize an optimum in accessibility for the user by simply always implying round about 7 items on each page. Human psychology is much more complex and so is the subject of Usability, thus it won’t really fit into this tiny blog post.

Still, you don’t have to be a psychologist to be able to explore the usability of your application. Fortunately, there are alreasy someone guidelines developed by experts that can support you. We can get started on this taking a look at the Usabilty principles defined by ISO 9241-10. They are less abstract than psychological constructs and therefore quite easy to understand:

suitability for the task

(Can the application be used to carry out the tasks efficiently? Are all required functions needed to carry out the task implemented?)

suitability for learning

(Does the application offer the user a step by step acquisition of these functions? Can the user deal with the complexity of the application?

suitability for individualization

(Can the application be adjusted to different user needs?)

conformity with user expectations

(Is the usage of the application comparable to similar applications?)

self descriptiveness

(Can the user comprehend the application intuitively? Are there help functions implemented?)

controllability

(Can the application be adjusted to the work flow, different task assignments and time periods?)

error tolerance

(Does the application offer a smooth error-handling?)

So start your usability evaluation of your application with checking the points mentioned above and you will have quite a good basis for further investigations in this research field.

More secrets about Usability, User Experience and how to measure them concerning your game will be revealed in my next blog post!

Share/Bookmark

Our way of game testing

Team Felix/Markus — Mon, 05 Jul 2010 12:04:44 +0000

Hi guys,

today we want to introduce you to what it means to be a game-tester. Being a tester doesn’t mean playing games all the time, but rather exploring every possible constellation in which a bug could appear.

Maybe you have been asking yourself already: “How is it possible that some games are full of bugs?” We have the answer! Some testers just don’t apply the right methods for their bug tracking.

This is why we would like to introduce you our favorite ways of testing now.

The first way is the “Switch off your brain”-method.

You just follow the instructions of the test-cases and note your results. If the test-plan is well-organized, this is an effective, but less creative method. And as no test-plan can cover all bugs, you need an additional, less structured method of tracking bugs!

Therefore, here comes our second option, which is: “Simply playing the game.”

You play the game without any evil bug tracking intentions – as if you bought it for your personal pleasure. The benefit of this way of testing is, that you have more freedom while playing the game. On the other hand, bug tracking is quite random in this case, which is a disadvantage and makes a further option necessary.

So, in total, our advice is our third approach to bug tracking. It’s the combination of testing method number one and two and corresponds to the following rule: “As structured as necessary, but at the same time as creative as possible”.

You have to test every state in every possible order. For example: The test-plan requests you to change the display resolution. In practice, there are two ways of doing so: You can either change the display resolution by using the main menu; but it is also possible in the course of the game. This means you have to think yourself. We have to admit, this example is not the best one, but the more complex a game is, more states in which bugs can occur will be given.

Next time we will reveal our secrets of how to raise the effectivity of your testing skills.

Thx 4 reading our first blog entry.

To be continued…

Share/Bookmark

Numeric Enumerations (Enums) for AS3

Manuel — Wed, 14 Apr 2010 09:11:51 +0000

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/

Share/Bookmark

Effortless Text Localization

Thomas — Tue, 29 Sep 2009 14:32:24 +0000

Automatization of repeated work is one of the keys to productive development. Another is abstraction of common problems to allow concentration on project specific work. Localization is one of the problems you have in nearly every project, especially in iPhone projects. The iPhone SDK brings interesting solutions that abstract many parts of the localization process.

The tool ibtool, for example, extracts strings from an interface automatically. The strings are placed in a .strings file, a textfile with key/value pairs. To localize an interface, you have to translate .strings and merge the strings back into the interface again. Because you have individual interfaces for every localization, it’s possible to adjust widgets individually for each one.

genstrings is another tool inside the iPhone SDK. It extracts textIDs from the source code and write them into a .strings file. You may ask how the tool knows which texts need localization and which do not. The solution is the macro NSLocalizedString, which will be replaced by a .strings file lookup method by the preprocessor, but also searched for by the genstrings tool to create the files.

Both tools help you to create a localized application without paying much attention to localization itself. But you cannot expect the localization department to search for .strings files inside your project and create localized versions of them. Of course this would be possible, but not very convenient, because you have to migrate the translated texts back into the interfaces using ibtool. Another reason for us at Rough Sea is that we use a localization interface from our publisher. This interface is well known to the localization department and the content is placed in a centralized database on a server.

So we have the great tools from Apple that help us to separate texts from the project and we have the great tool from our publisher that handles the whole translation and reviewing process. Now we need something to tie those tools together, because we do not want to insert new texts from the .strings file into the publisher’s localization tool manually or vice versa. This glue tool has to execute the Apple tools, extract the texts from the .strings files and insert them into the publisher’s loca tool. On the other hand, it has to check for new localized texts from the publisher’s loca tool, build the required .strings files from the results and merge them back into the interfaces. Sounds quite easy, but of course there are some obstacles to get there. You have to handle other things, like the deletion of a text entry or changes to an already translated interface. So you have to know what has changed since the last update and stuff like that.

It turns out that you only have to integrate this glue tool into the build process of your build server. The tool will update the localization database whenever the code or the interface changes and it will update the localized versions when the database changes. As a coder you only need to remember to use the text macro around your text id. You don’t have to add this text id in a file or anything else. As you commit your changes, the build server will do this for you. As an interface designer it’s the same: just create your interfaces in the primary language and commit it. After the localization department finishes localizing those texts, they will be inserted into the localized versions automatically. Of course you have to make adjustments to the interface if there are loca bugs like labels that are to small to hold the translated text.

As you can see those localization tools are a big black box for coders, interface designers and translators. The coders only have to write code, the interface designers design interfaces and the translators translate texts. At the end there will be a localized product.

Share/Bookmark

Common project management mistakes: Estimating tasks (part 2)

Joe Cool — Tue, 09 Jun 2009 14:19:46 +0000

Hi there,

we were quite busy over the last weeks, so updates of our blog are currently reduced. We are only going to post once a week in the upcoming month, but this should improve the quality.

Today I will continue my project management series. In my first post I described the common mistakes which are often happening when estimating tasks:

- Mistake 1: Estimation is not done by the task owner
- Mistake 2: The task has no proper description
- Mistake 3: Estimation is done by averaging worst case with best case scenarios
- Mistake 4: The tasks are too big
- Mistake 5: The tasks have unclear dependencies
- Mistake 6: The owner puts some unknown buffer time into the estimation

Please check out the first part of this article to find viable solutions to those mistakes.

The mistakes I wrote about are not really specific to a single department; most of them are quite common problems. Unfortunately, there is one department where task estimation can be very difficult. It’s obviously the programming department that I have in mind. Estimating tasks with programmers is quite an awkward business.

You need lots of knowledge and experience to get numbers that are even close to realistic. As a project manager you may wonder why this is so complicated and why programmers’ estimates are so often unreliable. There are several reasons:

Mistake 7:

Taking the estimates of a rookie programmer as the final estimate

Solution:
Programmer performance varies by a factor of 10, which means a very good programmer can solve a given problem ten times faster than a bad one/rookie. No problem, you think: just let the slowest programmer estimate the task. That will unfortunately not solve your problem.

Young programmers tend to overrate their skills and dramatically underestimate tasks. So let the lead programmers, who are able to rate programmer performance as well as task difficulty, review the rookie’s estimate. The more experienced programmers check the estimate, the better it gets.

Mistake 8:

The buffer time for the programming tasks is the same as for any other task in the project plan

Solution:
This is nothing new and a lot of people have written about this problem, but unfortunately it’s still not accepted as an unalterable fact. Maybe it’s because of the certainty that there is no simple formula to determine the right buffer time.

It really completely depends on your programming team. You might have a 100% or even 200% buffer time and it’s not enough. Track real life data and your estimates, compare them, learn from them . Every programmer has his own speed and estimation techniques. Find out which ones are reliable and which are not and adjust your buffers accordingly.

Mistake 9:

Assuming that a programmer programs 8 hours a day

Solution:
If a programmer tells you he needs one day for the task, does that mean one real life day? It depends, again, on the programmer, but you should not ask how many days; instead you should ask “how many hours do you need?”. This is very important because a rookie programmer might not have realized yet that his effective programming time is only 4 to 5 hours a day.

Mistake 10:

Changing numbers in the project plan in order to change reality

Solution:
Project managers very often reduce the (massive) programming buffer times after estimation is complete, because it tightens the project schedule and seems to save lots of money.

Well you know the answer already: this does NOT change reality and you will not save a single cent. Instead it will cost you a lot of money! Never reduce programming buffer times unless you are absolutely sure it can be done faster. To put programmers into a crunch because you reduced their necessary buffer times will damage your reputation, and the team will not trust you anymore and will sneak their own buffer times in their upcoming estimations.

Next time I will talk about crunch, a very common technique to waste money and lose good employees.

That’s it for today, thanks for your time .

Cheers,
Matthias

Share/Bookmark

ByteArray Beats Regular Array

Manuel — Tue, 21 Apr 2009 07:27:28 +0000

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.

Share/Bookmark

State Machine Best Practices

Manuel — Thu, 22 Jan 2009 14:56:30 +0000

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!

Share/Bookmark

Common project management mistakes: Estimating tasks (part1)

Matthias — Sun, 11 Jan 2009 22:53:59 +0000

Over the last several years I have managed and participated in different projects of different sizes. I made a lot of mistakes, some of them more than once. This time I want to talk about mistakes in estimating the time to complete tasks.

Estimating tasks is really tough work, and it’s done wrong most of the time. Estimations are never precise. I think that most project managers are aware of this problem, but may not know how to get better information out of their team.

Mistake 1:

The task is estimated by somebody who is not working on it — maybe by the lead, which is even worse.

Solution:
Tasks should be estimated by the owner of the task with the help of his colleagues or his lead. Programmers especially have different working speeds, which can be ranked from 1-10. This means a very good programmer can be 10 times faster than a very bad one.

Mistake 2:

The task has no proper description and/or is unclear to its owner.

Solution:
How do you know if the task has a proper description? Well, it’s a mixture of common sense and experience. If you, as a project manager, do not understand the task (e.g. it’s too technical), it might be already a very good hint. Tasks should be described non-technically, understandably and in only a few sentences. If you prefer working with user stories I would recommend to you this book from Mike Cohen.

Mistake 3:

The task is estimated with worst case and best case scenarios and the average is taken for the project plan.

Solution:
This doesn’t make sense because the owner has to make 2 estimations. In the worst case scenario there is probably a hidden buffer time, which is not obvious to the reader when checking the project plan. Ask only for one estimation from the owner or the team when estimating the tasks. It’s much clearer to them and they know you will add the buffer.

Mistake 4:

The task is too big and cannot properly estimated by its owner (tasks with 8- 16 hours are a maximum)

Solution:
As soon as a task is bigger than 2 days, it is time to break it down, because nobody can foresee the problems that are going to arise when approaching such a big issue. If you are not able to break down the task (e.g. because of a missing design), but you need the information desperately, you should estimate it and add at least a 100% buffer. Don’t forget to mark that task with “??”, to be sure to break it down later and re-estimate it.

Mistake 5:

The task has dependencies on other tasks that are not clear to its owner.

Solution:
This is not an easy problem. Try to make tasks as independent as possible when defining them. If you work with user stories, add the dependencies of the task to your war-room board and check if your priorities match the dependencies. It is really hard work for the designer and project manager to get this right. Communicate as much as possible with the team to avoid dependency hell early: it can vaporize your whole project plan if you do not care about it.

Mistake 6:

The owner puts some unknown buffer time into his estimation

Solution:
Again you need your soft skills and experience here to identify this problem. Some people just add buffer times to be sure they can handle the task. Be open with them, tell them that you will add enough buffer time, holiday and sickness absence. They will only tell you the right time if they trust you. Collect all the estimation data of each owner to get an idea of how well they estimate over the whole project.

I have some more mistakes on my list, but It is late already. So stay tuned for more in the upcoming days. Cheers for reading and I would love to hear your experiences…

Share/Bookmark

Asserting the Basics III – Unit Testing

Manuel — Thu, 08 Jan 2009 17:47:17 +0000

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.

Process: Run tests first: if one fails do not start project code
Extension: Our Asserts can be checked
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!

Share/Bookmark

Asserting the Basics – Part IIb

Manuel — Sun, 23 Nov 2008 18:07:36 +0000

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

Share/Bookmark

Asserting the Basics – Part IIa

Manuel — Wed, 19 Nov 2008 17:16:01 +0000

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)

Share/Bookmark

Asserting the Basics – Part I

Manuel — Mon, 03 Nov 2008 07:05:10 +0000

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

Share/Bookmark

Scrum and XP for distributed teams (part two)

Matthias — Mon, 20 Oct 2008 08:47:21 +0000

Please check my last blog entry for the background to this post.

This time I will focus a little bit more on the XP side and explain what exactly we practise here.

Step 5 – regular pair programming sessions

Unfortunately, we are not able to pair program very often. We currently try to meet up once a week and have a 3 – 4 hour pair programming session. At this session we go through as much code as possible and talk about the architecture and the current design flaws. We try to get hold of the worst things we did while coding on our own, and start refactoring on the spot to learn a little bit more of each other’s code.

Sometimes pair programming is not possible because people live too far away, so we are looking into remote pair programming. We have not established it yet, but have collected lots of information. Please checkout Doug Alcorn’s Blog or Andrzej Krzywda’s Blog for some field reports. We will probably try VNC combined with Skype, because Flash Develop (our current IDE) does not have any collaboration support yet.

Step 6 – collective code ownership is even more important

CCO means that everybody can make changes and fix bugs anywhere in the code. There is not a single line of code in the project that is under the control of only one person. A good description of code ownership can be found at Martin Fowler’s Blog. As mentioned, we know each other very well already. If this weren’t the case, CCO would be much more of a hassle. A lot of trust and a lot of communication is necessary and coding divas are not allowed. Fortunately there is no diva in our team yet.

CCO is key for the success of a distributed team, because it helps to spread the knowledge of the code, systems and architecture of the project among team members (as pair programming does). Programmers will perform much better when they know how to use a specific system and how to adapt it to their needs. Not everybody on the web thinks that CCO is a the best idea ever; please check Ralf Sudelbücher’s Blog for a different perspective.

Step 7 – consistent and very regular refactoring

This, you might think, is not something specific to distributed teams — but I’m here to tell you you’re wrong. Sitting at home on your own, without a team mate next to you who reminds you to fix that broken window now (kudos to the pragmatic programmers), makes refactoring much less likely. The code quality can decrease quite fast for a distributed team if the programmers do not really care about it. What to do?

It’s actually quite easy. At each pair programming session, we identify broken designs and foul code and write our own refactoring stories. We give those stories the highest priority in the backlog. It’s very important to keep these stories as small as possible, because refactoring can sometimes get out of hand and this should be avoided. We only put the most relevant refactoring tasks into stories, because otherwise the backlog gets too confusing.

Step 8 – keep up the motivation

This is by far the most relevant and hardest part for a team which does distributed work, especially when there is no investor yet. The 7 steps already described help a lot to keep up the motivation when done right, but that’s not everything which can be done.

Try to establish a culture of praise and respect in your team. As soon as people start blaming each other, motivation will ebb and the team will break apart. If possible, the whole team should meet on a regular basis, as this helps a lot to improve communication and trust.

It’s also very important to have progress in all areas, not only the development part. Somebody has to care about investor relations, marketing issues, team building, business development etc. The team needs to believe that the product will be a success and that it is worth selling to the customers.

That’s it for today. I hope I could shed some light on our Scrum and XP processes and if you have some improvements or suggestions for us, I would be very happy to hear them.

Share/Bookmark

Scrum and XP for distributed teams (part one)

Matthias — Tue, 30 Sep 2008 08:56:47 +0000

As promised, this blog will include some thoughts about development processes and their impact on teams and projects. Today I will write about scrum and extreme programming (XP) for distributed teams, because at the moment we are one of those teams.

Scrum is a well known and currently very popular agile project management process. XP is a technical process, for programmers, and is also an agile methodology. The basics of Scrum are summarized in this great video from Kent Schwaber. If you looking for a good overview on XP check the Codebetter.com blog. More info on Scrum and XP can be found at the Agile Alliance Website and Mike Cohen’s blog.
I know both processes quite well, read all the available books, and have had the great opportunity to build up a team using these agile approaches at full scale. The team included some offsite workers, but that wasn’t too hard to organize.

To implement Scrum and/or XP in a team which does not share an office sounds almost impossible. Everything in agile methodologies relies on communication and transparency. A distributed team talking over e-mail/ICQ/wiki normally has difficulty communicating, and most team members have almost no idea what their colleagues are currently working on.

I will tell you what our team has done to improve communication, and why it is currently working like a charm. I have to admit that all team members know each other and are quite experienced. All of them have used Scrum and XP methodologies before. So the techniques described might not work for new teams which have never worked in an Agile way.

Step 1 – a wiki substitutes for the daily Scrum

We established a wiki as our major communication platform. WOW! That’s magic, isn’t it?
Well, the magic is not in the wiki itself, it’s in the motivation of its participants. If the team doesn’t update the wiki several times a day, it becomes absolutely useless.

Every day, I post the latest technical and business news, and all team members, including me, write an update on their current tasks. We still write e-mails and chat over ICQ, but most important communication happens in the wiki. It contains our business plan, the product backlogs, the complete (and current!) game design, helpful FAQs, various artwork and brainstorming thoughts. We even track our work hours and expenses in the wiki. We are still trying to improve our communication processes, but for now it’s working out quite well.

Step 2 – removed sprints, and introduced stories as mini sprints

We are currently working part time on our project, because we are still looking for an investor. People work in their free time on weekends, vacation days and so on. At first we tried to fix sprint timelines to certain dates, but that didn’t work at all. Working in your free time with (arbitrary) deadline pressure is horrific and far too much stress for everybody, so we skipped it.

Instead, Rafael put together a backlog in which the core game mechanics are written down as stories with acceptance tests. Stories get estimated by the programmers — not in a planning game, unfortunately, but the estimations do work out, because the team is quite experienced. It is very important that the stories do not exceed 2.5 points (most of our stories have 0.5 to 1.5 points). One point is a perfect day, so you need 2.5 perfect days to complete a 2.5 point story. This might take up to 2 or 3 weeks, depending on the time available. So the size of the story is important because of motivation issues: completing work in a short time gives you a very good feeling.

Step 3 – sprint demos are done for each story

We have always a working build and our designer is able to update the svn repository whenever he wants to. After updating he just has to start FlashDevelop, press F5 and can play the game. As soon as somebody moves the story to the “completed” section, Rafael checks the story directly in the current build and adds a comment if something has to change. If the change request is too big, Rafael writes another story and adds it to the product backlog. This works absolutely great so far; thanks go to Rafael for doing a fantastic job here!

Step 4 – established test driven development from the start

Fortunately there are some open source frameworks for Actionscript 3 which support test driven development. We are currently using one of them, which Manuel has improved a lot in the first weeks of the project. Maybe Manuel can explain what he exactly did in some of his future blog posts.

We used TDD from the very first moment, and it proved to be a good decision, because it helps us to have very stable builds. Having a stable version of the game is a must for distributed teams, because it will highly affect the motivation and performance of the team.

To be continued…

So I guess that’s it for today. There is a lot more to say about this topic, so I will write part two in the upcoming week. I hope you enjoyed this post and are able get some valuable info out of it.

Cheers,
Matthias

Share/Bookmark