Jump to content
  • Advertisement
Sign in to follow this  
Nicholas Kong

Is hacky code allowed in industry?

This topic is 2072 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I find myself doing something like this alot. Basically setting a condition to false to avoid the if block from running more than once. 

If I do not turn it off, the mushroom will keep appearing.

 

The hacky code is isHit = false;

Given a update method that constantly get executed from the game loop in this pseudo code.
 
[code]
public class Mario{
 
public void collide()
{
        Block.setHit(true)
}
 
}
[/code]
 
[code]
public class Block
{
    public void setHit(boolean hit)
    {
        this.hit = hit;
    }
  
 
   public void update(long milliseconds)
   {
      if(isHit)
      {
                // hacky code
                isHit = false;
                Mushroom mushroom = new Mushroom(50,50);
                Game.getInstance().add(mushroom);
      }
 
    }
}

So my question is: is hacky code allowed in the industry?

Do industry professionals or game developers use hacky code in their game code?

 

I always found hacky code to fix all the bugs in my game and let me progress faster in my game development process.

Edited by warnexus

Share this post


Link to post
Share on other sites
Advertisement

There are kludges in any industry, though with varying degrees of frequency. The question isn't whether or not they exist but why they happen. I've only done games as a hobby, so I can't comment much on patterns for that industry, but my experience with them is that a kludge happens when deadlines loom, developers gloom, and project managers give out ultimatums of doom. In general, a kludge is a sign that either your design isn't working, you don't understand how to work with your design, or you're in a very funky context. The last one being rather uncommon.

 

Given that Mario.collide is calling a method on Block, is there some reason you can't have Block.createMushroom or Block.collide(thingHittingMe)? Does it need to be in update for some reason? An event makes more sense to me than an update loop for a context like this--the collision happens once at one moment and really only needs to fire off, "Hey, I've hit something!" to the interested parties (usually those involved in the collision). It's a lot cheaper than every few milliseconds, "Am I hit? Am I hit? Am I hit? I'm hit! Am I hit? Am I hit?"

Share this post


Link to post
Share on other sites
I interned at Microsoft and before I could commit my code to the master code repository other people had to review it and they would point out anything I did poorly. They would sometimes suggest alternatives but other times I had to fix it up myself. I realized that many times I would to a hacky solution more because I didn't want to take the time to find a better solution but in the long run you save time by making good design decisions for more elegant solutions. Hacky solutions usually are parts of more bugs later on. If it is allowed will depend on where you work but as I a rule of thumb I think it is good to avoid the hacky solutions, with the possible exception of if you are working on a prototype that you will throw away later.

Share this post


Link to post
Share on other sites

It depends how close you are to a deadline tongue.png

If the game has two months of work left before it's finished, but the publisher wants to see a working/finished version of the game in two-weeks, then all sorts of horrible looking "duct tape" code starts appearing, which may work for now, but is barely managing to hold itself together!

Share this post


Link to post
Share on other sites

Hacky code is frowned on and there are code reviews and code style guidelines to try and prevent it.  However hacky code still gets through.  In the games industry you are likely to find a lot more hacky code than anywhere else though because most games code is throwaway code.

Share this post


Link to post
Share on other sites

Depends on where you work entirely, and the general stress level. Good programmers would rather fix stuff like that properly, but management and/or reality may disagree about that priority.

 

 

 


IMHO hacky code is OK if it's used as a stepping stone. Actually, many times I've found that adding a lot of hacky dependencies allows you to use the resulting code smells as a guide to find the architecture.

 

Agree on this one, if I can't immediately see a clean solution I may start out with a hacky one and then refactor it later once it becomes clear exactly how the related code meshes together. (Or I don't even start implementing it until analyzing it further. Starting to code when you don't know what you're doing is a major time waster.)

Edited by Petter Hansson

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!