Podcast
MULTI-CHANNEL GAMES DEVELOPMENT - ODOBO
Should game developers begin the design process with a view to creating a multi channel game?
I think any game developer building games today that wants the maximum potential commercial opportunity has to be thinking about distributing multi channel. It means that they’re going to need to consider distribution technology that supports publication to desktop, tablet and mobile. Should they anticipate that in the design of their new game? Increasingly we’re encouraging developers to think first about the small screen, and design for the mobile device and then upscale to desktop, whereas two years ago, a lot of thought was around how to take those desktop games and make them work on the mobile. There are still those thinking desktop first and designing games for the desktop before down scaling it, but with mobile being the direction of consumption, the bigger challenge is to give the player a good expe- rience on the small screen - you can always upscale to add all the embellishments to the game, but if you haven’t gotten it right at the small screen level you have a very difficult time going the other way, so it’s of critical importance that they contemplate or anticipate multi channel for maximum commercial opportunity. Many opera- tors today aren’t taking content unless it’s desk- top, tablet and mobile compatible.
How consistent should the game be across multi channels? Do players accept the changes and the mechanics from one channel to the next?
It’s a very good question, because its something that can easily be ignored. You can think of multi- channel as the convenience of accessing a player through any device, but you have to look at it a
how it ties into the ability of the players to play across multiple devices and communications?
This is a key message from us from the start. We designed our platform anticipating that not only was there going to be an increasing amount of consumption happening on mobile devices, but if you go beyond that actually there would be an evaporation of any differentiation of fragmenta- tion between thinking about content as being desktop versus mobile content.
We designed our platform focused on HTML5 as development client side technology and always anticipated that those HTML5 games would be fully viable technology for use on desktop as well. When we started out, everything on desktop was flash, mobile on HTML5 was emerging and there was a lot of debate concerning native Apps versus HTML5. Since then we’ve been proven right as regards HTML5, where today it’s now becoming the standard, if it’s not already the standard, for games development across all channels. On our platform we support the same client build as pub- lished to desktop, tablet and mobile, ensuring the player experience is seamless across all channels.
We designed our platform focused on HTML5 as
development client side technology and always
anticipated that those HTML5 games would be fully viable technology for use on desktop
layer deeper than that. There are two considera- tions; there’s the fact that the amount of player behavior across those devices is different. You have a longer player time, or session time, every session on both desktop and tablet game than you do on mobile, so from a mathematic design stand- point, you want to ensure that during the shorter session time on the mobile, the player is still get- ting the intended experience that you have in longer play sessions on desktop and tablet.
If you have an anticipation that the player is going to encounter a bonus feature and that fea-
ture is likely to happen in seven or eight minutes, you want to consider whether that is the right math for an average player session time of three to five minutes on mobile. Can they can get the right experience in the time allowed?
The second side of that question is should it be consistent across all the devices and I think it should. you would see both examples on the mar- ket where there is light versions of games ? If the technology platform you’re building upon allows you to serve different assets based upon the channel the player is playing on, then I think you should try to give a consistent play experience across all of the channels.
I don’t want to pluck the strings of our bow too much, but this is a key part of the technology that we deliver. When a game is loaded that’s built on our platform, the first thing we do is a pre-flight check on the user’s device. This serves to report back to the server what device is being used, what connection speed is available, what browser has been adopted and only then do we serve the appropriate assets the developer has produced for that device. This ensures that for a small screen device we’re not loading heavy, large screen assets or retina display backgrounds, but still maintains that we’re giving the right player expe- rience. On the other hand, if we’re serviing a large screen desktop user, then we take advantage of the greater screen real estate, capacity and better connection speed and we serve them an enhanced version of the game. It’s about develop- ers being aware of the technical obstacles to bet- ter optimise game performance on mobile devices so that their games is more accessible for the con- sumer. This ensures that the technology you’re using allows you to differentiate, rather than try- ing to push the same game across all devices.
What are the specific difficulties in creating multi channel games? I’m expecting the costs to be bigger, the development time to be greatly increased... is that the case?
Well, definitely when you add fragmentation, and multi channel is fragmentation, you’re increasing the development cost for the game developer. Wwe estimate that from the difference between producing a flash game for desktop versus pro- ducing channel games there’s about a 25 to 30 percent increase for production cost. So we’re doing everything we can to alleviate the develop- ers of the technical side of that to produce more development tools that enable multi channel publication. Those tools are accessible through our tool kit without the developer having the cost of producing them and where they don’t constrain their creativity these are not tools that are involved in the novelty of their game concept, but are necessary to publish and distribute their games across those channels.
Publishing and distribution don’t need to be areas where developers make new investments - they should be investing in the quality of the content that they’re putting in the canvas that we provide
1 2 5
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60 |
Page 61 |
Page 62 |
Page 63 |
Page 64 |
Page 65 |
Page 66 |
Page 67 |
Page 68 |
Page 69 |
Page 70 |
Page 71 |
Page 72 |
Page 73 |
Page 74 |
Page 75 |
Page 76 |
Page 77 |
Page 78 |
Page 79 |
Page 80 |
Page 81 |
Page 82 |
Page 83 |
Page 84 |
Page 85 |
Page 86 |
Page 87 |
Page 88 |
Page 89 |
Page 90 |
Page 91 |
Page 92 |
Page 93 |
Page 94 |
Page 95 |
Page 96 |
Page 97 |
Page 98 |
Page 99 |
Page 100 |
Page 101 |
Page 102 |
Page 103 |
Page 104 |
Page 105 |
Page 106 |
Page 107 |
Page 108 |
Page 109 |
Page 110 |
Page 111 |
Page 112 |
Page 113 |
Page 114 |
Page 115 |
Page 116 |
Page 117 |
Page 118 |
Page 119 |
Page 120 |
Page 121 |
Page 122 |
Page 123 |
Page 124 |
Page 125 |
Page 126 |
Page 127 |
Page 128 |
Page 129 |
Page 130 |
Page 131 |
Page 132 |
Page 133 |
Page 134 |
Page 135 |
Page 136 |
Page 137 |
Page 138