Journey of game designer

Welcome young designer! Here for my help you are, yes...?

Yes, O lead designer! I have the greatest game idea in the world and I want to found my own game company, what should I do?

"Love games you must!" Are you crazy enough to work long days for years without vacations, salary or any guarantee of eventual success to see the dream to become reality?

"Yes, you say? Good, great potential in you I sense." Then you will only need to find others who share a similar vision and have the right skill set to form a team. Finding the right team is the most crucial part in setting up the company so make sure to pick the right people. It's better to have no one than the wrong one.

I'm scared that someone will steal my great game idea, how do I protect it?

"Worry, you should not." The game industry is not short on ideas, everyone has them. Your unique idea is likely not nearly as unique as you might think. As such, ideas themselves have no real value. The value is in the ability to make quality games out of the ideas. And for that, you need a lot of feedback from anyone who is interested in your game as early as possible.The real risk is that you get too little feedback and fail to make a good game as a result rather than someone stealing your idea.

Oh well, could you take a look on my plans then? It's all here in the 750-page design document... 

"Ready the design is, hmm?" Creating too detailed plans early on tends to be a waste of time and resources. The plans should be kept on a high level at first and just start doing as soon as possible. Prototyping can be used as necessary to learn what works and what does not. Prototyping can be used as necessary to learn what works and what does not. During the process you will learn and the game will change so much that your original plans will be outdated in no time. As resources are limited, prioritizing is essential. The first goal should be to implement only the absolutely minimum setup containing only the very core of the game and get it right through testing.

But the design is already perfect! I don't want to make changes that taint my vision!

"A great designer, hmmm...? Learn humility, you must." It's good to have a strong vision, but it should not become a principle. A good game designer is always ready to listen and adapt the ideas. Don't fall in love with your own ideas. If something does not work, fix it or ditch it without second thoughts, no matter how much effort or love you have put on the idea. Always be ready to question any and every aspect of your design as well as the design as a whole. 

Well, how do I know what works and what does not?

"To listen, you need learn." Mirroring your own ideas to all the feedback you get is the key. Be it from the players, the data you collect from the game, testing sessions, other team members, things you learn by playing other games or any other source. Never dismiss new viewpoints at first hand, even if they seem unrelated or contradict your own vision. They rarely come in clearly understandable form. You need to always consider what is the heart of the idea and can it be used  in some form to make the game better? Best ideas often come from unexpected sources.

Okay... Do you have any advice how to make the game a success?

"Easy will it not be".Game industry is a hit business. Only the best succeed, nobody cares about mediocrity. You need to be able to stand out with something, be it the original idea, polished mechanics, great story, known brand, special style, unmatched gameplay, innovative controls, less contested category or distribution channel, superior marketing plan or anything else you come up with. Don't polish the game forever before publishing but don't publish crap either. It's better to have half of a game that works than full game that doesn't. The rest of the features can be added later once the potential of the game is confirmed.

How can I be best with so many games around?

"Learn from others you must." If something has already been done, make sure you don't make a game which does the same thing but worse. Making a game differ from another is a wrong motive to do changes: if you can not improve an existing concept, use it as it is. If this would make you game a copy of an existing product, you are in wrong market. If you can not honestly say that your game will be better at least on some aspects than your most direct competitors, the game is not worth making in the first place.

Oh... Any more concrete advises?

"Bite more than you can chew must you not." Always consider the resources you have available. If your game concept is too big for the available resources, do something smaller first. Don't let the project bloat with new features, concentrate in getting the game ready first. Concentrate on one project at a time and give that your full attention.

"Also remember finances you should." As cool as it is to make games, if you can not make money from them, the company will be short lived. Especially in the free-to-play world the monetization is an important part of the design process. It must be taken into account from the start to integrate it flawlessly in the game. Poorly designed monetization can easily destroy the game balance and player experience. And of course, if people don't know about your game, they can not buy it. Be it a publisher, marketer, self marketing or a combination of those, the earlier the marketing is planned and started, the better.

"Pick your battles, you must." Challenging the big studios and their huge resources in the AAA market might not be the most productive idea. Luckily game industry is in the middle of big changes and many of the trends favor small indie studios.

What are these trends you mention?

"Opportunities I see, hmmm..." There are several big trends currently in the game industry which offer possibilities for small companies which are willing to adapt to the rapid changes. Digital distribution, rise of mobile and social gaming, triumph of free-to-play business model, popularity of crowd funding and the possibilities of cloud computing are among those. Technologies like Unity3D and HTML5 allow easy ways to make multiplatform games and not be restricted to a single platform and it's success or lack of it.

Thank you O lead designer! I will now retire to meditate on the wisdom you shared.

"May the ideas flow freely from you, my young designer. Farewell."

The pains of user interface design

Designing good user interfaces is hard work. That is a given. Designing good user interfaces for multiplatform games doubly so. For us, multiplatform means everything from mobile phones to web browsers. This, together with limited resources, makes user interface design a real challenge. This blog post will start a series where I alight on a number of issues we have faced in terms of UI design. In this first post, I will not delve too deep into any specific UI issues. I will instead give you an overview of where we are coming from and how it affects our UI choices.

In the web design world, one of the biggest contemporary trends is response design. In summary, it is a change of mindset from “we need a desktop site, a browser-optimized version and a mobile app” towards “we need a website that works across all devices”. This is achieved using fluid layouts and a number of other techniques (see Wikipedia). Responsive design makes content a first-class citizen, a position it rightly deserves. As a bonus, this tends to lead to far less crippled mobile services (go find a handful of news websites. Now, visit their mobile sites and see if their comments functionality is still there).

The reason I mention responsive web design is simple: it has made the web far less device-oriented. There are other positives but for the purposes of this post, the moving away from designing for particular devices is sufficient.

In our minds, simply porting your game to another platform does not make it “multiplatform”. We see multiplayer games as games that do not build barriers between players just because they happen to play on a different platform. Games, where you can transition from one device to another, using one account. Games, where the device is really just an access point into the game.

We believe this “access point” thinking is the future of serious mobile games. Unfortunately, it also makes user interface design a far greater challenge than it would otherwise be. Now, if we had the time and resources to design the interface separately for each “access point” (desktop browser, tablets, mobile phones etc.), life would be easy. Alas, we cannot. We have to design UIs which work on the entire range of devices our games support. We must be mindful of available screen estate and make sure everything is readable even in the smallest displays. We cannot rely on hover effects because of all the touch devices. We must take note of platform specific features (e.g. the availability or absence of a hardware back button). Good thing we don't mind challenging undertakings.

In the next post, I will talk about some UI designs we have chosen and I will also go over some specific issues we still need to tackle.

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.

Permia – Duels

Welcome to the Seepia Games blog also on my behalf! I’m the person responsible for the design of our games and today I will tell you something about our upcoming game: Permia – Duels, from the designer's perspective. You can sign up for the Windows Phone closed beta at http://permiaduels.com/. The game will be released soon for Windows Phone and later for iOS and Android.

As the name suggests, Duels is the first game to be situated in the fantasy world of Permia. Don’t expect to encounter dwarves, elves or even humans though. Permia is populated by completely unique humanoid races and prehistoric animals like dinosaurs. The Permia lore will be revisited later in detail though, so stay tuned! But for now, let’s get back to Duels. 

Seepia Games are all about multiplayer games and Duels is no exception. We wanted to create a collectible card game which can be played in five minutes, is accessible to anyone and still offers enough strategic depth to make you think. To keep games short, the basic mechanics need to be rather simple but still allow new tricks to be added in updates to keep the game interesting in long term.

Two Final Fantasy mini games, Triple Triad and Tetra Master, were both built around the idea of capturing tiles by playing stronger tiles next to opponents. For me, Triple Triad had too little variety as it is always played on 3*3 grid. Tetra Master offers a more varied game board, but the game system feels too random and it does not give enough feeling of control. While neither of the games managed to capture my interest for long, I believe that similar basic idea has a lot of potential when done right and that's where Duels comes in.

Deciding the tile shape was the first big design decision for the game. Using squares would allow either four (Triple Triad) or eight (Tetra Master) attack directions. We decided to go with hexagons instead. The resulting six attack directions give more options than four and give enough room for extending the game in future. Eight directions would make the game harder to grasp and be graphically less appealing.

We tested different versions of the attack system and in the end decided against using any kind of randomization. Instead, the game board is varied each time making games feel different. Especially interesting are the mountain and water land types which prevent normal unit placement. Units with flying or swimming ability can ignore these restrictions though. The game ends either when players run out of tiles or if no more free hexagons exist. Thus players don't know beforehand if all tiles will be played and who will play the last tile. These are affected by decisions to where flying and swimming units are played, which adds an interesting twist to the game.

The last major design issue I want to mention here is the card collection system. One thing I don't like in many collectible card games is that I tend to end up buying cards among which only small portion are usable and majority is excess copies of cards I already own. In Duels, the units can be combined to increase their power. One does not end having a huge collection of useless units but rather the excess units are useful for improving others.

Well, is Permia - Duels a game for you? Probably yes. :) I’m very excited about the game myself. Be wary, though. Our testers tend to get hooked to it, so you might too! Stay tuned for the exact release dates.

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

The blog

First of all, welcome! This blog is long overdue. When we founded Seepia Games, one of the goals, a part of our vision really, was to be as open as possible. So far, our openness has only reached so far. With this blog, we will hopefully start edging towards being more open.

Pretty much any startup can start its first blog post along the lines of "it's been a hectic year/month/etc.". I'll spare you from the usual oh-we-are-so-terribly-busy lament. If you're running a new company and you're not busy, you are doing it wrong. Disclaimer: future posts may contain whingeing about deadlines, hecticness and whatnot. Bear with us. :)

Our goal is to have everyone from the team writing posts every now and then, so the topics covered should range from the "joys" of running a games studio to network programming. Each of us will likely focus on our strong areas so do not expect game design articles from me or a visual design masterclass from monsieur Rönkkönen. If there is anything you really think we should write about, just get in contact with us via email, Facebook, Twitter or email.

We will post roughly once a week but you may see more posts around important events such as games exhibitions etc. If you fancy even more regular updates, following @SeepiaGames on Twitter is a good idea.

If you already do follow us on Twitter, you will have noticed that we are currently in AppCademy, a four-week accelerator program kindly sponsored by Aalto University, Nokia and Microsoft. I will be writing a more detailed post about our learnings here later on.

Again, please, please be active and get in touch with us so we can write about the things you are interested in!

Thank you!

 - Pasi / Seepia Games

(My fancy job title is "Creative Director" - in practice, I'm responsible for all things visual in the company.)