It’s once again time for that pluckly little gathering of industry bigwigs: the Game Developers Conference. This year, we sent Helios to be our man on the scene and report back any juicy mobile tidbits. But before the conference had even started, he emailed us a little musing he composed while on the plane (flying first class, of course). Check it out.
Several weeks MobileIndustry.biz reported that several major industry players had formed a working group to create a new open architecture for native game development. There are few details on the matter outside of this announcement and that there would be support for several native implementations (such as Symbian and Windows Mobile). Though it is hard to discuss in any detail on the matter without more material on the subject, there are a few things that come to mind.
The creation of a standard architecture for development of games can only lead to good things. Assuming implementations are bug free and conform to specification, developers will not have to worry about re-implementation code for every different platform they come across. The architecture should provide a degree of abstraction from the varying mobile platforms. Things such as native widget and life cycle code would be abstracted from the developer and generalized by the architecture. Porting time across platforms and development costs should be reduced as a result of this common architecture.
There are many benefits of an architecture that is open. Companies directly involved with the development of games have say in the specification. These game developers are the end users of the architecture so they should be driving the requirements of the specification. The architecture should effectively free the game developer from the specifics of a unique vendor. Additionally, the fact that the architecture is open means that no royalties are paid to a governing entity controlling proprietary specification.
The quality, robustness and durability of the specification will also be higher since it is carefully defined from a large working group of industry players; new features of the specification can only be introduced on the consensus of the entire body. This makes it difficult for one specific player to steer the specification in a specific direction. Having said this, extension of the standard is possible and allows for anybody to introduce new features and grow the architecture. This has both positive and negative repercussions. On one hand, it allows for the specification to grow and mature at a faster rate that with a closed specification. Vendors or developers might be able to implement new features and rapidly expose them through an extension to the specification. These extensions may then be considered candidates to be incorporated back into the next revision of the API. Having an API that is flexible allows it to grow and adapt to changing industry needs. This could, however, cause even more fragmentation across devices making harder and more expensive for developers to create games.
Although this standard will help to reduce fragmentation across platforms, the issue will still exist. It will only reduce the problem, as fragmentation due to many other factors will still exist. This includes, but is not limited to:
Device specific API
Device specific Hardware
Device specific memory constraints
Device specific screen sizes
Errors or deviations in platform Implementation
But, all in all, itï¿½s a step in the right direction for the industry.