Development of the client part of the game for Windows 8

Good day. Trying to read materials about the development of games anywhere did not meet figures on the development time, due to the complexity and material means. This wants to talk about our experience. Of course, one can speak of complexity only subjectively, but the connection with time will still be traced. Everyone will be able to highlight the ratio of communication, briefly review the application and article. I draw your attention, the conversation will focus exclusively on the client side, the server part is pre-prepared, covered with tests, and for some time worked with clients on other platforms. But not without minor changes to the server part, which will benefit her.

Initially, there were four people, a server, a bit of cash and an abstract plan in my head. Development experience, on the Windows 8 platform, none of us had, so we quickly read the literature on the topic: Windows 8, C #, .Net. Two days later, we were ready to begin development, having received enough information about the structure of Metro applications, and our overall experience with .NET affected. Then two began to engage in prototyping and experimenting with the platform, which in the future gave the necessary answers in the shortest possible time. At the same time, the first work schedule was drawn up, and the last person was constantly looking for a designer who could take up work with us. Everything lasted about 13–15 days, during which time the sketches of the parts of the game were jointly evaluated, each sketch was tried to adequately, from our point of view, pay. The designer himself chose what he could and for how long we could imagine; for this, he had a game at his disposal that used HTML and JS as its basis. The cost of sketches ranged from 1,000 to 2,000 rubles, a total of 4 sketches were considered. As a result, we chose a layout, got time in 2 months to create everything and cost about 40,000 rubles for the whole design. It is worth noting that there were applicants with prices from 100,000 rubles, which did not suit us. Further, according to the compiled TZ, the designer sent the elements, and we decided whether they were suitable or not. Each element was cut into pieces and fitted into the XAML markup by the developers, the designer used only a graphic editor, without touching Blend.



The server part consists of a set of WCF services that use the wsHttpBinding binding. Services are deployed based on Windows Service in the Windows 2008 R2 environment. Since the HTML client was previously used, the MVC .NET application solved all the issues with authentication and authorization, and the service accepted it as a trust. Here, the use of such an approach was superfluous and difficult, as Metro applications can interact with WCF services directly, although they require the use of certificates and basicHttpBinding. The test certificate was successfully installed on the development machines and tied to the port used by WCF, and a real certificate was also received for publication. The result was such an instruction for developers:
')

• Get a certificate and import it;
• Run cmd and view the ports with the assigned certificates: netsh http show sslcert, check that the required addresses do not have a certificate before us, we need port 8734 ie entries: 0.0.0.0:8734;
• Add an entry with the parameters of the certificate imported in the first step: netsh http add sslcert ipport = 0.0.0.0: 8734 certhash = HashCertificate value appid = {GUID}. The hash value of the tag is taken from the "Fingerprint" field of the certificate on the "Composition" tab, entered without spaces. Next, you need to check the availability of the record by repeating the second paragraph.

The authentication issue was resolved by implementing a heir from UserNamePasswordValidator and using a Windows Live ID. The resulting validator has been added to the app.config services.

<behaviors> <serviceBehaviors> <behavior name="Security"> <serviceCredentials> <userNameAuthentication userNamePasswordValidationMode="Custom" customUserNamePasswordValidatorType="Thisislogic.XGame.Service.Common.SecurityManager, Thisislogic.XGame.Service.Common" /> </serviceCredentials> </behavior> </serviceBehaviors> </behaviors> 

The validator understands, using the secret key of the Live ID service, a user ID and a conclusion is given whether the service is allowed or not.

 public class SecurityValidator : UserNamePasswordValidator { private const string LiveSecretClientKey = "My_Secret_Key"; public override void Validate(string userName, string password) { try { if (string.IsNullOrEmpty(userName) || string.IsNullOrEmpty(password)) { throw new Exception("User or Password not set"); } var d = new Dictionary<int, string>(); d.Add(0, LiveSecretClientKey); var jwt = new JsonWebToken(password, d); var jwtUserName = jwt.Claims.UserId; if (jwtUserName != userName) { throw new Exception("Manipulated Username"); } } catch (Exception e) { var fe = new FaultException("Unknown Username or Incorrect Password \n" + e.ToString()); throw fe; } } } 

Later, authentication based on a unique user ID was added, without the participation of a Live ID. Below is one of the options for obtaining a unique user ID.

 private string GetHardwareId() { var token = HardwareIdentification.GetPackageSpecificToken(null); var hardwareId = token.Id; var dataReader = DataReader.FromBuffer(hardwareId); var bytes = new byte[hardwareId.Length]; dataReader.ReadBytes(bytes); return BitConverter.ToString(bytes); } 

By the time the designer was agreed, the plan for using the services, the end of the prototyping, the decomposition of the works and the approximate terms, many of which were repeatedly revised afterwards, matured. The plan was drawn up using MS Project and the Work Items subsystem in TFS 2010. All tasks were distributed to TFS, at the end of each working day they received updates from TFS to the plan and looked at what should be changed.


We used TFS as a common point of interaction between code, documents, and tasks. Some discussions took place in Skype, but most of it was held in person. The code was written together by two or more developers, which made it possible to quickly spread a new MVVM approach for us, with the same understanding. Here, the Kind of Magic plugin helped us a lot, which made it possible not to write tons of code with INotifyPropertyChanged.

 [MagicAttribute] public abstract class PropertyChangedBase : INotifyPropertyChanged { protected virtual void RaisePropertyChanged(string propName) { var e = PropertyChanged; if (e != null) { SmartDispatcher.BeginInvoke(() => e(this, new PropertyChangedEventArgs(propName))); } } [MethodImpl(MethodImplOptions.NoInlining)] protected static void Raise() { } public event PropertyChangedEventHandler PropertyChanged; } 

The application architecture mainly depended on the fact that the server part already exists. It all came down to the fact that the game process takes place entirely on the server, the client only, at a certain interval, requests data from the server and processes it, sending responses. The following event terminology was adopted: server and client, and the server never accesses clients, the basicHttpBinding binding does not imply duplex. Working with XAML was partially familiar with Silverlight and WPF technologies, but the main experience was with Windows Forms and ASP MVC. The main time was spent on working with the code and adapting the design, about 2 months. Writing code and related questions did not differ much from other projects. It does not make sense to talk about bindings, validation, async-await. After the end of development, we published a game in the Windows Store .

As a result, a summary table of results:

Activity	Time	Money
Training	7 days	10,000
Room rental and technical expenses	3 months	35,000
Design	3 months	40,000
Initial sketches	15 days	6500
Salary	2 months	50,000
Total		141500

Total spent about 141500 rubles and 3 months of work.