Sponsored By

Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs.

Game Localization Issues Part I: Time Estimation

The first part of a series of articles on issues which arise during the process of games localization and linguistic testing. This post is focused on time estimation issues.

Pawel Rewinski, Blogger

December 19, 2014

5 Min Read

This is a series of articles on issues which arise during the process of games localization and linguistic testing. However, many of the topics discussed are applicable to functional testing as well. Please note that these are thoughts from a point of view of a localization/functional tester (albeit a tester with 4+ years of experience), so consider them mostly as topics for discussion. No connections should be made between my personal opinion and my former employers’ as they are completely separate.

Game Localization Issues

Outsourcing Localization and Linguistic Testing

 

I. Time Estimation

Estimation of project resource requirements is usually conducted by Project Managers in a company, which provides localization services (the company, which a customer contacts for outsourcing). Nevertheless, time estimation is a two-way process. Unfortunately, it often resembles a battle of two forces - a customer wants to pay less, which means they want the localization or testing process to be as fast as possible, and the localization company (if it is a decent one) wants to provide best quality services, which often means taking much more time to perform localization and testing, than the customer is ready to pay for. Finding the perfect balance point is no easy task, and sadly, a situation when both parties agree on the same terms and everything goes according to plan is rather rare. In my experience localization companies often lose ground in this battle for many reasons (probably, the most important one is fear of losing a potential client) and agree to overly short project timespans, which in turn, affects the final quality of the product. As I see it, there are no easy ways of resolving the problem, but here are some of my thoughts on how to improve the process of estimation of project resource requirements, focused mostly on time estimation and divided into two groups - client-side (a developer or a publisher) and localization service provider side.

Client-side

a) Be realistic

Before even contacting the localization service provider, it is possible for a client to estimate their own resources and conditions, i.e. amount of data which has to be tested (word count of the game loc-kit, number of languages to test), the complexity of the game (which impacts the time needed to test the localization in-game), the present condition and stage of development of the game (alpha, beta, submission build). All this data may provide at least a rough estimation of time required for the localization.

b) Assess the costs/budget

Comparing the data, mentioned in point a) to another very important resource, namely the client's budget, may also provide answers to questions like, for example, whether it will be possible to thoroughly test all the areas of the game. The amount of iterations and the duration of testing and localization will directly depend on how much money the client is ready (or able) to spend on it (obvious, I know).

c) Assess the offer from the provider

Assessing the resources of the provider is also useful for time estimation process. Get the information on availability and amount of human resources from the provider (e.g. native speakers of required languages), analyze the logistics (time required for builds delivery and deployment, difference in time zones). Compare the cost of the offer to the budget, taking into account that problems and delays will most likely happen, caused by both the client and the provider.

 Localization service provider side

a) Be clear

After receiving the project offer from the client, the provider should be very clear in conveying information on resources available for the project. Situations when the provider takes and signs the client's offer before making sure they have enough "manpower" or other resources to fulfill the project in the given time, unfortunately, aren't as rare as one may think (at least in my experience). It is best for both parties to know about any shortcomings (on both sides, of course).

b) Be realistic

The same ‘Be realistic’ point also goes to the provider. When estimating time for a project, it is best to assess as many factors as possible and as accurately as possible. Testers' experience, professional skill sets and even personal preferences in games may influence the workflow and change the required time. Naturally, other resources have to be taken into account as well, such as hardware, work space, logistics and all that was already mentioned in the same point on the client-side.

c) Be firm

I think this will be the most controversial point, at least from a business point of view.  However, the provider should not give in when the customer pushes for a shorter time than estimated. In my experience, localization and testing outsourcing companies often quickly agree to the terms forced by the client because they fear that if they stand their ground, they can lose the client. It may be true, but in the long run, standing one's ground and providing high quality services without constant crunch times and delays will create a good name and reputation for the provider and have a positive impact on their internal working environment. On the other hand, clinging to the clients and providing a poor quality service for them will result in the clients not offering any further work and also giving the provider poor references to other potential clients in the industry.  To make a long story short, if you know that you won't be able to provide the highest quality service in the time proposed by the client, either clearly inform the client about this, providing them detailed reasons and try to find a suitable solution for both parties involved or, if the client is still pushing and does not meet halfway, do not accept the contract.

This is it for the first part. Feel free to comment and discuss the post, I’d be happy to see any amount of useful criticism.

Read more about:

Featured Blogs
Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like