Game Development Design articles

[Tank]

'by' looks like it should be 'but'. This sounds like the fact of keeping readability is a way to achieve hashing and performance. I might be wrong.

I replaced the "by" by "while". Thanks

The article might contain product placement adverts.

Of course, that's cheap advertising. Indeed the articles' only purpose is advertising my our game!

[Tank]

I decided to give everyone the opportunity to support the author of the GDD articles (existing and future) by doing a small donation and in return get a PDF/epub/mobi version of all articles.

All future articles will of course still be published at my blog. I'm doing this because it's fun, and not to earn my daily bread, so no worries about this.

Check the Leanpub webpage to get the PDF/epub/mobi version. Price? Pay what you want!

WEBLINK GDD at Leanpub

[FRex]

Tank, could you give us some examples of 'good' messages to send on the bus?

[eXpl0it3r]

I'm not really sure, what you mean with 'good' messages, but you can basically send anything.
One easy example would be the whole window events (Lost/GainFocus, KeyPressed/Released, etc). Another example would be any UI interaction: "Button X was pressed" and anyone that cares about the button X can 'listen' for it; keep in mind though, that most of the GUI libs already have somesort of dispatching and thus it might be better to use these.

It really depends on what you're doing and how you want the architecture to be.

Did I get the question right?

[Tank]

eXpl0it3r already answered your question, I just wanna add that everything that needs to be passed to other modules should be sent via messages. There's no "good" or "bad" regarding to what you send. Just make sure that you don't target your messages at specific receivers (like explained in the article).

[Tank]

Hey guys,

a new article has been published which is about how to raise and work with errors. Hope you like it!

LINK http://stefan.boxbox.org/2013/10/11/game-development-design-4-errors/

[eXpl0it3r]

Hehe got the mail from leanpub about a new version before checking my RSS feed or reading here.
Will dive into it later on.

[Tank]

Sure, donators get the notification ~1 minute earlier.

[Ixrec]

Some of the code examples say && instead of &&.  Otherwise, definitely a good article, especially for newbies.

Though it's a little ironic that SFML is the example when it says a library's error reporting has to be consistent, since most SFML errors are reported through the err() stream but a handful of functions, like the example, return bools instead (though I think Laurent said he'd like to fix that in SFML 3).

[Nexus]

Good article, it gives a nice overview about different error handling techniques! I also like that you emphasize the importance of naming functions clearly ("find" vs. "get").

Some remarks:

• Saying error codes should be completely avoided is a bit too strict, considering that it's still a legitimately used technique (sf::TcpSocket::connect()), and even newly introduced as a part of the C++11 standard library with std::error_code. But it may be okay as a general guideline.
• "Remember the two different kinds of errors: Exceptions and programming errors." -> I would probably also mention the term "runtime error" here, since it is very common and differentiates the type of error from the language feature exception.
  
• "In most languages, the assert calls do only work when building and running a program in debug mode." -> Do you mean "compilers" instead of "languages"? (The behavior of assert depends on the definition of the NDEBUG macro)
• You should catch exceptions by reference.
• I don't know if that's your personal style, but if (x == true) and if (x == false) instead of if (x) and if (!x) looks like code from beginners who don't know how boolean expressions work

[Tank]

Hey Nexus,

thanks for the feedback.

Saying error codes should be completely avoided is a bit too strict

Indeed it's very strict. I tend to follow my own guidelines in every possible situation without exceptions. It's true that using error codes is still widely done, even by the STL, but I don't agree to the idea (reasons in the article). There are for sure situations where an error code might feel easier to use or more straightforward, but I still want to stick to my guidelines to be consistent.

I would probably also mention the term "runtime error" here, since it is very common and differentiates the type of error from the language feature exception.

I thought about that for a long time but came to the conclusion that "runtime error" is too squishy. Even a programming error is evaluated during runtime.
For me "exception" and "programming error" are in the same category, just like "runtime error" and "compile-time error".

Do you mean "compilers" instead of "languages"?

Thanks, that's right. I will correct it.

You should catch exceptions by reference.

That's also right, typo will be fixed.

looks like code from beginners who don't know how boolean expressions work

Haha. Yes, it's my personal style. I like the verbosity and am used to it from unit testing, where you often exchange true/false in the expressions.

[Tank]

I can't believe that the last GDD entry was made almost 2 years ago, phew! Time for something new, I guess. Here you go!

GDD#5 Optimizing & Engineering

[Lee R]

Bullet point number one should have been 'Understand the hardware'. You almost touch on that right at the start by pointing out that it's slow to jump around in memory, but why is it slow? What is it about modern computer architectures that makes memory access patterns such a big deal when it comes to performance? You get the idea