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.

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: https://rhyskucharski.wordpress.com/2015/07/04/quantum-cheeks-has-launched/comment-page-1/#comment-7

Mobile Game Review: Does Not Commute

Does not commute, by Mediocre AB, is a game for the iPhone/iPad which was originally released on April 15, 2015. It recently won an Apple Design award and was listed in a special category in the app store, which is where I discovered it. I only played the iPhone version so this review is limited to that.

The game has a pretty unique concept: your objective is to drive a series of vehicles through a city, each from a starting point to a destination point. The interesting part is that as you begin controlling the second vehicle, the first vehicle starts taking the path you choose at the same time, and each successive car’s path gets layered onto the map until it becomes difficult to navigate and reach your destination in time.

If you are able to help all vehicles reach their destinations before time runs out, you get to go to a new area of the city which is effectively a new stage. On the way you can grab items to increase your remaining time, and use the rewind mechanic to retry the path of a car, though you loose some time in the process. Each vehicle has a little different steering, and there are upgrades to can get to improve things like traction. Hitting other objects damages your vehicle, which makes it start smoking and slow down.

The strongest point of this game by far is the graphics, which are done with an extremely visually pleasing top-view rendered with 3D and heavy use of lighting effects, such as headlights for each vehicle. The models are pretty simple but generally good enough, except for some of the lakes which look badly designed. The visual effect during the rewind function is pretty cool looking, and the intro pages are also very nicely designed. Above all, the entire game has a very distinctive visual atmosphere.

I enjoyed this game for around an hour but eventually started to get bored with it. One of the reasons is that the control of vehicles is pretty limited, such that you can only turn left or right, with no braking or acceleration. Also, I found the top-view much more disorienting to drive than a typical first-person view, though I understand why they chose the former to fit with the concept of each car commuting simultaneously.

Does not commute tries to give a personality to each character by giving a short textual description of what is going on in their life and why they are in a hurry, but I found that underdone and insufficient to make me care about any of their lives.

Having said that, with stunning visuals and a very creative concept, this is one of the better games I’ve played on mobile in the last few months, especially considering it’s a free game (with some In-App purchases).

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:

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.

Developing games for multiple devices on iOS: Part 2 – how screen differences effect menu design

In the second part in this series, I’d like to talk about some of the struggles I had with the menus of Play The Field when porting from iPad to iPhone.

In the game there are two types of menus: interface builder designed menus and custom menus.

The interface builder menus are where I dragged and dropped various components (mostly UILabel and UIButton) onto the relevant view from within Xcode’s interface builder. This main menu, credits menu, and help menu were all done this way. As these menus don’t need to be shown in any of the app previews or screenshots, I kept them extremely simple and functional.

When I first made the iPad version I’d played around with the location of the elements and got things looking nice on a live device, but then when I eventually tried the same menus on an iPhone, things were totally messed up. I’ve found for the purposes of layout, it’s safe to use the simulator for the most part.

From the beginning I had tried to use Xcode Interface Builder’s constraints system to help with layout of the various components. The system works by providing logical constraints like “I want this element in the middle of the screen horizontally”, and then Xcode figures out where that should be depending on the size of the device. Sounds pretty neat, but there are wrong and right ways to use it, and I’m still in the early learning stages.

One of the things I had done wrong was give some buttons constraints so that they were spaced a certain number of pixels from the top of the screen, and some from the bottom. The problem with this was that when the vertical pixel count changed (since iPhone has a smaller resolution than iPad), the positioning of these elements got totally out of whack and the result was a jumbled mess of buttons and labels.

In my case I ended up giving up on perfect vertical centering of elements on both iPhone and iPad, and changed most of the elements so they were relative to the top of the screen. For the end result things looked much cleaner, though there was a larger empty space between the bottom most element when using the iPad.

I’m not trying to convince you to use any specific technique here for layout – there are many articles on this stuff all over the net. But I do think it’s important to have a good understanding of what each devices resolution is before you start making any of the menus. And once you start adding elements to a menu, consider checking on different device types (using the simulator) several times through the process. Try to avoid what I went through which was basically redesigning all of the menu screens from scratch to get the game usable on iPhone. Depending on how complex your menus are, another option is to use completely different view controllers for two or more device types. I ended up doing that for one of my menus.

The in-game menu (showing the available units to create) as well as the level menu both used a set of custom buttons I designed. These gave me full control of the visuals and control processing, but I was not able to use constraints and had to set the button’s locations all manually in code.

For best experience, on iPad I had expanded the level map so it nearly filled the screen, coming close to the right edge. However, when running this on the iPad, since the resolution was significantly less the menu now ran off the side. The way I handled this was by creating a constant that was multiplied against the button sizes and spaces. The constant was set conditionally based on the device type.

For the in game menu bar I used a similar technique, though there wasn’t enough room unless I made the buttons really small, so I removed the “select all button” and moved the help button to the main menu. This gave enough space for reasonably sized buttons. I also tweaked the way the level number, score, and remaining money was displayed so it fit on all device types.

Regardless of what type of menus you use, in order to have things look acceptable on multiple devices it’s best to do a certain amount of planning and research from the beginning.

Developing games for multiple devices on iOS: Part 1 – how screen differences effect gameplay

One of the challenges of writing games for multiple devices is that there are typically several form factors you need to support. In the Android world, you literally have hundred of devices to consider, though you can target popular ones and probably make most people happy. I haven’t done too much development on Android however so can’t give too much detail here.

In the iOS world, it’s a bit easier since you have a much smaller universe of models to tend to. Grouping all the similarly sized devices into categories (and excluding old models that aren’t supported anymore) you end up with only six device types, which isn’t too bad.

There are only two things to really be concerned with for each screen type: it’s resolution (number of pixels horizontally and vertically) and physical size. Sometimes you hear about pixel density (DPI or PPI), but this can be derived from the size and resolution of the screen.

In this series of articles I’m going to talk about some of the challenges I came up when porting Play The Field from iPad to iPhone, and along the way give some ideas that may help you doing the same for your game. PTF is a minimalist RTS game, but I expect many of the things I discuss will apply to other game types as well.

Though as I mentioned above there are six devices types on iOS to worry about (at least as of May 2015), I’m just going to focus on iPad Retina (which I originally wrote the game for) and iPhone 6. You can see the full list of specs for all currently supported iOS devices here here.

Before I get any deeper I’ll explain a little more about how Play The Field works. There are two sides, the user and the computer, and each has their own units – you can think of them as little tanks if you like though the game is mostly non-violent. There are different unit types, but most share in common the following characteristics: movement speed and attack distance, both specified in pixels.

Movement speed represents how many pixels the unit can move in a turn, and attack distance is the maximum distance to an enemy before it can begin attacking it. One more important piece of information is that there is a series of levels, each with a different layout of enemy units, and I wrote the engine to scale the layout to the screen size.  So if a certain level contains 10 units in a circle, this circle will be adjusted to fit properly on any resolution without being cut off.

iPad Retina has a resolution of 2048 x 1536, and iPhone 6 has 1334 x 750. The latter is a little smaller than you would expect given the resolution difference, because the pixel density is roughly 23% higher. What this means is that if I draw a circle of a certain radius (in pixels) on both devices, the one on the iPhone 6 will be approximately 23% smaller. In the case of PTF, I determined this was not a major problem so I left the unit sizes the same. If the density difference was significantly higher, I would have had to scale all the unit sizes accordingly.

The problems begin when you consider how the levels get rendered on each device. Just ignoring the menus for now, there is 2048 – 1334 = 714 pixels extra in the vertical direction on the iPad Retina, as compared to the iPhone 6. Assuming I don’t change the speed of the units or the board layout at all, it would take units significantly that much longer to cross the board. Also, assuming I don’t change the attack distance, this means the board is effectively more cramped. For example, on some levels where I could have added a unit safely without being attacked immediately by an enemy, now there is less space and my unit will get attacked right away. As a user playing the game on both devices and comparing, because the physical distance is almost the same, this difference would seem strange. After all users don’t actively think about resolution.

I knew these factors could have a pretty major effect on the gameplay, so I play-tested the levels on the iPhone to see how it was. Fortunately, though the game had a different feel, most levels were playable and still had a good degree of challenge. I did tweak a few things to make them work better on the smaller resolution, however. For example, I removed the red area (which blocks unit placement) on one stage because it limited the user’s choice too much. Another option I had when doing the port was to just scale everything down to match the lower resolution: the unit size, speed, and attack distance. In theory, this should keep the gameplay the same as the larger device, as if you were watching recording an iPad on a camera and replaying it on a small TV.

But this approach has its own issues. First, the units would not be much physically smaller, which would render them hard to see as well as hard to select. Accidentally selecting the wrong unit would also happen more often. Also, the speed of units (as seen visually), which had been carefully adjusted, would now be significantly slower on the iPhone. This is because the units are moving the same speed relative to the number of pixels available, but the physical size of the screen is smaller so this translates to less distance per movement.

Yet another option would be to redesign each level from scratch for the smaller form factor of the iPhone. This has the potential to have the best user experience because things are fine-tuned, but it puts a heavy burden on the developer for the redesign process. I am considering doing this eventually, but for the initial iPhone release I just wanted something that was playable and fun, and was able to achieve that without the extra work.

But alas, our work is not yet done! There is still one more area where I had to put in extra time to fit the iPhone’s smaller screen and resolution – the menu system.

I’ll dedicate part 2 of this series to the menu changes I made.

References

http://www.iosres.com

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: https://itunes.apple.com/us/app/play-the-field/id985621862?mt=8

(Image credit: Matt Trostle (creative commons attribution license): https://www.flickr.com/photos/trostle/6848810640/in/photolist-brcWN5-4UA6My-8QKFCa-bd88Ue-qpJH4d-4M6Jou-ehmy7i-bP2MWP-9rcj1f-5jKhPh-9m3Srr-5eYjSG-GaSJ6-7pAjno-4kAY89-89igMH-7rrg9h-9LiPpm-4pJmY5-9TSfwz-7pAVoS-8PcDor-b19MYk-kzUBDW-9mB2Sw-9sqQAA-Q2hEK-xULQW-dwDFBc-3Xmcvh-7eEbDP-4AAnR3-n9GwQ-CED3C-jKUF6d-6wqxxe-4ytp2-j1MjXi-7rVtoK-7pAXtY-dxHQfC-5Ftq8C-9vvgMv-eV5XK3-7pwv3K-bunSTi-7pAorY-bQPpYF-djDDRw-7F83fo)

A little about the game music

I’ve already gotten some good feedback about the game’s music, so I’ll talk about it in this post.

This good feeling retro-y techno music is from an album called Resistor Anthems, but Eric Skiff.    You can see the artist’s web page here: http://ericskiff.com/music/. The entire album is released under a Creative Commons Attribution License, so you are free  to use any of the songs in any way you like, as long as you give credit to the creator.

I’ll leave it as a secret which song(s) from this I chose to utilize, but in the game’s credits screen you can see the song name(s) listed.

The music is truly awesome, and Eric himself is awesome for releasing this to the world for free.

Play The Field – Android version?

Though PTF has only been in the store for around a week, I’ve already gotten one request for an Android version. This is great feedback, please keep it coming!

To be honest, I have actually thought about an Android version from day 1, before I wrote the first line of code. Because of that, I’ve tried to implement much of the core logic in C++, as opposed to Objective-C. I haven’t done a line-by-line comparison, but I would guess 60-70% of the game is in C.

A few minutes of googling shows there are even frameworks that supposedly allow compiling Objective-C on Android platform, such as Marmalade Juice, and another one called Apportable.

I’m eager to get more users to play PTF so I can get more feedback and refine it even further, but at the same time I don’t want to stretch myself too thin. Even if one of the aforementioned frameworks, there will be surely some parts that are non-portable (like the UI), and those will have to be maintained across both platforms.

In related news, Microsoft announced this week at their yearly Build developer conference that they had a mechanism to easily convert iOS apps to run on a windows device, all while using Visual Studio. I think it will take some time to work out the kinks in the system, but maybe months from now it will be a breeze.

For those who do have an iPad, you can the iTunes page here.

If you are interested in an Android port of PTF, please like this article to show your interest.