Archive

Archive for October, 2010

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.

Conclusion

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….