The Story Behind ‘True Fool’

The story begins in late Summer of 2009. As long as I can remember I was interested in programming. Unfortunately, I never was succesful with my sporadious programming endeavors. Whenever I tried to learn programming, a programming language or a library/framework/tool—most of the time during school holidays—I gave up sooner rather than later primarily because I lacked the necessary discipline to put myself through the hard stuff. Programming and all that it encompasses is simply not an easy task to learn let alone to master. But this time it was different I told myself. I am going to use my free time before starting my university studies to finally finish a programming project: Durak, a fairly popular card game in post-Soviet states.

I learned Durak fairly young from my grandmother and since then I played it here and there. It seemed a perfect and manageable task for a month I thought. At first I had to find a game engine resp. framework for Java as I wanted to implement a game and not an engine. I found Pulpcore, a game framework ahead of it’s time. Unfortunately, the trouble already began when implementing the class representing a playing card.

Of course, I must follow MVC by the book and not by the idea and I must prepare for future requirements by making the classes as general as possible. Design Patterns must be incorporated no matter what. I am a good programmer after all!

This misguided attitude lead to a lot of classes, complexity and doubts. I had not yet learned to weigh the trade-offs of code architecture decisions. Plus, I severly underestimated the intricacies of implementing the game logic. After a lot of trial and error I think I got the basic rules right. But the resulting code was so messy and hard to understand… I am pretty sure there are still bugs lurking somewhere and I dont want to imagine how to modify the code to implement the more interesting advanced rules of the game. Some further former attitudes follow.1

Usability? Haha, the programs I write are usable by default. I am a good programmer after all. If somebody does not understand how to interact with my software he is obviously stupid. Double-clicking to signal passing should be crystal clear, no need to inform the player. Source Control? Never heard of it. Having a dozen different folders is good enough. AI’s must be scriptable, right? So I need to have a JavaScript scripting interface for implementing the AIs. I could never write the AIs in Java, that wouldn’t be scripting, silly me.

Anyways, I don’t want to go into more details of my misguided former self :). Even with all these problems I managed to “finish” the project albeit in a much more rudimentary state than I had imagined in the beginning. The following is a video of the project’s evolution. After 1:40 I just play a game from start to finish in real-time so you might want to skip this ;). You can even play the game for yourself online: http://storytube.kilu.de/. And the following post on java-gaming.org already then showed my interest in formalizing problems in code as clearly as possible.

The story does not end here. I promised myself to revisit the task of implementing Durak as a fun computer program once I completed my university degree in order to see if I improved over the course of the following five years. It helped that fellow students and I somehow started playing Durak whenever we had eaten lunch rather religiously. Thus, my motivation to revisit the task only ever increased and I knew that I had some very critical testers to provide me with valuable feedback. The rest of the article will go into more detail of my second Durak endeavour and here is the trailer of the completed game by the name of “True Fool“.2

True Fool is available at the following places.

Motivation

As mentioned in the introduction, the main motivation for me to create True Fool was for it to be a test of my self-improvement. I just knew that there had to be a better way to code Durak. Yet, I couldn’t see it since my experience and knowledge were rather limited in 2009. In 2014, however, I had a much clearer picture of how to tackle this problem and I wanted to see if I finally got what it takes to solve it properly.

Since in 2014 mobile devices and games were much more widespread than in 2009 and since I had some previous mobile game development experience I naturally decided to make True Fool a mobile game. Of course, I wanted to find out if there already were Android/iOS Durak games to be inspired by and to identify potential shortcomings that I may want to avoid. The one huge problem I had with basically all of these Durak manifestations was that playing them just didn’t feel as fluid as I think it should have been even with the popular premium games that otherwise boasted a lot of impressive features. In short, I wasn’t satisfied with their usability and I wanted to show that I could do better.34

Last but not least, writing a Durak game is simply an interesting challenge. There is the part that is concerned with modelling the game and its rules in code. Thinking about use cases, weighing trade-offs, considering the resulting code usability, fruitfully combining language features while trying to keep it all simple is just a fun thing about designing code. Getting the rules, the behavior, the UI and all the edge cases right requires a lot of logical thinking (to cover all the cases correctly), imaginative power (to think of the edge cases) and endurance (to find all the edge cases). Creating a usable UI whose code is managaeble is really hard and fun. Making the AI intelligent is also a fun challenge.

Evolution 2014

The following video shows some of the various iterations of True Fool.5

All in all, you could say I had around five different UI versions until I arrived at the one that my play testers and I were really satisfied with. It was important to try things out and to gather feedback from the testers. It led to a lot of code that was written with effort yet had to be thrown away ultimately. One of the important lessons for me therefore, at least for game code, is to be prepared to throw it away if it implements a non-fun interaction no matter how hard it was to create it.

Usability

As stated earlier, I wanted set True Fool apart from other Durak games by having a much more usable and intuitive interface. One of the main problems I saw even in the popular premium games was a lack of visibility in several respects. For example, in some games the player has to double-tap to signal passing. This is not obvious and has to be explained to the player. But especially a player unfamiliar with Durak might forget this. Which leads me to visibility of the context resp. context awareness.6

In Durak, there are basically two modes: attacking and defending. Many games, in my opinion, do not make it clear enough in which mode the player currently is and who is currently being attacked. This is the reason for the sword/shield marker in True Fool. Also, the buttons are displayed depending on the context and make all available actions in a situation visible. Some buttons map to the same place in a different context which is why I tried to map buttons with a similar action to the same position and have the same color. Defend buttons are on the left and attack buttons on the right to make the contrast of different contexts even clearer and prevent subconscious errors where, e.g. the action of a button is confused because it is in the same place but in a different context.

Placing cards on the field in basically all games is more complicated than necessary. The chosen card must be manually dragged on the playing field or on the attacker card to be defended. In the vast majority of situations, however, there is only one possible action for a card so manual dragging is much too explicit (compare to type inference for local variables in programming languages). This is why in True Fool simply tapping a card will choose the one possibility. Yet, if there is more than one possibility for a card when defending, a drag symbol is displayed under the corresponding “ghost card” (see the video to understand the concept of ghost cards) to allow for the needed explicitness in rare situations but not penalize the common situation with unnecessary explicitness.

Choosing a decision and committing it can be distinguished in True Fool (the reason for the ghost cards). This makes it also possible to have a good UI for attacking/defending with several cards at once. This way as a player you can also plan your defense better since when choosing a card for defense other cards in your hand which become unapplicable due to this choice are faded out. In general, cards which are unapplicable in a situation are faded out to help you concentrate more on the strategical aspects of Durak than on the busy-work of identifying which cards can be used and which not.

There are also expert controls which are quicker and avoid the pushing of buttons. This expert control is basically flinging a card. It also works when having stacked several cards. True Fool is novice-friendly because of the visual hints, an interactive tutorial and in-game rules. All the available horizontal space is used for the player hand to improve detection of card selection. Also, the playing hand is like an accordeon, i.e. unusable cards for the current situation take less space than usable ones and are greyed out. Status texts help new players understanding what to do and further improve the identification of the current mode/context. The animations and timings are fine-tuned to be as smooth as possible and be relatively fast to not bore the player. The animations are actually quite important because they show where an action originates from. There are probably much more minor details I could go into but even I do not remember all the explicit or implicit decisions I’ve made.

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

  • Focus on Usability: helpful visual hints, very good controls and tight gameplay
  • Beginner-friendliness: in-game rules and an interactive tutorial
  • To be played in between times without friction
  • Correct implementation of Durak Rules
  • Few options, good defaults
  • Less features, more Durak: no sound, no start menu, no multiplayer, no Inn-App Purchases, no social media integration

Acknowledgements

First of all, without the help and good feedback/suggestions/support from my great testers True Fool would have been a much worse experience. I would particularly like to thank Wadim, who was my first tester and helped me with the graphical design, Sergey, who really devoted himself to finding a lot of edge situations and helped with the russian translation, Markus, who was giving me great bug reports and gameplay suggestions, Sven, who did the same, Oliver for giving me feedback and writing a great review and Christian for convincing me that the game is fun.

Without the existence of services like openclipart.com or iconfinder the graphical design would have turned out much worse. libGDX is a really good and free game framework and without its existence I doubt that I would have created True Fool in the first place. Although young, Kotlin is a really nice JVM language that made coding much more fun.

I also want to thank everyone who left a good review/rating on one of the stores!

Further Work

There are a lot of minor suggestions from my testers and myself that would improve certain gameplay and other aspects. These will be cumulated in the next release.

Currently, there are >1000 Android and >2000 App Store installations of the free version. Traction is still there, too. I plan to do a bit of additional marketing to see if I can increase these numbers though.

Prior to that, I want to improve the AI. It plays okay, currently, but it is quite simplistic. It’s especially apparent at the end of the game when only two players remain. Making the AI really good without too much of an computational overhead is quite challenging though. I have actually written a Durak specification aimed at computer implementations of Durak. It could be used as a basis for other Durak programs. One idea I had is an online Durak AI contest which I’d find really cool. It’d be a lot of work though.

The graphical design is ultimately that of a programmer. It’d be great if it were improved but that would involve paying a graphic designer a lot of money. Some players asked about an online mode but I don’t feel it fits my vision of True Fool. If anything, there would be another version, e.g. “True Fool Online”, whose interface and gameplay would be optimized for multiplayer gaming. Simply tacking on multiplayer on True Fool would not work. Some other things that could be done (and were suggested by players) would be customization (e.g. a changeable background) for the premium version and sounds. I also wanted to try interstitials between plays instead of a banner for the free version.

There are some (current) shortcomings with respect to coding in Kotlin, libGDX and Gradle. Compilation times should be instantaneous, it’s a form of usability! Kotlin should already reach 1.0 ;). Gradle should be much more intuitive and faster and written in a statically typed language. Mobile game development should be more like web development, e.g. having effects like drop shadows, styling support, fonts, an easy way to create UIs. UI programming in general should be level-upped. I don’t have the power to improve these things from my end (although I really would like to tackle these problems) and, anyway, these would be monumental efforts but it would be worthwhile to improve the situation in my opinion. There are also some unintuitive and annoying things about libGDX’s API or rather things to be aware of when using libGDX that the API itself cannot prevent. Dynamic scoping would alleviate some of the problems (like piping quasi-global parameters through classes, function calls because of Android’s problems with staticness).

When will I find the time to do all this? I don’t know, frankly. I’m currently quite busy preparing for the next step after my soon university graduation.

Insights

In terms of coding, one should not be afraid to throw away code and be prepared for pain points when using young technologies. A usable interface is most probably not achieved on the first try but takes a lot of testing and feedback. In terms of logistics, i.e. having to manually maintain and manage a premium and free version in the Play, App and Amazon store, be prepared for a lot of mundane work and error proneness. In terms of store reviews be prepared for some unfair, untrue and very demanding ones. In the beginning I placed a bit too much (emotional) value on them thinking something along the lines of “Oh man, I need to hurry to get this feature done / problem solved to appease this person”. But then I found this very insightful thread which made me realize that it’s simply not worth to try to appease every single wish of your players. In terms of ad-based revenue it really is less than I thought initially.

In terms of the overall game development process this blog post reflects my own impressions with True Fool better than I could have described them myself. The following are some quotes that coincide particularly well.

You also have to learn that unlike the browser environment, OpenGL gives you very few visuals for free [..] For a web developer, it is a bit of a culture shock to find yourself without CSS, or even any usable fonts.

Whereas a web programmer usually deals with nice snapshots of data at given instants, the time element inherent in animation creates many transient bugs.

Although the total development to that point had taken about a month of evenings, it was easily another month before I was confident that everything had been fixed.

Usually distribution is very much somebody else’s problem. In this case, it was still all up to me.

Working in a team is usually great - and you can achieve so much more; yet there’s supreme satisfaction in building something all of your own. There’s lots to do; a solo indie developer has to wear a lot of different hats - designer, programmer, tester, composer, marketer, trilby. I learned a lot.

A reddit comment succinctly puts another key insight I had.

[..] Making a thing is way easier than making this thing fun.

An insight from the startup world I found and really like is about having realistic expectations when releasing something you have created. Success usually will take much more work and time than initially anticipated.

An idea is not a design
A design is not a prototype
A prototype is not a program
A program is not a product
A product is not a business
A business is not profits
Profits are not an exit
And an exit is not happiness.


  1. Frankly, I didn’t even understand MVC or the design patterns I tried to use at the time which naturally did not improve things. 

  2. The Trailer’s in Russian because the Play Store statistics showed that the better part of installations came from Russia so I wanted to target this audience and didn’t want to create three trailers. 

  3. The previous project is Knotty Ropes which was created in a team. I need to write another blog post about it someday and the different development approaches between Knotty Ropes and True Fool. 

  4. Although, in the beginning I had no idea how exactly the UI should be better and it took more than five UI iterations until my testers and I were satisfied. See also the video later in the article. 

  5. It’s a pity the video doesn’t show the multi-touch capability of the old versions. A multi-touch UI where you could stack cards by using two fingers took me almost two days to write. The code was unmanageable but I was really proud. Then I tested it with my players and, first of all, they didn’t even notice that it is possible to stack cards and, on top of that, they disliked the stacking UI. Into the trash it went. It hurt a bit to throw away hard work but it is sometimes for the better. 

  6. The green plus symbol that is sometimes on a card is another form of visibility. It was added due to user feedback to make it clearer that cards can be stacked.