We, UEI, develop a variety of products from games to server systems.
Strictly speaking, originally Ryo Shimizu is in a line of game development, and Takuhiro Mizuno is in system development. They can effectively share their work by utilizing their specialities. However, we cannot divide our work completely as we are not a big and systematized company. For the most part, we share our specialities and do our work together.
Ryo’s team programs not only for games but also for something which users directly use, such as mobile applications.
We do this work for a variety of companies, from a theme park to a mobile career and an electronics maker, to help making their products more attractive.
The bigger a company is, the more strict its quality standard becomes.
Truly sensitive test will be done especially for a game whose data should be burned into a ROM. Once the data was burned, it is difficult to fix something.
Especially, for some products, such as telephone devices, tests becomes really strict because they contains user’s privacy data or the law restrict its functions and demand such strict test.
The work for a big company whose products should be done such a strict test, it quite often happens that its test period for quality control is far longer than actual period of development, to avoid something disastrous happen.
It was when we talked about a new products with a big maker the other day.
They said to us, “How do you control products’ quality?”
Usually they asked us to apply their standard of quality control to our test.
The company is famous for its most strict quality control in Japan, so we thought they would talk about their (probably large) materials or plans for the test.
Contrary to our expectation, actually, they said to us that they would apply our standard to the test because they would like to create a product something innovative.
It was the first experience for Ryo in his 7 years career in UEI. The company’s behaviour was really flexible.
Therefore, Ryo explained our usual way of test. Then, they were surprised at that. supposedly, it was the last way for them.
The testing method by a cautious maker: Waterfall method
For Japanese makers’ products, failure is never allowed.
To avoid the failure, all specifications should be expected at the planning stage. All mistakes or errors should be checked in specifications or plans.
Testing plan is written at this early stage and all testing contents are assumed.
Meeting for this assuming take quite long time. What talked at over 10 hours meeting is precisely recorded on the minutes. The specifications will be fixed after all plans are agreed. To fix specification means that no more specification will be added to the product.
Next, at the implementing stage, each part is tested and report of it will be written.
Finally, as an unit test, all modules are connected and tested whether it correctly work or not.
All the tests are done to check whether all the specifications work correctly.
Even if a problem is found at this stage, it would be pass the test if only the specifications are correct. If not, it should be restarted from the first stage, making specification.
The obvious merit of the developing style, called “waterfall” method, is that products can be created without any mistake by checking all mistakes at all stages of development. Contrary to it, its demerit is that it takes so long time until all processes are done. But this method is necessary for big development as it is originally based on the construction work.
However, in reality, private companies cannot have enough time to do such developing as they should compete with other companies and time is the crucial key. As a result, priority to it is solidity or completeness, and functions or user interface is cut because it is most complained and difficult to be realized.
User interface priority in games or Web
Have you ever thought that products by big maker work dull though they are beautifully made? Handling of the products, such as response of remote controller or menu button, sounds something difficult or not smart.
Contrary to that, in games and Web development, user experience is the first thing to be considered. When user experience is not wholly completed, features or functions of it will be cut. Therefore, it’s rare case that a game with difficult handling. Handling impression will directly affect selling of the product. Games with bad user experience will be dismissed soon. So makers manage not to be done that.
Also, in games, a little bug, if not crucial, can be allowed as it can makes the game funny. Games in these days do not have so many bugs, but when Nintendo was popular, many players enjoyed the play with bugs as special techniques.
Of course some crucial bugs may freeze the game or delete data (I remember there were a few games with such bugs), but non-crucial bugs could be granted as one of features of the game.
Rather, specifications for games will change easily one after another.
In game development, it seems to be difficult to keep a specification fixed.
In the comic featured game development, Tokyo Toy Box,Taiyo Amakawa, the protagonist game director, often says as his favourite saying, “Change the specification.” Actually the same situation would never happen in other development.
The waterfall method wouldn’t allow any bug by following their fixed specifications as their bible. That is completely opposite to game development, isn’t it?
The way of debugging by experience and feeling: Monte Carlo
To debug games, testing plan cannot be prepared based on specifications because the specifications changes day by day. Testing plan is written at first according to the early specifications, but usually the final version of specifications is different from the early version.
Also specifications are changing during the test if the game is boring. So debugging is generally depend on the experience and feeling of the people in charge of the test, called debugger.
Debuggers know well the peculiarity of game programs.
So they persistently test a certain point which seems to have bugs.
They will try unexpected handling as well as expected ones according to the specifications. “Player will handle this scenario by certain way, but what will happen if handled in unexpected way?” “If the same thing is repeated by a hundred times, is it ok?” They test such unexpected handling.
Will they find a bug by repeating the same thing a hundred times?
The answer is yes. Actually some handling test that seem nonsense can find crucial bugs.
For example, a bug was actually found that cause hung-up game machine 10 minutes after the repetition of plug and unplug the controller by twice in a second. Though people doubts the relevance of the handling at first, a crucial bug was actually found when they examined inside of the OS that leaked memory and that might cause a crush of saved memory.
We call this debugging method “Monte Carlo.” Such a way based on one’s experience and feeling will be seen irrelevant by technical developer, but it is suitable for game development.
High-tech products like Game
Recently, developers became to pay attention to user experience.
We are often consulted with user experience after iPhone’s sensational release.
So it is certain that developers or makers pay attention to the topic.
Japanese makers have not paid so much attention to beautifulness or comfortableness of products that is difficult to be quantified. However, in game development, such difficult topic, enjoyableness, comfortableness, beautifulness or high-tech, has been effortely tackled.
So we think people consulted us, as we are the company in the middle between games and high-technology development.
Recently such ways of thinking as game developer is called Gamenics and people try to argue it as a theory.
However, solidity of home electronics which will be “never broken” or will “never work mistakenly” is very difficult goal for gaming.
In these days, many companies take both ways, waterfall for never broken parts and the game way for user experience.
Japanese game development is advanced, but only solid development or system cannot compete with developers in other countries any more. To win international competition, we think it become necessary the game development as home electronics from early stages.
