Jump to content

  • Log In with Google      Sign In   
  • Create Account


Dirty Tricks

  • You cannot reply to this topic
1 reply to this topic

#1 kuramayoko10   Members   -  Reputation: 386

Like
1Likes
Like

Posted 25 February 2013 - 09:01 PM

Well, I was reading Patrick Wyatt's blog the past week and he cited an article from Gamasutra that list some Dirty Tricks that shipped some games.

 

I don't know how rude/good it is to post references to blogs here. But the things discussed there are pretty funny.

Worth sharing smile.png

 

On this topic I will share one experience of mine from college:

 

We had to create a game in Assembly (our own Assembly language btw smile.png) and apply it to a processor we created using hardware description language and run it on a FPGA board.

 

Me and my friend were developing a Treasure Hunt kind of game. I remember it clearly... I wrote the moveLeft "method", labeled it and tested.

It worked pretty well, so lets just copy/paste it as moveRight, moveDown, moveUp.

As soon I did this, moveLeft stopped working.

We spent hours trying to debug (there was not much code to debug) and we couldnt find out the problem.

I then had a brilliant idea... lets just swap the code position of moveLeft to moveRight, moveUp or moveDown. Just doing that made moveRight/moveUp/moveDown would break.

We couldn't believe this, the code was breaking because of a specific line (or block). That line, a thousand something, was on strike.

 

The solution we found: we created a method moveFu** (sorry for the obscenity... college kids) This code didn't do anything and was never called, but we inserted it at the "broken line position". Just like that the movement was fixed.


Edited by kuramayoko10, 25 February 2013 - 09:06 PM.

Programming is an art. Game programming is a masterpiece!

Sponsor:

#2 Bacterius   Crossbones+   -  Reputation: 8187

Like
1Likes
Like

Posted 26 February 2013 - 06:52 AM

It's not much different from a compiler bug I had a while ago which caused the compiler to fail with an internal error unless a comment was present at some line, which gave rise to painfully misleading comments such as /* do not delete */ or /* fix */

 

Very irritating indeed.


The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis






PARTNERS