Game development: reducing scope (traffic simulation)

One of the tricks of game development, especially that done by small teams, is reducing scope of each feature or element to a minimum necessary level. It is critical to make efficient use of developers’ time since there is only so many cycles available, and the longer a project goes on the more likely it is to get cancelled or postponed. The more games you get under your belt the more you start to care more about this kind of stuff.

To give an example of this – one of the core elements of my latest game in development is a series of connected roads with cars running through them, a little like what you would see in a modern version of a SimCity-type game. Starting several weeks ago, I experimented with several different ways to implement this “traffic simulation” element in my game.

Initially, I started with the idea that I would use Unity 3D, since that would allow me to show a very realistic simulation of cars moving through a network of roads. I was inspired by the mobile game Does Not Commute, which uses a 3D engine to good effect.

However, after learning a little more about the Unity 3D workflow, I realized I would be spending a big chunk of my time on the graphics and other 3D elements, which would make the core gameplay elements (behavior, logic, rules) take that much longer to do. Though the end result might look quite attractive, I had doubts that I could finish the game on my own if I took this route.

So for the time being I decided to make the game 2D. My next decision was whether I should use a physics engine or not. I’ve been interested in physics engines myself for some time, having made very simple ones years ago, so I decided to download and experiment with a few different frameworks, including Box 2D. In only a few hours, I was able to get some test programs running and there was a surprisingly rich set of functionality for the free frameworks I tested.

But again, I posed the question to myself – do I really need detailed physics simulation? Is having cars collide, spin out of control, and follow a physically accurate path really critical to my game’s core gameplay? While this would be a cool feature, I eventually decided this was overkill, and again reduced the scope of my traffic simulation efforts.

At this point I entered into prototype development, spending my evening hours making a bear-bones traffic simulation where each car was resented with only a handful of properties such as color, location, and speed. I got this working and am now experimenting with different game objectives, and creating stages to see what is actually fun (and challenging) – the most important aspect of any game.

If things go well and I feel I’ve made an entertaining prototype, I can continue to polish the visuals, or even consider going back to 3D. With a proven game idea, the risk for failure would be greatly reduced.

If I had determined that simulating cars as individual entities was not a critical element of my game, I could reduce scope yet again and simulate at a coarser granularity. For example, in the original SimCity game (which happened to be the first game I purchased with my own money), traffic was handled by road-piece granularity, where a stock animation was selected based on the traffic density of that area at the given time. You couldn’t follow a single car around since they would appear and disappear if you looked closely. While a system of roads was important in building an efficient city, tracking an individual car from point A to B wasn’t necessary, and players had more to concern themselves with. Also, I believe the original SimCity was only made by two or three developers. In more recent versions of that series it seems that cars are modeled as individual entities.

I’ll post some more about this project as things progress.

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.

Dokusen: The Art of Domination Released [“go”-influenced puzzle game for iPhone]

Dokusen is a casual puzzle game which was just released on the Apple App Store for iPhone. It was heavily influenced by a favorite board game of mine called Go, and the game’s title “Dokusen” means “monopoly” or “domination” in Japanese (独占) in Japanese. It also shares some similarities with the classic game Othello.

Players take turns coloring one square at a time, and the game ends when all squares are colored, with the winner determined by the one with the most squares of their color. This may sound simple, but things get complicated fast since after both players take their turns, colored squares will “grow” outward to neighboring squares. The concept is a little bit like Conway’s Game of life.

As you progress through the levels, you are challenged with more and stronger opponents, and also have to rebuild when hit by falling meteors. The game is free on the app store, with no advertisements or in-app purchases.

You can see the game’s iTunes page here:

https://itunes.apple.com/us/app/dokusen/id1000275892?mt=8

Note: I was having problems the iTunes at one point. You can try searching for “Dokusen” in the app store if it doesn’t work.

This is the game’s app preview video:

I plan on writing followup posts with more details on the game, and maybe a brief tutorial. I’ll also be talking more about how I developed the game, so stay tuned!

Game Credits

App Preview Music: Throcke

Game Music: Eric Skiff

Game Sound Effects: http://www.freesfx.co.uk

Beta Testers: J.W. and K.G.F.

Dokusen: The Art of Domination – Coming soon to Apple App Store [6/22/2015]

After the usual week and half wait, my latest game was approved by Apple for distribution in the App Store for iPhone. I’ve decided I’m going to release it on Jun 22, but before then I’ll give a little more information about the game.

Dokusen, which means “Dominate” in Japanese, is a casual puzzle game that was loosely based off the ancient board came of “Go”, and involves trying to capture more space than the opponent(s) through a series of turns where each player chooses to claim a square. For those who are not too familiar with Go, you can think of it as being similar to the more modern game of Othello (sometimes called Reversi). An interesting fact is that this latter game was invented by a Japanese person and was influenced heavily by Go itself.

Since this game is free, and I’m developing it as a hobby, you might wonder why I would go to the trouble of setting a release date and delaying like this, when I could deploy my app to the app store with a few clicks.

One of the reasons is because I’ve heard that games released on Sunday statistically have more downloads, though I don’t have a great amount of faith in that. All things being equal, just changing a game’s release date to a different day of the week shouldn’t change the number of downloads that much.

A bigger reason is that by giving myself a few extra days I can more carefully plan my marketing strategy, which at this point will mostly consist on advertising an several forums. I did a bit of this for my previous game, but did it with less organization and several weeks after the game had been released. I’m hoping my renewed advertising efforts, plus a greater focus on visuals and ease-of-use in the game itself, will give a little more favorable results this time.

But above all, doing this makes me feel more like I am doing Game Development with a capitol “G”, meaning it’s much more than just writing a bunch of code. By doing this I can get a little taste of what it means to truly design, implement, release, and market a game – the full end-to-end process which is similar to what real game companies do (albeit at a much smaller scale). I’m also hoping that whatever I learn with this experience will be useful down the road, regardless of what I end up doing 5 or 10 years from now.

iOS game advertising stats: view count comparison of a view popular forums

For my first game on the app store, Play The Field (a casual RTS game for iPad/iPhone), I did some advertising experiments by posting in several related forums.

I think it’s important to separate the number of people who decided to click on the post title, and those who actually went ahead and downloaded the game as a result of reading the advertisement. For PTF, the latter number was pretty small so  I can’t say it was a real success. However, the former number is still important since it shows how many people reading each form were interested in the game baed on the title and the fact it was an iPad/iPhone game. These view statistics will come in handy when I try to advertise another game.

Since these numbers might help out others as well, I’ll post the exact number of views I got for my advertisements on each site, ranked with highest first.

• forums.toucharcade.com: 588 views
• forum.devmaster.net: 405 views
• forums.tigsource.com: 169 views
• http://www.armchairgeneral.com: 88 views
• http://www.gamedev.net: 36 views
• iosdeveloperforums.com: 15 views
• http://www.slidedb.com: 5 views

For my next game, I will very likely use the first two because of the great turnout (forums.toucharcade.com and forum.devmaster.net). The small number of views from the last site (http://www.slidedb.com) was especially surprising since there was many fields to fill out, and a 1-2 week period of waiting to be approved. All of that for a measly 5 hits!

I did achieve one minor goal, which was to not get banned from any sites. This was done simply by following all the rules for each of the forums involved. On all forums I only posted a single time, and only in the proper sub-forum.

One thing to keep in mind is that I submitted these posts over a week or two period, so some are a bit older than others. However, because I think most of the traffic comes in the first few days (when the post is near the top of the list), I think this has a minor effect on the overall hits. It would be an interesting follow-up post to check these again in a month or two.

I’ll put links to the posts below in case you want to see how I phrased things, though because of the low overall effect on downloads I think I need to work on writing more appealing, concise advertising text.

http://www.slidedb.com/games/play-the-field

http://www.gamedev.net/topic/668462-play-the-field-minimalistic-rts-game-for-ipadiphone/

http://forums.toucharcade.com/showthread.php?t=261996&highlight=play+field

http://forum.devmaster.net/t/play-the-field-minimalistic-rts-game-ipad-iphone/26744

http://www.armchairgeneral.com/forums/showthread.php?t=159587

http://iosdeveloperforums.com/forums/advertising-and-self-promotion.18/

http://forums.tigsource.com/index.php?topic=48058.0

Moving onto a new mobile game project and a new set of goals

My first mobile game on the iOS apple store, Play the Field, was a great learning experience in many ways, but to be honest the number of downloads was quite below my expectations, especially considering it was free. I knew the mobile game market was dog-eat-dog, but nevertheless I think I was still a bit too naive.

I still feel the game is a lot of fun, and at least one person who tested the game for me (who had experience with RTS games) said he felt it was enjoyable to play. But it’s pretty clear to me neither the gameplay nor the difficulty was the main factor in the small number of downloads. I’m pretty sure the game’s simple, unrefined visuals, was the real culprit. Although I tried to market those as “retro” or “minimalistic”, the actual number of games with visuals that simple that become popular seems pretty small. The game’s unfamiliar genre (“casual” RTS) may also have been a factor in the lack of popularity.

While I have recently done some experimental advertising for PTF, and may continue to do so in the future, I have decided on spending the biggest chunk of my time on a new mobile game. It’s something along the lines of a puzzle game influenced by classic games.

This time around I have a different set of priorities, the most important being to spend a greater amount of effort and time on polishing the visual and UI aspects of the game. In all my game projects up until now I’ve always went the path of least resistance (meaning I spent the most time of my time on other elements such as gameplay, AI, level design, difficulty, etc.), but this time I will shift that balance.

Since my lack of artistic ability isn’t likely to change anytime soon, I’m making the best of what I have – still trying to keep to simple visuals while adding things here and there to please the eye. In particular I’m trying to add more animations to the game, for the background as well as at the start of each level. In between each player’s turn there is also a special animation I’ve spent some time refining.

Besides this emphasis on visuals, I’m hoping my decision to make a more standard puzzle game will give it better chances at popularity, while acknowledging that genre is extremely competitive.

The final thing I’m planning on putting more effort into is making an enticing preview video, since I feel that’s one of the most important things determining whether a user makes the jump to actually download an app or not. Of course the screen shots are also important, and since animations won’t show up in these I’ll have to pick what to showcase wisely.

I’m aiming at the somewhat arbitrary figure of 2x over my previous game’s downloads, though part of me is hoping I can get at least 10x. Even 100x wouldn’t result in a famous game, but if I can see concrete progress in some form it will motivate me more to keep along this route. Otherwise, I may chose to devote my time elsewhere.

Programming is great fun, but there’s nothing quite like the thrill of real users around the world downloading your mobile game, with a great degree of unpredictability around what will be popular and what won’t.

Gameplay element: visually indicating maximum attack distance

For this post, I’d like to talk about a minor tweak I did to Play The Field whose aim was to improve the gameplay.

Like most Real Time Strategy games, units in PTF have a maximum attack distance. This means that if an enemy comes within that range, they can attack (and unless ordered otherwise will attack).

Attack distance is especially important in this game because for many of the levels the player is forced to place units in very tight environments – sometimes in the middle of a group of enemy units just waiting to attack. This contrasts from most other RTS games where you have to create units at specific buildings.

By playing through a stage a few times you can figure out roughly where this attack range ends, but each unit has a different attack range so memorizing all of them is tedious, and visually identifying where are safe zones can be hard.

After realizing this, I decided to put a visual indicator of each unit’s maximum attack distance. After some experimentation, I decided on a light grey sphere around the unit showing the “danger zone” of that unit. This was implemented with translucency (an alpha value), and an interesting side effect is that these zones visually combine whenever they intersect. For example, for the region where two zones intersect it will twice as bright, and so on.

This not only creates interesting patterns, but gives you different levels of safety based on brightness of the zone. Dropping a unit in one of the brighter zones means you would be taken out almost immediately.

At first, I felt that this graphical change would be a big too busy and detract from the game’s mechanics, but after testing it I feel that it doesn’t interfere much with the gameplay. This is probably because the game’s visuals are already extremely simplistic, with a completely black background.

See the below screenshot for an example of what this looks like:

Play The Field version 1.2 released on the apple store [iPad / iPhone game]

Version 1.2 of Play the Field, the minimalistic puzzle/RTS game, is now available on the Apple store, for all iPad and iPhone devices. You can get it here:

https://itunes.apple.com/us/app/play-the-field/id985621862?mt=8

This release has a few balance adjustments and bug fixes, including a mistake that prohibited devices below iOS 8.2 from running it. Any devices with 8.0 or later are now supported.

However, the biggest thing added to this release is a new mode – survival mode. It’s goal is to see how long you can survive as you struggle through over 20 stages of attackers, gradually increasing up to a dizzying frenzy of enemies.

The music has also been improved, with an additional song from Eric Skiff’s Resistor Anthems album.

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.

iOS development: Don’t unknowingly limit your users

Recently I asked a friend to try Play The Field, after which he replied he could not because the game required iOS 8.3, but his iPhone was currently still at 8.1. I hadn’t realized the app was set such that “Deployment Target” (in the XCode project’s General settings under “Deployment Info”) was set to 8.3, which means that 8.3 is the minimum OS required to install the game. This was very valuable information, and in the next release I’ll change this to 8.0.

Just be careful because your program may be using Apple APIs which aren’t supported by certain older OS versions. The father back you go the more you have to worry about writing code to dynamically detect the version and use alternate APIs.

If you are new to mobile development you might take the stance of “Why don’t the users just upgrade to the latest OS?”, but that naive stance won’t help you get any more downloads. There are several reasons people might avoid an upgrade: risk avoidance of new bugs and security problems, inability to upgrade on a jailbroken device, and fear of bricking their device. You may think having a device destroyed by an upgrade is impossible, but I have had a MacBook Pro totally messed by a failed OS upgrade before.

I doubt that once I remove this restriction the downloads will come pouring in, but it’s literally a single click to fix (excluding the whole process of uploading a new version to the app store, which I would have to do eventually anyway). Creating an iPhone version was significantly more difficult, but had the same end result – reducing a reason that user’s couldn’t download the app.