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!

We are hiring:

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

Just click the links for more information.

Cheers,
Matthias

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

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…

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

Goodbye Duke Nukem Forver or a last  ” Hail to the king, baby!”

We all played it! We all loved it! We all made jokes about some release date troubles. But who thought of living without DUKE NUKEM?!

Why did this happen? Maybe a serious alien invasion of the 3D Realms studios? Too much bubblegum to chew?
I hope Duke Nuke Forever will be not buried and someone can resurrect the charming hero of muscles and big guns.

But I am quite sure this will happen, as Duke has balls of steel! I keep on waiting to see DNF! Hear my words!

Here you can see Chucky the first movie monster based on a suggestion from our blog reader Mr. Boomerang:By clicking on the image you can see a bigger version with a short Tutorial how the image was created.

Chris

Last time I told you I already know what I will draw next for my new blog series Famous Movie Monsters. And here you can see one of my personal favorite movie monsters…By clicking on the image you can see a bigger version with a short MakingOf.
I already got some feedback and ideas for the next images in the series but if you still have a favorite you want to see write a comment to this post, name your movie monster and I will see what I can do…

Chris

To compare the performance of different approaches for handling large data I wrote a small test suite.

This application contains one test class (cDataHandlingTest) that writes to and reads from an abstract data class (iData). Each data class offers an unified interface but is implemented in different ways. The test class repeats each test several times, records initialization times and accessing times and then calculates the average for each data class. If you want to have a closer look on the code, you can download the FlashDevelop-project here. You can check out the test application at the end of the post.

Three-Dimensional Array (cDataArray3D)

This data class uses a three-dimensional array to store the data. Initialization takes a very long time because you need to cycle through several nested loops allocating the data. Access times are ok.

Linear Array (cDataArray1D)

Here I used a linear array for the data. Initialization for a linear area is lightning fast. The draw-back is the access, though. Calculating the offset of the data in the array is pretty complex:

var index:int = (((_y * m_width ) + _x) * m_entries) + _entryType;


This makes working with a linear array really slow if you cannot predict in what order you will access the data. If you will usually access the data in the exact order it is stored in the array, you would actually be really fast. Unfortunately, this is usually not the case. The linear array is about 10 times slower than the three-dimensional one on random access.

ByteArray Int-Based Access (cDataArrayByte)

In this example I used a ByteArray. The position is calculated in the exact same way as in the linear array example. Data is extracted by using a readInt() command on the stream, data is written by using the writeInt() command. I expected this approach to be really slow. Well it isn’t! On my computer it already outperforms the three-dimensional array in all areas. (It might not on others, though).

ByteArray Byte-Based Access (cDataArrayByteOpt)

If you only need values between 0 and 255 you can use the array operator [ ] of the ByteArray class. This is the fastest way to access the data. Initialization times are really good and access is on my computer about 25% faster than the three-dimensional array.

Test Application

This is the test. Click into the window to start. Be careful, it needs a lot of resources. If you have significantly less then 2GHz per core or only one core I recommend not to try it because it will lock up your computer for too long to be convenient.

I hope you didn’t take Manuels last blog post too serious.

Currently I’m working on a new series for the blog called Famous Movie Monsters. The series starts with Dracula (You know… the guy with the sharp teeth and sun allergy). By clicking on the image you can see a bigger version with a short MakingOf.
I know what to draw next, but if you have ideas, wishes, suggestions… feel free to add them in a comment to this post and who knows… maybe you can see your favorite movie monster here on our blog soon…

Best wishes and a happy easter!

Chris