BLaBZ Blog

All good stuff. Many of us don't have the benefit of being mentored. You learned (like many of us I'm sure) the long way round through experimentation and simply 'doing' which is fantastic. We'd all do things differently if we knew then what we know now.

 

And to compound it all, some coding practices today haven't been around that long. Some were possibly not around when you start a project.

 

If I were to add anything to your list it would be unit tests, especially on complex or large projects. That and recognizing basic design patterns as they tell you how to build something (at least recognize the problem and how to structure your code).

 

I now work in professional testing and development and even though it's not related to games, all the things you mention apply. As skills go, they work across the board.

 

Josh would have less issues with releases if there was a more solid testing system in place. Sadly testing is much neglected, it's something that not only saves money but also time and customer satisfaction. The earlier you can catch bugs the less impact it has on a project. Developers are the first line of defence when implementing automated testing using unit tests and code contracts. It's also harder to retro-fit to a project the longer it runs.

 

To end my comment with a t-shirt quote; what doesn't kill you, gives you experience.

I wish I could get into Unit Testing but every time I do it, it all seems so tedious, trivial and pointless :-/. Maybe I'm doing it wrong, but even the examples I see online always seem so small and pointless. It has a big following so it must work well but I just can't get used to it.

They test units of code. And give you code coverage. For large projects that may have multiple releases or rely on 3rd party libraries that might change, it's a way of confirming they still do what you expect if you need to apply an update to your source.

 

Take RakNet for example, you might have helper functions that listen for a client message and sends back an ack message with some server information. If you have to update the source, you would just run all the Network Unit Tests and if they are crafted well enough, will tell you quickly if the update has borked anything without having to compile the whole project and test it.

 

For Leadwerks you might want to test different raycasting and collision scenarios with each update. Checking you get expected values from a bunch of operations on hulls and vegetation.

 

These are more functional tests than Unit Tests but you can use the same Unit Test functions built into Visual Studio to give you a nice 'at a glance' traffic light panel.

 

You can't always make a good case for using them, or justify the effort at all when dealing with small projects. But they can help you focus on your code and what it's supposed to do. Especially with classes which ideally have singular responsibilities. It's all too easy to pile multiple things into a class and a unit test will flag that if you can't easily write a test for it.

 

It's more like 'healthy eating', not required, but is of benefit.

I find the trade off between spending the time making unit tests (which seems to not really be about making the tests as much as it is taking the time to organize your code a certain way to aid in unit testing) vs "normal" testing and fixing issues when they come up, interesting.

 

I almost feel like we're so used to bugs in software in general that users don't really value bugless code all that much. We seem to be able to put up with bugs if the software is good and works most of the time. Windows almost seems to be the prime example of this.

Great points Flexman!

 

I'm really glad you mentioned this and this should definitely be on the list. I'm a huge fan of the concept of Test Driven Development (TDD). Unit testing creates a big win for code quality.

 

Writing all your tests before even starting development ensure thorough planning and quality.

Nice blog. Can you explain the Serialize point a little more? How do you handle this. Does every object that needs saving have an interface to a Serialize function?

Nope. You only have 1 serialize function in which you pass a list of objects that includes everything you want to save.

 

The function then -

1. Uses reflection to determine object composition("has-a" relationships) adds dependent objects to the list then sorts the list from most dependent to least dependent.

 

2. Using reflection enumerates through each objects properties and saves them(xml or some other format).

 

You also need a deserialize function that then -

 

1. Reads the xml.

 

2. Enumerates through each object, and using reflection, instantiates each object and its properties.

 

3. If you're loading things into video memory as with Leadwerks you would then need to call the appropriate LoadMesh and LoadTexture functions.

 

 

I'm actually kind of suprised SaveGame and LoadGame aren't functions that already exist in Leadwerks.

C++ doesn't really have reflection. Enter boost and all that **** but that introduces a good amount of bloat, considered by many. I do like reflection in the .NET space but though.

What serialization libraries have you found and feel happy with?

Thanks for the reply. I know C# has the auto serialization based on public variables, but I don't think C++ does this the same way or even at all.

 

I use TinyXML when using XML.

http://www.grinninglizard.com/tinyxml/

 

 

But I am about to switch to JSon since I want to send over a lot of data to a server.

http://jsoncpp.sourceforge.net/