Friday, June 24, 2011

Send report to Microsoft?


You might expected another "water tutorial". Excuses. Already wrote the text (a month ago actually), but I'd like to have some water pictures with it. I'd like to finish some maps first. You don't show photo's of your grandma when talking about your new girl either.

I got some other pics though. Sergi started producing various models. So while I was stinking in bed, he made an old computer, a lamp, comfortable bed, and a barrel. What kind of game doesn't use barrels?! Doom, Double Dragon, Halflife, Crysis, Final Fight, Donkey Kong. Except for Tetris, every game should have barrels. Especially the red explosive ones. A game without barrels (and crates) is like beef without beef.

To help the modeling guys, they finally got a working editor. This tool can import meshes, and render them in a test environment with the same graphics we use in the real game. As a little bonus, you can toss around objects to test their physics, and test the impact. Impact effects are collision, scrape, roll and spin sounds, particles, splat decals, bullet shots, et cetera.


Deployment my ass
Getting it to work on another computer wasn't so easy. I never had ATI videocards or a 64-bit machine, so the Editor went to unknown, possibly dangerous, territory. The very first issue was a mysterious "Runtime error 217". It seems to happen before the creation of any form, and the application just stops. Grumble!! Checked the DLL's dozen's of time with Dependancy Walker, but finally it turned out we had a "Millennium bug". Sort of. Sascha mentioned something about date function problems. The Delphi(7) function "strToDate('01-01-1900')", called at one of the unit initialisations, was making havoc indeed. What, not a valid date @#$%@#... my great grandmother was born in 1896 or something (married Julius Caesar, lived in a dolmen, and fought in the Eighty Years'War).

Now it works, and surprisingly it didn't produce tons of shader-compiler-errors... at least not on the computers with modern nVidia cards. One of the many programming horrors is to make your app "multi-platform". Yeah sure Java, OpenGL and the likes claim to be multi-platform, but in practice every PC is different. Even when using the same operating system. Conflicting security rights, hardware, Windows service pack version, screen resolution, component XYZ installed or not... It's a mess.

Any programmer should know that your program isn't finished as soon as you say "it's finished!". On your dev-station maybe, but you'll be amazed what kind of (stupid) errors will appear as soon as you deploy your hard-work on a customer computer for the first time. "Array index out of bounds... cannot open file... Hey... that's strange... Normally that doesn't happen.". Yes admit it, you said that more than once!


Congratulations, you have been selected to become a Beta tester!
That's why I try to delay my releases usually. Keep testing, add logbooks, and make use of those "try - catch" statements. If something goes wrong -and it will-, you can locate the cause somewhat better. At least try to give the client the impression you got it all under control hmm?

But yet, if you don't have extensive testing capabilities (thus 30 different computers including one with coffee spilled on it, and another one completely screwed up by porn websites), you got to move on at some point, and hand it over. For one thing, you are not a proper beta-tester, as you know how to use your own system unaware. You won't be hitting buttons 10 times in a row like a monkey, you don't click the cross while you should click "save". But don't underestimate the "stupidity" of your clients when it comes to using your software! They will produce fault-reports like Beethoven can write symphonies. Professional program-crashers as they are!

In other words, you'll need customer feedback to create stable software. Therefore it's wise to hand over your "Beta" version first to a few trusted persons (with a lot of patience!), before throwing it in the public. The problem is, the average user will stick to his/her first impression. If this first impression is "Access violation at address FF01234", they won't trust your software anymore. Even when build 4.0g12 is rock solid. First make sure it works as desired for a few test-persons (make them feel good about theirselves by telling they are specially selected to test your Beta!), then take the next step.

fuel barrels, empty barrels, rusty barrels, stinky barrels, bumped barrels, broken barrels, shiny barrels, important barrels, holy barrels, shitty barrels...

This card doesn't support multi-texturing
The advantage of a fixed hardware setup (like a PLC in a range of machines, or gaming console) is that the platform is equal everywhere. You know what to expect, now deal with it. Once it works perfectly on your development-machine, it should work on any other machine as well. But obviously, Tower22 is aimed for the PC. Maybe it will be ported to the XBox 720 Roundhouse kick, PS Forty-core, or Nintendo W00t some day :) But let's focus on my own dev-station first.

At some older ATI card, the Editor already didn't work. At least not with all the shaders enabled (you can still render with textures only). Well, I could do two things. Make a profile with simplified graphics and shaders that make it run on older machines. Or B:, ignore them. When releasing a game, more audience means more money. So obviously engine-makers try to get CryEngine2 run on an Atari as well (although one has to draw a line somewhere of course). Yet, I chose option B. For now. Why?

Adding support for older platforms takes time, of course. You can't just disable a few tricks and get a result that is "good enough". At the same time, T22 is far from finished. The graphics I produce today, are likely to be (out)dated two years later. So instead of spending energy on the past, I'd better try to focus on the future. Waste too much time on making your engine "backward compatible", and you will stick in the past. The average gaming computer might not be able to run T22 smoothly right now, but don't forget the "average gaming computer" evolves too. I'm pretty sure these systems can run (the current) T22 nicely in two years.

Other than that, I'm just too lazy to work through all those shaders again :) Hey, programming a game all alone in your free time isn't easy!

Playing around with some concrete textures. We'll need a lot of those for the upcoming Radar Station map.

4 comments:

  1. Looks like it is moving fast! :)
    Also, you seems to have some weird kind of shadow artifact on the ground?

    I think you are right to not spend time on backward compatibility. You have a game to do! :) After your demo, I wonder which kind of ambiance/theme there will be in the game! Still focusing on the horror genre? (if I remember well yes)

    ReplyDelete
  2. The stripes on the floor are indeed shadowMap artifacts. That's because the spotlight that shines through the windows has quite a large distance. Instead of a normal spotlight, I should use a Cascaded ShadowMap light here... But that type of light isn't completed in the engine :)

    It will be the horror genre indeed. Plans didn't change. It's just that we don't have new maps/monsters to show yet! But to give a little idea, the next Demo should contain more gore/action than the first one ;)

    ReplyDelete
  3. So much changes since the first demo, keep it up !!

    ReplyDelete
  4. The refraction in the water looks great!

    ReplyDelete