Show Developers the Money

In late November 2010, approximately one month after the launch of the App Hub website, two major criticisms were reported by the developer community towards the Windows Phone Marketplace:

No App Hub store analytics No payouts until Feb 2011

No App Hub store analytics
Initially, the App Hub did not provide developers with store analytics to indicate how many titles they had sold. One potential explanation for the missing functionality related to sales data in the App Hub was:
An intentional effort to avoid any leaks of hard data that may indicate poor sales of Windows Phones 7 devices.

Fortunately, store analytics are now available on the App Hub.
In fact, there are two main types of reports:

Graphical view of daily and cumulative downloads plus raw data break-downs Payout Reports with aggregated and detailed views of Marketplace payouts

No payouts until Feb 2011
The App Hub supports quarterly payouts for all sales of Xbox LIVE Indie Games. The minimun threshold is $150: if this target is not reached within the quarter then all sales are rolled over into the next quarter.

The App Hub also supported quarterly payouts for all sales of Windows Phone apps upon launch in October 2010. The minimum threshold is $200, however. As Microsoft allows up-to-45 days to payout, this meant there would be no payouts until Feb 2011.

The announcement: no payouts until Feb 2011, prompted much concern from the developer community, categorizing: Windows Phone 7 development as a hobby or a learning experience rather than a source of revenue until the App Hub issues are sorted out.
Hardly the response Microsoft were targeting after spending $500m on the Windows Phone ad campaign!

Fortunately, there has been an update: the first payout will be in Jan 2011 for all sales of Windows Phone apps in Qtr-IV 2010. After Jan 2011, developer payouts will be processed on a monthly basis for all sales of Windows Phone apps that meet the minimum payout threshold limit.

Going forward, there is an opportunity to align monthly payouts for all sales of Xbox LIVE Indie Games. Another option would be to consolidate monthly sales figures for all platforms: if total sales accumulated across all platforms meet the minimum payout threshold limit then payment should be made.

Example
Developer has published two games: one on Windows Phone and one on Xbox LIVE Indie Games:

Monthly sales on WP7 Marketplace = $100 Monthly sales on Xbox Marketplace = $100

Currently, the developer would not be eligible for an end-of-period payout on either platform.
However, if there was an option to consolidate total sales then payment would be made.

In conclusion, the App Hub does have potential. In fact, Microsoft has announced over 15,000 developers have registered for Windows Phone development since the launch. There are also whispers that XNA will eventually provide Kinect API support in the future as well.

Therefore, there are encouraging signs that should hopefully increase the number of applications and the quality of games available for sale on the App Hub, which in turn, generate more revenue for developers.

XNA Creators Club now the App Hub

In October 2010, Microsoft re-branded the XNA Creators Club website to the App Hub. The new website continues to support Xbox LIVE Indie Games as before, but now includes support for Windows Phone development.

All existing XNA Creators Club memberships have been migrated to App Hub annual subscriptions: they function as before however, independent game developers can now submit "apps", that is, apps and games to the App Hub for sale or free download in the Windows Phone Marketplace.

Therefore, the focus from Microsoft is now clearly on the Windows Phone.

All App Hub subscribers must activate their account and complete the following registration tasks:
Verify your email address
Subscribers new to the App Hub will need to register an account to verify email address. Existing XNA Creators Club members can simply verify email address from the My Apps page.

Publisher Identity Verification
Developers require a process to authenticate their identity. Identification validation is the process to ensure developers within the Windows Phone Marketplace are authentic. This protects from someone assuming their identity while also maintaining end-user trust.

Important: identity validation must be complete before developers can unlock Windows Phone devices, deploy apps to the phone, and submit to the App Hub for certification testing.

Microsoft partners with GeoTrust whom provide identity verification services. On Microsoft's behalf, GeoTrust will contact the developer during the identity validation process. Developers outside the U.S. are required to complete a GeoTrust form that includes a copy of government issued photo identification and the developer's signature. Once identity is confirmed, GeoTrust will issue a unique digital certificate; the App Hub uses the digital certificate to sign all applications published by the developer.

New subscribers to the App Hub should experience smooth transition here: after verifying email address, GeoTrust will contact the developer and begin the Publisher Identity Verification process.

However, existing XNA Creators Club members may find the Publisher Identity Verification process confusing and frustrating: after verifying email address, the App Hub displays the following message:
This message is misleading and incorrect: as existing XNA Creators Club memberships are migrated to App Hub subscriptions, no new details are sent to GeoTrust. Therefore, GeoTrust has no knowledge of existing members, thus no contact is made. Meanwhile, the developer will wait indefinitely for GeoTrust to contact them, as per the App Hub message!

Fortunately, there is a workaround this issue for existing XNA Creators Club members:

Create dummy app Submit dummy app Upload capabilities Follow steps: description, artwork, pricing Before submitting, uncheck the Automatically Publish to the Marketplace This will ensure that the dummy app is not published!

Submitting a dummy app should initiate contact from GeoTrust. From there, GeoTrust will request documentation from the developer, as required, in order to complete Publisher Identity Verification.

Unlock your phone
Once publisher identity verification is complete, Windows Phone device(s) can be unlocked:

Download and install the latest Zune software Connect Windows Phone to the computer Launch Zune software and synch phone Start Menu, Programs, Windows Phone Developer Tools, Registration Enter Windows Live ID, password and click "Register"

Status: Your phone has successfully been registered.
Apps can now be deployed to Windows Phone.

Eligibility for Payout
While this step is not required to unlock the device, developers must provide bank and tax information
to ensure payment is made from the sales of apps on Windows Phone Marketplace.

Navigate to Payee Details. For all subscribers, the App Hub currently displays the following message:
New subscribers to the App Hub must submit the relevant Form W-8 tax form to Microsoft.
Pls read this post for more information.

However, existing XNA Creators Club members may find this message very confusing, especially if they have previously submitted Form W-8 and their Xbox LIVE business information status is as follows:
"W8 Form processed. Ready to be paid."

As of the time of this writing, Microsoft has issued the following statement:

I have confirmed with internal authorities that the commerce mechanisms are now integrated. You only need to set up the W8 once for your account, and then it will work for all the technologies supported in the App Hub.

Also, the bottom of the Payee Details page states:
This assumes the VAT identification number is optional. However, developers are currently unable to save their bank and tax information: when the VAT textbox is left blank, the following error is displayed:

Fortunately, Microsoft has acknowledged this issue and confirmed a fix in the next update release.

In conclusion, the App Hub launch has caused much confusion and frustration for developers:

apps cannot be deployed until Publisher Identity Verification is complete tax status is inconsistent across Windows Phone and Xbox technologies bank and tax information cannot currently be saved on the website

Note: to be correct, some developers have reported the ability to hack bogus VAT identification number in order to successfully save their bank and tax information, although this does not seem appropriate.

On a brighter note, there are encouraging signs for games on Windows Phone and paid games are a hit on the device: games occupy the Top 10 slots in the Windows Phone Marketplace; good news for independent game developers whom wish to publish on both Windows Phone and Xbox platforms.

Hopefully the App Hub experience will also improve once these issues have been resolved.

Back in Five Minutes

XNA is an exciting technology that allows independent game code to be developed and deployed to Windows, Xbox 360, and Zune.

In 2009, I developed Henway using XNA. The game was approved and published on the Indie Games area of Xbox LIVE Marketplace.

I also setup this blog to highlight some of the issues encountered during XNA game development, potential solutions to these issues, and to provide a general discussion on XNA.

Here is a quick summary of some of the previous discussions on the site:

Design patterns: Abstract Factory, Command, State, Template Method Performance monitoring and testing TAX forms to submit to get paid Henway game publication

XNA is currently at version 3.1, which includes extensions for the Zune HD device. However, version 4.0, scheduled for release later in 2010, will be compatible with Visual Studio 2010 and .NET Framework 4.0.

The big news from Microsoft however, is that XNA 4.0 will target the Windows Phone 7 mobile device: provide full 3D graphics support and tight integration with Xbox LIVE Marketplace.

Therefore, independent game code could now target the same marketplace on both a gaming console and mobile device within a single deployable code base. XNA 4.0 could create some very interesting opportunities, difficult to challenge by competitors in the gaming console and mobile device space.

In conclusion, I would like to take a break from regular monthly blog posts to get more info on XNA 4.0 and begin working on the next game project.

If I'm not back in five minutes, just wait longer J

XNA and TAX

Once your game has been approved and published on Xbox LIVE Marketplace, it will be available for sale to all regions that can purchase Xbox LIVE Indie Games.

All download history and purchase information can be found in the My Business section of the XNA Creators Club web site. However, in order to get paid, you will need to submit your personal and tax information.

If you are an independent game developer and a non-U.S. based creator then the task of processing your personal and tax information can be very challenging. Therefore, this blog post attempts to shed some light on the process, and ensure payment is made from the sales of Xbox LIVE Indie Games.

Note: I am not a tax advisor; pls do not read the following as defacto or proven advice.

Process
In order to get paid, creators must enter their personal and banking information on the XNA Creators Club web site and submit the relevant Form W-8 tax form to Microsoft.

Note: there are four types of W-8 forms available on the Internal Revenue Service (IRS) web site;
Form W-8BEN is the most frequently submitted form: I will refer to this as Form W-8 from now on.

Independent game developers who are non-U.S. based creators, may be eligible for a reduction or exemption from U.S. income tax on their revenue, provided their country has a tax treaty with the U.S.
If this is the case, then you may be able to take advantage, providing you have a relevant Individual Taxpayer Identification Number (ITIN) and submit a properly completed treaty claim on Form W-8.

It appears this is the most difficult and confusing part of the tax process for independent game developers who are not based in the U.S.:

You must determine if your country has a tax treaty with the U.S., and You must decide if you would like to take advantage of the tax treaty

Determine if your country has a tax treaty with the U.S.
Navigate to the United States Income Tax Treaties page on the IRS web site. If your country is listed then your country has a tax treaty with the U.S.

Decide if you would like to take advantage of the tax treaty
If your country has a tax treaty with the U.S. then you may like to take advantage in order to claim a reduction in U.S. income tax. Therefore, you must apply for an ITIN and submit a properly completed Form W-7 to the IRS.

Note: an ITIN is not strictly required to get paid, although without it you will be subject to an automatic 30% U.S. tax withholding, even if your country provides a lower rate of U.S. taxation.

Important: the process of applying for an ITIN alone can take weeks / months and it is easy for the ITIN application to be rejected by the IRS if Form W-7 is not completed perfectly.

To summarize, in order to get paid, you must complete the following tasks:

Enter your personal and banking information Submit the relevant tax form(s)

Enter your personal and banking information

Login to the XNA Creators Club web site Navigate to the My Business section Click the link to Personal and Tax Information Enter all relevant personal information Enter all relevant banking information Confirm

When you enter your personal information, you have the option to agree to the 30% U.S. tax withholding:
If your country does not have a tax treaty with the U.S., or you decide not to take advantage of the tax treaty, then leave U.S. Tax Identifier blank and check the box. If / when you have obtained an ITIN, you can enter this as the U.S. Tax Identifier and leave the box unchecked accordingly.

After entering your personal and banking details, a confirmation panel similar to the following will appear:
The panel states you will now need to submit a physical copy of your Form W-8 tax form to Microsoft.
The panel may also state which particular Form W-8 tax form you need to send, e.g. Form W-8BEN.

Submit the relevant tax form(s)
When you submit the relevant tax form(s), you have 3x options available:

Option Submit Form W-8 without ITIN Option Submit Form W-7 to obtain ITIN Submit Form W-8 with ITIN Option Submit Form W-8 without ITIN Submit Form W-7 to obtain ITIN Submit Form W-8 with ITIN

Submit Form W-8 without ITIN
Option 1: you cannot claim a tax treaty with the U.S or you choose not to take advantage of the tax treaty because the effort to obtain an ITIN is too time consuming, too difficult, or you cannot wait.

Complete Form W-8 as per the instructions. There is also an informative post on the XNA Creators Club web site:

Simply complete Part I, III and IV Check 3. Type of beneficial owner as Individual Leave 6. U.S. taxpayer identification number blank Do not complete Part II as you are not claiming a tax treaty benefit

Send Form W-8 to:
Microsoft
Attn: Finance Department,
29011 Commerce Center Drive,
Valencia, CA 91355
USA

Submit Form W-7 to obtain ITIN / Submit Form W-8 with ITIN
Option 2: your country has a tax treaty with the U.S. and you would like to take advantage in order to claim a reduction in U.S. income tax.

Download and print the latest Form W-7. Follow the instructions carefully (recommended).
Remember: if Form W-7 is not completed perfectly then your ITIN application will be rejected by the IRS.

Form W-7
As an independent game developer, you will be claiming royalty income from Microsoft. Therefore, a good example on how to complete Form W-7 can be found on Pg. 27 of IRS Publication 1915:
When you check box (a). Nonresident alien required to obtain ITIN to claim tax treaty benefit with a foreign country, also check box (h). Enter "Exception 1(d) – Royalty Income" on the dotted line next to box (h). Also, enter treaty country, which is your country of residence, and treaty article number 12.

Note: to confirm the correct treaty article number:

Navigate to United States Income Tax Treaties Click your country link e.g. Ireland Click the Income Tax Treaty link Search for "Royalties" in the Table of Articles; it should be Article 12

Important: Form W-7 line instructions state "Enter N/A (not applicable) on all lines that do not apply to you. Do not leave any lines blank". Also remember all dates must be month / day / year format.

Documentation: as Microsoft is the withholding agent, you will need to complete and attach the following letter. You will also need to send identification document(s). If you submit an original valid passport (or a notarized or certified copy of a valid passport), then you do not need to submit any other documents.

Send Form W-7, letter from Microsoft, and proof of identity to:
Internal Revenue Service
Austin Service Center
ITIN Operation
P.O.Box 149342
Austin, TX 78714-9342
USA

Once you obtain an ITIN, you can now complete Form W-8 as per option 1. However, this time enter your ITIN on line 6. U.S. taxpayer identification number and check box SSN or ITIN accordingly.

You must also complete Part II Claim of Tax Treaty Benefits: Check box (a). and enter your country on the dotted line. Also, check box (b) as the U.S. taxpayer identification number is stated on line 6.

Finally, on line 10. Special rates and conditions, there is an informative post on the XNA Creators Club web site (excerpt):
The beneficial owner is claiming the provisions of Article 12 of the treaty identified on line 9a above to claim a 0% rate of withholding on (specify type of income): Royalties. Explain the reason the beneficial owner meets the terms of the treaty article: I am a XXXX citizen and resident of XXXX receiving royalties from U.S. source.

Send Form W-8 to:
Microsoft
Attn: Finance Department,
29011 Commerce Center Drive,
Valencia, CA 91355
USA

Submit Form W-8 without ITIN / Submit Form W-7 to obtain ITIN / Submit Form W-8 with ITIN
Option 3: although you can claim a tax treaty benefit, you would like to get paid immediately: Submit Form W-8 without ITIN as per option 1. and ensure payment is made from the sales of Xbox LIVE Indie Games.

Next, submit Form W-7 to obtain ITIN as per option 2. While you ITIN application is being processed, or if your ITIN application is rejected and you need to start over, you will still continue to get paid regardless. When your ITIN is approved, submit Form W-8 with ITIN as per option 2.

Option 4
Finally, if you are new to XNA game development, there may be one other option worth considering: submit Form W-7 immediately. By the time your game is published you would (hopefully) have obtained the ITIN.

Therefore, you could enter your personal and banking information on the XNA Creators Club web site: Enter the ITIN as the U.S. Tax Identifier, leave the 30% U.S. tax withholding box unchecked, and submit Form W-8 with ITIN from the outset.

Remote Performance Monitor II

In the previous post, we began a discussion on the XNA Framework Remote Performance Monitor. To recap, the Remote Performance Monitor exposes 2x common game code scenarios that unnecessarily generate garbage on the XNA platform:

1. Unnecessary string object creation
2. Unnecessary boxed value types

In the previous post, we discussed the first scenario: Unnecessary string object creation. Now, let's complete this discussion with the second scenario: Unnecessary boxed value types.

Unnecessary boxed value types
In a typical game, there are often enemies to kill, obstacles to avoid, gems to collect etc. Usually game code stores, for example, a list of enemy sprites to kill, in one collection variable:

IList<Sprite> Enemies { get; set; }

During game play, game code may need to iterate through the list of enemy sprites every single frame to invoke the Update() and/or Draw() methods accordingly. In .NET, iterating through an IList<T> can typically be done either using the for statement or the foreach.

Code Optimization Demos measure the performance of the for statement compared to the foreach: the for statement is generally more performant although the foreach statement provides better readability in code. However, if used incorrectly, the foreach statement can unnecessarily generate garbage, impact performance and potentially drop frames.

Let's check out an example using the foreach statement in more detail.
Consider the following Sprite class:

public class Sprite()
{
 public Sprite()  {}  // ctor.
 public void Update(GameTime gameTime) {}
 public void Draw(GameTime gameTime) {}
}

As above, game code may store, for example, a list of enemy sprites to kill, in one collection variable and construct the collection accordingly:

IList<Sprite> Enemies { get; set; }
Enemies = new List<Sprite>();

During game play, game code may iterate through the list of enemy sprites and update each sprite accordingly:

public void Update(GameTime gameTime)
{
 foreach (Sprite Enemy in Enemies)
 {
  Enemy.Update();
 }
}

The previous game code snippet may seem harmless enough, however, the Remote Performance Monitor reveals a single managed object allocated on the heap and a single value type is boxed every single frame. When game code executes this Update() method at 60fps then 60x value types are boxed every second:


What happened? Why is this simple game code snippet generating so much garbage?

The problem begins with our collection variable declaration: the collection is declared as an IList<T> but game code actually constructs a new List<T>.

IList<Sprite> Enemies { get; set; }
Enemies = new List<Sprite>();

The problem then manifests itself with the foreach statement: the foreach statement requires an enumerator to iterate through each enemy sprite in the list.

foreach (Sprite Enemy in Enemies)
{
 Enemy.Update();
}

In .NET, both List<T> and IList<T> implement the IEnumerable<T> interface. The IEnumerable<T> interface has one method: GetEnumerator(), which returns the enumerator required to iterate through each object in the list.

However, the implementation of the GetEnumerator() method differs between List<T> and IList<T>: List<T> GetEnumerator() method returns Enumerator<T>, which is a struct: a value type stored on the stack. Whereas IList<T> GetEnumerator() method returns IEnumerator<T>, which is an interface, a reference type stored on the heap.

Therefore the previous game code snippet initially returns an Enumerator<T>, as a value type for the List<T>, but then boxes the enumerator value type to a reference type because the collection is actually declared as an IList<T>!

Therefore, there are 2x potential solutions to resolve this issue with Unnecessary boxed value types:

1. Update the collection variable declaration to List<T>
2. Replace foreach with the for statement altogether

The first solution simply updates the collection variable declaration thus no boxing will be necessary:

List<Sprite> Enemies { get; set; }
Enemies = new List<Sprite>();

foreach (Sprite Enemy in Enemies)
{
 Enemy.Update();
}

The second solution simply replaces the foreach with the for statement thus no enumerator will be required:

IList<Sprite> Enemies { get; set; }
Enemies = new List<Sprite>();

for (Int32 index = 0; index < Enemies.Length; index++)
{
 Enemies[index].Update();
}

Either way, the results in the Remote Performance Monitor are the same:


To summarize, when using an object in which Enumerator<T> is a value type, like List<T>, game code can employ either the foreach or for statement and not generate garbage. When using an object in which IEnumerator<T> is a reference type, like IList<T>, the foreach statement may generate garbage whereas the for statement will not.

In conclusion, the XNA Framework Remote Performance Monitor a simple tool to detect if game code is generating garbage on the XNA platform. Typically, there are 3x static statistics that require the most attention during performance testing:

• Managed String Objects Allocated
• Managed Objects Allocated
• Boxed Value Types

However, there is also one final statistic that is important to monitor: "Exceptions Thrown". In a perfect game, the "Delta" column in the Remote Performance Monitor will be zero at all times.

Remote Performance Monitor

Performance is critical in game development. In XNA, game performance will degrade if you allow garbage to be generated during game play. On Xbox 360, generating too much garbage will force full garbage collection. If garbage collection takes longer than 1/60th of a second then the game will drop frames, and the more frequently full garbage collection occurs, the more frequently the game will drop frames.

The XNA Framework Remote Performance Monitor is a simple tool that can detect if game code is generating too much garbage. Here is a common work flow to game development and performance testing using the Remote Performance Monitor:

• Write game code on Windows
• Test game play on Windows
• Deploy game code to Xbox 360
• Launch Remote Performance Monitor
• Start game from Remote Performance Monitor
• Monitor performance results
• Resolve performance issues as necessary
• Repeat process

Here is a quick tutorial on how to use the XNA Framework Remote Performance Monitor if you have never used the tool before.

There is a large source of information available on the Internet, in the form of blog posts, audio casts, articles and white papers that gives detailed analysis on all the statistics generated from the Remote Performance Monitor; from Pinned Objects to Platform Invoke Calls.

However, in my experience, there are typically 3x statistics that require the most attention during performance testing:

• Managed String Objects Allocated
• Managed Objects Allocated
• Boxed Value Types

Ideally, the goal is to have the "Delta" column in the Remote Performance Monitor for these 3x statistics consistently set to zero during game play:
This ensures game code does not unnecessarily generate garbage, force full collections and drop frames.

Unfortunately, during game development on the XNA platform, there appears to be 2x common game code scenarios that cause the "Delta" column in the Remote Performance Monitor to be consistently set to values greater than zero during game play:

1. Unnecessary string object creation
2. Unnecessary boxed value types

Each scenario reveals game code that consistently generates too much garbage, impacts performance and has the potential to drop frames.

Let's check out each scenario in greater detail:

Unnecessary String Object Creation
In a typical game, there is often a lot of numeric data that must be displayed on screen to the player, for example: score, hi score, level, lives, bonus etc. Consequently, there are numerous game code snippets similar to the following:

public void Draw()
{
 spriteBatch.DrawString(spriteFont, score.ToString(), position, color);
}

Each time game code executes score.ToString(), the .NET Framework will allocate a single managed string object on the heap. When game code executes score.ToString() unconditionally at 60fps then 60x additional managed string objects will be allocated accordingly every second:


However, there is no reason for game code to execute score.ToString() unconditionally every single frame.

A better approach would be to create 2x variables: one variable to store the integer score value and another variable to store the equivalent string representation of the score:

private Int32 scoreValue;
private String scoreText;

Now game code would only be required to execute score.ToString() when the score actually changed:

public void Update()
{
 if (playerKilledSomething)
 {
  scoreValue += 100;
  scoreText = scoreValue.ToString();
 }
}
public void Draw()
{
 spriteBatch.DrawString(spriteFont, scoreText, position, color);
}

During a standard frame, in which the score value will not change, the "Delta" column in the Remote Performance Monitor for Managed String Objects Allocated will now be set to zero as no garbage generation occurs:


This simple approach to avoid unnecessary string creation may seem obvious, but it is surprising how many times the following game code can be found in Production:

public void Draw()
{
 spriteBatch.DrawString(spriteFont1, score.ToString(), position1, color1);
 spriteBatch.DrawString(spriteFont2, hiScore.ToString(), position2, color2);
 spriteBatch.DrawString(spriteFont3, level.ToString(), position3, color3);
 spriteBatch.DrawString(spriteFont4, lives.ToString(), position4, color4);
 spriteBatch.DrawString(spriteFont5, bonus.ToString(), position5, color5);
 // continue draw method...
}

In the next post, we will continue this discussion on the Remote Performance Monitor with unnecessary boxed value types.

Retrospective

Happy New Year! The company that I currently work for operates an agile software development process and employs SCRUM as an iterative incremental framework for managing complex work.

At the end of each Sprint cycle our team holds a Retrospective to:

• make continuous improvements to the development process
• reflect on the previous sprint
• set goals for the next sprint

Therefore, I thought I would conduct a simple XNA retrospective for 2009 and set goals for 2010.

2009 Achievements

Complete XNA 2.0 book Complete XNA 3.0 book Buy Zune 2nd gen. 120 Gb Buy Zune HD 32Gb Platinum Upgrade XNA Game Studio 3.1 Zune Extensions Give XNA presentation Setup XNA blog with monthly posts Publish Henway XBox LIVE Indie Game Note: purchasing and configuring Zune device outside United States is an achievement!

2010 Objectives

XNA general development	XNA 3.1 development	ZUNE development
3D graphics Networking Unit tests Mocking Physics	Avatar personalization Xbox LIVE Party Video support	Accelerometer Touch panel 3D graphics

One final goal is to become more active in the XNA Creators Club: contribute more in the forums and participate more in the playtest and review process.