Rudi

Top  Previous  Next

Christian Behrenberg, the author of Rudi, kindly took the time to answer the questions for this month's interview.

 

Q: How big is your team and how long did it take you to create the game?

A: To cut a long story short: there was never a "team". The game has been planned & developed by me from the beginning, nevertheless I had some really outstanding people behind me. I believe you can achieve anything as long as you work with the right people. "Right" doesn't implicate that they are experienced or very talented, but if they are dedicated to what they do, have a certain passion for it and are hard-working, you can achieve anything.

 

It took in the end 75 days to finish the first public version of the game and the workshop until Christmas 2007 and there are a lot of stories to tell, I swear. When I called people in the beginning most were interested but I don't want to beat around the bush: over 75% of those proved to be unreliable and interested in other stuff than "finishing" a game.

 

Q: I see that the menu includes, among other things, “low”, “medium” and “high” details. How do these influence the game?

A: One crucial point during game development is performance vs. quality. The North Pole level is more detailed than I expected it to be. It has lots of vegetation, props, actors, shaders, particle effects, gameplay objects and of course, our hero, Rudi, with that really long chain of sleighs. So, in combination, the game can really slow down your PC - a little bit contrary to what you expect when you play a casual game.

 

The first premise beyond the "fun factor" (which is another story) was a high performance and a beautiful presentation. These two things are contrary and if you add A7 as engine, it is a quite tricky thing to discover the most elegant and powerful way to solve things - most people should know what I mean. The game has been always designed and produced for the "medium" detail settings on a Windows XP System at 2GHz with 1 GB of RAM and a Radeon 9800 128 MB graphics card. We wrote some shaders that were looking nicely but they are too slow for "medium" details mode, so these are switched on for the "high" settings, where we also have an increased density of effects and so on. The low mode is the lowest common denominator - a lot of entities are removed, you only see half of the special effects and some unnecessary actors are removed, too. We have also added the dynamic LOD of A7 for all models in order to get a speed boost, too. One really helpful thing was the use of the DDS textures, who have reduced the loading times and memory consumption. The ABT tree was also a reason for the good performance - in A6 this wasn't possible.

 

Q: Do you have some Easter eggs in your game?

A: Since the game is fully developed for its purpose, this doesn't mean a lot, because we have only one level. Though, there are two things in the North Pole - level... an iced A7 cube and a model which is covered with graffiti at one side. It is interesting that you ask if areas can be unlocked.. since we plan to add for the next version a level manager, we will be able to add unlockable bonus-levels. No matter whether this will be done or not - I am always a great fan of Easter eggs ;)

 

Q: What was the most complicated part of the game and how did you do it?

A: Obviously, the complicated thing was to get it done until Christmas. This involved lots of things, like making the workshop and the game being on the same level. Sometimes I was able to code and write simultaneously, but sometimes I had to invest time into coding instead of getting the most elegant and easy to understand solution (e.g. the path tracking for sleighs or the effect/shader code) before I wrote the corresponding workshop chapter.

 

I also didn't found a companion to work at the level environment, so I had to do this myself, which was also very new to me. In the beginning, three levels were planned, but after the first three weeks I was sure that time is running out. I then dumped over 50% of the planned features and content - which was a very good decision, although the most complicated thing was balancing, I guess. The first beta was handed out in early December and the difficulty was way too hard... everyone was complaining, which surprised me. The trouble is that when you are working alone on game elements or on the whole game, you turn yourself into a "pro-gamer". So I believe that prototyping new things very often and giving them out to others as soon as possible makes it easy to see design mistakes very early - and then you know "if it works" or if "it is fun or not".

 

Q: What important features did you plan for the following Rudi update?

A: Four things: a tutorial, a better configuration, a second level and an extended experience. The tutorial will also serve as foregoing level of the North Pole. The player will learn the controls and the most important game elements. The second level will introduce new enemy & actor types, as well as a new environment. We will introduce new game elements together with a slightly modified North Pole level, . Alternative ways of controlling Rudi were requested so I'll add a fully customizable support for absolute / relative control with keyboard, joystick and mouse. The graphics details will be also customizable: beside 3 settings (low, middle and high details) a table with several options will be there for the more advanced users, along with a new points-system. Each level will save its own highscore, too.

 

Q: Please tell us the names of some freeware or low cost game development tools that you find to be really useful.

A: For modeling tasks, I always recommend Wings3D. Its a polygon-based editor and super-powerful once you get used to its interface. Compared to blender, it's easy as pie ;) One thing I have to mention about Wings3D is the superb UV unwrapper which is in my opinion superior to all other unwrappers I have seen so far (even better than the unwrapper of Maxon's Bodypaint3D). Blender is also a nice tool for different purposes, like shadow map rendering or general modeling, though its interface is alienating me so I don't really like it. I use Cinema4D R10 for most of my modeling work - though Cinema isn't that cheap but you can purchase a very cheap students license if you are studying at the university. Human modeling is quite complicated and only some people are able to do this at a decent quality, but with MakeHuman you can generate a highpoly-version of a human person; the generated mesh in MakeHuman is parametrized like in the Sims 2 game, so it is very easy to generate a human model. For trees I recommend "TreeMagic 3" from The Gamecreators. With it you can easily create lots of different trees to populate your environment with vegetation.

 

There are lots of tools for 2D art content. A lot of people use GIMP for their textures and their general 2D art. Textures are a big issue for beginners, because they don't have many resources and tools to "convert" images to tiling textures. There are lots of sites like "CG textures" which offer a huge set of free high-res images. I very often use the "Seamless Texture Generator" to grab them and convert them into perfectly tiling textures. After that I process them in my favorite graphics application, Corel Photopaint. Corel products are not so cheap if you want to use the latest release, but you can get older versions very cheap, though (like Corel 10 or 11). For manipulating images with filters I use often the filters from Corel, the GIMP or Filter Forge. In RUDI I used vector art to create the 2D art for the menus, splash screens and so on - this is a very cheap method to create clean interfaces. Inkscape for example is a free vector graphics editor.

 

If you are dealing with 2D images, you have to take the memory consumption into account which can be quite high with high resolution textures and bitmaps. For this purpose I recommend DDS files: these are compressed images so that they can be directly dumped into the memory - they are up to 4 or 5 times smaller than regular images, loading time is smaller and you can also control the amount of mipmaps. DDS files can be created with some plugins for Photoshop, but I recommend the AMD Compressonator or the NVIDIA texture tools instead. The Compressonator comes with a GUI and the NVIDIA tool is commandline based, so you have to chose what suites your needs. If you have some nice textures and you need normalmaps, use CrazyBump. It is incredible how accurate and precisely this tool generates normalmaps - better than any other normalmap tool I know.

 

My list focuses only on the graphics side of the medal, because it is very difficult to most people. I don't want to say that programming is less complicated, but as a programmer you really just need a text editor (I chose ConTEXT), a cup of coffee, time and growing experience / knowledge to get better and better results.

 

Q: What would you like to see implemented in the engine in the near future?

A: I am quite satisfied with the overall development of the engine in the last 2 years - a lot of new and exciting features (addressing both coding and graphics) were added; they were also somehow the reason why RUDI was finished in time. Nevertheless, there are also a lot of issues and complaints all along the community which I second as well. The 3 features I am really waiting for are decals, native support for 2nd uv-sets of models (for lightmaps, dirtmaps and that stuff) and - most important - a better workflow. There were lots of discussions about it and I tend to circumvent everything as much as I can, e.g. by writing my own tools (cinematics, WRS compiling, content pipeline (from raw production data (tga textures, wav sounds, ini/xml data..) to game data (dds textures, ogg, binary packed config files,..)), advanced game framework (GUI manager, animation machines, font renderer, own audio implementation, lipsync..) and game related helper tools. If you think about it, you will notice that this is really missing. I really like GameStudio, but it is sometimes very time consuming to work on things which are already available in other packages right from the start. Nevertheless, I don't have any reason  to give up GameStudio; I don't know any other solution for this price, features and community.

 

Q: Can you give us some advice for the beginners out there?

A: It is quite difficult to answer this question because every "beginner" has different experiences. Some of them never programmed a single line before nor did they make any artwork or such - they just played games and thought "Cool! I want to make games, too". Some others jump in from very different areas. I met a guy some weeks ago which works at the university and writes medical applications in JAVA and he asked me how he could start game programming - so every beginner is different ... they all share the dream of making games but they don't know how. I think some things are very important: know you basics, have a plan, organize your team effectively, and realize that game development is software development.

 

When you decide to program with Lite-C and you don't know how, grab a book about C (not C++. I mean really C!) and learn C in-depth programming. You don't understand recursive functions or structs / pointers? Don't give up! Then get to know how the engine works with which file formats, what you can do in general and particular with Gamestudio and then experiment with Lite-C and the engine instructions. Practice, practice, practice. Observe other games and try to think in game programming terms. Shut down your messengers. Avoid asking in forums for help. Try to get it working on your own. Use the search button. Read other's code. Don't ever use templates if you really desire to create something with your own hands. If you follow this, you will certainly succeed.

 

When you know your basics: have a plan! Games which have a poor planning (or none at all) take much longer than they should, run over budget and tend to be very buggy. Figuring out what your game needs is essential and it is way easier to work together with others if you have planned the things. Even if you are working alone, you must still take your game's project planning seriously. Once you are done with this, the game production starts and this is where most of us begin with - and fail... for various reasons. During production, almost each day new features will be implemented and in a healthy project, a team feeds itself with new energy to go forward. Due to feature creep you have to know when to freeze features. Almost all AAA titles have a narrow feature set - but these features are polished very deeply. Also get to know how to manage your time. Instead of being in a really big team at Electronic Arts you are most certainly in a very small team or even alone, so, all methods of creating achievable tasks, measuring progress and controlling features are even more critical.

 

I will throw in a last aspect which I believe is often rejected: game development is software development! Games are certainly special, but most developers are holding themselves apart from formal software development and production methods with the false intention that making games is an art, not a science. Making games is fun but you have to keep in mind what you are doing there and that it is definitely no child's play. For this I recommend the books "The Game Production Handbook" from Heather Chandler and "Game Development and Production" from Erik Bethke.

 

Thank you a lot, Christian.