DawnBringer3D Tips & Tricks, Personal News, Game Development

Function Driven Design

I have been trying out different ways of doing things while writing my 2D graphics engine. I came up with a pretty neat way of doing things fast with good enough design before implementation, I call it function driven design, don’t know if that already exists or not, but that describes my way.

The Basics

The idea in function driven design is to first design your ‘module’ interface, e.g. write down all your functions to header file. Now this requires a bit discipline, like everything. For each function spent some time (max 5 min) to give it a proper name and right parameters. Time is fixed because I don’t want to be spending eternity on thinking the function declaration. Now after you have written all down you probably already have some ideas about what needs to be changed / improved, now run through a second iteration doing the same thing : check the names, parameters (and their names too!), the general design (think about how it should work) and add new required things.

Second Move

Now you have a interface designed and it is start to continue to source file. Copy all your functions from your header file to your source file in the order they are presented at the header. Then make them all do nothing ‘NULL’, ‘nada’, got it?

After you have functions that can be executed, but won’t do anything you have a prototype of it, kinda. Now start going through every function and add description in few sentence what it should do, if you can’t do it in few sentence then it is probably too long function and at that point I have added TODO in there (explain why) and continued to next funtion. Spent 5-10 mins on each function to come up with the description, again think about how it should work, what it should do, what is it using…

Nearly Implemented

So now you have an interface and null functionality and descriptions for the functions. Do a quick overview of everything : handle the TODO’s, if you spot mistakes fix them right away and so on.

Alright, now you should have a pretty good idea of the ‘module’ : what it should do, how it is designed, what it will use, etc. So we can start implementing, start doing the real implementations : even if some function is not yet implemented use them as you will implement them soon anyway. Compile at least after each function to fix all warnings, errors, etc.

Finishing Touch

After you have implemented your functions go through it once again with small functionality test, e.g. if it is sprite module try that you can create sprite, render & animate and destroy it. Fix all design errors, etc.

As a side note to testing : remember what ever happens it should not ever crash! Even if you shoot nulls, empty filenames, etc. in it, it should just return a clean error message and exit.

Conclusion

I have found this way to be very effective. It has reduced design mistakes, bug and time spent on doing the module and getting it up and running. Used to I had to fix loads of stuff after implementing the module before getting it running, now I’m even sometimes able to get it working right away!

Many iterations and fixed time boxes ensures the quality -> -> makes it is good enough and it doesn’t take eternity, which is really cool.

Software Development Tips & Tricks E-Book Released!

I have released my very first e-book : Software Development Tips & Tricks

Book contains 18 software development tips & tricks that I have found useful. I can’t say that it would be top quality book as I know it isn’t as it is my first one, but I know that it contains loads of useful information.

It costs only 18 dollars -> 1 dollar per tip, I think that is pretty fair price. Also it has 28 – Day Money Back Guarantee!

Font Cover & Table Of Contents

Buy it from here :

Thoughts On Sprint Retrospective

I had my first sprint retrospective last week and it was a very useful thing to do.

Sprint retrospective is like a post mortem of the sprint : go through what went well and what could be improved. It becomes very powerful as you will have many retrospectives during the project, after each iteration you are able to improve for the next sprint!

Note that it is important that the improvement process is organized. When improvement process is organized it is a lot easier to handle, e.g. improvement will done during or at X – date, how it is done, who will be affected by it, person X is responsible for it.

I really recommend trying out Scrum. Iterative development is very useful if used right. If used wrong it will probably just do more harm than good. You need to give it some time, apply these processes step by step, results won’t show right away. Scrum doesn’t solve all problems, and it should not, it will identify more problems. And that is important : you cannot improve if you don’t even your problems.

Our team found loads of improvements to be done, we are going to apply some of those right away and some later. Remember that you might also find improvements that doesn’t just fit in to this project but might be good ones to next one, so it is useful to write those down too.

Books For Game & Graphics Programmers

Andre LaMothe is one of my favorite game & graphics programming book writers, I really recommend getting both of these books :

Tricks of the 3D Game Programming Gurus-Advanced 3D Graphics and Rasterization (Other Sams)
Tricks of the Windows Game Programming Gurus (2nd Edition) (Other Programming)

Fast And Practical Testing

I’ll be releasing this Tips & Tricks – article as free. When I four months ago started my 2D graphics engine I had problem with testing :

• How to test for regression if I don’t have the resources to setup nightly builds.
  • Manually running those tests was not good enough solution.

This is really a problem in many projects, people think that there is no sense to do testing if it cannot be automated. Most of the time there is just not enough resources to setup a nightly build system. I thought about this problem for a while and I love solving problems, so I came up with an idea :

• Create fast dummy tests for the core.
  • Will not test everything, but is good enough.
• Test on each build.
  • This is even better than nightly build!

Now if you know that testing is the way to go you know how important it is to do as much testing as possible. This system ensures it. So, how to do it :

• Create tests in your code so that they are disabled for the release build.
• Create a RunTests – function in general or RunTestsModuleX – functions.
• Add these to your init code as early as possible.
• All tests must pass in order to continue, assert if failed!

I’ll have to say that even after years of doing shit loads of testing I’m still amazed how much it helps. I have been able to catch dozens of bugs from my code just by doing a few tests! And I’m still amazed why people don’t do it.

Note : for your information, don’t pretend to be agile developer if you are not, it makes you look -not good-.

Happy testing!