Thinking agile

Personally, this is my first ever blog post. I am the CEO of Seepia Games. It means that you can blame me if anything goes wrong. If something does not go wrong, please ask me and I will tell who you should thank for it. For me, it is good to start with agile way of thinking. That is something I am known for if you trust LinkedIn endorsements.

For Seepia Games, agile means focus and readiness for change. It is also good not to be afraid of making mistakes.

Ready for a change

Things very rarely go as planned. There are different reasons for that. Sometimes plans are way too optimistic. Those who know me know that my plans are always way too optimistic. Sometimes you don't have all the information available that will affect the execution of the plans. That one has drastically affected us. Agile way of thinking gives us the possibility to change our direction. There have been multiple situations already on our journey to use this possibility. One of the biggest one was changing our target from creating Permia - Tournaments to Tetrablok and Pet Shows games. First eight months of the company were used purely for creating a hardcore collectible card game. We created the working prototype and even a first closed beta version of the game, but we did not manage to find a funding publisher for the game during our trips to the different parts of the world. Then we encountered a possibility to have some funding for a couple of smaller games targeted at the Habbo hotel. It was a very fast decision from our team. On Thursday we had a discussion with a project funding organization that they think that we should make small games to Habbo. On Friday we had a board meeting and on Monday we had two game idea suggestions for the project funding organization. Few weeks after that we froze the development of Permia - Tournaments and we started building two new games.

Focus

Small team do not have time to do wrong things. Keeping the focus is one of the most crucial and hardest thing to do. Ilkka Paananen from Supercell said in a presentation that for them focus means saying no. For us it often feels that there is about three times more things to do than we have people to do it. I think that it is quite common with startups. This means that the team has to prioritize all the time what to do. We have had a very good understanding about our vision and what are our strengths. We have not been very good at explaining that to others though. Even so, we have made quite many mistakes that can be counted as loss of focus. One of the biggest mistakes for us was to start doing two games at the same time. We currently have a team that can effectively do one game at the time. About six months ago we decided to concentrate on one game even when we have a pressure from the customers, partners and from ourselves. That is the only way for us currently to keep the quality of work at a high level. Agile way of thinking reminds us to prioritize most valuable tasks at the top of our task list.

Mistakes

Everybody makes mistakes. It has been less than a couple of years that we have been working to build our game company. I can count multiple mistakes during that time. Mostly the reasons behind the mistakes have been lack of experience and knowledge. Some are based on our personalities and some just because we have not had time to process the information enough. When you make mistake based on lack of experience and knowledge, you may think that if you had used more of your time making studies and plans before making the decisions, you would be making less mistakes. One can use all the time in a world just learning, studying and analysing. When do you know that you have enough information. For me I don't even try to fool myself to think that decision I make is the only possible one. For the current information I have, it feels like it, but tomorrow when I have more information my decision might be different one. The agile way of thinking gives us a possibility to make decision based on current information. With keeping the focus we go full speed ahead and if or when we encounter new information we can change our direction based on new current knowledge and experience. It is not a problem, if you make mistakes. It is a problem if you don't learn from them.

Results

Our focus is in cross-platform multiplaying games. We want to give our players good entertainment with some need of using brains during the game play. We have created platform that enables us to create good quality multiplaying experience and that enables us to concentrate on game content in a long run. There is still much to do before the platform is ready and productized but it is in a very good shape already. We have published one game in Habbo hotels globally. It has been translated in 11 languages and over 850 000 people have tried the game. Earlier this week we delivered our first real release candidate for Windows Phone 8 store review of our Permia - Duels title, the first Permia-themed collectible card game. Release date will be published in near future.  Our third game Pet Shows is close to be ready as well. It has been in that phase already about half a year, but because of our concentration for one game at the time, we have not had possibility to finish the game. Currently we are three full-time entrepreneurs, one part time architect, one advisor and a partner organisation. We thank all the customers, trainees, board members and subcontracting partners from the journey so far.

Please, sign up for the Permia - Duels beta.

- Jani Tietäväinen / CEO of Seepia Games

Luck in games

One of the big questions in game design is the luck factor: should there be any luck in a good game, and if so, how much? There is of course no right or wrong answer here as different people prefer different games. What I'm going to write about today is my take on the different aspects of luck in game design.

Image: Lee Daniel Crocker

A good, classic example of a game without any luck is of course Chess. While the design is solid and has stood the test of time, I'm not myself a big fan of pure skill games like that. They tend to be a bit too serious and dry for me. Rather, I enjoy games with enough luck to keep things interesting, but not too much to take the feeling of control away. Let's take a look of different ways of adding luck to a game.

Dice rolls in action results

When talking about luck in games, most people think about dices. In chess every action has a clearly defined and guaranteed outcome: a piece always kills the opponent's piece in the square it moves to. In Risk, the result of an attack is decided by a dice roll instead. Games that add uncertainty directly to the action results define the probabilities for different outcomes of the action and then roll a dice to decide the actual outcome. Typically, the player has ways to affect the probabilities and decide the desired actions. The decision is based on the possible rewards/penalties of the action as well as the probability of success. 

Including this kind of a luck element may easily take away the feeling of control: it's natural to think that when I have a 75% chance to succeed, it's a guaranteed success and won't fail. When it does fail (which happens every fourth time in this case),  it often feels unfair, especially if it was an important action. On the other hand, such an uncertainty can add a lot of tension to the game as one can never be sure of the outcome. As such dice is best used for actions that are repeated many times to even out the dice rolls. It is a dangerous approach to be used for major actions that can change the course of the game.

Accuracy

Image: Xiaphias

Another way to add uncertainty to actions is to add a dexterity element into the game. Examples of such games include Angry_birds, Jenga, Pool, Bowling, Darts and sports in general. Truthfully the accuracy element in this kind of games is directly dependent on the player's skill and thus the word luck does not describe it well. Still, when we compare Chess to the games listed above we notice an interesting difference: Chess is all about strategy and a huge decision space, where one needs to be able to outhink the opponent. Once the move has been decided, the execution will always succeed. In bowling the strategy is very simple: always knock out all the pins. It's the execution part that makes the challenge as even the best players are not able to do that consistently with every throw.

Adding an accuracy element to a game can make otherwise very simple game more interesting and challenging. A good example of using accuracy as a minor element in a game is HellFire. Both HellFire and its predecessor Rage of Bahamut are essentially sophisticated card collection systems with very simple game mechanics. In Rage of Bahamut, battles are decided almost directly by the card stats, while in HellFire the opponents employ weak points to which the attacks should be aimed at by swiping the touch screen. This adds an interesting accuracy element to the battles as skilled swipes give an advantage over poor ones.

Complex action chains

A slightly different approach to accuracy is found from the attacks in Clash of Clans. The game is essentially a multiplayer tower defence game, where players build their villages and decide the defensive tower setup. Then other players use their army to attack the villages and try to steal resources and points. An army may contain over 200 troops. While placing a single troop is simply a tap on the screen, deciding the order, timing and placement of the whole army offers almost endless possibilities.

After being placed onto the field, each soldier automatically attacks based on its behavior model which is defined by its type. The behavior is predictable and thus in theory there is no luck involved, except traps and invisible towers which are hidden information and thus not completely predictable. But even without those, the sheer complexity of the setup means that it's not possible to exactly predict what will happen. It's a common thing to see my troops go to a completely different direction than I predicted and then get slaughtered by a tower they should have destroyed earlier. This unpredictability keeps the attacks interesting as there is always the chance of failure. Yet,  the failure does not feel unfair as the result was not due to an unlucky dice roll but rather the decisions I made.

The challenge in complex action chains is in the execution part similarly to the accuracy element. The difference is, accuracy uses independent actions which should all be executed perfectly. In complex action chains, the actions are are simpler by themselves, but not independent and the goal is to execute the whole action chain flawlessly.

Hidden information

Many people have asked me why do we keep the opponents hand units hidden in Permia - Duels. Wouldn't it be better if all the information was always available to both players, like in Chess? As you might guess, my answer to the guestions is no. But why is that? What do we gain by hiding the information and adding a luck element to the game through that?

Opponent's hand is hidden during a match

In games like Chess, where all information is always available, the only limitation when deciding the strategy is the computational capability of the player's brains. This makes the decision base huge and easily leads to an "analysis paralysis", which means that the players can analyze a single move for ages if the time is not limited. Of course we can limit the time, but again, it becomes a task of analyzing as much of the available information in the given time as possible. For me this kind of games often feel dry and exhausting to play as there are no real surprises, only raw calculations and memorizing chains of moves.

Hiding opponent's units takes away some of the strategic depth and puts more weight on the tactical side. One cannot calculate the exact strategy for the whole game at the beginning as all the information is not available. Rather, the decisions must be based on the own units and their strenghts and one needs to be able to adapt when something unexpected happens. This drastically reduces the decision base at the start of the game and makes the game feel lighter. Additionally waiting for an opponent's moves is more exciting due to the uncertainty: "does he have the unit which wrecks my cunning plan or not?" Rather than knowing all in the beginning, one needs to try to deduce the opponent's hand during the game based on the units he has already played. This adds the possibility for bluffing, which is another element not possible in a full information game. Simply put: for me, games that have hidden information tend to be more fun to play.

Limited options

Another way to reduce the decision base of a game is to limit the options the player has available at once. Good examples are most card games, where the player's hand decides the available actions while the deck defines the whole actions pool. The player typically knows what to expect from the deck and thus has a vision of the grand strategy, but the decisions which cards to use are tactical ones: How to make the best use of the cards in hand, which might or might not be the optimal ones for the situation at hand.

Limiting the options is often used together with information hiding, which allows even more interesting bluffing elements. Limiting the player's options is also an excellent way to make game sessions feel different as the actions available in different phases of the game vary from session to session even if the whole action pool stays constant.

Varied setup

Varying the game setup can also be used for making different playing sessions feel different and to keep the game interesting for a long time. Instead of limiting the options available, the gameboard or gameworld behaves differently from session to another. A good example is Bejeweled, which always generates a different playing field for the game. Varied setup also reduces the advantage gained from memorizing certain chains of moves, as different situations require new solutions.

In Permia - Duels, the varying gameboard is one of the key elements of the game. Differently positioned landscapes form a new challenge for each game session and require the players to their update strategies accordingly.

 Jani Rönkkönen / Lead designer of Seepia Games.

Cloud service: Windows Phone application - receipt verification

Introduction

It's time to share also something from our "technical" journey. As you may have already noticed from the earlier blog posts, our current focus has been to get Permia - Duels to work in Windows Phone, which will naturally mean that we need integrate a few modules into our cloud service to have an interface towards the Windows Phone "ecosystem".

Mobile purchase verification is an important feature that is needed to make sure that the subscriber has really purchased what it clams. In Windows Phone environment it means receipt verification. Sounds like a pretty simple feature, which it is in fact is: get receipt and verify it.

In general, the Microsoft MSDN Dev Center has instructions, guides and examples how the receipt verification works in Windows Phone, but I did find that the web pages are more or less not so well structured. I had to combine several sources to get a good idea how the verification should work and even after that "the final" solution it did not work. Well, after all we got it to work.

One notable thing is, that we had to implement almost everything by ourselves. There were lots of different kinds of implementation, but mostly those were not directly suitable for our use. As a background information, our cloud service is build up with  C/C++ and LUA scripting language, but we have also ways to extend it to use other technologies. I am going to write another post about that, so let's have a more closer look those topics then.

Receipt verification

Very first thing I did, was using search engines to find pages with keywords "Microsoft receipt verification".  I was lead to Microsoft's Dev Center web page Using receipts to verify purchases. There was a nice example in pseudo level (for me), as we are not using C# in our cloud service. Now I had an idea that in what format the receipt is received and in pseudo level what should be done.

XMLSig handling

Next step was to get further information about the receipt. The receipt is in fact an XML document having a signature element in it. There is a W3C Recommendation about XML signature syntax and I had to spend some time to get an idea how it was supposed to be used. Fortunately, I did find one nice web page, that did demonstrated how the XML signature works: Signing an XML document using XMLDSIG
The guide is split into two parts. Part 1 explains "enveloping" a signature while part 2 explains an "enveloped" signature. Microsoft receipt uses an "enveloped" signature, but it is also worth checking part 1 to get a general idea what it means.

It took a while to I implement what was needed for this, but in the end I had the needed pieces in place. I got the example from the article to work and the verification worked fine.

• Helpful pages
• XML parsing with LUA
• GnuTLS

Fetching Certificate For Receipt Verification

Next, I started to study Microsoft's example from  Using receipts to verify purchases, and build up the certification fetch logic and used certificates to test my implementation. Below we have a receipt example and an example of HTTP messaging from certification fetch.

<receipt certificateid="b809e47cd0110a4db043b3f73e83acd917fe1336" receiptdate="2012-08-30T23:10:05Z" receiptdeviceid="4e362949-acc3-fe3a-e71b-89893eb4f528" version="1.0">
 <appreceipt appid="55428GreenlakeApps.CurrentAppSimulatorEventTest_z7q3q7z11crfr" id="8ffa256d-eca8-712a-7cf8-cbf5522df24b" licensetype="Full" purchasedate="2012-06-04T23:07:24Z">
 <productreceipt appid="55428GreenlakeApps.CurrentAppSimulatorEventTest_z7q3q7z11crfr" expirationdate="2012-09-02T23:08:49Z" id="6bbf4366-6fb2-8be8-7947-92fd5f683530" productid="Product1" producttype="Durable" purchasedate="2012-08-30T23:08:52Z">
 <signature xmlns="http://www.w3.org/2000/09/xmldsig#">
  <signedinfo>
   <canonicalizationmethod algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
   <signaturemethod algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256">
   <reference uri="">
    <transforms>
     <transform algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature">
    </transform></transforms>
    <digestmethod algorithm="http://www.w3.org/2001/04/xmlenc#sha256">
    <digestvalue>cdiU06eD8X/w1aGCHeaGCG9w/kWZ8I099rw4mmPpvdU=</digestvalue>
   </digestmethod></reference>
  </signaturemethod></canonicalizationmethod></signedinfo>  <signaturevalue>SjRIxS/2r2P6ZdgaR9bwUSa6ZItYYFpKLJZrnAa3zkMylbiWjh9oZGGng2p6/gtBHC2dSTZlLbqnysJjl7mQp/A3wKaIkzjyRXv3kxoVaSV0pkqiPt04cIfFTP0JZkE5QD/vYxiWjeyGp1dThEM2RV811sRWvmEs/hHhVxb32e8xCLtpALYx3a9lW51zRJJN0eNdPAvNoiCJlnogAoTToUQLHs72I1dECnSbeNPXiG7klpy5boKKMCZfnVXXkneWvVFtAA1h2sB7ll40LEHO4oYN6VzD+uKd76QOgGmsu9iGVyRvvmMtahvtL1/pxoxsTRedhKq6zrzCfT8qfh3C1w==</signaturevalue>
 </signature>
</productreceipt></appreceipt></receipt>

First the real location of the certificate was queried from the "redirection" service (https://go.microsoft.com/fwlink/?LinkId=246509&cid=b809e47cd0110a4db043b3f73e83acd917fe1336) :

GET /fwlink/?LinkId=246509&cid=b809e47cd0110a4db043b3f73e83acd917fe1336&lt HTTP/1.1\r\n
Host: go.microsoft.com\r\n
User-Agent: seepia-rozelayde-ms-be/0.0.1\r\n
Content-Length: 0\r\n
\r\n

HTTP/1.1 302 Found\r\n
Cache-Control: private\r\n
Content-Type: text/html; charset=utf-8\r\n
Expires: Fri, 11 Oct 2013 07:26:01 GMT\r\n
Location: https://lic.apps.microsoft.com/licensing/certificateserver/?cid=b809e47cd0110a4db043b3f73e83acd917fe1336\r\n
Server: Microsoft-IIS/7.5\r\n
X-AspNet-Version: 4.0.30319\r\n
X-Powered-By: ASP.NET\r\n
Date: Fri, 11 Oct 2013 07:27:00 GMT\r\n
Content-Length: 221\r\n
\r\n
<html><head><title>Object moved</title></head><body>\r\n
<h2>
Object moved to <a href="https://lic.apps.microsoft.com/licensing/certificateserver/?cid=b809e47cd0110a4db043b3f73e83acd917fe1336">here</a>.</h2>
\r\n

Secondly, the real certificate was retrieved (https://lic.apps.microsoft.com/licensing/certificateserver/?cid=b809e47cd0110a4db043b3f73e83acd917fe1336) :

GET /licensing/certificateserver/?cid=b809e47cd0110a4db043b3f73e83acd917fe1336 HTTP/1.1\r\n
Host: lic.apps.microsoft.com\r\n
User-Agent: seepia-rozelayde-ms-be/0.0.1\r\n
Content-Length: 0\r\n
\r\n

HTTP/1.1 200 OK\r\n
Cache-Control: private\r\n
Content-Type: text/plain\r\n
Server: Microsoft-IIS/7.5\r\n
X-AspNetMvc-Version: 2.0\r\n
X-AspNet-Version: 4.0.30319\r\n
X-Powered-By: ASP.NET\r\nDate: Fri, 11 Oct 2013 07:27:01 GMT\r\n
Content-Length: 1398\r\n
\r\n
-----BEGIN CERTIFICATE-----\r\n
MIIDyTCCArGgAwIBAgIQNP+YKvSo8IVArhlhpgc/xjANBgkqhkiG9w0BAQsFADCB\r\n
jjELMAkGA1UEBhMCVVMxEzARBgNVBAgMCldhc2hpbmd0b24xEDAOBgNVBAcMB1Jl\r\n
ZG1vbmQxHjAcBgNVBAoMFU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjEWMBQGA1UECwwN\r\n
V2luZG93cyBTdG9yZTEgMB4GA1UEAwwXV2luZG93cyBTdG9yZSBMaWNlbnNpbmcw\r\n
HhcNMTExMTE3MjMwNTAyWhcNMzYxMTEwMjMxMzQ0WjCBjjELMAkGA1UEBhMCVVMx\r\n
EzARBgNVBAgMCldhc2hpbmd0b24xEDAOBgNVBAcMB1JlZG1vbmQxHjAcBgNVBAoM\r\n
FU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjEWMBQGA1UECwwNV2luZG93cyBTdG9yZTEg\r\n
MB4GA1UEAwwXV2luZG93cyBTdG9yZSBMaWNlbnNpbmcwggEiMA0GCSqGSIb3DQEB\r\n
AQUAA4IBDwAwggEKAoIBAQCcr4/vgqZFtzMqy3jO0XHjBUNx6j7ZTXEnNpLl2VSe\r\n
zVQA9KK2RlvroXKhYMUUdJpw+txm1mqi/W7D9QOYTq1e83GLhWC9IRh/OSmSYt0e\r\n
kgVLB+icyRH3dtpYcJ5sspU2huPf4I/Nc06OuXlMsD9MU4Ug9IBD2HSDBEquhGRo\r\n
xV64YuEH4645oB14LlEay0+JZlkKZ/mVhx/sdzSBfrda1X/Ckc7SOgnTSM3d/DnO\r\n
5DKwV2WYn+7i/rBqe4/op6IqQMrPpHyem9Sny+i0xiUMA+1IwkX0hs0gvHM6zDww\r\n
TMDiTapbCy9LnmMx65oMq56hhsQydLEmquq8lVYUDEzLAgMBAAGjITAfMB0GA1Ud\r\n
DgQWBBREzrOBz7zw+HWskxonOXAPMa6+NzANBgkqhkiG9w0BAQsFAAOCAQEAeVtN\r\n
4c6muxO6yfht9SaxEfleUBIjGfe0ewLBp00Ix7b7ldJ/lUQcA6y+Drrl7vjmkHQK\r\n
OU3uZiFbCxTvgTcoz9o+1rzR/WPXmqH5bqu6ua/UrobGKavAScqqI/G6o56Xmx/y\r\n
oErWN0VapN370crKJvNWxh3yw8DCl+W0EcVRiWX5lFsMBNBbVpK4Whp+VhkSJilu\r\n
iRpe1B35Q8EqOz/4RQkOpVI0dREnuSYkBy/h2ggCtiQ5yfvH5zCdcfhFednYDevS\r\n
axmt3W5WuHz8zglkg+OQ3qpXaXySRlrmLdxEmWu2MOiZbQkU2ZjBSQmvFAOy0dd6\r\n
P1YLS4+Eyh5drQJc0Q==\r\n
-----END CERTIFICATE-----

Now our cloud service was able to fetch the certificate that was needed to verify the receipt.

Receipt verification: failure and solution

I failed to get the verification of the example receipt to work. I spent a "few" hours to verify the logic and retested with different scenarios. Then finally I got it: the receipt was in wrong format, as all hash calculations were based on a receipt where there were no newlines or spaces between the XML nodes. I don't know if I missed something while reading the Microsoft Dev Center pages or XMLSig recommendation's canonicalization definitions, but also the Microsoft beta server sent the receipt in this format.

Real format of Receipt:

<receipt certificateid="b809e47cd0110a4db043b3f73e83acd917fe1336" receiptdate="2012-08-30T23:10:05Z" receiptdeviceid="4e362949-acc3-fe3a-e71b-89893eb4f528" version="1.0"><appreceipt appid="55428GreenlakeApps.CurrentAppSimulatorEventTest_z7q3q7z11crfr" id="8ffa256d-eca8-712a-7cf8-cbf5522df24b" licensetype="Full" purchasedate="2012-06-04T23:07:24Z"><productreceipt appid="55428GreenlakeApps.CurrentAppSimulatorEventTest_z7q3q7z11crfr" expirationdate="2012-09-02T23:08:49Z" id="6bbf4366-6fb2-8be8-7947-92fd5f683530" productid="Product1" producttype="Durable" purchasedate="2012-08-30T23:08:52Z"><signature xmlns="http://www.w3.org/2000/09/xmldsig#"><signedinfo><canonicalizationmethod algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><signaturemethod algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"><reference uri=""><transforms><transform algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></transform></transforms><digestmethod algorithm="http://www.w3.org/2001/04/xmlenc#sha256"><digestvalue>cdiU06eD8X/w1aGCHeaGCG9w/kWZ8I099rw4mmPpvdU=</digestvalue></digestmethod></reference></signaturemethod></canonicalizationmethod></signedinfo>  <signaturevalue>SjRIxS/2r2P6ZdgaR9bwUSa6ZItYYFpKLJZrnAa3zkMylbiWjh9oZGGng2p6/gtBHC2dSTZlLbqnysJjl7mQp/A3wKaIkzjyRXv3kxoVaSV0pkqiPt04cIfFTP0JZkE5QD/vYxiWjeyGp1dThEM2RV811sRWvmEs/hHhVxb32e8xCLtpALYx3a9lW51zRJJN0eNdPAvNoiCJlnogAoTToUQLHs72I1dECnSbeNPXiG7klpy5boKKMCZfnVXXkneWvVFtAA1h2sB7ll40LEHO4oYN6VzD+uKd76QOgGmsu9iGVyRvvmMtahvtL1/pxoxsTRedhKq6zrzCfT8qfh3C1w==</signaturevalue></signature></productreceipt></appreceipt></receipt>

YESH! Now the receipt verification worked with example receipt.

Windows Phone Store service & beta testing certificate

Nothing new on the planet, but we ran into more problems when we tried to verify that the receipt was received during beta testing. The problem was that the certification fetch failed for certification ID "A656B9B1B3AA509EEA30222E6D5E7DBDA9822DCD". I tried to search for a solution by using search engines and certificate ID as a search keyword, but no luck.

Then we sent a question to the community (Discussion Thread) and finally there was an answer that helped us. I could get a certificate for "A656B9B1B3AA509EEA30222E6D5E7DBDA9822DCD" from inside one sample In-app purchase receipt verification. I admit that having visited this page before, but I somehow had missed / not read the example so well. In fact in In-app purchase receipt verification page there is a statement:

Note:
The IapReceiptProduction.cer certificate file is used to verify a live in-app purchase receipt from the Windows Phone Store service.

My opinion is that Windows Phone Store service certificate is not "visible" enough and searches with keyword "A656B9B1B3AA509EEA30222E6D5E7DBDA9822DCD" will not give good results to resolve the problems I had.

We still have a one open topic. During beta testing, there was received a Receipt, that was somehow malformed, as there was missing " from XML node arguments (argument was in next format: NameOfArgument=realdata"). Our parser did not like it and when I added "-mark manually, hash calculations did fail. I have to check the issue in some point, and hopefully I manage to solve this issue soon.

Conclusion

Maybe nowadays there is a well-implemented and optimized XML parser, which runs smoothly in the newest hardware, but in general I would not like to use XML in cloud service / backend / server-side, as it is not so lightweight as well-defined "binary" formats.

This is not the only feature where Microsoft uses the XML approach and in fact it seems that Microsoft's approach to these issues is XML-driven. This is my current view, but let's see what future brings.

From the receipt verification point of view it is not such a big deal to use XML and XMLSig, as the receipt verification is not performed so often and should not cause problems to the cloud service. Hopefully our lightway implementation works for a long time and is robust if/when there are changes to the receipts. Anyway we had to also implement a backup system for the case where the receipt verification fails, so users won't lose their purchases.

Links:

• http://msdn.microsoft.com/library/windowsphone/develop/jj206949(v=vs.105).aspx
• http://msdn.microsoft.com/en-us/library/windows/apps/jj649137.aspx
• http://code.msdn.microsoft.com/wpapps/In-app-purchase-receipt-c3e0bce4
• http://lua-users.org/wiki/LuaXml
• http://gnutls.org/manual/html_node/
• http://www.w3.org/TR/xmldsig-core/

If you have any questions related to this topic, just ask it via comments..

AppCademy in retrospect

If you follow us on Twitter, you know that some of us spent the last month in Espoo, Finland with Aalto, Microsoft and Nokia. The AppCampus acceleration program (aptly titled AppCademy) is a four-week training course sponsored by the aforementioned.

I intentionally waited until now before writing this post. Being back at the office is usually good for putting things into perspective. It is easy to get excited about all sorts of things when you are in an an isolated environment focused on one task.

As I have told many people I've talked to, we were rather skeptical about AppCademy at first. Startups are always busy and the idea of spending four weeks away from home, getting very little work done, just seemed off. And um, Helsinki.. not exactly the most interesting and exotic holiday destination for us. 

I am happy to say we were wrong. The four weeks we spent in AppCademy were useful, constructive and fun.

Working on the pitch

Let me first address the elephant in the room: Windows Phone. I doubt there are more than a handful of teams in the program who only target WP. The same probably goes for AppCampus awards (i.e. the bag of cash they give you). I do not believe the AppCampus/AppCademy people kid themselves about this. In fact, I am sure they realize that most teams will eventually go for other platforms as well. Obviously, in the program all training is centred around Windows Phone and some of the sessions (namely the technical ones) have very little relevance outside the world of WP. There are very few of those "WP-only" sessions though and most of the knowledge you gain is applicable to any platform.

AppCampus do ask you for 3 months of exclusivity, which I find reasonable. After 90 days (starting from the day you release) you are free to publish your app anywhere you like. For most apps, this is a non-issue. 

The training topics cover a wide range of subjects from branding and marketing to privacy and legal issues. Most of the instructors are established professionals who have actually worked in the industry, which is a huge plus. It only took us a few days to overcome our initial skepticism, mostly thanks to these great speakers. Naturally depending on the state of your startup, you will find some sessions more useful than the others. We found that almost all sessions were useful to us.

1-on-1 sessions are another form of instruction they use and these we found extremely good. The idea is simple, you have short sessions where you showcase your game to a professional (or two) and they give you feedback on your app. We met designers, UX experts, investors, marketing professionals etc. who all gave us valuable advice on how to develop our business or improve our game. We tried to make the most of the 1-on-1s we had. You rarely get this good a chance to get 3rd party professional advice, for free. Useful tip for those taking part in future AppCademy courses: these sessions are short (20-30 mins usually) so make sure you can explain your app and your issues in a couple of minutes so you have time to actually dig into the app.

Final day pitch. Photo: Aydin Mir Mohammadi

It is also very important to keep an open mind. It's a cliché, I know; still, it is very hard to accept criticism of your brainchild you've worked on for months even if you realize it is right on the mark. For us, this was particularly evident during the 1-on-1s with the designers. Some decisions we have made simply do not work. We are still working on making some changes we now feel are necessary for the game to really shine visually and hopefully this will show on the final product.

And the bad parts? There weren't many. After a couple weeks I did feel like ramming random objects down anyone's throat who mentioned the Nokia Imaging API. It's also exhausting. The sessions usually start around 9am and last til 2pm-4pm (some days are more relaxed so you can actually get some work done) but you are still quite removed from your usual routines. Helsinki (the AppSpace is in Espoo but you live in a minuscule hotel room in Helsinki) is a bit on the pricy side when it comes to living. There were a few subpar sessions but by no means did they ruin the whole show. 

The other teams were great and it is always fun to hear what other app developers think about your game (or app). I am sure we will stay in touch with quite a few of the developers we met and got to know during AppCademy.

I am happy we decided to accept the invitation to AppCademy. We now have a pretty good idea where to go from here, what still needs to be done and, also importantly, what are our strengths. As they say, time well spent.

EDIT (5th Oct): fixed the second paragraph, the last sentence was incomplete.