Development of the client part of the game for Windows 8

Good afternoon. Trying to read materials on the development of games, I never met figures on the time of development, due to complexity and material means. I would like to talk about this in our experience. Of course, one can talk about complexity only subjectively, but the connection with time will still be traced. Everyone will be able to identify the connection coefficient by skimping through the application and article. I draw your attention, the conversation will be exclusively about the client part, the server part is ready in advance, covered in tests and for some time worked with clients on other platforms. But it will not do without small changes to the server side, which will benefit it.

Initially, there were four people, a server part, some cash and an abstract plan in my head. None of us had any development experience on the Windows 8 platform, so we hurriedly read literature on the topic: Windows 8, C #, .Net. Two days later, we were ready to start development, having received enough information about the structure of Metro applications, the general experience with .NET affected. Then the two began to engage in prototyping and experiments with the platform, which in the future gave the right answers as soon as possible. In parallel, the first work schedule was drawn up, and the last person was constantly looking for a designer who could take up work with us. It lasted about 13-15 days, during which time the submitted sketches of the parts of the game were jointly evaluated, each sketch was tried to pay adequately, from our point of view. The designer himself chose what he can and for how long to present to us, for this he had at his disposal a game that used HTML and JS as its basis. The cost of the sketches ranged from 1000 to 2000 rubles, a total of 4 sketches were considered. As a result, we chose a layout, got a time of 2 months to create everything and a cost of about 40,000 rubles for the entire design. It should be noted that there were applicants with prices from 100,000 rubles, which did not suit us. Further, according to the compiled TOR, the designer sent the elements, and we decided whether they fit or not. Each element was cut into pieces and adjusted in the XAML markup by developers, the designer used only a graphical editor, without touching Blend. The cost of the sketches ranged from 1000 to 2000 rubles, a total of 4 sketches were considered. As a result, we chose a layout, got a time of 2 months to create everything and a cost of about 40,000 rubles for the entire design. It should be noted that there were applicants with prices from 100,000 rubles, which did not suit us. Further, according to the compiled TOR, the designer sent the elements, and we decided whether they fit or not. Each element was cut into pieces and adjusted in the XAML markup by developers, the designer used only a graphical editor, without touching Blend. The cost of the sketches ranged from 1000 to 2000 rubles, a total of 4 sketches were considered. As a result, we chose a layout, got a time of 2 months to create everything and a cost of about 40,000 rubles for the entire design. It should be noted that there were applicants with prices from 100,000 rubles, which did not suit us. Further, according to the compiled TOR, the designer sent the elements, and we decided whether they fit or not. Each element was cut into pieces and adjusted in the XAML markup by developers, the designer used only a graphical editor, without touching Blend. according to the compiled TK, the designer sent the elements, and we decided whether they fit or not. Each element was cut into pieces and adjusted in the XAML markup by developers, the designer used only a graphical editor, without touching Blend. according to the compiled TK, the designer sent the elements, and we decided whether they fit or not. Each element was cut into pieces and adjusted in the XAML markup by developers, the designer used only a graphical editor, without touching Blend.

Design

The server part consists of a set of WCF services using the wsHttpBinding binding. Services are deployed based on Windows Service in the environment of Windows 2008 R2. Since the client was previously used in HTML, all issues with authentication and authorization were resolved by the MVC .NET application, and the service accepted it as trusted. Here, the use of this approach was redundant and complicated, 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 developers' machines and tied to the port used by WCF, as well as a real certificate was received for publication. The following instruction for developers turned out:

  • Get the certificate and import it;
  • Run cmd and look at the ports with the certificates assigned: netsh http show sslcert, check that the certificate is not specified on the addresses you need, we need port 8734 i.e. Records: 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 = CertificateHashCertificate value appid = {GUID}. The tag hash value is taken from the "Fingerprint" field of the certificate on the "Composition" tab, is entered without spaces. Next, you need to check the availability of the record by repeating the second paragraph.

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



The validator understands, using the secret key of the Live ID service, the user identifier and gives a conclusion 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();
            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 was added based on a unique user ID, without the participation of a Live ID. Below is shown 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 approved, the plan for using the services, the end of the prototyping, the decomposition of the work and the approximate dates were ripe, many of which were repeatedly reviewed after. The plan was drawn up using MS Project and the Work Items subsystem in TFS 2010. All tasks were distributed on TFS, at the end of each working day they received updates from TFS to the plan and looked at what should be changed and how.
Initial project schedule

As a common point of interaction between code, documents and tasks, we used TFS. Some discussions took place on Skype, but most were held in person. The code was written together by two or more developers, which allowed us to quickly spread the new MVVM approach for us, with the same understanding. Here the Kind of Magic plugin helped us a lot, which allowed us 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 architecture of the application 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, with a certain interval, requests data from the server and processes them, sending responses. The terminology of events was adopted: server and client, while the server never accesses clients, the basicHttpBinding binding does not imply duplex. Working with XAML was partially familiar with Silverlight and WPF technologies, but still the main experience was with Windows Forms and ASP MVC. The main time, about 2 months, was spent working with code and design adaptation. Code writing and related issues were no different from other projects, talking about bindings, validation, async-await does not make sense. After the development is complete, we published inWindows Store game .

As a result, a summary table of results:

ActivitiesTimeMoney
Training7 days10,000
Rental of premises and technical costs3 months35,000
Design3 months40,000
Initial sketches15 days6500
Salary2 months50,000
Total141500


Total spent about 141,500 rubles and 3 months of work.

Also popular now: