100 Hour Game: Days 16–18

Hours Remaining: 0

So the 100 hours is up and here’s what I managed to achieve in that time:

The game at 100 hours

Clearly, the game is unfinished (I would like the cartoon exuberance of the title screen to be reflected throughout the game) but I could still release it today and it certainly wouldn’t be the worst thing the App Store has ever seen. However, I would only be doing it to meet this arbitrary deadline I set myself. I can and should make this better.

So even though it won’t be released within the 100 hours, it could. I count that as a success.

But even if it wasn’t ready for the App Store, I would still count it as a success because I have thoroughly enjoyed working on it and I know in my bones that it is something that I am going to see through to the end, however long it takes.

Which is the much more important thing.

Deadlines and Goals

Personal deadlines and goals can often be a good motivational tool to get us started, but they can easily turn in to weapon against our own self esteem. We often underestimate how long things take and overestimate our own abilities, willpower, and motivation to get those things done.

This can lead to these deadlines being missed and the goals unmet, which turn the good work we have done into failure and disappointment. Instead of seeing what we’ve achieved, we only see what we haven’t.

For personal projects, deadlines and goals should be MacGuffins—Randy Pausch head fakes—designed to get the plot of our lives moving towards something bigger without having to pay attention to that bigger (and often paralysing) thing.

The deadlines themselves should serve as moments of reflection, in which we re-evaluate the work we’re doing. Is it everything we thought it would be (the daily grind of a creative life, for example, often doesn’t quite match the romantic expectations of it)? Are we still enjoying the process? What was the larger goal and is that still something we want?

Sometimes, in doing the work, an unexpected aspect of that work might grab our interest and make us re-evaluate what it is we actually want. In that case, do we really want to carry on working to these goals and deadlines that were set before we knew this stimulating new interest we’ve discovered even existed?

The enjoyment of meeting a goal or a deadline or completing a project is fleeting and momentary and hollow. It will never make up for all those spent hours if we hated each one of those hours (of course, we won’t love all of them—ask me about provisioning profiles and certificate signing—but on balance there should be many more good hours than bad).

Finally, we should never feel beholden to our past selves. As soon as we start doing the work they set for us, we gain knowledge about ourselves that they never had.

100 Hour Game—Days 12–15

Hours remaining: 15

The game is functionally complete and I have begun to play and tweak and play and tweak. I look at what I’ve made and consider it in two minds: the first is that of the craftsman. I turn it this way and that, feel the weight of the objects beneath my fingers as I slide them around the scene. I watch as everything works as intended, and I’m pleased at what exists.

Continue reading 100 Hour Game—Days 12–15

100 Hour Game: Days 4 And 5

Hours Remaining: 67

Last week a friend of mine, Mike Sowden, contacted me with an innocuous message about Lifeline, a new mobile game he had discovered. It was a cross between a text adventure and a choose your own adventure, but with a modern twist, taking advantage of push notifications to create a sense of real-time communication.

You’re texting with Taylor, an astronaut who has crash landed on another planet. He messages you, pausing to ask your advice and you get to direct his course of action as he attempts to survive and arrange rescue. The actions play out in real time so if he has to, say, hike for an hour, you won’t hear from him for an hour.

Continue reading 100 Hour Game: Days 4 And 5

The 100 Hour Game—Day 2

Time Remaining: 84 Hours

After playing around with Inverse Kinematics and struggling to get it to transfer the velocity of arm motion to the coin in a realistic way, I thought about how much time I wanted to spend getting this to work and came to the conclusion that I didn’t really like this idea enough. So I threw it out and started over, which is always a good idea when you have severe time limitations.

I considered the set of limited skills and experience I had with SpriteKit and figured out what I could do with them in a hundred hours and came up with:

Continue reading The 100 Hour Game—Day 2

The 100 Hour Game

Inspired by Pancake and Burger by Philipp Stollenmayer, I want to make and release a simple but well crafted iOS game in 100 hours.

The 100 hour deadline is part business—as this is unlikely to make any money, I probably shouldn’t spend that much time on it—and part creative—having a time constraint will force me to make faster decisions and to not second guess them.

Continue reading The 100 Hour Game

Fastlane

Fastlane is mostly pretty great, automating much of the drudgery around releasing apps, but there are issues with Xcode’s UI testing where the simulator will fail to launch with UI Testing Failure - Timeout waiting to launch Target Application. or UI Testing Failure - App state is still not terminated. errors, especially with a large number of UI Tests (Trail Wallet has over 35).

This means that one of the big ticket items of Fastlane, Snapshot, is unreliable with my full test suite. However, I didn’t want to give up on it because the idea of having a process that automatically takes and uploads screenshots to iTunesConnect for all devices across multiple locales based on the current version of the app was just too good to leave behind.

In the end, in order to get reliable results, I ended up duplicating my main scheme and simply removing all other UI Tests, leaving only tests specifically designed for Snapshot. It’s defiling the sanctity of my tests to have tests specifically to take screenshots, of course, but the potential time saving benefits are well worth it and, hopefully, it’s only temporary.

Here’s how I did it:

1. Click the app icon to get access to the Scheme menu, then click ‘Manage schemes…’

Screenshot showing how to access the scheme manager in Xcode

    2. Select your main app scheme, then down in the bottom left click the gear icon and click “Duplicate”

    Screenshot of the scheme options menu in Xcode

    3. Rename your scheme (e.g. <AppName>Snapshot) then click “Edit…”

    4. Click on Test in the left hand list, then click the disclosure indicator next to your UI Tests target and deselect everything except your snapshot tests.

    Screenshot showing how to edit the Test target of the new scheme in Xcode

    5. Finally, (assuming Fastlane is set up in your application folder) edit your Snapfile at [AppDir]/fastlane/Snapfile and set the scheme to your newly created scheme:

    Snapshot will use this new scheme and only run the relevant tests.

    It’s not ideal, as having Snapshot run through every test and verify they pass on every device before uploading a build is good practice, but given the unreliable nature of the simulator for me at the moment this at least gets me some of the benefits of using Snapshot.