Wednesday, September 27, 2006
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
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.
Friday, September 22, 2006
Tuning Up Battlewizard on MacosX
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:
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:
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:
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:
6.- Other options
Two more options can be used to change our application into a more esthetic and MacosX Look&Feel one.
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.
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.
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.
Wednesday, September 20, 2006
A day in QA
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.
All it we will be it commenting in next post.
Wednesday, September 13, 2006
SCRUM at Unkasoft: eXtreme Programming (XP)
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.
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.
- 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
- 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.
Monday, September 11, 2006
SonyEricsson, Eclipse, JUnit and more
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
Friday, September 08, 2006
Mobile Marketing... 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
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
- 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.