Jump to content

  • Log In with Google      Sign In   
  • Create Account


Is hacky code allowed in industry?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
29 replies to this topic

#1 warnexus   Prime Members   -  Reputation: 1379

Like
0Likes
Like

Posted 07 November 2013 - 08:34 PM

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, 07 November 2013 - 08:43 PM.


Sponsor:

#2 tychon   Members   -  Reputation: 652

Like
1Likes
Like

Posted 07 November 2013 - 09:12 PM

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?"



#3 HappyCoder   Members   -  Reputation: 2224

Like
1Likes
Like

Posted 08 November 2013 - 12:10 AM

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.

#4 L. Spiro   Crossbones+   -  Reputation: 12215

Like
9Likes
Like

Posted 08 November 2013 - 12:27 AM


I always found hacky code to create all the bugs in my game and let me progress more slowly in my game development process.

Fixed.

 

Hacky code leads to bugs.

Doing it right leads to a better you with higher skills.

 

Hacky code is absolutely not allowed in my company in my department (nor likely in any other department) because the above holds true invariably.

 

If you’d taken all those times you ran away from proper design via hacks and instead took the time to do it right, the easy solution to the problem you suggested would be obvious to you by now.  Every time you use hacky code you miss out on a chance to learn.  Remember that.

 

 

L. Spiro


It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#5 Hodgman   Moderators   -  Reputation: 27563

Like
1Likes
Like

Posted 08 November 2013 - 12:35 AM

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!



#6 plainoldcj   Members   -  Reputation: 695

Like
4Likes
Like

Posted 08 November 2013 - 02:02 AM

Read this: http://gamasutra.com/view/feature/194772/dirty_game_development_tricks.php



#7 Buster2000   Members   -  Reputation: 1416

Like
0Likes
Like

Posted 08 November 2013 - 02:56 AM

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.



#8 Felix Ungman   Members   -  Reputation: 893

Like
6Likes
Like

Posted 08 November 2013 - 03:31 AM


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

 

I've realized that adding code almost always makes it less clean. And the faster you add new code the faster it gets dirty. There are two solutions:

1) Add code slowly to keep it clean.

2) Add code quickly and then come back and clean it up.

 

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.


openwar  - the real-time tactical war-game platform


#9 Bregma   Crossbones+   -  Reputation: 4749

Like
12Likes
Like

Posted 08 November 2013 - 05:36 AM

Clen, perfect, academically correct code rarely survives contact with shippable product.


Stephen M. Webb
Professional Free Software Developer

#10 Petter Hansson   Members   -  Reputation: 583

Like
3Likes
Like

Posted 08 November 2013 - 05:41 AM

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, 08 November 2013 - 05:45 AM.


#11 Adyrhan   Members   -  Reputation: 212

Like
0Likes
Like

Posted 08 November 2013 - 07:06 AM

 Hacky code is not allowed, but when there are deadlines is tolerated. I think that sums it pretty much.

 

I'm actually working in a product for a client and from time to time he asks for some more functionalities. It happens that if I would go the safe route and take my time to design proper and clean code, my clients go hunting me constantly asking for progress and they go with a bad feeling about my services. If i do hacky code, I deliver much faster and they say ohh you are very productive, but its obviously a trap not only for them but for myself. What happens is that after two or three updates, code gets messy and difficult to modify and even understand after some time since its writing, you already know the story. What I do now is to clean an even rewrite those hacky lines of code only after delivering even when they dont expect a second release. Its more work for me but with this I get saved from the chaos, they get a free update and the code is ready for being upgraded with more functionality if the client requests it.


Edited by Adyrhan, 08 November 2013 - 07:25 AM.


#12 warnexus   Prime Members   -  Reputation: 1379

Like
0Likes
Like

Posted 08 November 2013 - 09:30 AM


If you’d taken all those times you ran away from proper design via hacks and instead took the time to do it right, the easy solution to the problem you suggested would be obvious to you by now. Every time you use hacky code you miss out on a chance to learn. Remember that.

 

I will bear in mind. Wow! Thanks for the truth about hacks.



#13 America Freeman   Members   -  Reputation: 436

Like
0Likes
Like

Posted 08 November 2013 - 09:51 AM

I have seen something similar to what you are referring to as a "hack" many times in the software development industry. I am not sure if this is the official name for it, but at my job we refer to it as a "latch". It is usually used to stop normal functionality when the form "IsLoading" or something of the sort.

#14 Nypyren   Crossbones+   -  Reputation: 3674

Like
0Likes
Like

Posted 08 November 2013 - 12:15 PM

Where I work, hacky code appears:

 

- When the programmer is not experienced enough and/or does not care enough to write good code.

 

- When the system has already been implemented (with nice, clean code) and the product managers decide to drastically change it close to a deadline.

 

- When a programmer leaves the company without documenting his systems and another programmer is told to make changes to the system close to a deadline.



#15 kalle_h   Members   -  Reputation: 1274

Like
0Likes
Like

Posted 08 November 2013 - 01:48 PM

Sometimes you need hacky solutions for bugs that are out  of your control. Yesterday I fixed bug where new Apple A7 chip renderered pure black if there were shadow receivers but no casters with horrible kludge where I render small sub pixel size triangle to center of shadow map. This fixed nasty bug just before deadline.



#16 rpiller   Members   -  Reputation: 655

Like
0Likes
Like

Posted 08 November 2013 - 02:53 PM

Your collision callbacks should be more robust. You should have OnCollideEnter, OnCollide, OnCollideExit. Enter and Exit will only ever be called once per collision with a given object. OnCollide would fire each frame. This way you can put your mushroom creation in the OnCollideEnter so it's only called once per collision.

 

Who cares if the industry allows hacky code. You should try to not make it hacky if possible. If you don't have control over your collision library and it doesn't support the enter/exit thing then you have to do what you have to do to make it work. It just so happens that you picked a path that is a little wasteful.

 


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

 

This is another way of saying you get lazy. It's not the end of the world. We all get lazy in different aspects of our lives (even football players who get paid millions sometimes "take plays off"), but it's important to know that's what you are doing (if it's a hobby project). Don't deny that fact or try to justify it in any way.



#17 warnexus   Prime Members   -  Reputation: 1379

Like
2Likes
Like

Posted 08 November 2013 - 04:22 PM


When the programmer is not experienced enough and/or does not care enough to write good code.

 

No! I do not want to be that guy. Okay. I am def going to have to find a better way soon enough. This is the toughest part.



#18 cardinal   Members   -  Reputation: 798

Like
0Likes
Like

Posted 08 November 2013 - 04:28 PM

The amount of hacky code in professional game code depends entirely on how strict the team's leaders are. I've been on teams where every bug I fix seemed to be the result of some hack, and I've been on teams that are very strict with code reviews and would not allow hacks at all. Generally the latter teams had better products commercially and critically than the others.

 

Deadlines and laziness generally are the main causes for hacks. On my current team, the only acceptable time for a hack is right before going into certification, and only if it's a localized targetted fix where the proper solution (which we also have prepared) would require extensive testing since the fix touches many game components. Generally the process there would be to send the hack (after testing) through certification and testing the proper fix extensively while waiting to hear back from first parties (Sony/Microsoft). If there are bugs preventing certification we would evaluate our testing on the proper fix and include it in the next submission. If the games are certified with the hack, then so be it.



#19 warnexus   Prime Members   -  Reputation: 1379

Like
0Likes
Like

Posted 08 November 2013 - 04:49 PM


This is another way of saying you get lazy. It's not the end of the world. We all get lazy in different aspects of our lives (even football players who get paid millions sometimes "take plays off"), but it's important to know that's what you are doing (if it's a hobby project). Don't deny that fact or try to justify it in any way.

 

Interesting statement. I will come up with a better design to avoid hacky code or latch. Thanks.



#20 EarthBanana   Members   -  Reputation: 803

Like
0Likes
Like

Posted 08 November 2013 - 06:01 PM

I wrote some hacky code back when I was prototyping the rendering part of my engine out - just trying to get stuff together and render some meshes on the screen..

 

well I forgot to go back and fix it..

 

3 months later certain types of meshes would scale and rotate what seemed in a random fashion - took 1 week to find my problem - took about 30 mins to rewrite the bad code...

 

so - I think most of the time it pays to take the 30 mins rather than the week






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS