During our daily work we try to develop our software following eXtreme Programming practices, and specially Test Driven Development (usually called TDD). I said "try", because sometimes it isn't so easy applying TDD in order to fix bugs or work with not-so-clean allready-written code. However, TDD works great for new classes, specially if you use Eclipse.

Lets give a silly sample: we need to develop a "Device" class, which should have an identifier, a description, a copy constructor and one method which sais us whether this device supports a specific audio format (basing on UAProf or WURLF data base).

We can approach this problem from three different ways:

• The traditional way, coding directly the class, using it wherever you want, and fixing errors as they are quicked on the uptake.

• Another way is coding the class, and then coding an unit test for that class. There's a lot of frameworks can help us to work with unit tests, although we're using JUnit and J2MEUnit.

• And finally, we can start from the end and apply TDD: coding first of all our tests and then corresponding logic code. Warn you there're several scenarios where it makes any sense applying TDD, but in others it can clear you mind at all. For instance, if you have a clear idea about the public interface of your class (because you have already developed something similar or because you have a clear, full detailed design), probably you don't need code your tests before the logic. However, if you don't have a clear idea about the class you're going to code, begin with tests, and you'll see the outcome is much better than you expected.

Well, the thing is Eclipse gives us a group of tools which can helps a lot if you apply TDD.


Let's start coding the typical template code for one test case with JUnit, and we'll see that Eclipse will mark a lot of compilation errors. As we can see in right image, it says us "Device" class hasn't been found (it's natural, because this class doesn't exists yet). Double clicking over this red error mark, let's see a list with all possible solutions for this error, and among them: create new Device class. So we let Eclipse doing its work and create "Device" class for us, and we can continue with our tests.

After coding two test methods, we're in the same problem: we've several compilation errors, because we're calling methods which don't exists yet.
For instance, we've a test that checks our copy-constructor, and this constructor doesn't exists yet (neither all setters), so we click over error mark at left margin, and choose "Create constructor Device(Device)" option. With the rest of the compilation errors we perform in a similar way, although there will be some situations in which you should complete or change data types for some parameters which Eclipse isn't capable to deduce.

This way, we can achieve Eclipse works for us generating all templates for our classes and methods, basing on all calls we made in the tests code. And this can save us a lot of time.

Once we have all templates written by Eclipse, we can continue coding all logic code in order to get all tests passing (I suppose Eclipse couldn't help us in these tasks :)

Now that we are localization our first games, we start understanding in which things we were right and wrong when we designed our tools. Our experience told us that we must adapt our tools for supporting the known “Locale” based in two ISO, the ISO-639 for languages and the ISO-3166 for countries (example: en_US for English from USA). When we planed our development, we thought about internationalising text strings and image resources because we could find images with text that need to be translated. On the paper everything was fine and at the end we found more problems that we have started solving nowadays: we need a way to export and import string text resources and the translated resources sizes can be very different. The solution that we are applying consist on creating an export and import system for editing the string text resources translations in spreadsheet programs, that is more useful than our string text resources editor that is lees known by translators. In a long-term we are going to implement a layout manager for creating screens with text and images that could be adapted to the size changes, thinking on the mobile phones screens limits. Nowadays we support internationalisation of strings of text and image resources, but although this is enough for our first videogames, we think that can be improved in usability. Our next release from Battlewizard will include at least the import and export system for text string resources and their translations, and we think we will have in a short time, an screen editor based on layouts.

We are at nervous moments waiting our first heavy users game launching, The Fourth Seal. The launching will be done in many countries. We will start from Spain, where packages have been provisioned into download servers, where advertising is ready. Spain will be followed by some Latin America countries and we will continue with other European countries. The Fourth Seal was translated to four languages and we will translate it to other languages by distributor’s requests. This moment is also a hard working moment adapting games for advergaming and designing and developing the October and November titles.
Our expectations of getting into mobile games market start seeing.
By other way we have launched the last Battlewizard Early Adopter version that will be installed in some companies in the next 15 days. The first migration tests with our first Early Adopter GPM was fine. We migrated a complete project, contents and source code, in 20 minutes approximately, and we test it in some mobile phones. Now we must improve the portability part, that supports 200 mobile phones and must reach from 350 to 400 in this year.
Launching a game, no matter casual or heavy user game, needs of a hard work in all levels and when you are in the final stage, you are at least nervously, expectantly and always busy.

Sometimes because of the hurry in developing a game or because of closing an iteration, some developers find that they couldn’t fix some bugs and they decide to cover that bugs managing some unexpected exceptions or errors.
This practice that must be a serious practice to the eyes of experienced developers, is extended to some developers comunities.
It is true that sometimes avoiding some errors from an external technology, like Java Swing or a KVM implementation from a Mobile Phone Manufacturer, need of managing strange exceptions to solve that problem. Sometimes there is no other way than catching that exceptions for doing nothing and depends on the platform we are using. But when we are managing our logic and our source code, catching generic exceptions in all methods in a non controlled way, can be a practical joke or a nightmare:

/**
 * Controls "key pressed" events
 * @param key Key that has been pressed
 */
public void processKeyPressed(int key) {
    try {
        // Here all logic
        // …
    } catch (Exception ex) {
        // Nothing to do
    }
}

A nightmare because the time of processing that try/catch blocks is high and involves that key detection, AI processing, states changes, movement control, resources loading, painting some elements, the creating and building of characters, the managing of events and actions, and in general everything that must be executed each game cycle, will execute the game too slow.
Not much power in mobile phones could be, but usually we must keep an eye on bad practices that sometimes we did and that developers teams must not make.
If you detect in your developing teams this practice, usually used by low experience developers or the ones that doesn’t look after their work results, you must put a stop to it or you will find a last minute problem. My recommendation is making source code reviews often, making it by developers that don’t know the code they are going to analyse for detecting those bad practises. Some developers will see in this source code reviews something personal, but we must show them that is only a professional activity and that some practises make more complex a product developing.

We are launching our first great game and at the same time we are launching a casual game that will be followed by others in a short time. Our surprise with the market since we started with Unkasoft, is the fast that the market can change and the needed of continuous adaptation that we need. Two years ago, any game that we take to the distributors and operators will have enough success because of the needed of content in the market. Nowadays a lot of us have entered all of a sudden for covering that demand and we have saturated the “mediocre” mobile videogames market. The force of the known brand and the casual game has been imposed, and operators and distributors are real slaves from brands. They don’t value the quality of the content they are distributing and selling. The market is full of mix agents like the developer-distributor that are all time seeing competition in everywhere and are disposed to “kill” for inserting their catalogs in the operators at any price. Now we have started hearing about the needed of seeing some quality games, but what we are seeing are “brand games” and the quality is something far.

We have a hard commitment, we have created quality and we have embarked on a launching without brand to persuade from their mobile phones possibilities. There, where we think that we will beat, can be our major weakness: Does the mobile games player want a great game of high quality? We think that a quality game for mobile phones can be played by “heavy users” in some free time or completing the big videogames platforms, and at the same time can open new doors for casual players. But as usual we must fight in different fronts; we also have casual games for a short use, and being more easy to use for the not initiated into the videogame world, but not loosing the quality and the fun.

I think that the market needs quality in all of the games and not making the mistake from other platforms like “only is important getting money at any cost no matter the quality, the fun and the player”.