Archive

Archive for the ‘Software Architecture’ 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.

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

Summer and Winter Camps

August 10th, 2010 No comments

We just finished our summer camp with great success on our current project.

What is a summer camp with respect to a software project you might ask?

Well, a summer or winter camp are seasons of the year where many or most of your staff and developers are on vacation, but not all of them are. So those who are left behind in the cold or summer heat will still have something useful to do. In many places people try to make a real sprint, just with fewer people and reduced amount of user stories. Those artificial sprints are often without big success.

The summer camp also has user stories, but these are either of innovative character or getting rid of PITA issues.

Many project managers might now intervene and say, that this is a clean-up sprint and this is not needed on their project or that they do not have time for such a thing because people need to be as productive as possible. To those managers I can just say: you are so wrong.

There are a lot to gain from this way of working during periods with a reduced number of team members. I experienced the most gain among these areas:

  • You increase the morale on the team, as people can tackle issues, which have bothered them for a long time
  • People are especially dedicated, because part of the user stories are their own idea
  • Absent team members do not have to catch up with a lot of new things
  • The product is actually advancing to a better state

Even I, as the chief architect on the project, benefit from these summer camps. There is time to dig a little deeper into various areas of the project.

Categories: Software Architecture 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 Development – Initial Comments

June 7th, 2010 No comments

By this post I will start a little serial on developing for the App Store based on my experience.

For the newbies among you, I have these basic hints (some you can find all over the places)

1) Do not expect to get rich overnight!

2) It is hard work (though fun!) to publish something with value. I would not feel satisfied earning some 1000$ on a fart-button App :)

3) Test your App on the real device. When I finally got the iPad in Germany, I was surprised how my Apps *really* performed! Also, if you can, get hold on some of the old devices. I have a 1. Gen. iPod touch. Trust me, the performance is not the same as an iPhone 3GS.

4) Make some small Apps in the beginning. Get a feeling of the framework, the iTunes Connect, the reviewing process. Many professional colleges have aimed too high in the beginning and stopped developing because they got tired and lost in a huge first time project.

I have developed for many years on many platforms and for many different devices. The XCode/iPhone development is in itself not so much different, but my personal driver in this is the possibility to get things out into the world and have a lot of feedback.

Categories: Software Architecture Tags:

Frameworks, the neverending story….

January 6th, 2010 No comments

Dear fellow architects,

Please consider avoiding to create frameworks, just because you think that a generic foundation for the upcoming project is just what need.

In my experience most projects can use existing frameworks and do not need to be generic in general. When you find yourself using the same complex code over and over again during the development, then make this part into a common reusable part of the project. This does not call for a special framework.

Also, think about all the maintenance time you will have to invest in order to keep the framework up-to-date. I guess that you want to invest as much time as possible in the business logic and other close-to-customer parts. You will have to stop coding these parts all the time and fix your framework.

Categories: Software Architecture Tags: