<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.2.1" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Why Game Code Sucks</title>
	<link>http://www.heimburg.com/blog/2007/07/24/making-game-code-suck-less/</link>
	<description>A developer's perspective on development</description>
	<pubDate>Wed, 07 Jan 2009 14:20:23 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.2.1</generator>

	<item>
		<title>By: Nikos Beck</title>
		<link>http://www.heimburg.com/blog/2007/07/24/making-game-code-suck-less/#comment-229</link>
		<author>Nikos Beck</author>
		<pubDate>Mon, 30 Jul 2007 14:40:49 +0000</pubDate>
		<guid>http://www.heimburg.com/blog/2007/07/24/making-game-code-suck-less/#comment-229</guid>
		<description>The first version of every function I write is:

Echo("you're here");

I want to make sure the function is triggering at the right time, then I code it, adding whatever functions I need. If I'm lucky the new functions don't break anything. If I break something I refactor the class, search the entire project for calls to that class and flag them or fix them.

I suppose I avoid messy code by refactoring constantly. It's very time consuming.</description>
		<content:encoded><![CDATA[<p>The first version of every function I write is:</p>
<p>Echo(&#8221;you&#8217;re here&#8221;);</p>
<p>I want to make sure the function is triggering at the right time, then I code it, adding whatever functions I need. If I&#8217;m lucky the new functions don&#8217;t break anything. If I break something I refactor the class, search the entire project for calls to that class and flag them or fix them.</p>
<p>I suppose I avoid messy code by refactoring constantly. It&#8217;s very time consuming.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: lawrence</title>
		<link>http://www.heimburg.com/blog/2007/07/24/making-game-code-suck-less/#comment-226</link>
		<author>lawrence</author>
		<pubDate>Thu, 26 Jul 2007 07:29:17 +0000</pubDate>
		<guid>http://www.heimburg.com/blog/2007/07/24/making-game-code-suck-less/#comment-226</guid>
		<description>Well it is good to maintain a proper and correct code in order to avoid problems!</description>
		<content:encoded><![CDATA[<p>Well it is good to maintain a proper and correct code in order to avoid problems!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Koen Witters</title>
		<link>http://www.heimburg.com/blog/2007/07/24/making-game-code-suck-less/#comment-224</link>
		<author>Koen Witters</author>
		<pubDate>Wed, 25 Jul 2007 08:13:27 +0000</pubDate>
		<guid>http://www.heimburg.com/blog/2007/07/24/making-game-code-suck-less/#comment-224</guid>
		<description>It's indeed difficult to find the right balance between time and quality. I've had a lot of code that I thought that I would never touch again after the release, but to be honest, all code you write will come back to you sooner or later (porting, small adaptions, etc. ). But quick hacks still remain really seductive, even after programming 5 years or more (especially when the project is almost finished :). I still fall into that same trap. 

Maybe one of the problems is also that when we think the project is 90% finished, the other 90% still needs to be done. But most of the time we do the other 90% with quick hacks (so half of the code will smell).

Another problem is that a lot of times you already have a working code base (the first 90%), and you don't want to refactor that because it already works, so you hack the extra features around that code without touching it too much (to keep it stable). And with every hack you make, you don't want to break the previous hacks. But in the end I think, all your hacks will make the code more unstable than when you should have refactored it in the first place.

Maybe the best way is to first prototype it, like you say, and then decide: 1) throw it away or 2) refactor it and commit.

And to be honest: I never regretted making quality code, but lots of times I regretted building in quick hacks.</description>
		<content:encoded><![CDATA[<p>It&#8217;s indeed difficult to find the right balance between time and quality. I&#8217;ve had a lot of code that I thought that I would never touch again after the release, but to be honest, all code you write will come back to you sooner or later (porting, small adaptions, etc. ). But quick hacks still remain really seductive, even after programming 5 years or more (especially when the project is almost finished :). I still fall into that same trap. </p>
<p>Maybe one of the problems is also that when we think the project is 90% finished, the other 90% still needs to be done. But most of the time we do the other 90% with quick hacks (so half of the code will smell).</p>
<p>Another problem is that a lot of times you already have a working code base (the first 90%), and you don&#8217;t want to refactor that because it already works, so you hack the extra features around that code without touching it too much (to keep it stable). And with every hack you make, you don&#8217;t want to break the previous hacks. But in the end I think, all your hacks will make the code more unstable than when you should have refactored it in the first place.</p>
<p>Maybe the best way is to first prototype it, like you say, and then decide: 1) throw it away or 2) refactor it and commit.</p>
<p>And to be honest: I never regretted making quality code, but lots of times I regretted building in quick hacks.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
