3 Years Later - Lessons Learned
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).
-
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.
-
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.
-
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.
-
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!
-
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.
-
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!
- 3
10 Comments
Recommended Comments