It was reading blog of DevZing on development of games and it made me reflect.
One of the greater dangers than we have testers is “the contamination”, is an aspect that repels directly in the balance of the product. It is necessary to differentiate, tests to detect bugs (already we will speak seriously at another moment) to balance a game.

Normally a base is created where the game is theoretically to point, later, when already they have reviewed bugs, it balances on emulators and finally tested by people other people's to the project. These last ones, if that plays, the rest has been done test after test.
Another subject is the market towards which it is directed, mobile, consoles, Pc… the design and tests are different in each case. It is not the same to validate a console that a mobile.
For it one of the options is to have an equipment of testers and a beta-testers set, but this in most of the companies usually does not happen, more workers = too much money…

It is like everything, there is very good ideas and also good methodologies but in my opinion all are not applicable to the 100%, I am explained, is necessary to be realistic at the time of seeing the duration of the project, which usually happens habitually, since we are in a market that does not allow developments of more than 45 days if you really want to be inside.

In order to avoid it it is possible to have prepared patterns with the general batteries of tests (the programmers also must say this way), with the purpose of proving aspects that can be common in the games, sees menus, options, audio modules etc.
And a battery of tests makes specific, grouped by different sorts for example, tests for a Arcade that for a strategy game.
This avoids in a high percentage to test aspects of the game that do not have relevance, in addition, we proved those parts that more interest to him to watch the programmer.
Another one of the aspects that there are to consider is the type of game, if he is casual or hardcore, the content and the complexity that it has, according to this also we would test of IA: it is not possible to be validate in only a pair of games that each component has the behavior that is expected. There will be difference to each other is a Pac or a The fourth Seal the diversity of the behaviors and states causes that a more exhaustive analysis is made.

One important thing about Battlewizard is that can be run on any S.O. supporting Java 1.4 or above; this characteristic makes it suitable for any user, despite of if he uses Windows, Linux or even a Mac.
In this post, we will cover running up Battlewizard over a MacosX Tiger platform.
Anyone who uses MacosX will know that there are some important things much different from other operative systems; for example, menubars are always on the upper side of screen, just by the apple. With a few simple tweaks you can give your Java application a native look and feel so that Mac OS X users can install and run your application without being aware that they are running a cross-platform application.

It's important to notice that Battlewizard will have a launcher for MacosX systems that will make use of all this stuff.

1.- Using plain JVM
If we just launch Battlewizard with a plain JVM, our application will look like this:



2.- Setting MenuBar on its place

We will make some use of JVM system properties to achieve this; just add the following argument to the jvm arguments at battlewizard launching:

-Dapple.laf.useScreenMenuBar=true

And the result is as follows:


See how menubar now is on the upper zone??

3.- Changing that class name....

As you can see on the last picture, menubar now lays where it has to, but the name of the application is still the full name of the class, package names included.
This is far from style, so we will change it in order to see the name right there.
In this case, we use a special macosx jvm option instead of a system property:

-Xdock:name="Battlewizard"

And here comes what it results:


4.- Adding an "About" entry on the system menu

It's not really important, but every macosx application has one, so... why wouldn't we?
Using this system property:

-Dcom.apple.mrj.application.apple.menu.about.name=Battlewizard

will let us see the following menu option:


This option still have to be coded to be useful, but we have an "About Battlewizard" option on system menu....

5.- Graphic improvement
Well, maybe this should have be called downgrade graphics... but a little explanation will serve.
JVM by default enables Double Buffering for all its graphics. It results on smoother animations and flicker-free.
MacosX uses a graphic engine, called Quartz 2D, part of the Core Graphics framework, is an advanced, two-dimensional drawing engine that is resolution- and device-independent. Its powerful features include transparency layers, path-based drawing, offscreen rendering, advanced color management, as well as PDF document creation, display, and parsing.


This engine always do DoubleBuffering, so if we don't disable it on Java, we will have a double buffering of a doble buffered image. It still works, but will not see much improvement but less performance.

In order to disable Java double buffering, we'll use the following system property:

-Dawt.nativeDoubleBuffering=true


6.- Other options
Two more options can be used to change our application into a more esthetic and MacosX Look&Feel one.

-Dcom.apple.mrj.application.growbox.intrudes=false

The one above makes applications respect the growable area of a MacosX window. If this option is not used, window contents would invade growable area.


-Dcom.apple.macos.smallTabs=true

The last one is to the size of the tabs. It is hard to do cross platform GUI design if you try to set the size and location of components precisely. One obstruction is that the font size is different on different platforms. Apple allows you to choose between using big and small tabs. The default is for big tabs and which one you choose is merely a matter of judgement.

Conclusion

Although Java is a cross-platform development language, we've got to be aware that each of this platforms has subtle features that can be tweaked. It's good to know how to change them with little effort.

Hello, I am Jorge of the department of QA in Unkasoft and I would like to comment you a little on the habitual tasks that development throughout a day of work.

I hope that already you know some game Unkasoft; ‘The Fourth Seal’ or ‘IsoRoller’ in the opposite case, is not bad idea that you play the next one, transmits mystery with its graphics of great quality, generates more addiction in each level, you want to arrive in the end!! We hoped that you like it!!

Now we are in the heat of phase of production, at this moment I am testing that one next game, so that in the next days it is left balance and next my mission will be to validate it in different terminals so that it is possible to be guaranteed that he is compatible with almost 300 models of moving body.

On the other hand also we made tasks of tests and quality on the Battlewizard platform, executing the functional tests, partly of way manual and partly of form automated with Open-Source tools like Marathon, that we complemented programming scripts in Python. At the moment we are in process to automate all the possible functional tests, until the moment we have covered 80% with them in our Smoke-Test, the rest we are investigating it with other tools.
All it we will be it commenting in next post.

Since we started our SCRUM series, we've received some mails about eXtreme Programming. Are you keeping on it? Can we use XP along with SCRUM? Where XP practices are placed inside SCRUM process?

First of all, we should clarify some aspects:

• eXtreme Programming: it is a development methodology made of twelve programming practices (and some of them about planning). It is focused on writting adaptable code minimizing error rate.
• SCRUM: it is a planning and tracking project methodology (software projects, engineering projects or gardening ones :) with practices focused on managing the team, tasks, features, etc. It doesn't explain how you must write you code (gardeners don't write code!), but it explains how you can arrange your team to lead it to safe harbour.

So that, each stuff should be used for its purpose.
Thanks to SCRUM, we manage to track continuously our project, bringing forward
unpleasant surprises, in order to give enough time to respond to them. We
achieve a nice working environment, giving responsibilities to each team member, and
trying to don't create stress between team mates (although some of them are unavoidable).

Even though, whether we used only SCRUM in order to manage our project, we don't have any control for whole programming side. How we should write our code? Which tasks should be done before coding? And then? At this point, we can introduce XP. With eXtreme Programming, we have an agile methodology focused on programming, which fits perfectly with filosophy suggested by SCRUM. Perhaps, due to this fact, the SCRUM + XP combo is been applying successfully inside several Microsoft projects and even inside some games companies.

So, along with all SCRUM stuff we've talked about, we're applying next XP practices:

• Planning game: more or less it's the same we're doing during sprint planning:
  product owner suggests new features to be implemented and development team estimates them.
• Small and frecuent releases: therefore we're using 1-2 weeks sprints instead of 30 days as formal SCRUM suggests.
• User histories: all features we write down in product backlog are, more or less, user histories.
• Simple design: the least code you write the better. We try to avoid superfluous features and complex architectures. Remember XP motto: "the simplest thing that could possibly work".
• Unit tests: we go on with TDD way: write tests before code, at lest, whenever it's possible.
• Refactoring: our code base is under continuous evolution, trying to simplify and clarify it.
• Continuous integration: we build frecuent and automatic releases, running all tests.
• 40 hours week: it doesn't mind trying to set up a nice work environment if you're exploiting your team.
• In-place customer: our product owner is always available for solving questions.
• Programming standards: we're following Sun's Java code conventions.

But there're some practices we've abandoned:

• Pair programming: SCRUM doesn't limit us in this side. During your daily
  scrum, two programmers could be assigned themselves to one single task, if
  they prefer working together. Actually, we don't do it, except if someone is in
  difficulties.
• Collective code ownership: we don't let private modules, but we do with
  module responsible. Everybody could change code from all modules, but each
  responsible should aprove or at least be up to dated.

In short: SCRUM alone could be insufficient, due it doesn't give us guidelines about approaching programming tasks, so mixing it along with eXtreme Programming, we get a better and more complete agile methodology.

Today should be the SonyEricsson's news day because I'm finding out all about, although many of them comes from few days ago.

In one side, Felix told me that SonyEricsson releases its JUnit version for J2ME. Great news, because we had very few xUnit implementations for Java Micro Edition and we need them!
We were using J2MEUnit for months, but it didn't conviced at all. The framework takes up almost 20 KB, so with test data files, logic to be tested, and tests logic, we're very tight for tiny devices (up to 64 KB for JAR size)
Two months ago, we realized one new xUnit framework for J2ME was delivered: JMUnit. The name is great (: but I haven't enought time to check it yet.
And with brand-new SonyEricsson's framework, we have more pending work to do. I'm sure it's worth.
I hope next sprint I could add new tasks for check these frameworks and next weeks we'll change our standard xUnit framework for J2ME.

In the other side, I found out that SonyEricsson is joining to Eclipse project to contribute providing plug-ins for J2ME development. This news is better than previous if possible. Integrating all SonyEricsson toolkits and libraries as Eclipse plug-ins, is a dream became true.
In few months's time we'll have our Eclipse full of plug-ins and we won't need more external apps for our daily work.
We hope all these announces lead us to safe harbor and soon we'll get better development tools for mobile

Mobile marketing, cool after the summer, more and more people is trap by the move. I guess is due the end of the vacation period, people start to go to the gym, collect magazines, and …innovate in advertisement. Anyhow, mobile marketingis stuck in a groove.

In spite of the options for creativeness, we keep using promotions codes within the products asking for sending SMS with a code in order to win a prize. An example I’ve seen the other day, – company and names censored -
"Once acquired the product XXXXX , text us TUPREMIO with your code of 12 digits to XXXXX (0,90 euros + taxes) and win....”

The whole marketing theory goes down with this sample, buy your snacks paying one euro and pay another to be in a lottery. If that isn’t enough for us then comes the crucial time to text a code with 12 digits -Thank God for the people’s patience -. The idea should be different, at least if you don't want to compete aginst Lottery agencies. A prize could be part of a promotion but couldn’t the promotion itself.

Recently was published Mobile Marketing by Alex Michael and Ben Salter, I’ve read it carefully seeking new cool ideas. At the end I felt as my friends who have watch Pirates of the Caribbean 2... The authors achieve a study about all the telecom aspects, but I feel a lack of ideas and essence focus to real mobile marketing.

Within the vast content, we could find out interesting notes:

• Powerful; it opens a wide range of opportunities to segment ads based on age, location...
• Response rates to SMS campaigns (Mobile Marketing literary source):

94% of messages are viewed
62% of ads are remembered
22% of receivers forward it (viral marketing)
18% of response to the campaign

• Costs: contrary to TV or radio advertisement... mobile marketing require less financial effort.
• Measurement, with the response rate information, companies could improve their campaigns.
• Wireless Advertising Association (WAA): (as important as IAB for Internet)

Creative Standards and advertisement model
Consumers issues and privacy
Promotions measurements

• General guidelines and best practices –independent of the way is publish the advertisement- : legal, decent, honest, truthful, permission-based, responsible and respectful.
• STOP command. Command to get rid of mobile ads, the opt-out for user who didn’t like advertisement.
  

The theory to define the business model to marketing agencies is still the same:

• Set-up fee
• Monthly support fee.
• Pay-per-view fee for the mobile content (games, wallpapers…).

Recently some news from HandyGames make me happy, they launch an idea based on a business model with advergames for free (from customer view). I hope to receive more good ideas & news.