Rough Sea Games

Automatization of repeated work is one of the keys to productive development. Another is abstraction of common problems to allow concentration on project specific work. Localization is one of the problems you have in nearly every project, especially in iPhone projects. The iPhone SDK brings interesting solutions that abstract many parts of the localization process.

The tool ibtool, for example, extracts strings from an interface automatically. The strings are placed in a .strings file, a textfile with key/value pairs. To localize an interface, you have to translate .strings and merge the strings back into the interface again. Because you have individual interfaces for every localization, it’s possible to adjust widgets individually for each one.

genstrings is another tool inside the iPhone SDK. It extracts textIDs from the source code and write them into a .strings file. You may ask how the tool knows which texts need localization and which do not. The solution is the macro NSLocalizedString, which will be replaced by a .strings file lookup method by the preprocessor, but also searched for by the genstrings tool to create the files.

Both tools help you to create a localized application without paying much attention to localization itself. But you cannot expect the localization department to search for .strings files inside your project and create localized versions of them. Of course this would be possible, but not very convenient, because you have to migrate the translated texts back into the interfaces using ibtool. Another reason for us at Rough Sea is that we use a localization interface from our publisher. This interface is well known to the localization department and the content is placed in a centralized database on a server.

So we have the great tools from Apple that help us to separate texts from the project and we have the great tool from our publisher that handles the whole translation and reviewing process. Now we need something to tie those tools together, because we do not want to insert new texts from the .strings file into the publisher’s localization tool manually or vice versa. This glue tool has to execute the Apple tools, extract the texts from the .strings files and insert them into the publisher’s loca tool. On the other hand, it has to check for new localized texts from the publisher’s loca tool, build the required .strings files from the results and merge them back into the interfaces. Sounds quite easy, but of course there are some obstacles to get there. You have to handle other things, like the deletion of a text entry or changes to an already translated interface. So you have to know what has changed since the last update and stuff like that.

It turns out that you only have to integrate this glue tool into the build process of your build server. The tool will update the localization database whenever the code or the interface changes and it will update the localized versions when the database changes. As a coder you only need to remember to use the text macro around your text id. You don’t have to add this text id in a file or anything else. As you commit your changes, the build server will do this for you. As an interface designer it’s the same: just create your interfaces in the primary language and commit it. After the localization department finishes localizing those texts, they will be inserted into the localized versions automatically. Of course you have to make adjustments to the interface if there are loca bugs like labels that are to small to hold the translated text.

As you can see those localization tools are a big black box for coders, interface designers and translators. The coders only have to write code, the interface designers design interfaces and the translators translate texts. At the end there will be a localized product.

Popularity: 61% [?]

Here you can see Stripe from the movie Gremlins. He is the second movie monster based on a suggestion from our blog readers. The original idea came from Benita:By clicking on the image you can see a bigger version with a short Tutorial on how the image was created.

Chris

Popularity: 70% [?]

Designing an appealing and huge game world from scratch will take even really fast designers a looooong time: valuable time that can be spent in better ways. This is where generated content comes in handy. With the push of a button a designer can create a whole world (oceans, land, forests, deserts, mountains, cities, … ) in an instant. So this is what we decided to do for our game … and here is how we got to the finish line:

On the bumpy road to an actual working map generator we decided to split all map generation tasks into small modules: heightmap generator, water generator, forest generator, desert generator, and so on. In the map-generator GUI the designer can put these modules into a task list and define the order in which they are executed. Each module also has parameters that affect the characteristics of the generated map. Even though it is supposed to be a random map generator it is especially important to have deterministic behavior. Consequently, each module that actually generates content has at least a “seed” parameter for the random number generator. With the same seed the generator will create the same results every time. Changing the seeds will create a different map.

In the little animation above you can see the output of some of the modules.

Heightmap Generator
At first we create a heightmap. We use Perlin noise since it is built into the AS3 BitmapData class and it is amazingly fast. In the beginning we experimented with our own implementation of the diamond-square algorithm, but it was way too slow.

Water Fill
In the next step we apply water to the world. We simply declare everything below a certain height level as being under water.

Mountains
By looking for local peaks we detect mountains and flag the areas accordingly.

Humidity Map
By defining a water contingent that grows over water and decreases over land we can flag dry and wet zones on the continents. To make things easier we define our whole world as a west-wind zone. The centers of most bigger continents will be dry (yellow), coast regions will be mostly humid (green) and continental areas lying east of a big stretch of water will be very humid (dark green).

Climate Zones
Next we define climate zones in the world: tropical areas, temperate zones and polar regions. With this information we can easily place polar caps in the world.

Forest Generator
Using the information from the climate zones and the humidity map makes it possible to place different types of forests into the world. Jungle (purple) will be found in the hot and wet regions around the equator, while coniferous forests will be found close to the polar caps.

Desert Generator
The desert generator also uses the information from the humidity map to detect dry regions and place desert areas into them.

Well, now you had a look at some of the modules in our map generator. They are not only capable of creating earth-like maps (like the small sample map above) but also completely different maps by changing the parameters: a lake landscape, a waste land, a desert or whatever our games may need. With this we are able to quickly create new game content of any size for the players to explore.

Cheers,
Manuel

Popularity: 100% [?]

Hello out there,

my name is Thomas and I am the first programmer in our new R&D department. Like most of the other guys here at Rough Sea, I’ve worked on games for consoles (Nintendo DS and Wii) and PC before. I’m very excited to develop sophisticated software that helps us to make state-of-the-art games. Of course this is only technically, but I’m pretty sure that Rafael and Jan will assure this for the design part too.

I assume you’ve read the headline already, so you know what the R&D department will work on in the coming months. We’ve decided to do some research on the iPhone, because we think the way you use the iPhone is almost the same as how you play a browsergame. You get your iPhone out of your pocket, use it for a few seconds and put it back again. You have nearly the same procedure with browsergames: you open your browsergame window/tab, change a few settings and go back to work.

So the first thing to do is getting your working environment running. The only legal way to do this is to buy a Mac. I’m not really happy about that, because I’m a Windows guy and there are some differences in using MacOS instead of Windows. Maybe Apple only invented the app store to sell some of their Macs to iPhone developers. Nevertheless after some adjustments the Mac became usable. The nextStep (pun indended) was the installation of the iPhone SDK and all the tools that belong to it. It’s quite easy to get from the installation of the SDK to the first Hello World on the simulator (especially if you compare this to console development).

We at Rough Sea use test driven development and continuous integration to assure that we always have  a deliverable product at hand. Unit Tests are already integrated into the SDK and it was easy for Ole to set up a build server on a Mac Mini with hudson and the makefile-like shell tool xcodebuild. You don’t have a makefile: the tool just uses the settings of the project file to know how to build. Another thing is that you can add and change text macros for the XCode IDE. Text Macros are very useful to write code much faster. For example, you can add an alloc-init call [[class alloc] init] simply by typing the letter a and then escape. There are macros for if, for and while too. Because we have different coding guidelines than the apple guys, I had to change some of the macros. You find them in /Developer/Applications/Xcode.app/Contents/ PlugIns/TextMacros.xctxtmacro/Contents/ Resources. Copy the TextMacros.xctxtmacro folder to Library/Application Support/Developer/Shared/Xcode/Specifications in your home directory. Just open the *.xctxtmacro files with a text editor to change the macros. You can add your own file and project templates too. This is very nice, because you can set up a default project with many settings, like Unit Test Targets, already in place, and use this project to create new ones with only one click. To add a new project template, create the project the way you like it and copy the whole project folder to Library/Application Support/Developer/Shared/XCode/Project Templates/GROUP_NAME/PROJECT_NAME. For file templates you should just copy the File Templates folder from /Developer/Library/Xcode/ to Library/Application Support/Developer/Shared/XCode/ and change or add the files you like.

Next time I will write about Objective-C and libraries from the iPhone SDK like UIKit.

Popularity: 80% [?]

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: 11% [?]

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% [?]

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

Popularity: 28% [?]

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

Popularity: 45% [?]

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

Popularity: 15% [?]

Row row rock the boat … gently down the stream ….

And this streams leads to an ocean sooner or later .

Maybe it is time to discover the ocean. Google Earth 5.0 has been released and this gives you the opportunity to discover the ocean, the ground, the whole planet Earth.

Click Here for more information about Google Earth 5.0

Popularity: 4% [?]