Board Games for Windows Phone: Combat Intelligence
I was lucky to work in the Sarov Technopark - a secret place on the border of the Nizhny Novgorod region and the Mordovia Reserve, where among the snows and smart girls who are not seduced by the iPhone, a freelance artist, small form master and adept of iOS programming PapaBubaDiop creates his imperishable works.
Here I received the blessing of Pope Buba for playing the spelling, and with it the golden stock of the source codes of the Chapaev and Tower games for the iPhone. All this wealth was obtained under the promise to sow good and eternal in the fields of Android and WP7.
Under Habrokat I cite the history of the development of a small, but actively fertilized by Redmond and Espoov giants of the Windows Phone site. ')
A game
Drafts game Chapaev familiar to many since childhood. One of the virtual incarnations of the game was presented by Pope Buba six months ago. Today I reveal some features of the implementation that set the initial conditions for Chapaev to repeat on the WP7 platform:
A game engine of its own production, easily morphing under each new game;
Using standard user interface elements to build a scene;
Combining the animation performed in the game cycle (movement of the chips after the impact) with the standard animation provided by the SDK (for the initial construction of chips, turning the board or moving the turn).
Windows phone
Since we are supporters of evolution, not revolution, to implement the idea, we chose native Windows Phone programming tools offered by Microsoft. And the task of transferring the game is divided into two parts:
Relaying the physics engine and C # game models
The implementation of the graphical representation of the game using Silverlight
The first subtle point in the implementation of applications for Windows Phone, which had to face, is the need to save and restore the state of the application and its individual pages. The life of a mobile application is short and even innocent screen locking results in the closure of the page, and under certain conditions, it also forces the application out of memory. Unlocking, respectively, returns the application and the active page to its original state. In our case, the state of the page is the state of the game, including the location of the checkers and the animation performed.
Further, in spite of the substantial simplification of the developer’s life due to the predefined screen resolution for all Windows Phone devices, it was decided to distinguish the virtual size of the playing field and the actual screen resolution. As a tribute to Pope Bube, the coordinate system of the game model is aligned with the iPhone screen. In the future, a network game will live in the same coordinate system.
C #
Relaying the code of the physical model and the game model has basically come down to replacing the syntax constructs of calling functions and constructing objects in Objective-C, apart from combining the declaration and defining the class methods into a single source code file.
As a result, due to the simplicity of the language constructions used and the similarity of the C # and Java languages, the resulting model code can be used by 98% when porting the application to Android. One intolerable percentage is the names of the functions of the Windows Phone SDK, the second percentage is the properties of the class. And, if you can get rid of platform-dependent names by wrapping them in adapters, then it was unreasonable to refuse to use properties.
Properties greatly simplifies the task of saving and restoring the game state, as required by the application life cycle. The following piece of code defines the element of the game "checker" and its properties:
publicclassCheckerItem { publicint color { get; set; } publicdouble x { get; set; } publicdouble y { get; set; } }
The game uses a set of checkers:
publicclassGameObject { public CheckerItem[] checkers; }
And this is how the state of the game is saved in the application's isolated storage:
settings.TryGetValue<CheckerItem[]>("checkers", out checkers);
Silverlight
For a graphical representation of the game state and configuration dialogs, the choice was made in favor of Silverlight. The main reason to use a non-gaming framework for a gaming application was the desire to write the application in Metro style as much as possible. Yes, and the gameplay did not imply serious loads on the processor, which was later confirmed experimentally - the performance counters did not have to blush for choosing a framework.
However, the case did not go without stepping on a rake.
To implement the sound effects in the game, the SoundEffect class from the XNA toolkit was used, which required connecting the XNA Framework and “manually” turning the XNA game cycle. But the saddest thing turned out after the publication: instead of the main menu of the phone, the application from the store is located in the Xbox Live section. I hope the user has enough desire and goodwill to find it there after installation.
Another surprise was the global touch processor for the entire application. It turned out that once registered event handler will continue to exist and after closing the game page, it will gladly respond to tapes through the settings page, for example. Solution one: minus the event handler when leaving the page.
In addition, for my case, it was necessary to stop the animations when leaving the page to synchronize with the state of the game, since leaving the page does not always mean its destruction, and the return is possible bypassing the page constructor.
Marketplace Publishing
The review cycle of an application in the Windows Marketplace is experimentally defined as 4 business days, there is no movement on weekends. Moreover, consideration of the repeated application after correction of the comments lasts all the same four days.
From the moment of approval to the beginning of the direct link to the application, it took at least another day, and an additional 10-12 hours were needed for indexing inside the store. After that, the application began to appear in the search results.
Thus, the minimum time required to publish an application is 5 days, provided that the application is perfect and the application is sent on Monday.
The application review procedure is supplemented with a funny intrigue - the message about the refusal to publish is delivered by mail, but the reason for the refusal can only be found in the pdf report that needs to be received through the AppHub portal. The system is slim, but in practice it is not at all easy to do this with the help of a phone, getting ready for work at 7 am
The result of the work can be estimated on the video (thanks to Tolik from the well-known trading network for providing the Nokia 710):