Digital Dave

Have you ever built something and sent it out into the world for public consumption?  Did you wonder why people didn’t exactly have the response you thought they would have?  They didn’t respond the way you thought because they are not you.  People perceive what they experience differently depending on their skills, knowledge and passion.  While it is impossible to cater to every personality you can get a fairly good glimpse of this picture during your development phases.  In the end you will likely have buffed away issues that would have been common around the board.

Playtesting

So with Colorflys, unlike my prior projects, I planned to have playtesting sessions very frequently.  I will search out individuals after I complete each of my major milestones that incorporate major functionality into the game.  This way I will immediately see what people are having trouble with and what they like/dislike about the project.  If all goes well, by the time I ship the product I will have made a better game since I adjusted it from what people have already perceived of it.  It may not be enough to send you to the million download mark, but any improvement is a good one.

It’s not enough to have playtesting sessions while watching the participant.  You must take notes, ask solid questions that revolve around your goals for the session, and really listen — all with an open mind.  It will be frustrating to see people stumbling on things you could have swore were easy, or with things you thought were hard, but, again, these people are not you.  Don’t ignore reoccurring issues.

Beginning the Session

Before you begin your playtesting sessions, pin down exactly what you want out of the session.

For example, I recently completed my initial build for my pathing/movement routine and my main gameplay component.  For this playtest I had two major questions that I wanted to answer with each participant.

1. How challenging was it for the player to execute the main gameplay component?
2. If there was a noticeable problem, what did the player think would make the task easier?

You should always add a final question, ‘Did you leave the player wanting more?’ If you can talk about where you’re project is going after the session, and feel a good vibe, then I say you’re on the right path.

I select participants by how often they play games.  Some of them had very little gaming experience, while others were more hardcore.

The Outcome

At this point of the game I don’t want this to be hard for any player.  Overall, the results showed that it was not challenging to execute the main gameplay component, which was exactly what I wanted.  But, there was one participant that has played a game similar to this.  This is a case of old habits die hard.  They were used to committing this action a certain way and expected it to be exactly the same.  My takeaway is that I will incorporate a way of handling users that fit into this category because, in the end, it was not an unreasonable expectation.

The Next Session

My next playtest session will be conducted with a new batch of faces (5 – 10 people) after the level/progression system is incorporated.  My goal is to get a feel for how challenging the actual game will be for players.

Moving through a project will present unforeseeable challenges. The key is learning from those challenges and passing them on to everyone involved with the development of the project. Most likely the challenges that occur in one project will rise in another project and if you can present these to a group of developers before a project is in full motion maybe you can save yourself a headache or two.

But let’s not focus soley on what went wrong. It is very easy to nitpick and critize everything we do or didn’t do. What did we do right?

Writing a post mortem is about uncovering these key challenges so we can learn from them, but also our highest acomplishments so we can teach others. Even as a independent developer I reflect on what I did wrong and what I did right when I complete a project. I write these down so later I can revisit these documents to reflect. That reflection will influence my direction and hopefully help me create a better product in the future.

So I take a couple sheets of paper and answer two deceivingly easy questions -

1. List your top 5 items you feel went right with the project?
2. List your top 5 items you feel went wrong with the project?

From there I look at each technology I ended up using and making a note of my biggest challenge with that particular tech. This will give me a heads up in the future in case I mysteriously forgot that ‘thing’ that took me a week to implement.

That’s the key. Once you fire up a new project look back at your post mortems so you can refresh your mind on what you have done right or wrong in the past.

This question was asked on the new Game Development stack exchange website that is in beta. My answer takes a bit from my previous post and adds a few more tactics I use for development.

To-do Application
I use Things for Mac and ToDoList if I am working on a project on Windows. Alternatively, you can jump onto sourceforge.net or codeproject.com to grab a to-do application. You will have a lot of sketches, ideas, design information that really needs to be aggregated into one spot. Having an application like this with your feature list will help you stay focused.

Small Tasks
“Implement Leaderboard View” is not a sufficient task. What does that involve? Break it down -

• Create background artwork for leaderboard view
• Create class methods that fetch score data
• Create class methods that post score data
• Create a view controller which will display a back button, reload button, and a table view
• Implement the table view to load in the data from the model

Seeing the picture in finer detail will reduce your chances of missing a key element of your implementation and will provide you motivation as you tick off each task.

Keep the Scope Small
Don’t try to build Starcraft III if it is just you, scruffy, and purrdoodle. It’s just not feasible. Lower your expectations and find something you would still enjoy building.

Eye-candy
Get something on the screen — you may be surprised on how big of a jolt to your motivation it will be. I tend to focus on getting artwork early. In addition I also am able to work with a musician who starts showing me stuff relatively early as well.

Have fun
If you’re slaving over your save state system all of this week be sure to follow it up next week with something that is fun. One of my fun moments was redesigning the animation system for my user interface.

Collaborate
You don’t technically need to start adding people to your team, but talk to other people about what you are doing. Jump over to tigsource.com or gamedev.net and start networking.

Playtest
Start getting early feedback on your game. I’m talking about right after you finish your initial prototype. Let some of your friends mess around with what you have, get feedback, take notes, and revise your plan if needed. Be sure to test outside of your realm of comfort and cast a net that includes other game developers. Sometimes friends and loved ones are just not critical people.

Start a Blog
Talking about what you’re doing allows you to build a brand for yourself. This is priceless when it comes time to shipping your product. Just look at what Wolfire is doing. They are absolutely pure win at building a brand for themselves.

Take a Break
If your mind isn’t into the project at a specific time don’t try and force it. Get up and go for a walk or take a quick nap. That is the luxury of being an independent. In the end you’ll create a better product for doing so.

When I developed Project Void I spent a lot of time sketching out how the game was going to look before I actually started piecing the game together. My goal wasn’t to have a concrete design that would obliterate the opportunity to be agile but rather I wanted a good blueprint for where I was going with the game.

The Prototype

After I created a few sketches on paper outlining how the user interface was going to look, and how the game was going to play, I spent a few hours putting together an extremely simple prototype. I worked on the graphics and put together 480×320 PNG images of the game. I constructed the title screen, option menu and game screens. From there I put together an application that simply shuffled these images in and out of view as I pressed on the screen. This gave me a fundamental idea of what the game was going to look like in motion.

Playtest

I see people wait until they are 3/4th of the way complete before doing any playtesting or, worse, they completely ignore doing it. First, don’t ignore it. Your game is going to be an absolute blast to you but it could easily turn 5 of your 7 friends completely off for reasons you could have avoided. You can’t playtest early enough. I took this prototype and gave it to a few people to play around with. All of a sudden I was getting some good questions and thoughts about things that I didn’t think about.

Eye Candy

I feel that it is extremely important to create some eye candy EARLY — especially as an independent developer. This will put your vision right in your perspective and will make you hungry to implement it. This doesn’t have to be limited to solely artwork if you have the luxury of having a musician at your disposal. Music can be pretty powerful and is a very big focal point in my projects.

But it can even be code as well. For example, creating special effects or implementing the animation routines for your menu system.

Approaching the iPad

I currently have 2 projects being built for the iPad. Considering that it is just me doing development it will be interesting to see how I will end up managing these two projects. Luckily, I have two great artists working with me this time so I can finally get away from my programmer art!

So far from my design I will be taking advantage of the screen for the user interface. I’m not completely swapping views to display options, achievements, or even the leaderboard — all of this info will be accessed from the main menu with tighter views overlaying the menu.

The biggest change from the way I worked on Project Void is that I am spending time during the design to work on the model (MVC). If a project falls flat on it’s face after the first prototype at least I may have learned something. Also, since it’s the model, I can store it away for that game I develop down the road.

Conclusion

So the three points I would note is

1. Design a simple prototype as early as possible
2. Create some eye candy (or ear!)
3. Playtest routinely through the development

A buddy asked if I could create a simple application which would allow him to post GPS data from his device to a custom website that he was using. Easy enough. So I whipped it up and sent it his way.

Then I got to thinking that I don’t have any good sample objective-c code from my previous projects on my portfolio and in addition to that, I have never contributed anything to the open source community before. I jumped onto github and started to bring in this application. The original application didn’t have much of a UI so I spent a little time putting one together.

This app works by taking custom website and script given by the user. I default this to http://www.david-mcgraw.com/gpsinfo.php which simply returns the post values that is fed into it. Imagine the full URL being built like http://www.david-mcgraw.com/gpsinfo.php?long=34.48&lat=39.33&alt=38.43&userid=1. The user can then post that data whenever needed.

Right now you can change the settings and post. I thought it would be handy to add a map that shows you your previous posting locations in addition to a log view. I don’t have the time to implement those right now, but I hope this gives an idea of how I work in this environment. Hard to say if anyone will actually grab the code to work on it, but I doubt it.

http://github.com/mcgraw/GPS-Updater

How many of you are carrying a business card? How many of you know how to grab enough information from somebody to create a link that you can use to follow up?

Let’s just say you just happen to be standing next to somebody while you both are enjoying an event. Well, that seems normal… It’s just like every other person you stand next to every time you go somewhere. Standing in line to grab a cup of coffee at Starbucks? Maybe a museum exhibit? But this time a conversation sparks as the event plays out. You learn that this individual is very experienced within the industry you are involved in. Quick! What do you do?

Time’s up. Connection opportunity disconnected… Did you get enough information to follow up?

The time it took for you to read those last two lines is about how fast you can lose out on a great contact. Be sure you have enough wit to maneuver effectively within a situation like that. The person you are talking to could, literally, catapult you to new heights.

Congratulations, Welcome to Yelp! Here are your friends who are already on Yelp and here are your contacts who are not on Yelp, yet! Who do you want to invite?

Congratulations, Welcome to Farmville! Here are your friends who already play Farmville, and here are your friends who don’t! Who do you want to invite?

Congratulations, Welcome to Loopt, Foursquare, Gowalla, and whatever new social geo-locating friendship app comes out in the near future! Here are a bunch of your contacts, who do you want to invite?

…

Request sent

…

Wait for a response

…

Send a reminder

…

I’m sure you’ve been able to grasp the point by now. There are a whole lot of applications out there right now that feeds into your social graph. If I am connecting to an application that several of my friends are already using, why should I send an ‘invite’ for those friends to join me? They are my friends for a reason!

Some people like to invite random people into their social graph so they can take advantage of the benefits that come from having a large friendship network. I can see why you may not want those people to instantly be connected to you when you sign up for an application that both of you have. Well, there should be lists that control the scope.

Facebook dominates in knowing who your friends are so they would be the most suited to tap into this experiment. They’re view on privacy pretty much means they would be open to implement something like this as well.

This problem is obviously seen in Facebook games. How many Zynga game invites does it take before your friends start ignoring their notification area? If, by chance, your friend actually looks at their notification area you will get connected. But a lot of people are probably ignoring notifications since it is a huge spam-bucket. So, now you are left with the option of sending an actual message to your friend to remind them about your invite. Great, more spam.

In my mind, it makes sense for a game to know who of my friends are already playing. Moreover, It makes sense to just connect those that are in my friends list to a game that I am new to. This bottleneck of inviting doesn’t have to exist.

Expand that to other applications outside of Facebook. Hi, Yelp, You already check my contact list for those that are already within your network. Well, it doesn’t sounds too extreme to think that those people are probably people who I have a friendship with. Why not just link our accounts together? This is just one example, but there are many applications that are starting to tap into your social graph.

It’s only going to get worse.

I’ve been on the lookout for some good books that are startup in nature. Rework fit that bill easily. This book was written by the brains that brewed 37Signals and they give some great advice.

The book is divided into small chunks which makes it easy to put down and pick back up. The good news is that you’ll probably plow right through it since it is pretty entertaining to read.

A couple of pieces that stick out in my mind -

About failing
“Another common misconception: You need to learn from your mistakes. What do you really learn from mistakes? You might learn what not to do again, but how valuable is that? You still don’t know what you should do next.”

Which is followed by, “A Harvard Business School study found already-successful entrepreneurs are far more likely to succeed again (the success rate for their future companies is 34 percent). But entrepreneurs whose companies failed the first time had almost the same follow-on success rate as people starting a company for the first time: just 23 percent.”

About being a workaholic
“Workaholics miss the point, too. They try to fix problems by throwing sheer hours at them. They try to make up for intellectual laziness with brute force. This results in inelegant solutions.

They even create crises. They don’t look for ways to be more efficient because they actually like working overtime. They enjoy feeling like heroes. They create problems (often unwittingly) just so they can get off on working more.”

This especially hurts the people who are NOT workaholics. Those people feel inadequate.

Meetings are toxic
Not that we don’t know this. But why are companies not paying attention to this? Granted, I only have experience at one company, but our meeting process is terrible at best.

A couple of points they make that I like… “Set a timer. When it rings, meeting’s over. Period,” “invite as few people as possible,” “End with a solution and make someone responsible for implementing it.” I would also be a fan of removing the chairs and making meetings stand-up right by a whiteboard that has the problem written out and circled.

Your competitors
“Who cares what they’re doing”

Your customers
“Let your customers outgrow you”

Don’t be the people who continue chasing after customers. If your service no longer satisfies their need, let them move on. Focus on those that really need your service instead of diluting your service by casting a wider net.

There is so much good stuff in the book that I could continue writing. But, instead, I highly recommend checking it out.

If you’re in the developer program.

From the many I’ve watched, I downloaded and tucked away these that I thought were worth keeping.  There are some outstanding sessions.  I think I have about 13 more sessions I plan on watching.

Coding

Session 113 – Working Effectively with Objective-C on iPhone OS
Good refresher on a few topics from a veteran at Apple, Blaine Garst
Blocks, @properties, categories, selectors, delegates, @optional

Session 114 – Advanced Objective-C and Garbage Collection Techniques
Class extension, synthesize (and optional to synthesize), weak linking, blocks (talks about stack/heap), leaked/abandoned memory

Session 123 – Building Animation Driven User Interfaces
Adding animation is one sure-fire way to give your application a feel of polish and detail.

Adopting Multitasking Sessions (105/109): If you don’t like reading, watch part I, otherwise, read the documentation which is really well written.  Part 2 shows some great examples of doing things in the background (audio, location, etc).

Session 120 – Simplifying Touch Event Handling with Gesture Recognizers
Goes over UIGestureRecognizer. Documentation is here.  I was actually unaware of this… We’re talking about dropping 220 LOC to about 40 LOC, optimal, and simple to implement. Very sweet stuff.

Design

Session 103 – iPad and iPhone User Interface Design
Considering that we all can’t hire excellent designers, we need to take it on ourselves to hear how designers think so we can produce something with simplicity and elegance.  There are some great points given in this talk. At least skim through it to see their major points of interest.

Tools

Session 310 – Advanced Memory Analysis with Instruments
Memory is absolutely critical on these devices. The included instruments are insanely useful. Take advantage of them.

“The application-identifier entitlement is not formatted correctly; …”

Are you seeing this error even when your bundle identifier is listed correctly on your provision profile and your info.plist?

Delete your Entitlements.plist file and re-create it.