#MadeWithUnity in 7 days

7 Days

IMG_06727 days after I got up in the middle of the night and – for no particular reason – decided to add my own peculiar contribution to a very long list of color-match puzzle games for mobile devices, I finished and uploaded the release build of Qube Crush 3D.

That’s 7 days (and nights) from initial spark to a completed F2P game with 50 levels of brain bending puzzles uploaded to the App Store.

Just to prove to myself that it wasn’t a fluke or a happy accident, and since I had a week or two to burn while waiting for the AppStore review process to complete, I decided to do another game in the mean time.

This was to be a 2 player arena battle game and the result is Magic Micro Battle Arena, which I completed in just 5 days – mostly because it has no IAPs or Ads and no highscores, so less integration work and no horrible IAP testing. Ironically, it also got approved faster because Qube Crush got rejected due to an issue with my AdColony integration.

IMG_0611So two fully functional playable games completed in two weeks. These are not Gears of War or Doom 8, and their feature lists has been cut to the bones, but anyone with an idea of just how much time the crud of project setup, tool chain woes, app-store nightmares and 3rd party integration (not to mention play-testing) usually takes, should realize what an amazingly short time-to-market that is.

The rapid development probably means I missed a bug here or there, and I could certainly have polished both of these two games for another couple of weeks, or months even, but before I do, I’d like to know that there is at least someone out there who wants to play it ;).

Because my investment is so limited, I can try whatever crazy ideas I come up with, and if it fails, I can move on without bleeding to death.

Unity Rocks!

And that’s really why I’m writing this blog post. Because of how this is all possible. Obviously, I *am* a pretty awesome developer (hah! 🙂 ) but, truth be told, I owe most of my productivity to the game-dev tools we have at our disposal today, and at the heart of those is (in my case at least) Unity3d.

I can’t say enough good things about Unity – sure, it has its bugs and quirks and annoying issues, but at the end of the day it’s just so insanely productive that I hardly notice.

I run a 4-screen setup with Unity and Blender on a big cinema display, photoshop on my Cintiq and Mono on my laptop with either my phone or iPad hooked up for testing – with Unity’s rapid automatic import there is no sense of context switching, it’s as if it’s one big application build up of state-of-the-art parts (minus Mono which is anything but).

IMG_0674Testing and trying out stuff in Unity is so quick and easy that in two weeks, I have not once had to start the debugger. Mind you, if launching the debugger from Mono wasn’t such a nightmare, I’d probably been able to finish the games even without cancelling my weekends 🙂

So here’s to the guys at Unity: YOU ROCK!

(But please find a replacement for Mono. For those of us who’d rather chop off our left arm than install Windows, Mono is still (if only barely) the preferable option, but I’d really like to see a Unity/JetBrains C# IDE with bullet proof indexing, a nice coder friendly editor and proper refactoring that does not break script-to-game-object bindings).

If you have an iOS device you can get the apps on the AppStore – Qube Crush is free* and Micro Arena is $1 (if you ask nicely I may have a promo-code for you 🙂 )

https://itunes.apple.com/us/app/magic-micro-battle-arena/id908075215?mt=8

https://itunes.apple.com/us/app/qube-crush-3d/id905380169?mt=8

If you don’t have an iOS device, wait for an Android update, or check out a video of Qube Crush here:

https://everyplay.com/videos/7850308

*) Yes, I know what I’ve previously said about “free apps”, I still think it’s a fundamentally bad idea, but the sad fact of the matter seems to be that as an unknown IP or small game developer you are left with a choice between “free” and, well, nothing else at all… So much for not being part of the problem, though.

TempusCura V1.8 Released

TempusCura V1.8.5 was released in the App Store a few hours ago, and to celebrate, all existing users has had their subscriptions extended with an additional free month 🙂

More New Features

I ended up adding quite a bit more features and changes compared to what I wrote about in my last post. During release testing I realized that some of the more “novel” UI concepts in the original app, while compact and quick to use, were not at all intuitive –  in fact, several of my test users had never understood certain aspects of the app, but had not realised it because they only had one project or a “team” of one person.

Here are some of the things that changed on that account:

Filters and Tabs

IMG_0452

In TempusCura you can filter your work on 3 properties: Time, Projects and People. These filters were set using the calendar, project and team tabs in the main UI, respectively.

However, these tabs also changed how data was visualized so that when you selected the project filter you got a list overview of work sorted by project, the team tab gave a list of work sorted by team members and the calendar presented work over time.

In addition to this, the “tab bar” had two buttons that were not tabs at all: Settings and Export, and the project list had an additional purpose in that it provided a way to add and edit projects and tasks.

In V1.8.5 this has changed completely. Now the buttons in the top are no longer tabs, but separate views.

The work button still shows work in a calendar by default, but it now has three sub-tabs to toggle between viewing work by time, project or people. Filtering is now hidden and only appears when relevant (I.e. when you have more than one project and a team of more than one person). To change project filter, you tap the project list at the bottom, and to change person filter, you tap the list of persons in the work table header.

The project button provides a list of projects and access to team and task management.

The team button is gone since its function is now handled by the work view

Work registration

The calendar grid uses tap-and-hold to register new work items rather than just a single tap. The reason for this is that tap-and-drag is used to scroll the view and without the “hold” part, it was very easy to accidentally add a new work item. While most people eventually “got” this, the way you then dragged to size the work item caused more confusion still, only to be topped off with “surprise” when the work-item view appeared immediately on release.

In V1.8.5 this has changed so that it works more like it does in the native iOS calendar. Tap and hold creates a block of one hour. Moving around drags the whole block, releasing leaves the block at its current location, but does not open the work item view. In this state you can either tap-hold-and-drag the middle of the item to move it again, or the top or bottom to resize it.

Tapping the work item then opens the work item view and allow you to provide the final details before the item is created.

Milestones

IMG_0456When I first started writing TempusCura, the center of attention was “Tasks” – planning, prioritizing and scheduling of tasks that would then be worked on. After testing this for a few months I realized that my daily business was mostly concerned with “work done”, and only rarely did I have time to sit down and create tasks, so I changed the focus of the app to be on “Work” instead.

Still, being able to plan ahead and keep track of what needs to be worked on is important, and the first version of TempusCura probably down prioritized this too far – to the point where it was only just usable. In particular, the task list, even when grouped by milestones, quickly got very long and hard to manage.

V1.8.5 takes a few steps in the right direction by automatically collapsing completed milestones and scrolling to the first relevant task. I have a few more changes coming up soon, but more of that in another post.

Calendar picker

The calendar picker has changed so that you now drag across the calendar to select the time period you wish to view instead of tapping first and last day. This is slightly embarrassing as the tap/tap method of selecting was just a temporary hack I did while implementing the date picker – it was never meant to end up in the released app, but for some reason it did. It’s not that it did not work, it was just hopelessly counter intuitive.

Also, date selection has been limited to one month since I don’t really think it makes sense to see more than a month at a time, and if you selected a long period by accident (say, 10 years) you could potentially bog down both server and client with a massive data download.

I also added buttons to quickly go to next and previous months, though this did not turn out as well as I wanted it to – it will most likely be replaced with something more sensible in a future update.

TempusCura Update

TempusCura V1.8

I’m pleased to announce that the first feature update to TempusCura is now complete and undergoing final testing prior to release on the AppStore. I’ve put together a list of the major highlights below.

If you’d like to participate in the beta test (or have found bugs in the current version you’d like to see fixed) please drop me a note.

Off-line Mode

Location tracking and off-line work registration

I originally decided that in this day and age everyone is always on-line anyway, so there was no real reason for adding the complexity of off-line synchronization with all its evil pitfalls, but for some reason I often find myself working in odd locations or have clients that seem to live in faraday cages with no access to neither 3G nor WiFi networks.

Not being able to register my work hours immediately meant I had to make notes of it elsewhere, somewhat defying the purpose of the app.

So as of V1.8 you can now use the app while off-line – registered work gets queued up until a network connection becomes available. You’ll see this in the UI as a work item with a dotted outline (See screenshot).

Note that off-line mode is currently read-only for everything but work items. Projects, tasks and user registration still requires a live connection – this is primarily because of item dependencies, but also because I have not personally had the need to modify any of these while off-line. Please let me know if your needs are different.

Location Tracking

Not being able to register work while off-line was, however, also a good thing since it made me think of ways to automatically track where I’d been and what I’d been doing.

The first step in that direction is the introduction of a location tracker. This feature uses iOS’ “significant change monitoring” to detect when the device is moved. Changes in location are marked in the calendar margin with a blue line and a little car symbol (screenshot above). These are initially gray in color to indicate an un-confirmed trip, but you can tap it to see the route and distance covered (screenshot below).

Trip details

You can associate each trip with a project (e.g. a customer) and name the start and end locations. TempusCura will remember the names of all locations you enter and automatically show the names next time you make a trip to that location. Once confirmed, the icon turns blue, and the trip will now be included in your reports. You can also delete trips that are not relevant to your bookkeeping.

Location tracking is off by default so you need to go to “Settings” and turn it on. You’ll see three options:

  1. Off
  2. Low Power
  3. Detailed

The Low power option relies exclusively on significant change monitoring and uses very little battery power. It is also not very precise. This option is mostly useful as a reminder of where you’ve been – the route is almost always too inaccurate to be of any use, and the measured distance can be quite far off (the screenshot is using the “Low Power” settings and as you can see, I’ve somehow managed to drive on water :)).

The detailed option still relies on “significant changes” in location as a trigger, but once a significant change is detected, TempusCura will turn on the GPS and use actual GPS coordinates (instead of relying on  3G triangulation and WiFi information). This is far more accurate but obviously uses more battery as well. TempusCura turns off GPS again when no major change in location has been detected for 30 seconds.

Note that because trips are device-specific rather than account-specific, I’ve so far opted to keep trip data locally on the device (in theory you could have several iOS devices making different trips at the same time on the same account which would create a mess in the UI). I will consider pushing confirmed trips to the server in a later version if there’s a desire for such a feature?

Improved Reporting

Reporting has been vastly improved over prior versions for those of you who are not really interested in importing CSV files into a spreadsheet for formatting. If you export by mail, a nice summary of all the work items is now included in the e-mail body. This includes both per-project summaries and per-person summaries. It also includes a mileage report with start and end locations.

Summaries are given in your selected currencies using the most recent exchange rates – note, however, that these are probably not the same rates you get in your local bank. Without getting into details about what I think of banks in general, I think we all know why that is.

Remembers Filter Selections

As you have undoubtedly noticed if you’ve used TempusCura with more than one project, it has an annoying ability to forget which projects you’ve checked off in the project filter. Basically, whenever the app gets shut down by iOS and has to restart, it will revert to showing only items from the first available project.

Not anymore. As of V1.8 the selected project and people filters are now stored and re-established when re-launched. (It’s one of those little annoying things that makes a big difference 🙂 )

Faster Login

Being able to work off-line prompted a change in the login procedure as well, since it now had to be optional. Revising this turned out to be a good idea as I was able to significantly reduce the number of server roundtrips and thus ended up with a much faster login procedure.

Minor UI Changes

The main view has received a minor visual update. The calendar grid now has vertical rows between days so it’s easier to tell them apart (for some reason, I missed this in the first release).

The header has changed from white to gray, so work items don’t get confused with the header when scrolling, and I’ve used the upper left corner of the table (which was previously empty) for a “now” button which scrolls the calendar view to the current time and day.

Changed work item text rendering so that it now renders special characters properly, and uses multiple lines of text if the space is available.

Bug Fixes

Fixed local timezone bug (daylight saving issue in some cases)

Fixed a bug that caused the calendar view to not center properly on the current day (it was offset by current time, and did not take the margin into account).

Fixed bug with “work by project” list sometimes not updating correctly

Remember, remember, the month of December

It’s been mildly annoying for a while – how iOS, and UIKit in particular, treats even the most irrelevant little deviation in input data as a hard error and throws an exception, instead of just logging the problem and either ignoring the request or adjusting the input parameters.

This morning it became *really* annoying, but I’ll get back to that in a minute.

You may argue that the hard error causes more of these issues to be fixed by sloppy developers who would otherwise ignore the warnings and release code that, strictly speaking, isn’t correct. This is a fair argument but I really think it should be limited to debug code.

The problems I have with throwing hard errors on a visual rect that is 2 pixels to wide or, say, a “scroll to index path” that has an invalid path (and this is what I will be getting back to, shortly), are:

1) The exception is caught at application level, and stops execution so further debugging is not possible. As a result, locating the actual code can be tedious – especially for cases that are not easily reproduced. If it had been a warning in the log, it would often be possible to step back and reproduce the action while the app is still running.

2) When this happens in released code you crash an app because of a glitch that would, in many cases, probably not even have been noticeable.

And (2), of course, is why I am even writing this – I got bit by this today, badly, as I realized that TempusCura basically does not work for the entire month of December.

The reason?

Well, as a courtesy to the end-user, the calendar view automatically scrolls to the current month when opening the main view. The current month, obviously, is a number from 1 to 12. The indices in the table that is showing the months, however, are 0-11. Now, for all other months, this creates a small offset as the view actually centers on the next month rather than the current – I never noticed this, and neither did anyone testing the beta version of the app. When you get to December, however, UIKit throws an exception because the index 12 is illegal for an index range of 0-11.

This is not really a critical feature in any way, yet it turned out to be a major showstopper, as the app is completely unusable for the entire month of December.

Yes, I know it’s a bug on my part, and yes, maybe I should have tested all uses cases for all days of the calendar year, but we all know how realistic that is.

Yet, if UIKit had not been so anal about these utterly irrelevant details, and simply showed January, or capped the index at 11, the app would have worked just fine.

And if Apple didn’t take 2 weeks to approve an app, the patch would already be on-line… Sigh!

** 2013/12/02 – UPDATE **

TempusCura is now available in V1.7.13 which fixes the December crash. Hats’ off to Apple who got the app reviewed and approved in just one day! Awesome :).

Tempo Tim Update

Last night I uploaded a new version of Tempo Tim with some new features that has been requested over the last couple of days since it was first launched:

  1. Ability to pause the timer without resetting it
  2. Parental lock to prevent kids from tampering with the settings
  3. Show remaining time while “parent lock” is on.

The remaining time is shown both as a time and as a “progress” bar in the form of a glass of lemonade 🙂

The new "lock" screen in Tempo Tim

The new “lock” screen in Tempo Tim

The MathRat is 1 year old today

It’s been one year, now, since the MathRat was released on the App Store.

I was going to write a follow up on the retrospective, but I really don’t have a clear conclusion. It’s been a strangely un-eventful year for the MathRat – sure, there’s been a few dips and a few spikes, but nothing that really had a lasting effect; It just keeps selling in the same low numbers every day, on and on.

Every now and then it starts dropping until it gets dangerously close to zero and then for no apparent reason, it starts climbing again.

So, to answer the ever-relevant question of “was it worth it?”, I would have to say yes. Not just for the fun of it, but it does actually (eventually) make enough of a profit to be something I can justify spending time on.

Which is really all I’m asking 🙂