Porting phase optimization and productivity maximization

Eric Thommerot

Introduction:

Why is it an important topic?

• Critical phase at the end of the project (on which all the rest has the biggest impact)

• Commitments to final customers (carriers) taken and launch slots reserved

• Credibility of your company is in question

• The product quality might be altered by this phase if it is not prepared/done correctly

Introduction:

What are we going to talk about?• This is the presentation of a mobile product life cycle within a

standalone studio (dev & porting done in the same studio)

• Various small tips that will help you prepare and secure your porting phase

• How to organize your teams in the best way

• How to maximize the exchanges between your porting and QA teams

• How to avoid miscommunication between those two teams

• How to measure that your project is healthy

Introduction:

What will not be covered in this session and why?

• This presentation is a bit European-centric BUT the same principles apply to the US.

• We will not talk about why is it difficult to port a game over 300+ handsets (you are all supposed to be familiar with this)

• We will not talk about handset bugs (you are all supposed to know most of the handsets are buggy)

• We will not talk about porting factories, their strengths and weaknesses (I’m not here to impose my vision and you are all supposed to have your own porting tools)

Project preparation

How can I prepare the project to ensure that the porting phase of my product is going to be easy and secured?

50% of the risk can be created here…“

Identify the mainstreams correctly

• Select your mainstreams depending on the project constraints:• Time

• Human resources

• Expected quality

• Project complexity

Define your porting strategy

(see Appendix 1)

Create a generic porting plan based on your own experience

• What is a porting plan (see appendix 2)?• Knowledge based on past projects

• Group phones per families based on screen size, heap memory and speed

• Sort the phone families easy at the top, hard at the bottom

• Logical way to address devices by proximity (avoid doing too big steps from one phone to another typically don’t jump from SonyEricssons to Motorola triplets in a single step)

Create a generic porting plan based on your own experience

• How to use it?• It’s a living document as long as it is not targeting a

project (add new phones in between porting phases)

• Freeze it when a porting phase starts and cutomize it depending on market needs.

• Customize it based on the specificities of your project (it might change from one project to another depending on the project complexity)

• Use it to progress safely and manage risks during the porting phase (will be explained in the following slides)

Answer all potential questions you can think about at the design stage

• Answer the basic questions:• What’s going to happen if I want to target a phone with

less memory?

• What’s going to happen if I want to target a phone accepting smaller binaries?

• What’s going to happen if I want to target a phone with a smaller screen size?

Basically what’s going to happen if my targeted platform changes significantly, what shall we do?

Write it in the game design…

Porting technology selection

• Select a porting technology now (and think about the future):• Don’t select it too late when the development is more

than half done

Avoid a 1st porting from a technology to another

• Can be your own porting tool but think about it twice before investing, don’t re-invent the wheel

• Capitalise your experience from one project to another

Improve your efficiency so reduce your costs

Interlude

How shall I organize my team efficiently to reach the maximum productivity?(Serial VS Parallel organisation)“

Team organization

• Serial:Product 1 Product 2

Team A Team A Team A

• Parallel:Product 1

Dev Team A Port Team A

Product 2

Dev Team A Port Team A

Dev Porting Dev

Dev

Dev

Porting

Porting

Team organization

• Serial VS Parallel:• Serial probably more efficient on the short term (the team knows its code

so they are faster in reducing the product to more restricted devices)

• Serial is more cost effective if you do not produce enough game per year.

• Serial probably less efficient on the long run because of the lack of specialisation (you can forget this or that bug or workaround in between projects where someone doing it all the time will not forget)

• If the two teams work regularly together, then the Serial organization advantage disappears since they ‘ll know each other’s habits

If possible select a parallel organization.

Project development

What can help me during the development phase to ensure that the porting phase of my product is going to be easy and secured?“

Charge everybody with responsability & accountability

• The pro-activity of the developers is crucial• Prepare the project and ease the life of the porting guys if they

see something obvious (50% of the necessary settings to reduce the basic binary might be identified by the developers)

• The development team needs to be educated and rigorous (comment the code, do not allow unexplained magic numbers)

• Involve the porting guys a bit before the porting phase

• Organize a pre-porting session somewhere around the Beta phase of the project (may allow to identify bottleneck and things that can be done better)

• Involve the porting guys to help the original team with the screen size targeting (will be useful to be familiar with the code)

Be careful yourself

• Do not do stupid supposed savings during the development phase that you might pay for during the porting phase (i.e. avoid creating an editor that takes time, hardcode something)

Porting phase

What can I do now to maximize the performance?“

The main problem

Porting team X resources

QA team Y resources

Portingplan

DeliveryValidations

The main problem

• 2 teams:• Different resource numbers

• Different capabilities

• But:• Must be used to their real capabilities every day

• Must synchronise themselves the best possible way

Provide the best performance at the end

Mainstream test & preparation

• The orginal mainstream test is crucial. Not allowed to find a significant bug when you have 100 gold devices.

• Request all necessary art assets (screen size & bit depth) from your art team in advance (during the validation of the mainstream is a good schedule so the porting team can move full speed without waiting for any element)

Prepare a document containing all the necessary screen sizes for your art team

What about BREW

• Brew is a separate technology if you’re doing it manually.• Get the Brew screen sizes implemented along with the

basic mainstreams

• Split the project when the mainstreams are gold

• Brew can be seen as some additional handsets if you do it using some known conversion tools in that case add them as extra handsets to your porting plan.

Delivery strategy

• Do not deliver more than your QA team needs to keep them busy for half a day to a day (it is generally confusing they don’t know what to begin with if you give too many things)

• Use a clear way to communicate your deliveries. Some tools can help you (see appendix 3). Poor communication can create confusion and lost days (especially if you’re working with remote locations in different time zones)

• Drive the deliveries in such a way that the « strategic » binaries are tested first.

• CARE… CARE… CARE… be present and adapt yourself very quickly to any wrong feedback (binary crashing for instance freeing a slot that you need to fill asap).

Risk management

• With your porting strategy defined earlier, move:• Down (if top-bottom)

• Up’n down (if bottom & low-top to middle)

• Up (if bottom to top)

• Every step is a potential risk to break the system and have the QA team waiting for some deliveries.

• Coordination between your porting team and your QA team will result in the success of the porting phase (if the teams are compatible & everybody is used all the time).

Risk management

• But move wisely…• You can move on more than 1 front at the same time (QVGA &

MidRes for instance). It will allow you to manage the difficulty everyday.

• Do not assign everybody on hard things at the same time. Manage the difficulty depending on the number of deliveries you need.

• Use a step by step process, do not do a too big single jump

• Use the compatibilities to fill the gaps between the deliveries

• Always keep one resource (at least) to deal with debug at anytime

Example

Communication

• Communicate clearly:• Where the project stands (progression, they must see the end of

the tunnel to increase the motivation)

• Give appropriate objectives on a weekly basis so everybody knows what to do

Don’t hesitate to say when things are good (avoid a too European behaviour)

Communicate when the goal is reached

Take credible actions if the goal isn’t

Show you are with them and not against them…

Project health

How can I measure my project health?“

Project Health

• Measure the project schedule on an average basis (being late one week isn’t dramatic if you are not late all the time).

Use a project scheduling tool to check if the situation is good

• If the situation is good you’ll see:

• The objective of every week is reached

• Low level of conflicts

• Teams are used at the max of their capacity (will allow you to measure the compatibility of the teams, 1 porting guy cannot give enough work for 20 QA guys alone)

• The bug database is not growing dramatically without decreasing (organize “debug sessions” in that case to reduce it).

THE END

Questions?