Dokusen: The Art of Domination [Gameplay basics]

Recently I was skimming the forums where I advertised my new puzzle game, Dokusen, and realized someone had made a comment about how they had no idea how the rules worked. I was planning on writing a post about the game’s rules anyway, but this made me decide to do it sooner rather than later.

Each stage has a different board size and shape, along with a different set of players. The types of players are as follows:

1) User player: the person playing the game, present on all board levels.

2) Inactive player: a player who begins the stage owning one or more squares. This player type does not place any more tiles with intent, but the existing tiles will spread automatically.

3) Active player: Same as an inactive player except it gets to play a new tile once each turn like the user player.

Basic game flow

1) User player plays a tile of their color in any legal square. Legal squares are defined as any square except one already owned, in other words either a black square (not owned) or one of a different color which is owned by an enemy (active or inactive player).

2) If present, one or more active players each play their color tile on any legal square. The level of skill of the active players depends on the stage.

3) All tiles that are currently on the board are then expanded or “grown” to legal spaces, if any.

4) Special effects will then take place (such on meteors on stages where they appear)

5) Back to step 1, where the user player goes again. The game ends when all the squares are taken. If the user player owns over half (50%) of the available squares, that stage is won and player proceeds to the next stage. Otherwise, it is a loss and the stage must be replayed.

The only other thing that needs to be explained is the rules for “growing”. They are actually pretty simple – a square will change ownership to whatever color is surrounding it on more sides (up, down, left, right) than any other color, excluding black. To see this in action, let’s look at the first few moves for level 5, which contains a inactive player owning four squares at the start of the level.


The user player decides to play on the topmost square, and you can see this represented by a white dot. After that, the tiles around squares of both the user player and the inactive grow and expand outwards.


Let’s talk about two squares and why they changed colors during the growing process.

1) Top left blue square above: this one was bordered by black on left and bottom, nothing above, and blue on the right (the one the user player just put down). Since black doesn’t count, the square was ‘dominated’ by blue and so it became blue.

2) Square in the middle of the board: this one was bordered on all sides by orange, so it became orange.

For the next turn, the user player (blue) decides to play on the bottom center of the board. During the growing stage, this new blue square expands to the left and right, but does not grow up. This is because there is an orange square two above it, such that the square about the newly placed square is bordered by black on the left and right, orange on the top, and blue on the bottom. Since there is a tie, the color doesn’t change.


I hope this explanation made the rules a little clearer, but if you have any questions feel free to comment on this post.

I recorded a short video of the above game which can see below. I ended up loosing, but the purpose of this post wasn’t to teach strategy. I may do another post on that later.

Difficulty in gaming

Difficulty of a game, how hard or easy it is and in what way, is an extremely important factor in game development. This is something good to keep in the back of your mind in nearly all stages of game development, including brainstorming, prototyping, implementation, and testing.

It’s easy to think about difficulty in simple terms (e.g. “This game is easy”, or “This game is hard”), but it’s actually much more involved than that. In this article I’ll discuss some of my ideas about difficulty in games.

Types of difficulty

Rather than a purely linear continuum, there are different types of difficulty that are good to be aware of, especially when deciding on your target audience. It’s pretty rare to find a game that just involves one of these – usually you get a mix of two or more.

A common type of difficulty in many games is calculational. These types of games challenge you to think ahead several steps and predict the outcome of a combination of events. A classic example of this is chess, and the ability to calculate ahead a few moves (along with a few other factors) is one of the keys to being a strong player. A related type of challenge is tactical, where players have to think about the relative positions of friendly and enemy units (ships, planes, tanks, whatever), and predict what the outcome of a battle will be.

Reaction time is another type of difficulty which can be seen in many popular mobile games like Mr. Jump or Alto’s Adventure, the latter of which is currently the #1 paid app on iTunes. In these types of games, besides being able to respond quickly to changes in your environment, you also have to estimate things like distances and paths you will take.

Memory difficulty is one that is less common in mobile games, though having a good memory may make it easier to remember common patterns to solve puzzle games. A good example is the class board game “Memory”. A language learning game that tests your knowledge of words using a flashcard-style interface is another example.

Another one is endurance difficulty, which means that you have to survive a long time in order to pass a certain point or level in the game. An example of that is many RPG games where bosses can take 30 minutes or longer to beat. The placement of save points (or some other mechanism to save state) is an important factor here. One of my pet peeves is games where you die after one mistake, putting you back minutes or even longer.

One final one to mention is system difficulty, which can also be called learning curve. By this, I mean the time required to learn the basic rules of the game before you can actually make any progress. A game with good tutorials reduces this type of complexity, otherwise it can take the user much experimentation to figure out what to do. I’ve played a few mobile games that seemed really great at first, but I lost patience and gave up before I got the hang of the system.

There are many others, such as deduction, but I think I covered the most common ones here.

Satisfaction and actual vs perceived difficulty

For a straightforward game like chess, the difficulty is obvious and there is no effort to convince the player otherwise. For other games, like the famous mobile game Candy Crush, there are a lot of distractions to take your mind off the basic gameplay elements. Candy crush has sound effects, exploding animations, and messages that pop up now and then to complement you (for example, “Sweet!”). As a result, you could tap somewhat randomly and feel like you are doing an awesome job. (Confession: I have not played this game for more than a few seconds, so I can’t claim to be an expert on it’s gameplay)

Ultimately, what’s more important than the objective level of challenge is the satisfaction gained by the player when he or she makes progress. If the game can fool you to thinking that you did an awesome job at the “difficult” task of randomly tapping, then great.

Difficulty ramp-up

How difficulty increases in your game is another important factor. Is there a bunch of levels with similar difficulty until you get to transition point when things become suddenly harder? Or do things gradually get harder as you progress? The user will quickly create their own expectations after playing your game for a few minutes, and if you betray those frequently that are liable to give up.

Another important factor is how/if you notify the user about the difficulty for each level or area. Is there a big sticker that says “HARD” on certain levels, or a color scheme? Is hinted at from the name of the level?

When you do increase the challenge level midway through a game, consider giving them several options. For example there could be three stages, from which they only have to beat one to move on. Forcing users to beat a certain stage which is extremely hard, with no other options, is one way to quickly alienate your users.

All or nothing vs optional goals

Rather than requiring perfect performance to complete a level, a common technique is to allow getting through the level somewhat easy while including optional goals that give extra points. For example, some mobile games will show you one, two, or three stars, indicating how well your performance was on a certain level. You can usually replay any level to try and get a better score, and replay value is always a great thing for games. This is another way to reduce the chances of users getting frustrated and giving up on your game.

Interpretation of difficulty

Ultimately, difficulty is a very subjective thing and varies between users. One game I might think is a piece of cake you might think is a nightmare, and vice-versa for a different game. Users may be less inclined to worry about the difficulty if the game has nice visuals and enough feedback (like the Candy Crush example above).

For seasoned gamers, each genre has it’s own expectations dictating what is reasonable. For example, many console RPGs from the 80s were known to have hours without a save point, and those who beat them got bragging rights. Users will be comparing your game to others in the same genre and if you deviate too much it may catch them off guard. For example, a puzzle game where the first few puzzles each take roughly 3-4 hours would be pretty unorthodox and scare away many players.

Because of the subjective nature of challenge, doing proper beta testing with users from your target demographic is extremely important to a successful game. Ideally, you would watch while they play, observing where they got stuck and where they blew through effortlessly. Ask each of them how they felt about the difficulty – was there any surprises and was it satisfying enough?

Using only main developers for gameplay testing is dangerous because they have a very biased view of game, with prior knowledge the basic rules and tricks. Until you show someone outside the team you’ll never really know how difficult and intuitive the game is, and the more people that playtest the better.

In fact, one can get a good feel for the difficulty of a game before the visual polish is complete, so consider making quick prototypes of the basic gameplay and having your testers try those at an early stage in the game’s development.

(Image credit:

Gameplay element: warp-in time

In this post, I’d like to focus on a gameplay element from my mobile game Play The Field and see how it helps improve the game’s overall balance and sense of fairness.

In traditional Real Time Strategy games (like Blizzard’s Starcraft series), each unit type can only be created at a specific building, and there is a time delay between the time the user decides to start building a unit and when it is finished. The opponent typically doesn’t know what unit is being built, but in some games like Starcraft 2 there is an indication that something is being built.

In Play The Field, in other to create new opportunities for tactics and avoid the extra work of maintaining buildings, units can be played anywhere on the map, given there is sufficient funds. The only exception is a few boards which have one or more red region(s), at which units cannot be placed.

In order to balance out for this extra freedom in unit placement, I made each unit take time to ‘warp-in’. During that time there is a visual indication that the unit is coming in and the enemy player can begin attacking the unit even before it is fully warped in. While a unit is being warped in it cannot attack or movie.

By adding this game element, the player has to have a good idea about the maximum attack distance of each unit and put more consideration into placement, which adds depth to the game. Placing haphazardly can lead to wasted funds and possibly even loosing the stage.

As with most gameplay elements, ideas only go so far – you have to test them. After playing a bunch of stages with this element enabled, I felt confident that it improved the game’s challenge in a fair way. It also helps to balance units that do spread damage to several opponents at once, since they cannot immediately appear in the middle of a enemy crowd and do damage before they are taken down.

Desktop Games vs Mobile Games: input method differences and how that effects gameplay

Although I had originally created this blog mainly to be a home base for my mobile game Play The Field, after some consideration I’ve decided to put a heavier emphasis on mobile game design in general. I think this will be more interesting for readers, as well as myself, in the long run.

In this post I’m going to focus on input control differences between desktop and mobile games, and how that effects gameplay.

For the desktop, the primary devices for input are the time-honored combination of mouse and keyboard. On mobile devices, a touch screen is the primary method. For now I’ll stay away from alternate methods such as console-style controllers, acceleration sensors, audio, and other custom devices like food pedals.

The first thing to note is that, given the user does not have any major physical handicaps, you can manage inputing nearly any type of content on either desktop or mobile. What is different, and what really matters, is how easy it is for each content type.

To give a specific example, typing up a document can be done on either a standard desktop keyboard, or on a in-screen mobile keyboard, but the latter is typically much difficult or at minimum awkward due to lack of force feedback, key sizes, and other factors. This isn’t the best comparison, however, since you can get a mobile keyboard to partially solve this problem.

For the rest of this post I’d like to focus on comparison of the desktop mouse vs the mobile touch screen, as they tend to be the main input methods used for a majority of games on each platform.

On the surface, these two input methods seem quite similar – after all, in both cases the user can pick a point roughly corresponding to the display screen. In other words if I want to click on a balloon which is floating on the screen, the conceptual action of clicking vs touching it is not that different.

One of the differences is that mice have two or three buttons, while a touch screen effectively has one. Also, mouse double clicks don’t translate too well to double taps on the screen; they can be done in theory but are rarely used in the mobile apps I’ve used.

What I consider even more important is the fact that tapping all over a mobile screen is just a lot more physical work than moving a mouse cursor the same relative distance on a desktop monitor. The higher the mouse sensitivity is set the less distance the hand has to move to translate to larger distance on the monitor. At the highest setting, crossing the entire monitor can take less than an inch of real distance, whereas on a mobile device the user has to cross the physical size of the entire device.

Another weak point of mobile devices’ touch screens is accuracy. Since you usually don’t know the exact pixel you are clicking on (like with a mouse cursor), there is uncertainty about exactly where you are clicking. The smaller the screen the larger this uncertainty is relative to the screen’s total size. Much of the problem here stems from the fact that the place you are touching is exactly the place that you can’t see, since your finger is obscuring your vision there. One pretty effective technique used in iOS to combat the accuracy problem when selecting text is to show a magnified view of the text and selected area.  Buttons and the like are also typically much larger on mobile apps.

What all these drawbacks mean is that input for mobile games, and mobile apps in general, tends to be much simpler. If you look at the most popular apps, you’ll find a good percentage of them have, well what I feel as maddeningly simple input control systems.

To give one iOS example that is a bit dated, the game Jetpack Joyride involves a character in what looks at first like a classic side-scroller, except the major difference is the control is super simple. Tap to jump, don’t tap to do nothing. The character moves to the right automatically so no other buttons required.

Another more example, a bit more modern, is Hellrider, where a motorcyclist runs literally through “hell”. The controls are equally simple: tap to change directions, don’t tap to keep driving in the same direction. The only two directions are forward-left and forward-right.

Both of these games were actually kind of fun for the first few minutes, but with so many years of mouse+keyboard experience I just couldn’t get over how limited and simplistic the input controls where. Sure, mobile games with such simplistic controls (and believe me, they are a dime a dozen) can have great elements like a   great graphics, engaging music, challenges, and require a certain level of strategy and persistence to beat, the extreme lack of options as the user just endlessly annoys me.

Fortunately, some games try to make the best of mobile touch screen’s strong points and increase interactivity. One good example is the classic Fruit Ninja, which utilities multi-touch and gestures, neither which work too well in the normal mouse-keyboard world. The result is much more satisfying to me, since I am not just dumbly taping the screen (albeit with perfect timing).

Another genre that I enjoy that has taken up a lot of popularity on mobile platforms  is defense games (or tower defense games). These typically involve a setup period where you place your buildings and units, and then start the game to let the battle unfold. It’s fun to watch the action and cheer for your side, and the level of control you have is much higher than the click/don’t click style I discussed above. But a key point here is that the setup time is typically not timed and you don’t have to rush to place buildings and units, and once the hectic battle begins you don’t have to do much but wait (though sometimes you can upgrade or do other tasks). Again, comparing to full RTS games on the desktop where you can change the orders of unit’s in the heat of battle, I feel there is a loss of control and as a result less enjoyment. There are such full-featured RTS games on mobile platforms, but they are relatively rare and typically not given away from free.

Having tried a great many iOS games (most free and/or from one of the ‘popular’ categories in the app store) and being disappointed with the lack of rich, engaging controls is one of the things that inspired me to develop Play The Field. I took some of the basic aspects from the RTS genre and boiled things down to their simplest elements: creating units (of various types), moving them, and attacking. The important thing was that both placement and control of units happened during the game, in real time, so I was never forced to sit back and watch dumbly, or just slam the screen with some perfectly-timed pattern. To help things out, I took a cue from games like Fruit Ninja and added gestures for unit creation and selection to remove tedious machine-gun tapping.

I think the end result is fun and challenging, if you are interested try it out here:

(Image credit: Matt Trostle (creative commons attribution license):

Play The Field – quick demo video

Due to a problem with the app preview video for 1.0 there is only static screen shots viewable at present, show in this post I’ve included the video which was supposed to be included in iTunes.

When you see a line of units being spawned quickly, that is done by simply moving your finger across the screen to create any sort of formation.