Archive for the ‘iPhone, iPad, iPod touch’ Category

Tutorials and Game Development

October 29th, 2010 No comments

Tutorials or training modes in games are useful for players to learn your game. The simplest games might be discarded by players because they cannot figure out how to play the game. This blog entry is based on my own experience in this matter. I will describe how I have done it so far and how I plan to do it in future game development.

Games developers coming from a business application area will know, that there are some fundamental differences in developing games instead of a business apps. The business app tries to solve a business case, where the program typically processes data and presents it to the user after some processing. A game is all about the user, here called player. Business apps need to be mathematically correct, whereas games might not even use correct physics. So, business apps are helping a user to solve a problem. Games are made to entertain the player, much like a movie.

Many developers begin to craft a game by making the main part first. Afterward, they add some intro and end-game scene. Based on my experience, this is wrong. The main part of the game will often appear detached from the rest of the game in the described case. The player will thus get a feeling of an unfinished or lower quality game. Furthermore, the developer will quite often find it difficult to add the missing parts, once the main part of the game is done.

When doing business software, I often tell developers to make the simplest implementation through all layers. I call this a feature bullet. You will avoid ending up with two parts of the system not being able to communicate (integration problems). Also a typical case is when something in the last steps fails due to technically impossibilities. By using the feature bullet you reduce the risk of failure, the risk of producing code-waste and you have a way to try out the feature earlier.

The feature bullet is also applicable for game development when you take the whole game and create the simplest possible playable prototype. This will typically include the tutorial part, because you want to distribute this to someone else in order to get his opinion.

So far I have discussed the game dynamics. Let us now look at the architecture and the way to integrate the game parts, especially the tutorial.

The best similarity between the tutorial and other concepts in application development is test driven development (unit and integration tests). Look at the tutorial part as a reference implementation of the entire game. Write the tutorial first and keep it updated while you extends the game with more features. You will always have an up-to-date tutorial for the current state of the game and you can at any time ship it to the beta testers, even though you are missing the uber-cool monster in level 516.

The implementation itself relies on your methods and algorithms to be scalable and configurable. In case you made the main game part as the first one, it is most likely, that the methods lack these attributes. A tutorial should be a scaled-down version of the main game in order to introduce the player to the main concepts. As a simple example you can imagine a puzzle game. It uses X by Y tiles and the goal of the game is for the player to re-arrange the tiles. Let us assume, that you hard-coded the game to use 20 by 20 tiles. This is too complicated for a novice player. A 5 by 5 tile game could just as well serve the purpose to explain the game. As a live demonstration of this you can take a look at the free iPad/iPhone game Lupus.

The principal idea of this blog entry is to use the tutorial part as a test tool for yourself and as an introduction for players. You want to work against a goal and the tutorial part keeps you on track. The game must provide a coherent and easy way to interact with it. Use the tutorial part as a proof-of-concept to test out new features before spending weeks on development. Building your game in parts and not using the feature bullet approach will let you end up with your architecture dominating the user experience. It is one of the principal patterns in GUI development to avoid that. Use the tutorial part to guide your game architecture.

JAOO went Pink

October 10th, 2010 No comments

Here are some thoughts on this years JAOO conference, ehm, I mean GOTO conference.

Biggest Surprise

First year that I attended the conference and it went from green to pink! Ok, at least not fluffy pink or metallic pink.

Best Quote

My favorite quote came from James Gosling during the Java User Group event. A guy from Nokia asked James, if he was concerned that Java would disappear. James replied: “No, these days I am more concerned that Nokia will disappear!”

Sexiest Session

Rachel Reinitz spoke about Management in the Large, where she illustrated the importance of a good management in order to achieve good product availability. (Fortunately) her suitcases went missing during her travel, so she did not wear the usual IBM suit.

Best Presentation

What Architects Need to Know by Frank Buschmann. OK, not so much news for an architect like me, but the session was really well presented. Furthermore it is always good to refresh the areas an architect needs to cover in order to do his daily work. 30% technical expertise, 30% leadership and 40% other. Most developers think it is 90% technical.

Most Groundbraking

Martin Odersky during the Scala training. I did not investigate Scala before this session, but now I will definitely incorporate it – I am sold!

Most Disappointing

Software Engineering at Google Scale by Jon Tirsen. Well, if you were new to computer science, then this session would have been OK. Otherwise, it was missing some key points on the solutions. Distribute calculations using shards and push instead of pull technology is not new wisdom. After the session you were asking yourself: How did he solve it? More code, examples or at least a little deeper into the matter would have been great.

Coolest Algorithm

During Brian Goetz Data Parallelism in Java session I had one of these “aha-moments”. The fork-join method using distributed work queues and applying work stealing will be on the list of my next innovation day.


Not so much news in agile, Java, management and the cloud, but a very good conference. I have enjoyed all six days and will definitely consider participating next year again. This year there were at least 80% of the people using a Mac or an iPad. Wonder what the Microsoft guys thought about that? They must have had a hard time to sell their Visual Studio licenses to this crowd….

Subversion, Mac OS X Server and XCode

August 14th, 2010 No comments

I write this blog entry to help you guys out there getting subversion to run on a Mac OS X Server (Snow) Leopard and access it through XCode.

I tried many how-to’s – they all failed to work. Something was always missing or incorrect. For a sysadmin or an SVN / Mac OS X Server expert it would probably be an easy task, but I am a developer / architect…

The breakthrough for me came with a description I found on Apples own site. Even though it refers to “Leopard” and not “Snow Leopard” it worked right away. Do yourself a big favor: Follow that instruction to the point and enjoy.

My environment is:

Client: MacBook Pro, XCode 3.x, Snow Leopard 10.6.4

Server: Mac Mini Server with Mac OS X Server 10.6.4

Time Capsule as the access point

Categories: iPhone, iPad, iPod touch Tags:

Ideas and Reality

June 21st, 2010 No comments

Good ideas are hard to come by, but people *think* that they have good ideas all the time. How can this be?

An idea itself is not struck by reality yet. You need to work with it, test it on other people or whatever the target audience is. This is not new and everybody is nodding now. So, the question is, why are there so few ideas that become actual products?

Most of the time I see a good idea being spoiled by people who can not envision it in their own minds and the guy who had the idea can not explain it. Almost as often the problem is, that the guy with the idea is not capable of bringing the idea to life. He is missing time, resources or skills.

The only way I have seen to work and resolve both issues just mentioned, is to make some kind of technology demonstrator, proof-of-concept or prototype. My observation here is that the tricky part is to reduce the proof-of-concept to the absolute minimum in order to show that it will work out. My rule of thumb is: If it takes more than a day to do – you are doing something else than a prototype. This is of course in the field of software – not making a new car or something.

Another aspect of the proof-of-concept is timing. Do not create something, which is based on creativity when you are stressed out and while you are doing something else. Furthermore, do not present it to people (if that is required), when they are in a hurry. A quick response to something new is almost always negative. People just love and embrace the safe and secure harbor of a known environment with predictive outcome. Give it time work in your and peoples minds.

Last, but not least – do not stop being creative and take failures as what it is: the best way of learning!

iPhone Developers and App Sales

June 17th, 2010 No comments

Just recently Apple published their first iPhone App (iTC Mobile), which allows you to check your App sales on your device.

In general this is good news for all of us developers, because the standard iTunes Connect Web Portal is not really suited to give a fast overview of sales and statistics.

The not so good news is, that it is the first version of the App and it still lacks some features compared to the other available 3rd party tools.

I personally prefer the open source AppSales App for the iPad. This App is not perfect either, but in my opinion it is still 21,5% better than Apples App.

Categories: iPhone, iPad, iPod touch Tags:

iPhone, Apple and the Glory of it

June 9th, 2010 No comments

It is a frequently discussed topic how much value you get out of Apple products compared to the rivals like Microsoft, Android (Google) and so on. I would like to state some of my personal opinions on this topic.

Basically, nothing is perfect – not even Apple! You can only discuss whether or not something is better or worse compared to other products, if you give the criteria of satisfaction. Otherwise you have no basis for a comparison.

So, my criteria of satisfaction regarding Smart-phones from a user perspective, are:

As a consumer, I want a device which easily and quickly provides me with the basic features of a telephone. Furthermore I want built-in features which help me organize my daily business tasks by using applications for e-mail, calendars and tasks. All the entered data must be stored in a secure way, so that these are both protected against loss and privacy is enforced.

On the surface, most smart-phones on the market will cover my criteria of satisfaction. So why have I chosen to use an iPhone as my primary smart-phone?

All the fuss about Apple being so rigid in the selection of what goes onto the devices or not makes me as a consumer much more confident, than all the other open, closed or semi-open platforms. When handling private data, I prefer a strong emphasis on security all the way through the process. While working with three different suppliers (Android, iPhone OS, Windows Mobile), I have come to the conclusion that the most secure feeling in my stomach is when working with the Apple products. This conclusion is based on the number and variety of problems I encountered when using these platforms. Foremost the stability of the software and the time spent on solving problems.

For the details, I have to dig into technical stuff. The following description is no longer from a users perspective, but from a developers point of view. This is the best way I can explain my findings, because after all, I am a developer and that is how my brain works.

I have mainly developed Java EE and Java SE applications the last couple of years and I have also worked intensively on .NET projects. All projects were large in time and budget (1000 man-hours or more). So in essence, I would have the best prerequisites for the Android and Windows platforms. Interestingly, it turned out that:

- I could quickly developed simple applications for Windows Mobile, but got stranded when I wanted to do real apps.

- I could never really get the Android environment to work, even though I have an 8 years daily experience developing with Eclipse in Java.

- It took me 2 hours to achieve creating a simple app written i Objective-C with XCode and upload it to a real device. (For fairness, not included are the 3 hours I used to get all the paperworks and provisions to work in order to upload to the device). After 3 days I had the first non-trivial App finished and posted to the App Store.

The last time I used Objective-C was in 1997. Back then I developed some AI algorithms in conjunction with my Masters Thesis in Computer Science. Before I started with developing Apps for the App Store, I had never used XCode before.

My conclusion is, that Apple provides a sound overall experience and thus gives me a good feeling in my stomach when using their software and hardware.

Categories: iPhone, iPad, iPod touch Tags: