commandos-style mobile strategy game

Some time ago, I tinkered with the idea of creating a mobile game that brings the classic “commandos” style strategy gameplay to touch-enabled handheld devices.

If you don’t know commandos or what it’s main gameplay mechanics are, take a look at the following video.

In a nutshell: It’s a real time strategy game focusing on stealth elements. Your protagonists seek to complete mission goals like “blow up that thing” or “reach that special area of the map without causing alarm”. You can use various tools to achieve this. Enemy units on the map can spot you and cause all kinds of trouble — it’s best to remain silent and unseen.


To play with the technology needed in order to provide the basic gameplay elements, I implemented some of them and fiddled. This ultimately led to me uploading the rather unspectacular results to YouTube and not even commenting on them.

Now, I’d like to reiterate and describe what they actually show.


These proof-of-concept-like implementations where done using android 4 and tested on the original Nexus 7.

The sparse game view shown in the videos below is to be seen as a 2d top-down view (I guess it’s a bit hard to see).

Gameplay mechanics “enemy patrol route” and “enemy field of view”

In a commandos like game, we’ll need patrolling enemy units. Each should follow a predefined path and have a 90 degree field of view (FOV) that, when intersecting with game objects, must be clipped. For example: a patrolling soldier cannot look through a wall.

Let’s have a look, shall we?

What we have here is a simple path that is followed by a (invisible) patrol instance. The only thing visible is the green field of view of that instance and it also follows the aforementioned path, simulating that the patrol always “looks” in the direction of travel. This was accomplished by using a generic path object and simple geometry — nothing special here.

When intersecting with a game object (the grey box), the field of view turns yellow and the part that gets clipped turns red.

This was accomplished by calculating intersections between any game object and the FOV of our patrol instance and cumbersome evaluation and construction of a new “clipped FOV” polygon.

The lesson learned is definitely to use an approach called “ray casting”. Basically, the root of the FOV should emit virtual rays for the complete FOV (that is 90 degree in angle, possibly in steps of 1 degree or smaller). When intersecting with a game object, the intersection should be checked regarding their distance from the FOV root (how far the patrol unit can “see”) and thus giving us a point for a new “clipped FOV”.

Based on that clipped field of view, a determination of whether the player object is actually “seen” by one of the patrols can be done. But that wasn’t part of my implementation.

Gameplay mechanic “player path finding”

Next up is path finding. The user must be able to send the player object to a different location in the game world without worrying about objects blocking the direct path to the destination.

For this, I wanted to try implementing a simple path finding myself, instead of relying on already existing algorithms like A*.

As you can see, the game world consist of an obstacle (grey), blocking a direct path. The player object (a small black square) moves to a destination by tapping it. When moving, the path is visible for debugging.

This was achieved by continuesly checking whether the destination can be reached directly and if not, taking 45 degree (if I remember correctly) corners to the left for a very short path — then checking again and so on until the destination is reached. Off course, taking only left turns is not suitable for finding the shortest path (see end of the video, at index 0:24). Also, the path is kind off jagged, which is a result of always making turns when the destination can not be reached.

Originally, I planned to generate the path in 2 batches: First, the rough path (as seen in the video) and second: Smoothing that path by comparing each path node with the node after the next node to find out if a shorter route can be used.

The lesson learned is: silly me, use A* next time


Since I’m not a game designer but a software engineer, my game ideas are not quite fleshed out or even fully thought through and I am aware of that.

But I hope you found this little digression entertaining or even inspiring, I had a lot of fun writing it.

As much als I’d like to play a game like commandos on my phone, I’m not aware of any game in existence to deliver the atmosphere and mechanisms commandos used. Do you know any?