Rough Sea Games

It’s always impressive, right after E3, to consider all the games that I could (or will) buy this year. The graphics and environment get more and more realistic, the heroes cooler and cooler. So shouldn’t that indescribable excitement — the release day fever, the “just can’t wait” trembling — have hit right about now? Well, it should have, but…

The developments of recent years provoke in me, an active gamer for a quarter century, the opposite feeling. The ever-increasing pressure to add unique selling points, better graphics, physics, etc. has decreased the willingness of the developers (or rather the publishers) to explore new directions, and in the end, they mostly produce interchangeable pablum.

Back when blocky pixels and abstract forms invited us to fill their gaps with our own stories; when we waited for minutes in a submarine off Gibraltar for the sun to set; when, after endlessly repeated runs through a level, we finally found the hidden key and with it an indescribable joy, games were primarily sparks for our imagination. Today they simply fulfill our expectations. We used to buy the key to a new world; today, a consumable product.

Today’s gamer has been squeezed into a mold of expectations. He expects games to work in certain ways; any deviations must be carefully explained in advance. Confronting the player with a task that he must solve by his own efforts, without hand-holding, is no longer allowed. Recognizing the patterns and mastering new skills was part of the attraction of earlier games. These days, games have degenerated to pure entertainment. They no longer challenge, they simply divert. This parallels the development of films, which have gone from providing a topic of conversation for post-show socializing to grabbing our attention with ninety minutes of bombast that are immediately forgotten.

Whether lack of design imagination will eventually lead games to follow another film industry trend, namely remakes, remains to be seen. Regardless, throwing away the chance to create high-quality games will certainly confirm a widespread and long-held gamer prejudice: anybody can design a game!

Popularity: 25% [?]

We are hiring:

• QA Manager
• Lead Programmer (R&D department)

Just click the links for more information.

Cheers,
Matthias

Popularity: 15% [?]

Hi there,

our company website is online since yesterday.  More improvement and updates to the website will follow. This blog will get an overhaul as well, in the upcoming weeks .

Cheers,

Matthias

Popularity: 13% [?]

Our server code can be built with one click. The build process does not take long. To be precise, the build server says “last build: 1 minute 38 seconds”.  That’s cool. (And mainly it’s because the code is not that complex yet…)

But despite fast builds and because they are definitely going to get slower as the project progresses, we need the ability to change certain parts of the game logic with a minimum of work. So far this is mainly for the game designers, who want to be able to change some equations that influence the game’s balance. Defining stuff in config files that are read on server startup is nice, and we use this as well, but starting the server takes time, too. A better way is to be able to change game logic at run time.  So a scripting language was the way to go.

We decided to use groovy. Now groovy is not a scripting language at all, but more or less an object-oriented programming language that can be used as a scripting language for Java. Groovy has some advantages over Java like e.g. dynamic typing.

Unlike in other scripting languages, the groovy code is not interpreted at runtime but compiled into java byte code. So don’t forget to automatically reload the scripting files every now and then to make sure that changes in the files are actually applied.

We haven’t yet decided whether to keep the scripting in the release version of the game or not, since implementing the logic in the code is surely better for the performance. People on the Internet tend to accuse groovy of weak performance in comparison to other scripting languages.  But it is very pleasant for experimenting during development. If you don’t believe me, go ask our designers…

Popularity: 9% [?]

Hi there,

we were quite busy over the last weeks,  so updates of our blog are currently reduced. We are only going to post once a week in the upcoming month, but this should improve the quality.

Today I will continue my project management series.  In my first post I described the common mistakes which are often happening when estimating tasks:

- Mistake 1: Estimation is not done by the task owner
- Mistake 2: The task has no proper description
- Mistake 3:  Estimation is done by averaging worst case with best case scenarios
- Mistake 4:  The tasks are too big
- Mistake 5: The tasks have unclear dependencies
- Mistake 6: The owner puts some unknown buffer time into the estimation

Please check out the first part of this article to find viable solutions to those mistakes.

The mistakes I wrote about are not really specific to a single department; most of them are quite common problems.  Unfortunately, there is one department where task estimation can be very difficult.  It’s obviously the programming department that I have in mind. Estimating tasks with programmers is quite an awkward  business.

You need lots of knowledge and experience to get numbers that are even close to realistic.  As a project manager you may wonder why this is so complicated and why programmers’ estimates are so often unreliable.  There are several reasons:

Mistake 7:

Taking the estimates of a rookie programmer as the final estimate

Solution:
Programmer performance varies by a factor of 10, which means a very good programmer can solve a given problem ten times faster than a bad one/rookie. No problem, you think: just let the slowest programmer estimate the task. That will unfortunately not solve your problem.

Young programmers tend to overrate their skills and dramatically underestimate tasks. So let the lead programmers, who are able to rate programmer performance as well as task difficulty, review the rookie’s estimate. The more experienced programmers check the estimate, the better it gets.

Mistake 8:

The buffer time for the programming tasks is the same as for any other task in the project plan

Solution:
This is nothing new and a lot of people have written about this problem, but unfortunately it’s still not accepted as an unalterable fact. Maybe it’s because of the certainty that there is no simple formula to determine the right buffer time.

It really completely depends on your programming team. You might have a 100% or even 200% buffer time and it’s not enough. Track real life data and your estimates,  compare them, learn from them . Every programmer has his own speed and estimation techniques.  Find out which ones are reliable and which are not and adjust your buffers accordingly.

Mistake 9:

Assuming that a programmer programs 8 hours a day

Solution:
If a programmer tells you he needs one day for the task, does that mean one real life day? It depends, again, on the programmer, but you should not ask how many days; instead you should ask “how many hours do you need?”. This is very important because a rookie programmer might not have realized yet that his effective  programming time is only 4 to 5 hours a day.

Mistake 10:

Changing numbers in the project plan in order to change reality

Solution:
Project managers very often reduce the (massive) programming buffer times after estimation is complete, because it tightens the project schedule and seems to save lots of money.

Well you know the answer already: this does NOT change reality and you will not save a single cent. Instead it will cost you a lot of money! Never reduce programming buffer times unless you are absolutely sure it can be done faster.  To put programmers into a crunch because you reduced their necessary buffer times will damage your reputation, and the team will not trust you anymore and will sneak their own buffer times in their upcoming estimations.

Next time I will talk about crunch, a very common technique to waste money and lose good employees.

That’s it for today, thanks for your time .

Cheers,
Matthias

Popularity: 16% [?]