Jump to content

BLaBZ Blog

  • entries
    18
  • comments
    59
  • views
    18,307

3 Years Later - Lessons Learned


BLaBZ

2,850 views

 Share

3 Years and 35,000+ lines of code later I can look back and see many things I would of done differently.

 

I started my project more than 3 years ago which was when Leadwerks was at version 2.2x and unfortunately I was in to deep to switch to Leadwerks. My software is a game creation tool that is specific to creating Real Time Strategy games like Command and Conquer and Starcraft.

 

I've learned a few lessons about developing game creation software that if I were to do it again I would not skip any of these. Sharing some of these is almost embarrassing but it shows how far I've come as a developer in the last few years (I started programming 4 years ago).

  1. Serialize - It's the simplest, quickest, and lowest maintenance method to save\load projects and game related data. I will never again manually code saving mechanisms.
  2. Inheritance - Smart use of inheritance reduces code duplication and can also reduce "spaghetti code" when used wisely. Silly me, I didn't even have a base class for all game objects.
  3. Mutators - I cannot emphasize enough the rigorous re factoring caused by not using getters and setters. This makes it a pain if you want to add additional logic when a value is changed and you don't have a setter method. It also makes your application more tightly coupled and difficult to replace classes. Bad me. Bad.
  4. Modular Coding - Code each component separate from your game\project! Code your GUI interface in one project, code your gameplay in another then combine. Keep things loosely coupled so it's never to big of a challenge to replace components!
  5. Reflection\Metadata - This is more specific to creating tools, but had I known what I know now the main editor would basically have built itself by reading metadata in the game engine module. So much time has been wasted hardcoding how to treat\populate gameobject properties in the editor when all of this could have been controlled by metadata.
  6. Interface Contracts - This is more of a "good idea" and Microsoft enterprise application best practice then it is a necessity but I note it anyway. Have an Interface or Abstract class that contains all of the classes required methods. If you later decide to swap out a class you then have all of the methods that class must implement in order for your game not to break.

I could of saved a lot of time had I known what I know now! Hope this is useful for you and thanks for reading!

  • Upvote 3
 Share

10 Comments


Recommended Comments

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.

  • Upvote 1
Link to comment

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.

  • Upvote 1
Link to comment

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.

  • Upvote 1
Link to comment

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.

Link to comment

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.

Link to comment

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?

Link to comment

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.

Link to comment

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.

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...