The Story Behind ‘True Fool’

The story be­gins in late Sum­mer of 2009. As long as I can re­mem­ber I was in­ter­ested in pro­gram­ming. Un­for­tu­nately, I never was suc­ces­ful with my spo­ra­dious pro­gram­ming en­deav­ors. When­ever I tried to learn pro­gram­ming, a pro­gram­ming lan­guage or a li­brary/frame­work/tool—most of the time dur­ing school hol­i­days—I gave up sooner rather than later pri­mar­ily be­cause I lacked the nec­es­sary dis­ci­pline to put my­self through the hard stuff. Pro­gram­ming and all that it en­com­passes is sim­ply not an easy task to learn let alone to mas­ter. But this time it was dif­fer­ent I told my­self. I am going to use my free time be­fore start­ing my uni­ver­sity stud­ies to fi­nally fin­ish a pro­gram­ming pro­ject: Durak, a fairly pop­u­lar card game in post-So­viet states.

I learned Durak fairly young from my grand­mother and since then I played it here and there. It seemed a per­fect and man­age­able task for a month I thought. At first I had to find a game en­gine resp. frame­work for Java as I wanted to im­ple­ment a game and not an en­gine. I found Pulp­core, a game frame­work ahead of it’s time. Un­for­tu­nately, the trou­ble al­ready began when im­ple­ment­ing the class rep­re­sent­ing a play­ing card.

Of course, I must fol­low MVC by the book and not by the idea and I must pre­pare for fu­ture re­quire­ments by mak­ing the classes as gen­eral as pos­si­ble. De­sign Pat­terns must be in­cor­po­rated no mat­ter what. I am a good pro­gram­mer after all!

This mis­guided at­ti­tude lead to a lot of classes, com­plex­ity and doubts. I had not yet learned to weigh the trade-offs of code ar­chi­tec­ture de­ci­sions. Plus, I sev­erly un­der­es­ti­mated the in­tri­ca­cies of im­ple­ment­ing the game logic. After a lot of trial and error I think I got the basic rules right. But the re­sult­ing code was so messy and hard to un­der­stand… I am pretty sure there are still bugs lurk­ing some­where and I dont want to imag­ine how to mod­ify the code to im­ple­ment the more in­ter­est­ing ad­vanced rules of the game. Some fur­ther for­mer at­ti­tudes fol­low.1

Us­abil­ity? Haha, the pro­grams I write are us­able by de­fault. I am a good pro­gram­mer after all. If some­body does not un­der­stand how to in­ter­act with my soft­ware he is ob­vi­ously stu­pid. Dou­ble-click­ing to sig­nal pass­ing should be crys­tal clear, no need to in­form the player. Source Con­trol? Never heard of it. Hav­ing a dozen dif­fer­ent fold­ers is good enough. AI’s must be scriptable, right? So I need to have a JavaScript scripting in­ter­face for im­ple­ment­ing the AIs. I could never write the AIs in Java, that wouldn’t be script­ing, silly me.

Any­ways, I don’t want to go into more de­tails of my mis­guided for­mer self :). Even with all these prob­lems I man­aged to “fin­ish” the pro­ject al­beit in a much more rudi­men­tary state than I had imag­ined in the be­gin­ning. The fol­low­ing is a video of the pro­ject’s evo­lu­tion. After 1:40 I just play a game from start to fin­ish in real-time so you might want to skip this ;). You can even play the game for your­self on­line: http://​storytube.​kilu.​de/​. And the fol­low­ing post on java-gaming.​org al­ready then showed my in­ter­est in for­mal­iz­ing prob­lems in code as clearly as pos­si­ble.

The story does not end here. I promised my­self to re­visit the task of im­ple­ment­ing Durak as a fun com­puter pro­gram once I com­pleted my uni­ver­sity de­gree in order to see if I im­proved over the course of the fol­low­ing five years. It helped that fel­low stu­dents and I some­how started play­ing Durak when­ever we had eaten lunch rather re­li­giously. Thus, my mo­ti­va­tion to re­visit the task only ever in­creased and I knew that I had some very crit­i­cal testers to pro­vide me with valu­able feed­back. The rest of the ar­ti­cle will go into more de­tail of my sec­ond Durak en­deav­our and here is the trailer of the com­pleted game by the name of “True Fool“.2

True Fool is avail­able at the fol­low­ing places.


As men­tioned in the in­tro­duc­tion, the main mo­ti­va­tion for me to cre­ate True Fool was for it to be a test of my self-im­prove­ment. I just knew that there had to be a bet­ter way to code Durak. Yet, I couldn’t see it since my ex­pe­ri­ence and knowl­edge were rather lim­ited in 2009. In 2014, how­ever, I had a much clearer pic­ture of how to tackle this prob­lem and I wanted to see if I fi­nally got what it takes to solve it prop­erly.

Since in 2014 mo­bile de­vices and games were much more wide­spread than in 2009 and since I had some pre­vi­ous mo­bile game de­vel­op­ment ex­pe­ri­ence I nat­u­rally de­cided to make True Fool a mo­bile game. Of course, I wanted to find out if there al­ready were An­droid/iOS Durak games to be in­spired by and to iden­tify po­ten­tial short­com­ings that I may want to avoid. The one huge prob­lem I had with ba­si­cally all of these Durak man­i­fes­ta­tions was that play­ing them just didn’t feel as fluid as I think it should have been even with the pop­u­lar pre­mium games that oth­er­wise boasted a lot of im­pres­sive fea­tures. In short, I wasn’t sat­is­fied with their us­abil­ity and I wanted to show that I could do bet­ter.34

Last but not least, writ­ing a Durak game is sim­ply an in­ter­est­ing chal­lenge. There is the part that is con­cerned with mod­el­ling the game and its rules in code. Think­ing about use cases, weigh­ing trade-offs, con­sid­er­ing the re­sult­ing code us­abil­ity, fruit­fully com­bin­ing lan­guage fea­tures while try­ing to keep it all sim­ple is just a fun thing about de­sign­ing code. Get­ting the rules, the be­hav­ior, the UI and all the edge cases right re­quires a lot of log­i­cal think­ing (to cover all the cases cor­rectly), imag­i­na­tive power (to think of the edge cases) and en­durance (to find all the edge cases). Cre­at­ing a us­able UI whose code is man­a­gae­ble is re­ally hard and fun. Mak­ing the AI in­tel­li­gent is also a fun chal­lenge.

Evo­lu­tion 2014

The fol­low­ing video shows some of the var­i­ous it­er­a­tions of True Fool.5

All in all, you could say I had around five dif­fer­ent UI ver­sions until I ar­rived at the one that my play testers and I were re­ally sat­is­fied with. It was im­por­tant to try things out and to gather feed­back from the testers. It led to a lot of code that was writ­ten with ef­fort yet had to be thrown away ul­ti­mately. One of the im­por­tant lessons for me there­fore, at least for game code, is to be pre­pared to throw it away if it im­ple­ments a non-fun in­ter­ac­tion no mat­ter how hard it was to cre­ate it.


As stated ear­lier, I wanted set True Fool apart from other Durak games by hav­ing a much more us­able and in­tu­itive in­ter­face. One of the main prob­lems I saw even in the pop­u­lar pre­mium games was a lack of vis­i­bil­ity in sev­eral re­spects. For ex­am­ple, in some games the player has to dou­ble-tap to sig­nal pass­ing. This is not ob­vi­ous and has to be ex­plained to the player. But es­pe­cially a player un­fa­mil­iar with Durak might for­get this. Which leads me to vis­i­bil­ity of the con­text resp. con­text aware­ness.6

In Durak, there are ba­si­cally two modes: at­tack­ing and de­fend­ing. Many games, in my opin­ion, do not make it clear enough in which mode the player cur­rently is and who is cur­rently being at­tacked. This is the rea­son for the sword/shield marker in True Fool. Also, the but­tons are dis­played de­pend­ing on the con­text and make all avail­able ac­tions in a sit­u­a­tion vis­i­ble. Some but­tons map to the same place in a dif­fer­ent con­text which is why I tried to map but­tons with a sim­i­lar ac­tion to the same po­si­tion and have the same color. De­fend but­tons are on the left and at­tack but­tons on the right to make the con­trast of dif­fer­ent con­texts even clearer and pre­vent sub­con­scious er­rors where, e.g. the ac­tion of a but­ton is con­fused be­cause it is in the same place but in a dif­fer­ent con­text.

Plac­ing cards on the field in ba­si­cally all games is more com­pli­cated than nec­es­sary. The cho­sen card must be man­u­ally dragged on the play­ing field or on the at­tacker card to be de­fended. In the vast ma­jor­ity of sit­u­a­tions, how­ever, there is only one pos­si­ble ac­tion for a card so man­ual drag­ging is much too ex­plicit (com­pare to type in­fer­ence for local vari­ables in pro­gram­ming lan­guages). This is why in True Fool sim­ply tap­ping a card will choose the one pos­si­bil­ity. Yet, if there is more than one pos­si­bil­ity for a card when de­fend­ing, a drag sym­bol is dis­played under the cor­re­spond­ing “ghost card” (see the video to un­der­stand the con­cept of ghost cards) to allow for the needed ex­plic­it­ness in rare sit­u­a­tions but not pe­nal­ize the com­mon sit­u­a­tion with un­nec­es­sary ex­plic­it­ness.

Choos­ing a de­ci­sion and com­mit­ting it can be dis­tin­guished in True Fool (the rea­son for the ghost cards). This makes it also pos­si­ble to have a good UI for at­tack­ing/de­fend­ing with sev­eral cards at once. This way as a player you can also plan your de­fense bet­ter since when choos­ing a card for de­fense other cards in your hand which be­come un­ap­plic­a­ble due to this choice are faded out. In gen­eral, cards which are un­ap­plic­a­ble in a sit­u­a­tion are faded out to help you con­cen­trate more on the strate­gi­cal as­pects of Durak than on the busy-work of iden­ti­fy­ing which cards can be used and which not.

There are also ex­pert con­trols which are quicker and avoid the push­ing of but­tons. This ex­pert con­trol is ba­si­cally fling­ing a card. It also works when hav­ing stacked sev­eral cards. True Fool is novice-friendly be­cause of the vi­sual hints, an in­ter­ac­tive tu­to­r­ial and in-game rules. All the avail­able hor­i­zon­tal space is used for the player hand to im­prove de­tec­tion of card se­lec­tion. Also, the play­ing hand is like an ac­cordeon, i.e. un­us­able cards for the cur­rent sit­u­a­tion take less space than us­able ones and are greyed out. Sta­tus texts help new play­ers un­der­stand­ing what to do and fur­ther im­prove the iden­ti­fi­ca­tion of the cur­rent mode/con­text. The an­i­ma­tions and tim­ings are fine-tuned to be as smooth as pos­si­ble and be rel­a­tively fast to not bore the player. The an­i­ma­tions are ac­tu­ally quite im­por­tant be­cause they show where an ac­tion orig­i­nates from. There are prob­a­bly much more minor de­tails I could go into but even I do not re­mem­ber all the ex­plicit or im­plicit de­ci­sions I’ve made.

Summed up, this is what sets True Fool apart from other Durak games:

  • Focus on Us­abil­ity: help­ful vi­sual hints, very good con­trols and tight game­play
  • Be­gin­ner-friend­li­ness: in-game rules and an in­ter­ac­tive tu­to­r­ial
  • To be played in be­tween times with­out fric­tion
  • Cor­rect im­ple­men­ta­tion of Durak Rules
  • Few op­tions, good de­faults
  • Less fea­tures, more Durak: no sound, no start menu, no mul­ti­player, no Inn-App Pur­chases, no so­cial media in­te­gra­tion


First of all, with­out the help and good feed­back/sug­ges­tions/sup­port from my great testers True Fool would have been a much worse ex­pe­ri­ence. I would par­tic­u­larly like to thank Wadim, who was my first tester and helped me with the graph­i­cal de­sign, Sergey, who re­ally de­voted him­self to find­ing a lot of edge sit­u­a­tions and helped with the russ­ian trans­la­tion, Markus, who was giv­ing me great bug re­ports and game­play sug­ges­tions, Sven, who did the same, Oliver for giv­ing me feed­back and writ­ing a great re­view and Chris­t­ian for con­vinc­ing me that the game is fun.

With­out the ex­is­tence of ser­vices like openclipart.​com or icon­finder the graph­i­cal de­sign would have turned out much worse. libGDX is a re­ally good and free game frame­work and with­out its ex­is­tence I doubt that I would have cre­ated True Fool in the first place. Al­though young, Kotlin is a re­ally nice JVM lan­guage that made cod­ing much more fun.

I also want to thank every­one who left a good re­view/rat­ing on one of the stores!

Fur­ther Work

There are a lot of minor sug­ges­tions from my testers and my­self that would im­prove cer­tain game­play and other as­pects. These will be cu­mu­lated in the next re­lease.

Cur­rently, there are >1000 An­droid and >2000 App Store in­stal­la­tions of the free ver­sion. Trac­tion is still there, too. I plan to do a bit of ad­di­tional mar­ket­ing to see if I can in­crease these num­bers though.

Prior to that, I want to im­prove the AI. It plays okay, cur­rently, but it is quite sim­plis­tic. It’s es­pe­cially ap­par­ent at the end of the game when only two play­ers re­main. Mak­ing the AI re­ally good with­out too much of an com­pu­ta­tional over­head is quite chal­leng­ing though. I have ac­tu­ally writ­ten a Durak spec­i­fi­ca­tion aimed at com­puter im­ple­men­ta­tions of Durak. It could be used as a basis for other Durak pro­grams. One idea I had is an on­line Durak AI con­test which I’d find re­ally cool. It’d be a lot of work though.

The graph­i­cal de­sign is ul­ti­mately that of a pro­gram­mer. It’d be great if it were im­proved but that would in­volve pay­ing a graphic de­signer a lot of money. Some play­ers asked about an on­line mode but I don’t feel it fits my vi­sion of True Fool. If any­thing, there would be an­other ver­sion, e.g. “True Fool On­line”, whose in­ter­face and game­play would be op­ti­mized for mul­ti­player gam­ing. Sim­ply tack­ing on mul­ti­player on True Fool would not work. Some other things that could be done (and were sug­gested by play­ers) would be cus­tomiza­tion (e.g. a change­able back­ground) for the pre­mium ver­sion and sounds. I also wanted to try in­ter­sti­tials be­tween plays in­stead of a ban­ner for the free ver­sion.

There are some (cur­rent) short­com­ings with re­spect to cod­ing in Kotlin, libGDX and Gra­dle. Com­pi­la­tion times should be in­stan­ta­neous, it’s a form of us­abil­ity! Kotlin should al­ready reach 1.0 ;). Gra­dle should be much more in­tu­itive and faster and writ­ten in a sta­t­i­cally typed lan­guage. Mo­bile game de­vel­op­ment should be more like web de­vel­op­ment, e.g. hav­ing ef­fects like drop shad­ows, styling sup­port, fonts, an easy way to cre­ate UIs. UI pro­gram­ming in gen­eral should be level-upped. I don’t have the power to im­prove these things from my end (al­though I re­ally would like to tackle these prob­lems) and, any­way, these would be mon­u­men­tal ef­forts but it would be worth­while to im­prove the sit­u­a­tion in my opin­ion. There are also some un­in­tu­itive and an­noy­ing things about libGDX’s API or rather things to be aware of when using libGDX that the API it­self can­not pre­vent. Dy­namic scop­ing would al­le­vi­ate some of the prob­lems (like pip­ing quasi-global pa­ra­me­ters through classes, func­tion calls be­cause of An­droid’s prob­lems with sta­t­ic­ness).

When will I find the time to do all this? I don’t know, frankly. I’m cur­rently quite busy prepar­ing for the next step after my soon uni­ver­sity grad­u­a­tion.


In terms of cod­ing, one should not be afraid to throw away code and be pre­pared for pain points when using young tech­nolo­gies. A us­able in­ter­face is most prob­a­bly not achieved on the first try but takes a lot of test­ing and feed­back. In terms of lo­gis­tics, i.e. hav­ing to man­u­ally main­tain and man­age a pre­mium and free ver­sion in the Play, App and Ama­zon store, be pre­pared for a lot of mun­dane work and error prone­ness. In terms of store re­views be pre­pared for some un­fair, un­true and very de­mand­ing ones. In the be­gin­ning I placed a bit too much (emo­tional) value on them think­ing some­thing along the lines of “Oh man, I need to hurry to get this fea­ture done / prob­lem solved to ap­pease this per­son”. But then I found this very in­sight­ful thread which made me re­al­ize that it’s sim­ply not worth to try to ap­pease every sin­gle wish of your play­ers. In terms of ad-based rev­enue it re­ally is less than I thought ini­tially.

In terms of the over­all game de­vel­op­ment process this blog post re­flects my own im­pres­sions with True Fool bet­ter than I could have de­scribed them my­self. The fol­low­ing are some quotes that co­in­cide par­tic­u­larly well.

You also have to learn that un­like the browser en­vi­ron­ment, OpenGL gives you very few vi­su­als for free [..] For a web de­vel­oper, it is a bit of a cul­ture shock to find your­self with­out CSS, or even any us­able fonts.

Whereas a web pro­gram­mer usu­ally deals with nice snap­shots of data at given in­stants, the time el­e­ment in­her­ent in an­i­ma­tion cre­ates many tran­sient bugs.

Al­though the total de­vel­op­ment to that point had taken about a month of evenings, it was eas­ily an­other month be­fore I was con­fi­dent that every­thing had been fixed.

Usu­ally dis­tri­b­u­tion is very much some­body else’s prob­lem. In this case, it was still all up to me.

Work­ing in a team is usu­ally great - and you can achieve so much more; yet there’s supreme sat­is­fac­tion in build­ing some­thing all of your own. There’s lots to do; a solo indie de­vel­oper has to wear a lot of dif­fer­ent hats - de­signer, pro­gram­mer, tester, com­poser, mar­keter, trilby. I learned a lot.

A red­dit com­ment suc­cinctly puts an­other key in­sight I had.

[..] Mak­ing a thing is way eas­ier than mak­ing this thing fun.

An in­sight from the startup world I found and re­ally like is about hav­ing re­al­is­tic ex­pec­ta­tions when re­leas­ing some­thing you have cre­ated. Suc­cess usu­ally will take much more work and time than ini­tially an­tic­i­pated.

An idea is not a de­sign
A de­sign is not a pro­to­type
A pro­to­type is not a pro­gram
A pro­gram is not a prod­uct
A prod­uct is not a busi­ness
A busi­ness is not prof­its
Prof­its are not an exit
And an exit is not hap­pi­ness.

  1. Frankly, I didn’t even un­der­stand MVC or the de­sign pat­terns I tried to use at the time which nat­u­rally did not im­prove things. 

  2. The Trailer’s in Russ­ian be­cause the Play Store sta­tis­tics showed that the bet­ter part of in­stal­la­tions came from Rus­sia so I wanted to tar­get this au­di­ence and didn’t want to cre­ate three trail­ers. 

  3. The pre­vi­ous pro­ject is Knotty Ropes which was cre­ated in a team. I need to write an­other blog post about it some­day and the dif­fer­ent de­vel­op­ment ap­proaches be­tween Knotty Ropes and True Fool. 

  4. Al­though, in the be­gin­ning I had no idea how ex­actly the UI should be bet­ter and it took more than five UI it­er­a­tions until my testers and I were sat­is­fied. See also the video later in the ar­ti­cle. 

  5. It’s a pity the video doesn’t show the multi-touch ca­pa­bil­ity of the old ver­sions. A multi-touch UI where you could stack cards by using two fin­gers took me al­most two days to write. The code was un­man­age­able but I was re­ally proud. Then I tested it with my play­ers and, first of all, they didn’t even no­tice that it is pos­si­ble to stack cards and, on top of that, they dis­liked the stack­ing UI. Into the trash it went. It hurt a bit to throw away hard work but it is some­times for the bet­ter. 

  6. The green plus sym­bol that is some­times on a card is an­other form of vis­i­bil­ity. It was added due to user feed­back to make it clearer that cards can be stacked. 

Published: 24.08.2014
Comment? Mail or tweet me.