Rough Sea Games

The Rough Sea Games team wishes you a Happy Halloween 2009!

Popularity: 39% [?]

I have finished the last part of the BadAss Rabbit graphics workshop (part 4 of a series) for the German game developer magazine ‘Making Games‘. In this series I created a 3D lowpoly game character model. You can find the workshop in Making Games 04/09, which is out now. Here you can see a test animation from the workshop:
Bad Ass Rabbit – Testanimation

Chris

Popularity: 41% [?]

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

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

Most computer game designs of recent years conspicuously neglect level design. A level designer’s job isn’t limited to level architecture and scripting — a game can benefit immensely from consistent atmosphere and psychological steering of the player. Modern level design should also be understood as a reality check for game design ideas.

Instead, many current games have filled this position inadequately or even tried to make it into a (minor) part of the game designer’s role. Ideally, the game and its scenarios should be believable and understandable, and the player’s actions should be cool and fit into the world; instead of adapting real life to achieve this, new games have introduced specialized, more or less awkward mechanisms.

In earlier games, all openable crates looked the same, and any slope that could be climbed had the same vine hanging from it. Such conventions were tolerable in the graphics of the time.

Such repeated elements aren’t welcome in today’s nearly photorealistic games, which makes levels harder to “read”. Thus, the aforementioned new mechanics:

Wolverine offers “smell-o-vision”, which highlights interactive elements and the path onward. However, this only forces us to play much of the game in false colours.

In Watchmen – The End is Nigh, a button press turns the character to face the direction in which he should next go, rather than designing the level so that the player can figure it out, or at least including a compass in the HUD.

The first clips of the new Splinter Cell show a system in which the character is shown as a ghost in the last place he was seen by the guards. Also, we can storm a room in the style of a modern action film, quickly and precisely eliminating multiple opponents that we have previously observed and marked. This will probably push the game toward an arcade feeling, because it doesn’t allow the player to know intuitively where his enemies are hunting him — it just breaks the atmosphere to show him directly. Also, storming rooms won’t feel fast-paced and cool, because it’s achievable only after a planning phase rather than simulating rapid and accurate shooting through e.g. discreet autoaim.

There are, however, counterexamples: while fleeing on the jetski in Half Life 2, for example, the level design uses the size and lighting of areas and scripted events to push us subliminally through the canals, so that we feel as if we were spontaneously choosing the right path from several alternatives. If we examine the map afterwards, though, it turns out that all of those (not so appealing looking) branches are actually dead ends. Skillful placement of eyecatchers makes the rail feel like a huge open space.

Clearly, there is much to do in the discipline of level design if the next generation of games is to offer a play experience as beautiful as its graphics…

Popularity: 67% [?]

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

Hi, my name is Peer. When I am not studying Media Design at the DHBW Ravensburg, I’m one of the busy artists working on Rough Sea Games’ premiere browser game. I have known the majority of the people here for years and I very much enjoy being part of this great team. This is my first blog post.

What if you wanted to create a lot of 2-D graphic assets, like for a map, which need to be very detailed and have a painterly look?

There are two ways. One is to paint; the second is to do it in 3-D and use the pre-rendered graphics. Sadly, pre-rendered objects in browser games tend to look very lifeless, sterile and, well, pre-rendered. The result is reminiscent of mid-nineties PC games.

Painted objects often carry more expression, more color, and more variation. To achieve that in a 3-D model would require a lot of small detail work. To get a highlight or a crack at exactly the location you want it to be is quite cumbersome in 3-D (it is also like shooting sparrows with cannons  if the final graphic asset won’t be very large). But painting everything while keeping a good amount of detail and coherence would be an enormous task.

Both approaches have their advantages, so why not combine them? What you are after when you need to produce dozens of objects is:

- Detail
- Coherence
- Reusability
- and of course, it needs to be done fast.

Over time you produce a huge amount of reusable assets. Those can be used in other objects to quickly add detail while maintaining a coherent style. By using the same lighting setup and materials you ensure a coherent style, even if you have to create dozens of models. Because of the similar ‘base’ for each model, it’s also very easy to split work between several artists.

Another important aspect is that, during the 3-D phase of the workflow, it’s very easy and quick to rotate, scale and retexture objects to create variations before deciding on the one you want to finalize.

Let me demonstrate my workflow with an example:
(The small lighthouse used in this post doesn’t have anything to do with our title; I did it tonight for demonstration purpose only)

1) First, you build a 3-D model while keeping in mind the camera position and scale it will have in the game. Don’t try to be too exact in the 3-D model. Everything can be quite rough and blocky. Details like surface imperfections, interesting highlights and minor details come later, in the painting stage. Very faint textures can be mapped onto the objects to create some ‘meat’ for the paintover. Don’t be too perfect with the mapping: simple boxmapping is often quite enough.

2) The first stage in painting over is to get some more variation in the shading. Because of the small scale, a very simple brush is enough. I just picked up some colors from the render and tried to get rid of perfect shading and all too straight edges. Then I painted some small details like cracks, dents and highlights. The 3-D rendered base model is a solid foundation, because the perspective and the lighting is already there. You can also experiment with blending textures of the picture to dirty up some areas.

3) The final stage is the color correction. Always do some color correction afterwards to make some areas pop, or to mute some others. I added some levels and selective color corrections with layer masks to further emphasize the lighting direction and to get some more bluish tint into the shadows. Then I selectively sharpened some areas to increase the contrast.

The lighthouse took me a little more than 1 1/2 hours from start to finish.

I hope you enjoyed my debut as a blogger : )

Best regards,
Peer

Popularity: 91% [?]

I have finished a new workshop (part 3 of a series) on how to map a 3D model and how to create and paint a texture for this model.You can find the workshop in the new issue of the German game developer magazine Making Games 03/09, which will be out soon.

Chris

Popularity: 84% [?]

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

Greg Costikyan is an idealistic game designer and critic who has been trying¹ to foster innovation in computer games since 2000. Back in 1994 he wrote a famous² game design theory essay: I Have No Words & I Must Design, with which I mostly agree… but I’m going to take a bit of it out of context and pick on it anyway. Here’s the quote:

If the game has more than one ‘resource,’ decisions suddenly become more complex[...] If I declare against the Valois, Edward Plantagenet will grant me the Duchy of Gascony, but the Pope may excommunicate me, imperilling my immortal soul.

These are not just complex decisions; these are interesting ones. Interesting decisions make for interesting games.

The resources in question have to have a game role; if ‘your immortal soul’ has no meaning, neither does excommunication[...]. Ultimately, ‘managing resources’ means managing game elements in pursuit of your goal. A ‘resource’ that has no game role has nothing to contribute to success or failure, and is ultimately void.

Costikyan is 100% right that dilemmas are interesting, but are the only interesting dilemmas game-mechanical? Well, when it comes to the current state of computer games, yes. “Hard core” players separate the game’s mechanics (e.g. the way the chess pieces move) from its “colour” (the pieces’ shapes and names) very quickly, and ignore the latter. But does it have to be this way? I say no! There are other ways to play. In a game that engages the player’s emotions — in particular a role-playing game in its true sense, in which the player strongly identifies with the character she controls – “colour” can dominate game-mechanics in the subjective play experience. Emotionally loaded decisions are interesting even if they do not affect your progress towards a goal — in fact, especially if they don’t: if the cowboy in the white hat accepted the reward for killing the bandits, he’d be a mercenary, not a hero³. Moral decisions become especially interesting if being virtuous actually makes the game harder.

The emotional impact of decisions increases if the game world reacts to them. For example, the quartermaster in Deus Ex reacts disapprovingly if the player decides to massacre all enemies in the first mission, although that is a game mechanically acceptable victory. Such reactions require a light touch to avoid becoming puerile and a lot of cleverness to avoid being very expensive (since the game developers must determine what behaviours they want to measure, how to measure them, and how to make the world react to them), but even in rudimentary form they are hugely rewarding for some players.

¹ And so far, alas, failing. In 2000, he hoped cell phone games, being cheap to make, were going to become a fountain of creativity. In fact, because potential players just see lists of titles (rather than demos or even a box blurb), licensing tie-ins or massive marketing are even more essential than in the “classic” games industry.
² “Famous” in a tiny niche of game design snobs, anyway.
³ Mercenary attitudes can be emotionally involving too, of course, but if they have no hidden heart, they get dull fast.

Popularity: 83% [?]