Abstract form

Why make an advergame for Hyzonia?

Posted in Architecture, Business, Coding, Development, Internet by Homam Hosseini on August 14, 2009

We have been working on a few cool features of Hyzonia in the past weeks. Hyzonia is a next generation internet ad service. Like traditional ad services Hyzonia receives advertisements from advertisers and distribute them in websites. But the ad materials in Hyzonia are not in the form of traditional banner or text ads. The ads would be placed inside games, in a way that players would interact and engage with the promoted subjects. This kind of games is being called an advergame. I don’t want to dig into the marketing stuff, but it worths mentioning that one interesting feature of Hyzonia is that it makes it easier for advertisers to utilize the power of advergaming, for less, as Hyzonia is providing a rich set of ready-to-use advergames. Using Hyzonia customers do not need to pay big moneys to interactive software companies to make and host an advergame as part of their online campaign.

We already have built a number of  favorite games, but Hyzonia is extensible by nature, meaning that it is easy to create an advergame for Hyzonia or integrate an already built game into it. Like almost every big web business we know, we found it is crucial for Hyzonia to be extensible and customizable. Hence we spent the last few weeks on making final touches on the first version of our APIs, improving security and testing it all by making sample games.

It’s no myth that most succesful indie developers are game makers. If you have some good ideas, you may find your two-week project shining on the top lists in Xbox Live or Apple Store.

In comparison with those programs, in Hyzonia you will start earning from the moment your game is added in the system. It would be based on a revenue sharing model, so as long as your game is attractive for promoters there would be some campaigns active in some instances of your game and a revenue stream for you. On the other hand contrary to Miniclip or Pogo, Hyzonia is not a single game portal, your game eventually will be displayed in our publishers’ websites. Hyzonia is a service that provides the infrastructure needed for this communication among advertisers, publishers, and developers to happen.

Currently in addition of standard Web Service interfaces we are providing .NET libraries that encapsulate all the basic functionalities that an advergame in Hyzonia platform should support. One exciting news is that you don’t need to make everything from scratch using Hyzonia APIs, but the required functionalities of an advergame in Hyzonia have been designed in a way to make it possible to take virtually any game, wrap it inside a shell (we call Island) and have it added in Hyzonia. The .NET libraries that we are shipping as part of the API have all the functionalities needed by this shell.

Because of its service oriented architecture, Hyzonia advergames (Islands) could be anywhere in the internet. But currently we are only activating the games that have been hosted physically in our datacenters, although exactly like a banner ad (hosted let’s say by DoubleClick) they could be displayed on other websites.

Obviously not any game can be converted into an advergame. This is another issue that we are adderssing it in the guidelines that will be released alongside the APIs.

A thousand words: Hyzonia connects developers, advertisers and websites.

Advertisements

Service Provider Pattern Part II

Posted in Architecture, Coding, Development by Homam Hosseini on May 29, 2009

Read the first part

At first I found it is generally a good advice to store the configuration in a static, read-only property somewhere. And there’s no better place other than the configuraiton class itself:

static MyServicesConfigurationSection _Value;
public static MyServicesConfigurationSection GetValue()
{
   if (_Value == null)
   {
     _Value = (MyServicesConfigurationSection)
        System.Configuration.ConfigurationManager.GetSection("myServices");
   }
   return _Value;
}

Here we assume that we always define the matching element to be “myServices” in the configuration file. It makes sense because it makes it easier for us to find the element in different configuration files. We can always access the value using:

var config = Configuration.MyServicesConfigurationSection.GetValue();

Modularizing is the obvious upgrade we are goging to make to the Service Provider Pattern Part I. I can find three distinct components:

Service-Provider-Pattern-Ar 

  • Service Provider Pattern contains all the logic required by the pattern to work. You alway reference it everywhere you want to use the pattern.
  • Service Definitions is where we define our services.
  • Implementation of the Services contains  concrete classes and implementations of (some of) the services that have been defined in Service Definitions module. In a real application you may end up with many Implementation components each containing the implementation of a one or few number of services.

As before the configuration file of the Host Application maps the definitions (abstract services) to implementations (concrete services).

It’s clear that using this architecture we can have host applications that are hosting different implementations of the services.

Configuring the Services

Till now the only purpose of the configuration file was to store the mapping between the definitions and the implementations. But we can use it in order to actually configure the services. For an example it’s very likely that the FTPFileStorageService that we defined in the previous part, needs a FTP account credential to work. In this case the <add> element (that maps FileStorageService to FTPFileStorageService) may look like:

<add def="MyServiceDefinitions.FileStorageService"
     impl="MyServiceImplementations.FTPFileStorageService,
                                      MyServiceImplementations"
     host="ftp://ftp.wingooli.com" username="wingooloi"
                                         password="password" />

Both the abstract service definition and the concrete implementation can implement IServiceBase interface:

public interface IServiceBase
{
    void Initialize(Configuration.ServiceProviderSettings settings);
}

This interface just has one method, Initialize, that takes a ServiceProviderSettings (the <add> element). We can read the additional attributes of the <add> element using a code like this:

settings.Properties["host"]

The logics in the Service Provider Pattern component automatically call the Initialize method if this interface has been implemented in the definition the  implementation of the service.

Here is the design:

Service-Provider-Pattern

Now our Service Provider Pattern has nothing less than ASP.NET Provider Pattern but it is easier to implement.

Using all these modules we can reduce the code needed to instantiate a service (this code snippet should be placed in the abstract service definition class):

static FileStorageService _Instance;
static object _InstanceLocker = new object();
public static FileStorageService Instance
{
 get {
    if (_Instance == null) {
      lock (_InstanceLocker) {
        _Instance =  ServiceModel.ServicesHelper
                       .GetServiceInterface<FileStorageService>();
      }
    }
    return _Instance;
  }
}

Because it is a repeatable pattern and to make it all more developer friendly, I created a C# code snippet that generates a similar code automatically.

You can download the whole things here.