game development

Playing Dirty While Game-Creating

Time to get dirty

Almost every project is bond to have issues you won’t get time to solve. What are the options? Working for 14 hours on a daily basis for month? Perhaps, if you are decent enough. Yet there are fixes and hacks that allows you to save time and effort, still you will need to have your hands dirty. I absolutely do not encourage the second option. But there are times in life when sneakiness wins. Here are some actual examples gathered from various domains of the internet. I’d have to notice people that were doing these actions are in no way proud of them, though the solutions did work. Now it’s up to your consciousness to decide. From now on I am putting on my sneaky-scam hat which I will be taking off only after the final words are written. Advise you to do the same. Prepare to get dirty!

Cheating at the beginning

This story has occurred to a game developer somewhere in the early 90s. He was just out of college and as green as a cucumber. His first project was a game, duh. It was as exciting as the first project gets. All was looking sharp and sparkly. The workflow was great, until…

The team has realized its way over the memory budget. All memory was taken by textures as well as models. Intense work with the artists has begun. Everybody was doing all they could to reduce the games memory footprint. Images, complex textures, decimated models and much more was reduced with the artists’ assistance. Or, sometimes, you had to knock a couple of those out in order to proceed. SO the war took on, the size was reduces a kilobyte after kilobyte. Then the turning point came. The team has reduced all they could, and were still some space short. A lousy megabyte and a half was separating them from their goal. And nobody could do anything with it, until… (Yes, I do love them dramatic pauses)

The projects ‘guru’, the guy who had years of development behind his back right from the ‘plain, good old days’ has decided to step in. Watch this, he said. So everybody saw a nice little line of code, which was pulled out of the surface file and stated:

static char buffer[768*768*2];

So? So what? – Everybody asked. Can you imagine the surprise on their faces when he just deleted the whole thing with a slight key push? And voila, 2 megabytes of space were spared. How? The sneaky old school dude has hidden them just in case, before the fuss even started. He had spare space, knew it all along and still was keeping the secret to the deadline. That’s a preventive strike.

Dead Cam

There it was, one of the first good 3D RTS games. It does not matter which one. It was using a camera that was supposed to follow your troops, you know, in order to be able to play. When the project was reaching its deadline an awkward bug was noticed. At some point the camera just refused to follow the units. It was freezing and standing still. It was appearing as a random bug because nobody could determine the reason of it occurring. Until…

Until a certain tester has noticed that the happening usually takes place after an air-strike. With that hunch the bug was tracked down. The cam was in the Physical Objects class because it was using acceleration as well as velocity and was collidable in addition. And you know what else physical objects do? They take damage. Thus a powerful air strike was simply killing the camera dead.

What to do? Easy! Boos the cameras defense and hit points enormously, thus you will have an actual un-killable ‘tank’ cam.

Blind on purpose?

There was one team that was making an FPS flash game in their University. The developer has chosen a strange path. The walls were not colliding with the character in order to stop him from moving further. Rather than doing this as an adequate decision the developer did it all upside down. The character was checking if there was anything like a wall, and was only allowed to move parallel to the obstacle. I know, weird right?

It has lead to an interesting result. You could not really cross the T-junctions in any level. In fact you could only move left or right on the passage. And the deadline was not too far. Do I even need to mention nobody had an idea on how to get rid of that bug?

The decision was brilliant in its creativeness. The artists have added an animation of the characters hands touching the walls. And they made the guy blind! The back-story was properly adapted and voila, an even cooler character emerges.

That isn’t a bug, no way, it’s a feature!

Now to my personal favorite, the RPG’s. Thy team was willing to make the NPC’s spot you at sight and to make a conversation with your character via the dialogue system.

What they did forget is adding a code that prevents NPC’s from spotting each other. Thus you, as a player, cold witness an amazing picture when entering a city. Everybody was having lovely chats with each other. And, due to a similar dialogue system, it took some time before the NPC’s started making complete nonsense. It looked like a lovely feature to the developers.

Let’s speed things up

Not making it in time with your compilation? There is a simple, yet handy trick you may use.A large amount of compilers do support slight explicit conditional hitting. And GCC possesses a handy function by the name of _builtin_expect. The function grants you the allowance of informing the compiler about the results you are expecting to receive.GCC will be using that extra data to optimize the conditionals. Thus your compiler will be working faster if the expected case scenario is valid (and slower if not). That’s how you do it:

if(__builtin_expect(entity->extremely_unlikely_flag, 0)) {
// code that is not being run too often
}

You may expect a seed-up to the whole 20% if everything goes as planned.

Well hidden

There once was a game. And some issues on its development level. One of such issues was a need of a particular object on a particular level to be hidden. And who wants to re-export an entire level for a slight change? Only goodie two-shoes people, which we are not (remember of the sneaky-hats we are wearing right now.) So why not write something similar to the following right in the very middle of the nice old engine code?

if( level == 13 && object == 13)
{
HideObject();
}

It worked fine, the only reminder of the hack came an entire year later. Some artist that was using the mentioned engine was quite pissed that day. He tried to export level 13 and one particular object was nowhere to be seen. Anybody knows why?

Who needs those branches anyway?

There are some mean compilers as well as platform that have the guts to throw away entire whole pipelines because of branches. Thus even the smallest if()’s may be devastating.

But there comes PowerPC architecture (used for PS3 and 360). And it rushes straight to the rescue with its fsel, the awesome floating-point instruction.

float result = 0;
if (foo > bar) { result = 2.0f; }
else { result = 1.0f; }

Transforms into:

float result = fsel(foo-bar, 2.0f, 1.0f);

The message matters!

One more game with an interesting bug. The bug is pretty harmless. It just is showing an error message stating Blah-blah_ERROR_MEMORY_some digits_Blah-blah every time you are exiting the game. And that is all it does. So why not change the text in the message to “Thank You very much for playing our game”? Work’s fine, right?

8-bit killer

Imagine a grouse QA bug report coming in 48 hours before the release date? A bug report that is taking the whole 30+ hours for reproduction only? And then, within hours before the shipment time you finally are tracing it up to a dirty firmware audio driver that is gruesomely writing 1 byte of random data somewhere in the executable code at a random time. Bummer. And, at last, you find out that it is doing so in one particular code spot. The clock is ticking.

So why not write and ship some new code straight into the very beginning of the main which will be saving those 8 bites of the executable code? Then to add some extra code that is created to do some running around each and every frame straight after the audio and restoring the bites into what they were originally designed to be. That hit launch. Success. A very dirty success.

Put on the white gloves

Did you know that there is a company existing that has a pair of actual white gloves in the developers’ office straight for these purposes. Not only will the naughty developer not leave his fingerprints on the code, he will not get dirty as an addition. That is, indeed, a fun practice. The one that makes you realize that there are times what you will need to think of a cheat. At the same time it is reminding you how dirty such a decision is. So it’s only up to you to make such a choice. Now that’s it, off with those nasty cheater-hats or whatever you call them! And on to the sweat, blood, tears and other fluids that are necessary to do everything right! The best of luck to all you guys!

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

    Facebook Comments

    comments

    'Playing Dirty While Game-Creating' have no comments

    Be the first to comment this post!

    Would you like to share your thoughts?

    Your email address will not be published.

    Software development and outsourcing blog by QArea © 2016

    Яндекс.Метрика