In WarCry continues its series of developer journals from the folks behind PlayXpert, an in-game browser system. This month's featured writer is Eric Cox, SDK Manager for PlayXpert and the discussion delves into the development cycle. Read on!
Thanks to WarCry for allowing me to share a little about the PlayXpert development process. My name is Eric Cox and I'm the SDK Manager for PlayXpert (and a bit of a BF2-god). Today we dive a bit deeper into the basic ideas driving PlayXpert development. As Charles Manning, our CEO and Fearless Leader, pointed out in the last installment, PlayXpert is an "In-game OS" - its purpose is to blur, or eliminate, the line between in-game and out-of-game for our user community.
We started out with an extremely complex equation: on one side, you have to implement something that can display output in every game, and on the other side you have to implement something to capture the output of every Windows application that gamers might want to use in-game. We chose to implement the former, and ask developers to work with us on the latter (through our API). The library we've created for PlayXpert allows developers to easily port existing applications, or develop new applications that simply weren't possible, or simply not considered, because there was no easy way to display their output where it was needed: in-game. Before PlayXpert, a lot of hobbyist developers, who had a great idea for a gaming-related application, simply decided it wasn't worth it.
Open for Energy, Closed for Safety
Gaming is war. There is a constant struggle between hackers and game publishers: hackers write code to allow them to gain unfair advantage (and ruin the game in the process), and publishers change games to render these tools useless in order to protect honest gamers who just want to play and have fun, and the cycle continues. Although PlayXpert brings widgets in-game, we intentionally limit its capacity to be used to support hacking activities. Examples of this include our TrueOverlay™ system which delivers overlay without cracking into the shared memory of the game (a clear mechanism to hack a game), our network-wide licensing system which allows us to automatically deactivate a widget if it's known to use malicious technology, and finally, our widget api which enables features to widget developers while requiring user opt-in for personal information use.
Keeping It Simple
One of our goals was to make it extremely easy for the average hobbyist developer to create a widget for PlayXpert. By implementing two interfaces and making a few namespace changes in their code, developers can port any existing .NET application to PlayXpert. We'll explore this process in detail in next month's article.