Want to know what goes on in a ported game life cycle?
Here is a brief overview on what goes on.
I have worked with South Korean game developers before, traveled there many times on business and even ran one for 2 weeks in Seoul while one of the people was away.
Here is how the process works for a North American Publisher. (It’s slightly different for Frogster because the parent is in DE)
Publisher seeks to port over a game, contacts a company that markets games for developers. We will call them the middleman. (Yes, I know who the company is that did RoM, initials are MG and the main contacts initials are MC, I have him on my MSN)
The middleman arranges a demo with the developer for the publisher to check out and if the Publisher likes it, then contract talks are started.
Decisions are made about (in no specific order);
a) Server hardware that the game will run on.
b) What are the bandwidth requirements?
c) What kind of API is available?
d) What payment structure the publisher will pay the developer.
e) When the server package will be delivered.
f) When the scripts (translations doc’s) will be delivered. In most cases it is up to the Publisher to localize to their region.
g) Response time to fix critical region bugs and balance and penalties if not met. ( Often the most missed in contract negotiation)
h) Bug tracking support from publisher to Developer. (Again, one of the most missed items and related to “g”)
i) Version the game will be released at. ( this is both decided by the developer and the Publisher for differing reasons, some are;
.......1) Developer decides what is the least version that they can give out that they are comfortable with its stability and content as well as longest life cycle they can get out of the product to get the most payments from.
.......2) Publisher decides what is the least version they think has the best content that will bring in paying players and the longest life cycle they can get the players to pay. They also look at what the current version is at to calculate from the starting point to current development in order to project the life cycle if the developer were to stop development for any reason. They also roughly calculate when each update should be done to maximize revenue.
j) When the expected Beta release date is.
k) Few other things....
Once the contract negotiations are finalized, the publisher now needs to (In no specific order);
a) Arrange an IDC location, purchase and set up the servers to be ready for the game package delivery. (More contracts)
b) Start work on the Website. (usually with basic API info to start with) (Possibly more contracts unless it is done in house)
c) Set up the localization team/company for when the scripts come in. (Possibly more contracts)
d) Start the setup for the payment system. (more contracts)
e) Generate a marketing plan.
f) Few other details....
Now it’s time for the fun, the game and scripts come in and the following happens (again in no specific order)
a) Localization team starts to do first pass on scripts, really rough pass.
b) IT Department sets up server as per Developer instructions (A lot can go wrong here where variance is made without the developers knowledge)
c) Clients are distributed to internal staff and some investors for sneak peeks and testing.
d) Website development is furthered with preliminary API testing and DB access testing.
e) Finalize marketing plan.
f) Few other details....
Up until this point, most new Publishers have around 5~8 people on staff, not including Corporate heads.
It’s BETA time!
a) IT opens up the server to the web and analyzes bandwidth usage.
b) Web site is near finalized.
c) IT creates a copy of the game servers in a secure environment for testing patches and updates before it hits live, usually called a “Staging Server” (This is an often overlooked step)
d) Marketing hits all the game review sites and arranges deals with sites to promote the game. (Sometimes the sites are given an exclusive and in return the site recommends the game, good or not, it gets high marks.)
e) Registration is up.
f) Client is made available for internet users to download.
g) Basic support system is set up.
h) Localization hits phase 2, cleaning up the rough translations.
i) Reporting bugs, issues and feature requests to the developer. (Remember I said “requests”)
j) Few other details....
Now that Beta is in full swing, the following happens (again in no specific order)
a) IT finalizes bandwidth usage and makes adjustments.
b) Payment portal is finalized.
c) Localization is finalized.
d) Marketing goes into phase 2 to announce the upcoming “Golden Release”
e) Bugs, issues and requests are still ongoing with the developer.
f) GM’s and support team is hired and trained.
g) A new team is rolled out, the “Live Team” (these are the guys like Swag and the CS guys)
h) Few other details....
Ok, seems like things are rolling along nicely, yes?
Well, not all the time, this is where the real pressure is on and because of steps missed or overlooked prior, life becomes hell.
a) Because in the contracts nothing was negotiated on response time for the developer to fix bugs and critical issues without penalty. The developer is sluggish to fix them because they are focusing on the latest version and revisiting old stuff is a real pain due to having to branch off at an earlier SVN point. Most of the time, the developer turnover in employee’s is high and if you have ever coded, if everything isn’t commented clearly, even going back on your own code you can get lost really easy, let alone going back on code that someone else wrote.
b) Fixing bugs and issues in an earlier version, that is fixed in a later version really seems like a waste of time and the developer usually tells the publisher, yes it is fixed when you get to X version. This is an issue for the Publisher because it may be up to a year before they scheduled that version to be released to public.
Tempers flare up and the Publisher is caught between a rock and a hard place, The publisher wants to make his release date, the investors are pressuring him to make the release date and the developer is dragging it’s heals.
9 times out of 10 the pressure is too much and the release date is made, ready or not.
Release day, hell hath no fury like a gamer scorned.
At this point, the gamer is expecting a finished and polished game to spend his/her money on, but most of the time, it doesn’t go that way and all hell breaks loose.
IMO, at this stage these are the things that is falling behind.
a) Support is not fully set up and usually falls to the low man on the totem pole to handle all the support ALONE. (can you say backlog)
b) Critical issues with the client and or server for stability.
c) Localization is not fully polished because the publisher is now totally focused with trying to get critical bugs fixed and the localization takes a back seat.
d) Web site testing is not 100% and site does not fully work correct with all browsers. ( Almost an impossible task these days)
Ok, now after a lot of hair pulling, the Developer give the Publisher a patch to fix “some” issues and “some” requests.
Because of the pressure to appease the players and get money rolling in for the investors, the new patch is often not totally tested on the staging server or tested at all (you remember that? It’s the testing server that they were supposed to set up in beta)
The patch gets pushed to live and... Well you guessed it.... BOOM!
Some things get fixed, others that were ok get broken and new things or changes get added that the publisher had no idea were in there and the developer didn’t say anything about.
The Publisher has no recourse because it was not laid out in the contracts.
Rinse and repeat till game dies.
There is a lot I have left out that happens in each step and I’m not up to writing a book about it, just a little blurb about the basics that happen in a publishers ported game life cycle.
