Play the Field version 1.31 release onto App Store

While I had taken a several year break from mobile game development, I decided to make some minor changes and upload a new version of Play the Field to the app store.

Changes include:

  • Additional screenshots for larger devices, tweaks to the description text
  • Minor changes to the UI, including component location and color. This was mostly to allow the game to look a little better on bigger devices, like iPad Pro
  • Updated copyright notice
  • Added Privacy URL (as per Apple’s guidelines)
  • Added flag to require full screen mode (this was required for iPad multitasking mode)
  • Some testing on newer devices (iPhone X, Xs, Xs Max, Xr)

After having gone through this exercise I am a little more confident now about making more changes to the game, including gameplay and stage changes.

While I’ve seen a lot of new games available on mobile devices in the last few years, I still haven’t see anything quite like the minimal RTS that Play the Field offers.

Please feel to check it out, and let me know what you think!

  Play The Field on the App Store – iTunes – Apple


Open source devices for the disabled

In one of my mobile games I had used music from Eric Skiff, and I heard he is starting a new company which makes open source devices for the disabled. So I thought I would give a link for everyone to check out if you are interested.

Here is the video which talks about their aims. Pretty cool stuff!

They have a Kickstarter campaign as well in case you are interested in helping out.


Japanese podcast about games: “Game chomp chomp”(ゲームモゴモゴ)

Recently I discovered an awesome podcast that discusses a variety of games, and one of the hosts actually works the business of developing them.

While you’ll need to know at least some Japanese to appreciate this, if you do it’s a great way to study up on Japanese as well as the art of game making.

You can more details about this podcast in my post here (on my blog about Japanese study).

Update: Failed prototype and competing hobbies

I haven’t posed to this blog in a while so I thought I would give a quick update.

The prototype I was working on for several weeks (traffic-related mobile game) didn’t turn out to be as fun as I’d expected. I still have this idea in my head about how cool and interesting it would be, but having trouble translating that into actual gameplay. If the game isn’t fun to me, then it likely won’t be fun to anyone else, so I’ve shelved that project for now. At some point I should probably think about what elements were good about it and what weren’t, and make a write up about it.

The other reason I had taken a break from the prototype-work was that I had went on a trip to Japan, and since I came back I’d spent much time writing up all my experiences and thoughts about that trip. You can see them here in case you are interested.

I actually have a new project that is bouncing around in my head, similar to a previous one in that it involves a card game. But I’ll save that for another post.

Mobile Game Review: Lost Echo [iPhone/iPad]

I discovered this game from the promotional category “15 Greatest Storylines” in the iTunes store for iPad/iPhone. Most of the mobile games I download are free, but an impressive trailer plus the fact that the game was on sale ($0.99 from a usual price of $2.99) was enough to make me buy this game. Lost Echo has been out for some time, released on Sep 2013 for the first version.

This game is an authentic adventure game where you control the main character, following a storyline that gets pretty mysterious after the first few minutes of play. The game’s graphics are all 3D rendered in real time, and depending on where you move the camera angle changes, sometimes gradually and sometimes suddenly.

When I first saw this game’s trailer on my iPhone, I was blown away by the graphics, but after playing it for about an hour or so on my iPad my impression dropped a notch. This is not only because the larger screen size shows off the flaws more easily, but because the design quality of the environments varies significantly, with some contain areas of very simple geometry that stand out. Also, the app preview shows some of the more interesting and better-designed areas, which is only natural from a marketing point of view. Overall they have done a great job with texturing the environment to create realism without using too many complex models.

I’ve been playing for around 90 minutes total time, and the story and dialogue is pretty well-written so far. I am not sure if they are purposeful, but I feel there are similarities to some of the Final Fantasy Games (story and dialoge-wise), plus Half Life series (mostly visual). I haven’t played many true adventure games on iPhone/iPad, but it’s great to know there are some serious adventure games like this on mobile devices. The only drawback story-wise is that sometimes I feel this game devolves to a click fest where I have to just click on everything in sight until I hit upon the right object.

The controls on the game take some getting used to be able to efficiently navigate the world, but even given this learning curve I think there are some things that could be improved. For example, clicking on a location to move there does not normally show any UI confirmation, unless you have happened to click on a hotspot representing a object or other important place. This makes for a frustrating experience, especially because sometimes it isn’t clear whether the place you clicked on is a legal location to walk to. Usually I end up clicking many times quickly to make sure the character starts moving.

There was one scene I just played involving a card game where clicking on a button on an overlaid menu to look at my hand of cards didn’t work properly – instead it acted as if I was trying to touch something on the backdrop, giving me the message “This is a wine crate”. Eventually I figured out I had to click my cards on the table first but I was almost ready to give up. There is one more short scene involving fixing a rattle that was surprisingly hard to control, and I feel that part should be cut completely from the game since it didn’t add anything tangible to the experience.

I also had to struggle with the camera angle, since it would change unpredictably and sometimes I didn’t know where I had to send my character to force the necessary angle change. I think some of this is unavoidable in adventure games with dynamic camera angles, but I think they could refine things a bit. Once you get to the camera setup on each area it’s not that bad though.

For some reason, part of the time when I was playing this game there was no music, even though I had my volume turned up all the way. When I went back and played the next day music was suddenly working, and from what I’ve heard it’s pretty good. This issue might be related to my device, however. Another thing that I experienced once is my iPad getting extremely hot after playing for a few minutes, though this too could be a device-specific problem (it’s an older model).

Almost immediately after starting this game I could tell it was a low-budget effort – not in a negative sense but rather that the team tried to do the best with limited resources. For example, the fact that areas are reused several times in the story, and also the fact there is a lot of dialogue. Both of these things could be attributed to their storytelling style, but with a big budget I’m pretty sure would exposed more areas to be explored.

Looking at the developer’s site (KickBack studios), the team is in fact very small with only two people, who must have worked very hard on this game (their first) in the last two years or so. I’d be very happy if I could ever make a game this cool that could get such visibility from Apple, and I’m looking forward to this studio’s future releases.

Despite the few flaws and annoyances, for $0.99 this game is totally worth it, so I recommend you check it out on iPad or iPhone.


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 (iOS puzzle game) — A month later

It’s been a month since I released my latest iOS game Dokusen on iTunes. At first I considered polishing some aspects of the game and releasing an update, but to be honest the idea of developing a new game from scratch is more attractive, so I’ve stared down that path instead. So in a sense you can consider this post a “post mortem” of this game.

At heart, this game was an experiment to see if a bigger focus on visuals would reflect in more popularity in the store. I also spent a much larger chunk of time advertising on net forums, on roughly 20-30 different sites.

From a downloads perspective, my personal goal was to get at least twice the downloads of my previous game. Initially things went great, with the number of downloads from Dokusen in the first two days surpassing those from the first week of my previous game. Unfortunately downloads suddenly decreased after that on the 3rd and 4th days, such that I only reached 75% of my target downloads (to date, Dokusen got 1.5x of my previous game’s count). Though this is a bit of a disappointment, I should look on the bright side because at least things are going in the right direction. The large spike on the first two days is still a bit of mystery to me, since with previous projects downloads leveled off at a much slower rate. Oddly, I got a large majority of downloads those first two days from France.

These numbers are a further confirmation that advertising on net forums is not a great way to pull in downloads. I did, however, get some good feedback on the game’s rules from on a board game forum I posted on, since it shares some elements with Go and Reversi.

A week or two ago I talked to one of the people who informally tested for me, and he remarked that my previous game was much more fun and easier to understand. This was good feedback, though altogether not that surprising since I feel the same way. Ironically, with Dokusen I had tried to build a game that would be popular with others, but not necessarily myself.

For my next game (codename “T.E.” for the time being), I am planning on making something which I enjoy more myself, in terms of both coding and gameplay. I also plan to make a proper tutorial, as well as get more playtesters (please leave a comment if you are interested in helping). This next game is rooted in a longtime passion of mine, and the work I’ve done on it already is more challenging and interesting than Dokusen. I’m aiming for a release in 3-6 months if things go well.

Though I implied this project was mostly done, I am always open to feedback on Dokusen or any of my other apps. If you looking for someone to review your game I am OK with exchanging reviews of your game for mine.

Programming Trick: Speeding up your recursive loops with a creative technique

Lately, I’ve been working on a new game project which is very different than all the other ones I’ve done so far. I’m planning on waiting until it gets a little further before I write about it in detail on this blog, but I ran into an interesting technical challenge and I’d like to discuss how I solved it.

To implement the game mechanics I need a graph of nodes, with various connections between each node. I have a need to find the shortest path between two nodes, where the path is calculated by the sum of the length of all connections as part of the path.

I started out with a simple recursive algorithm that started from each node and worked backwards to find all possible paths to get to it, and used a map to store the best connection to move, given a certain intermediate node and a certain destination node. This worked really well, although after around 13-14 iterations on a graph with many connections it started taking over a second to compute and them getting exponentially worse.

One option was for me to search for a more proper algorithm to find the shortest path, and I am sure this has been perfected by  programmers over the last few decades. But I had a secondary requirement to also store all non-optional paths as well, so some of those algorithms probably wouldn’t suffice.

Looking at my recursive function, I realized that there really wasn’t much going on in terms of sub-functions it called that do any significant calculation. If there was, I could try to optimize those or cache up some result. But the question remained – what was taking up all the time?

Looking at the function again I saw that I was passing four different arguments into it. If you have ever studied assembly, you probably know that there are several instructions just to push and pull each of these to and from the stack, and since the function is called so frequently I thought that maybe this added up to a big chunk of the total time.

I decided to test my hunch by making all the parameters into global variables. I purposefully didn’t use class variables since I knew there would be extra lookups required, translating to extra work for the CPU.

It was a bit of work to make this transformation, since for non-pointer variables I had to manually save the state before calling the recursive function, and then re-set it. But this was only for two of the variables since the other two were pointers anyway which were supposed to change (one was the map which stored the nodes that had already been traversed so far, and I already had code to adjust that when returning from the recursive function).

The resultant code was a bit harder to follow, but the performance was significantly better. For the test case I was using I was able to get several more iterations before it got significantly slow (>1 second), if I remember correctly to at least 19-20 iterations.

If I keep adding nodes and connections eventually it still gets slow again, but I will probably put limits on these anyway so I may be safe with this solution for the time being.

Although I enjoy designing games from a high level, after many years of coding I still enjoy these types of algorithmic challenges, and the satisfaction of a well-tuned function.

Mobile Game Review: Quantum Cheeks [iOS/Android]

I came across Quantum Cheeks on a fellow developer’s blog on WordPress, and decided to review it. It’s the first game from a small team of developers who are learning Unity, and the tone of my review takes that into account. The game is out for Android, iPad, and iPhone. I only played it on iPhone 6.

The concept of the game is simple – guide a hamster through a series of radioactive barrels. The controls are very simple: click anywhere on the screen to make the little thing jump out of his (her?) current barrel and hopefully into another one. Many of the barrels are in constant movement, rotation or translation along some path, and the core gameplay element of this title involves getting the timing right with respect to the barrels on screen. Each stage ends when you reach the ladder at the end of it. There are also some seeds you can collect along the way to get extra lives, similar to coins in Mario Brother.

The graphics are fairly simple but sufficient to support the gameplay. There are some little visual touches that caught my eye, like the fireflies on the first world. There was clearly a bit of effort put into this effect since their paths seem dynamic and there are different sizes of fireflies, plus a fading effect in and out. There is also a nice parallax effect with multiple layers of background, but I had to really pay attention to notice it. One minor nitpick is that the resolution of the barrels on the first world is too low and could use some refinement. The barrels on the second look pretty nice, though those on the third stage have a weird design, maybe a space ship?

Because of some issue I wasn’t able to hear sounds or music, although I think it is supposed to be there. Will update this post if I get that figured out.

My favorite thing about this game is element of shooting a hamster back and forth between barrels. It’s challenging, a little addicting, and adding the “hamster” idea gives life to what would otherwise be a dry physics simulation. I am not sure if the team plans to keep working on this game, but I think it would be interesting to expand on the concept, with more barrel types (maybe ones that explode after a single use) and more interaction with the world, for example bouncing off walls and such. Since they already have a physics engine I think some of these additions wouldn’t take that much additional development time.  I also like how you can just randomly shoot in one direction and have a chance at hitting a barrel in the distance, and I think if they can foster this sort of experimental play the game could be even better.

My biggest issue with this game is the bugs or inconsistencies I saw, which I notice even more being a software developer. I’ll give a detailed list here because I think they can probably fix these in a follow up release if they like.

1) Sometimes clicking on a barrel doesn’t seem to do anything. I noticed this mostly on barrels that are rotating back and forth 180 degrees, since it requires nearly perfect timing to eject the hamster at either endpoint. I would allow ejection at any point, and if the designers really want to limit this, queue up a click and eject when a valid point is reached.

2) Sometimes a rotating barrel will start ‘twitching’ back and forth for several seconds, after which it eventually stabilizes again. Seems like something has gone awry with the physics engine here. 

3) Once or twice it seems like a barrel ejected me before I touched the screen, though this is hard to reproduce.

4) There was at least one barrel (pointed up and to the right 45 degrees) which seemed to have less power than the others, so the distance the hamster was projected was unexpected.

5) At least once, I saw the game end before my character was completely off screen (on the right side). It would have gone off screen eventually, but the timing caught me off guard. This one is very minor, though.

6) I usually played the game in landscape mode, but there seems to be several issues with portrait mode which automatically triggers upon device rotation. Rather than go into all of them here, I recommend just disabling portrait altogether since it’s probably not worth the effort of supporting it.

In spite of these issues, the game is still fun to play, and I recommend you check it out. If you do, please consider giving their team feedback, since as a developer I can tell you this is one of the most important things for them (:

Link to the game’s release blog post with download links:

Mobile Game Development: learn your weaknesses and strive for consistent quality in all areas

Having taking a few iOS projects from conception to release on the Apple Apple Store, I’m starting to discover patterns in how I go through the development process. I plan to use this information to tune how I handle future projects, resulting in efficiency improvements as well as a higher quality result, hopefully leading to a larger user count.

I recently became more aware of the stages I go through in a typical project. I start development in what I would call a “creative” stage, where I am thinking of new ideas and enjoying the implementation process, as well as the iterative design that goes along with that. At some point when the project far along enough, I start to feel the need to just release something – what I’ll call the “get it done” stage.  I think this stems from my fear that other things will come up in my life and not have time to finish the project, or that I’ll just get bored of it and quit partway through, similar to why I would be hesitant to start reading a long novel.

The “get it done” stage is dangerous because the remaining tasks are done quickly, with lower quality than things done in the “creative” stage. For example, I usually create my app’s icons near the end of the project, and rush to just get something that looks reasonable enough. This is a bad idea since an icon is an extremely important part of the overall marketing presence of an app, and some people have even claimed changing only a game’s icon resulted in a major change in the download rate. Another example of this is creating a tutorial, as well as general visual polish.

For my next project, I’m going to try to get myself to think more long-term, and not jump into the “get it done” stage until the product is nearly ready to be released with high all-around high quality. It may be appropriate to rush to the finish line if there is a hard release date you are aiming for, for example to coincide with the release with a new OS version. But in cases where no such deadline exists, there isn’t much value in pushing things.

I am not sure if it is an appropriate comparison, but this reminds me of when I used to train in running to shave time off my mile. I measured how long it took for each 1/10th of a mile, and I found I got the best result when I had a good balance between these times. As opposed to having one or two areas where I sprinted and exhausted all my energy, a consistent good speed gave the best result. I feel that app development is similar, in that a consistent push through all areas is the best way to get a well-rounded product.

If I feel like I am too busy to make proper progress on a hobby project, rather than rushing it to release I’m going to try to just take a break. Odds are that I can just continue where I left off, whether it is a week or a month later.

The exception to this discussion is if you are working on your first mobile app or game. In that case I think it’s OK to just get something on the store, since you’ll gain valuable knowledge going through the entire process for the first time. For your second project, you can slow down and properly plan things out using your newfound knowledge. If you are worried about a low-quality app giving you a bad reputation, you can always pull it off the store at any time.