Forgot password
Enter the email address you used when you joined and we'll send you instructions to reset your password.
If you used Apple or Google to create your account, this process will create a password for your existing account.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Reset password instructions sent. If you have an account with us, you will receive an email within a few minutes.
Something went wrong. Try again or contact support if the problem persists.

PlayXpert: Diving into Development

This article is over 15 years old and may contain outdated information

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!

image

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.

Recommended Videos

To Infinity…

In keeping with our concept of PlayXpert as a platform, PlayXpert aims to offer the developer an assortment of tools and game-related information. PlayXpert widget developers have access to the entire .NET framework, so they can call on all of the services they are familiar with. In addition, PlayXpert currently offers simple gaming-related services, such as the ability to see if the user is in-game or out-of-game, what game they are playing, what friends are doing, and related widgets that are being used (to name a few).

Another important facility in the API is the ability to store widget settings on behalf of the developer. This means that any configuration, user preferences, and history information will follow the player to whatever machine they happen to be playing on. For instance: a user playing on his or her laptop at a friend’s house, changes their key binding settings, then goes home, launches PlayXpert on a desktop machine, and the key bindings are set. The widget developer has the ability to decide if a given piece of information should be stored on the server, or on the local machine, depending on the nature of the information being stored.

…and beyond!

For the future, we’re working on more advanced services, such as widget-to-widget communication, to allow widgets installed on one user’s machine to communicate and share information over the network to the same widget installed on another user’s machine. We anticipate very cool widgets developed by the community that push the envelope of community and collaboration. Imagine a white board widget, a webcam widget, or even a coordinating map or guide widget for a game… These are all things that end up being very useful to users and really fun to build!

Next month, we’ll explore the basics of what it takes to make a PlayXpert widget.

Learn more about the PlayXpert system at http://www.playxpert.com


The Escapist is supported by our audience. When you purchase through links on our site, we may earn a small affiliate commission.Ā Learn more about our Affiliate Policy