Sunday, April 29, 2012

Making of Radar demo #6: The Byteplumber

So far we covered mostly creative-production aspects of this demo. Making ideas, 3D modeling rooms, doing objects, and so on. So, what was my task as a programmer? Just hanging around a bit?

Well, as you know, the Tower22 engine isn't exactly finished. I can't recall the exact things that had to be done for this demo, but the listing was quite long... endless really. Once we decided to decorate the place with a snowy theme, one of the main new features that had to be implemented was stuff to make it look cold. Ice and falling snow particles for example. Furthermore, we needed water, And while doing so, I thought having water-ripples caused by the falling snow/drip particles would look nice too. Some more visual effects were:
- Lightshafts
- Snowdust particles
- (Compressed) DDS textures
- Gas particles
- Sharper looking graphics / improved specular
- Parallax Offset Mapping
- Waterpool decals
- FXAA (Post screen Anti Aliasing for smoothing the edges a bit)
- Heat-haze sprites
- Monster morphing animation (the "breathing")
And probably I forgot a few things. But if you thought that would be all, you're wrong. Most of the time being spend on "programming the engine", happens on invisible, magical things. And fixing bugs. Many of the points above have already been implemented once, but using old clunky code. More than often it happens I discard the old module, and replace it with modern techniques. The particles for example. Making a bunch of snowflakes falling down softly isn't the most difficult since unsliced bread. However, after looking some tasty modern-particle demo's, I decided we needed a GPU approach too. Which means the graphics-card will update the particle positions/physics instead of the CPU.

Let's not forget that games require more than just graphics, although this Tech-Demo was merely a compilation of rooms and effects, supported by spooky tunes. Spooky tunes... I still had to finish some unfinished business with FMOD, a third-party sound engine. And the camera-flight through those rooms needed some help as well. Portal-culling had to be improved and cleansed from some nasty disappearance-bugs, and while trying to capture a movie, I realized having a recording-playback tool would be nice too. The movie has been recorder quite a lot times, but the camera path had to be the same each time. Impossible to manually do that, so instead a camera-position logger has been added.

Usually adding a new feature ends up in a lot more work in order to integrate it nicely into the engine, and to prepare it for eventual other usage as well. That particle system for example is not only dealing with falling snow of course. Before even starting, the imagination flooded with fires, smoke, clouds, stinky flies around corpses, 80ies laser-Tron effects, green gasses, fog fields, rain, tornado's, mushroomcloud-laying-motherfuckers, and who knows what. So, I didn't just make a particle generator for snow, I made an all-round particle generator. And the extra effort paid off later on with the waterdrops, gasses and snowdust in the same demo. If you need to add or change something, do it well.
The ice required a new pass in the engine, as it uses a simple sort of sub-surface-scattering. First the the surface will get litten normally, then it gets rendered again, scattering its own light and the background contents.

Between adding features, I also had to support the modelers. Not just by giving instructions and feedback, but also by providing their tools of course. An engine is not just a library that can be used to render/drive a game. It includes the editors, tools, documents, and so on. After all, your artists rely on that. If I want them to make a rotating fan or animated screens on a computer, the editor needs functions to create those.


The Fly is Dead, yeah
========================================
Another thing that takes a (too) big portion, is bug-solving. Bugless programming is as realistic as having a relation and never arguing. Fixing things is part of the job. However, the engine sometimes feels like a Jenga Tower(22). Instead of removing blocks, we are inserting blocks. But at the same time, something else gets pushed out of the tower. Some typical bugs like "#$% barrel object doesn't cast shadows anymore" have been fixed dozens of times.

Sniff, smells like bad design? Maybe, although I would like to call it "lack of manpower". The engine has hundred-thousands code-lines, stuffed in unfinished sub-modules. In a real game-company, -you know, where they have more than one programmer-, each programmer(team) is assigned to a specific module, and will deliver something documented, tested, finished. At least, that's what they should do. But here at... erh, we don't even have a name, I'm programming everything. So, there is little to no time to finish modules, let alone document things. Instead, I work "on demand". Whenever artist X needs a certain effect, or if the game needs a new mechanic, I'll implement it. Of course, the modules have been designed with all possible functionality in mind so it's not that I have to hack in future add-ons, like stuffing a body in too small garbage bag. But since I work in small fragments on each module, the chance on bugs increases as some code-parts are left unfinished, untested, or if I forget a couple of conditions when adding a new feature months later.


Yes, it would be better to finish a module completely rather than stopping somewhere halfway. Then again, there is little time, and its often pretty meaningless to work on something that won't be needed yet. For example, I could renew the whole animation-module. But as long as there is no playermodel with a proper stand-walk-run animation-set, its not very motivating to start on it. In fact, it probably only makes bad code, as it can't be tested right away. I call this "blind coding". You make something, but you have no idea if it really works and fits the needs yet. Coding in advance only works if the goals are very clear, and with some test-subjects. Otherwise -> a waste of time.

Last but not least, I would hate to spend weeks/months on the same dull module. It's a relief to switch over from graphics to physics, or from sound to gameplay once in a while. Hey, I'm not spending so much unpaid hours of free time to torture myself! In the end, having fun in what you do might be the biggest key to success. Although I got to admit fixing bugs is goddamn annoying. Progress is the things that really rewards, not spending a couple of nights on the same old bug again. It's like the police catching the same toothless alcoholic prostitute every weekend.
Sometimes bugs can turn out pretty cool through. Forgot what the hell went wrong here, but it looks kinda angry.

========================================
Don’t worry, we’ll get there. Bit by bit. Each time when a new room or object is finished, the tools, engine, shaders and other related modules get bigger, faster, richer, tested, and better oiled. It might not happen in a truly professional way, but as said, programming is a story without an ending anyway. Do you really think the programmers at Valve or Crytek stopped one day during development, as their part was completely finished? Of course not. There are always glitches, bugs, missing features, non-optimized code. And otherwise modern-technology passes by with merciless speed, forcing you to upgrade or even rebuild certain parts again. And again. Unlike making a 3D model, a programming task is never really finished. That can be frustrating sometimes. Honestly, it makes me “restless”. Ever since I started programming and wanted to make a game ~13 years ago, I can’t just play take a pause, watch a movie, play a videogame or chill out with a fishing rod anymore. Because the programming is never finished, there is always that urgent feeling that something needs to be done. Not spending time on “the job” makes me feel useless. I’ll go to bed with it, and wake up with it.

Sure, I still have time left for my work, family, and drinking beer with the guys. But I need to be careful this hobby won’t become a sick obsession. Then again, we all have obsessions, don’t we? Some spend years on fixing old crappy cars. Some are obsessed by sixpack-abs and visit the gym every day. Others are obsessed by sixpacks of beer, and your mother is obsessed by cleaning the house and will fight the lost battle against dust. It’s this drive that makes us good at things. And what does it gives us at the end? Hell, I don’t know. The sports-guy will get old and fat eventually, mom has to dust the house again one day later, the car-lover doesn’t give a shit about cars that work again, he will start on another piece of junk. As for Tower22...? It will be my 5 minutes of fame when it gets finished ;)

No comments:

Post a Comment