Yeah, Casey was doing a Linux port. Partially so he could work on the game in his preferred environment! So, that is one way a Linux port could come about.

For us in the Linux gaming community, that’s hugely exciting! I (and many others) sadly thought that Jonathan had given up completely on it because of audio API problems and weak tools (well, weak for his requirements at least).

Should we have hope, maybe, that we’ll also be able to play this gorgeous adventure/puzzler?

It means adjusting the individual components of the vector such that the length of the line itself is 1.0 units. Since I don’t do this sort of programming much I’ll probably get the terminology wrong but hopefully the meaning is clear enough.

In 2D, a triangle with base 4 units and height 3 units has a hypotenuse of 5 units, from hyp^2 = base^2 + height^2 (which is Pythagoras’ theorem). The base and height are the X and Y components of a vector and the hypotenuse is the length of that vector.

To normalise the vector we divide each component in the vector by the length we calculate, giving us the normalised version of the vector.

For my example above, now we have 0.8 (4 / 5) for the base and 0.6 (3 / 5) for the height. So:
hyp^2 = base^2 + height^2
hyp^2 = 0.8^2 + 0.6^2
hyp^2 = 0.64 + 0.36
hyp^2 = 1.0, so hyp = 1.0.

You calculate the length of a 3D vector with a very similar equation: len^2 = x^2 + y^2 + z^2 and you can scale the components in the same way as I described up above. Normalised vectors simplifies a bunch of things in 3D math.

It’s the bugs made by naming conventions and assumptions that are easy to make and tough to find.

I remember spectacularly breaking a build because when I assumed a variable was called foo_binary was actually a binary value. Turns out people were using the high order bits to store “other” information.

That makes sense. Have you looked into component-based entities?

https://archive.fosdem.org/2012/schedule/event/game_entities.html

I think the overall architecture of the project may be the most important part. I’m considering integrating FSMs into handling messages once they’re broadcast to entities, possibly in combination with a minimal-effort routing system via reflection.

Can’t really ever bring up coding without getting into discussions about taste or relevancy of certain practices. It’s interesting food for thought regardless, as a young inexperienced programmer. Even if Doom 3’s source code is horrid, it’s certainly much better than mine.

My code is confusing and convoluted, doesn’t follow any conventions whatsoever and tends to lack a unifying structure that really feels well thought out. And that’s because it wasn’t. Sometimes you do just have to say Eff it to refactoring for the Nth time and just finish the game though. (Working on that one too.)

Thank you for the explanation. Now what does normalization mean in this context?

If I was more math-savvy then maybe this would’ve fallen into my ‘trivial-enough’ category but even then I’m not sure about that. The lesson from this, in my opinion, is that you should always verify you have understood the defect properly BEFORE implementing any solution.

To be honest, yeah, the whole article just seemed like it would add a bunch of extra work for minimal (sometimes none) aesthetic gain.

Oh and this might seem like completely off-topic, but this article just made me think of the “infinitely” many things to improve a game or its source code. A lot of software is “never done”, but games are not that type of software. At some point you have to declare it “done”.

BTW, I’ve been eagerly waiting for this follow-up and you did not disappoint!

Essentially everything it mentions is not really interesting as an isolated example of “beauty”, or even good programming practice. Source code is beautiful at a much deeper level than the things they’re talking about in that article, and the beauty of the Doom 3 source code (if it is beautiful – I have no idea, I’ve never looked at it) surely has nothing to do with the things the person highlighted. I’ve seen very beautiful code that does none of those things, or actively contradicts many.

– Casey

It’s highly subjective. Program in a consistent way, that’s more important.

Look up the common conventions for Python, Ruby and CoffeeScript and then tell me what you think about that article.

I had read that article at kotaku as well, but as a non-programmer I don’t have the knowledge to judge it’s legitimacy.

Why do you say you’re wary of it, Casey?

As an aside, I’d be a bit wary of that article on the Doom 3 source code.

– Casey

Not yet. As soon as _we_ know, we’ll let you know, don’t worry! :)

– Casey

It does not have a side effect on the object. It just returns a unit vector.

If you are working in an unfamiliar code base, never trust that a function does exactly what you expect it to. Always investigate.

It reminds me of how ashamed I was of my current coding style upon reading this:
http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code

Luckily for now, I’m still coding alone. So nobody has to decipher the meaning and purpose of my poorly designed functions. But I am glad to be learning, and have really been enjoying your write-ups, Casey. Particularly this one.

Where else might functions that look like accessors have side effects?

The problem is that I wrote my code expecting the plane class to store the plane equation {a, b, c, d} and then return it to me exactly as I stored it. So, if I computed (ax + by + cz + d) somewhere before storing the plane, then later asked for the values back so I could do (ax + by + cz + d) again, I need to be getting the same exact numbers back. Otherwise, obviously, the computations don’t match.

Since the Witness code was normalizing the a b c on the way out, my second (ax +by + cz + d) ended up using _differenct_ a b c values, which leads to completely erroneous results, all of which will be wrong by whatever the ratio was between the original vector {a, b, c} and the new normalized vector {a, b, c} / |{a, b, c}|.

It’s all just a simple misunderstanding about what the class did internally. Once I actually looked at its code, it was very clear what the problem was – it is not a subtle problem.

I’m not sure I understand exactly what your guess was, but it doesn’t sound close to either answer, unfortunately :(

Next time!

– Casey

But you could have easily had a similar situation where looking into it revealed that the problem was exactly what you thought, and you wasted hours of your life on something that meant nothing.

The takeaway here is not ‘always look into things’ but that good programmers have honed their instincts as to when to look into things or not.

Yes, I realize that. It still depends on my mood as to whether or not I would actually do it, regardless of what the reasons or benefits are.

Anyway, I’d like a layman’s explanation for what is happening so that I’ll know how close or far off the mark my guess was.

If the bug had been in front of me, would I have looked at it a second time after “fixing” it that way? I don’t think I can answer that, because I don’t think I would’ve tried to fix it that way without spending a lot of time staring at the actual numbers and trying to figure out where I was losing precision. But if I had explained it to someone I trusted, and they had said “oh, it’s numerical precision, try this” and they made the changes you did and then the problem went away… would I have looked a second time? Probably not.

The major takeaway is, as it often is, to _always_ investigate further. For example, in this case, even though the bug was completely fixed by my original solution, the insight into how the plane code worked has surely saved me future Witness bugs of this same nature, because now I know how to use the plane code properly.

– Casey

I’m not sure whether or not I would have just accepted the fix or investigated it further. I guess it would have depended on my mood.

p.s.: I love how clouds look in your game!