Historically the AAA development process has evolved from a point in time where online multiplayer was actually an optional bullet point on the back of the box. Back then a successful game could ship with or without online multiplayer. It is in this environment that the current FPP process was built, and why the focus to demonstrate a vertical slice of gameplay is more or less faked. With this mindset, it is acceptable for "online" to be eluded to and then added later during production. These days--due to resources limitations, dependencies, and risk--the online development is more often than not outsourced as a feature to another studio.
One of the earliest and most extreme examples of this was the development of Ghost Recon Advanced Warfighter (GRAW). In 2003 Tiwak was working on the brand new engine (Yeti) that the GRAW single player campaign was being built upon. However, due to the various aforementioned reasons, a decision was made to ensure that GRAW would ship within the expected holiday window. Following in the footsteps of Splinter Cell: Pandora Tomorrow, where Shanghai was successfully outsourced to create the multiplayer, it was decided that the GRAW multiplayer would be produced by Red Storm Entertainment (RSE). However, unlike the Unreal-based Splinter Cell, the Yeti engine was a developing technology, and for all parties involved it made sense to reduce risk even further by leveraging the seasoned GR2 engine for its well-tested lighthouse network library and successful multiplayer. This decision in turn required RSE to leverage a studio worth of resources to literally recreate their own version of GRAW in a different engine. The benefit of this arrangement doubled the team’s size and yielded a high quality hit game within a timely manner--as well as reduced each studio’s operational risk by splitting the development cost. Unsurprisingly, this practice not only continues today, but has been institutionalize with more than a decade of Ubi games treating online as a feature with great success.
There are, of course, downsides to this process especially pertaining to product vision and communication challenges. GRAW like any other project probably had its own unique share of challenges due to co-development, but it also had a few seemingly minor consequences that are of significantly more importance to acknowledge today. The first is that Yeti was never built with network replication in mind--which unknowingly created significant challenges, limitations, and risk to shipping Ghost Recon Online on the same engine years later. The second is that the GRAW cover system, one of its biggest breakthrough features at the time and a competitively unique selling point, was nowhere to be found in the multiplayer. It is a logical symptom of the split development process, but also probably the best "worst case" example of how treating online as a feature can literally yield two entirely different games.
Today, demands on the next generation of online games are changing. The online component can no longer be treated as a separate feature from the core when single and multiplayer modes are now touted as a seamless and cohesive experience. Outsourcing to another studio becomes notably problematic as considerations for the technical and design differences need to be closely monitored and coordinated. Next generation projects that revolve around the mandate to create this kind of seamless online/offline gameplay while still following traditional black box style development are more likely to render the developers ineffective—in the worst case resulting in re-scoping years of work, cutting dependencies, and even rebooting entire projects.
It's of importance to recognize that upcoming projects are being driven as the result of forward-looking next-generation global initiatives—requiring them to be designed around buzzword features such as fully online, systemic gameplay, data driven analytics, micro transactions, and companion gaming to name a few. As the industry evolves, institutionalized processes focusing on core story and gameplay that lead to online being segregated as another feature to develop need to evolve with it.
2. Think long term, because it's a self-fulfilling prophecy.
Short term thinking leads to long term operational losses, and F2P/online projects are long term in their very nature. Projects of this kind need to be built smart to reduce operational overhead, adapt to changing markets, and have the flexibility to support unforeseen monetary and strategic channels. As such, it should be entrenched that F2P online projects have an indefinite life span to prevent short term thinking. Mandating a concept like this from above helps change policies and procedures at all levels from HQ to QA.
Short term thinking leads to long term operational losses, and F2P/online projects are long term in their very nature. Projects of this kind need to be built smart to reduce operational overhead, adapt to changing markets, and have the flexibility to support unforeseen monetary and strategic channels. As such, it should be entrenched that F2P online projects have an indefinite life span to prevent short term thinking. Mandating a concept like this from above helps change policies and procedures at all levels from HQ to QA.
Anyone would recognize the silliness of developing a game on PC and then gold mastering to GameBoy. On day one you should strive to be operating in a live service environment.
4. Ignoring technical debt bites you in the ass forever.
Remember your project has an indefinite lifespan and the earlier you address the debt the more you save. If you believe in Commandment #2, there is always time to do it right regardless of who might say otherwise.
5. Your monthly development cost is indicative of your monthly operating cost.
If it takes a lot people to make your game it's likely to require even more to operate it. Remember Commandment #3. Be careful of when and where you scale development as you are actually scaling your operating costs in the process.
6. Numbers are only as meaningful as the questions you asked.
These days where data can be tracked and analyzed on just about anything, the real danger is the possibility for it to lead to a blind unquestionable trust in numbers and their KPI's once established. New questions need to be asked in order to constantly test and probe various hypothesis. A KPI cannot explain the "why".
7. If you don't know how much it costs to make your virtual item then you are doing it wrong.
Your content pipeline is a real world manufacturing plant from beginning to end. If it takes 1000 man hours at an average cost of $20/hour to make a virtual item, then you need to sell $20k worth before you start making a profit. Free to play games literally make their bread and butter off this process and there is always room to reduce its overhead. Doing so allows the bread and butter to more efficiently support other operations that don't have a clear ROI.
8. Elite military soldiers don't buy mystery boxes full of epic loot.
You are not making a store, you are designing a user experience. Support the IP and fantasy of the brand from beginning to end.
9. Players don't stop playing your game, they divorce it.
Bad experiences are more memorable than the good ones. Many small bad experiences can usurp the great ones and cause unidentifiable retention issues. It costs less to acquire new users than it does to get them back, so don't lose them. Note that happy players are your best acquisition tool and prioritize keeping players happy to benefit long term conversion.
10. If first time conversion yields buyers remorse, assume they will not convert again.
If people feel good about buying they will buy again. Don't mechanically force people to buy something they don't want.
11. At least people don't die from our mistakes.
We should make mistakes so we can learn and never punish people for making them. Besides, tomorrows patch will have the fix.
