Taking a small step back from actual the actual creation of code and unit test assets, I'm going to talk about version control and the importance of it in a development environment. When working as the sole developer on a project you can argue that there's no need for version control. I'll look at why, even in this situation, these this subject is important.

Version control is the act of tracking changes of a software system over periods of time. As the sole developer on a codebase you may ask why you even need it as surely you know what you've changed and when you changed it, right? Consider the situation in which you are adding a new feature to the system. What happens if you have to change some of your existing classes or interfaces which ends up breaking one or more features of systems. Without a backup, you're left to either manually rollback or try and fix it to make it work. Maybe you're wanting to try an experimental update to some existing code that you may or may not wish to commit to depending on the outcome of the update, a similar situation occurs. Imagine you've made a release or two to the world and you wish to work on a new version whilst keeping the original source around for bugfixes and minor updates that your users are asking for; how would you manage that? The typical approach would seem to be keeping a full copy of the source code folder, probably with names such as "Source-old", "Source-new", "Source-new2", etc. For the sake of argument, you fix a bug in "Source-old" which you realise is present also in "Source-new" - how would you go about applying the bugfix, bearing in mind that you may have also modified code around the situation in "Source-new". What happens if another developer wishes to contribute updates to your code? Hopefully you're now seeing some real problems in the old "backup your folders" methodologies many of us may be using. How do we look at addressing this? Enter version control software (VCS). Version Control Software provides a solution by storing your code assets in a database and maintaining every change you make from one commit to the next. It will provide the ability to revert changes to files, show differences and merge changes between two versions. Many, if not all, version control systems will provide the ability for multiple people to make changes to different files, allowing you to keep a single definitive version of the current codebase and all points in time leading up to it. A snapshot of the codebase can be taken or retrieved at any point in time to allow multiple 'branches' to be maintained, solving the need for keeping full filesystem copies of the codebase stored under different names. Typically, updates to one or more branches can be merged up and around into curent versions, allowing the bugfixes to merged into the cutting edge codebase in a much simpler way. I won't go into the ins and outs of how version control systems work, but if you're interested, please have a look at the wikipedia article on the subject and Eric Sink's excellent introductory article.

There are many version control providers out there, each of which offering new and different features. Deciding on which one to use depends on the specific requirements of your team and project. For this particular project, I will need the following features:

• Typical branch/merge functionality. I want to be able to keep the "Development", "Main" and "Release" structures I'm used to.
• Intelligent compare/merge tools. I need to see the differences between versions easily and merge them automatically without having to hack around files.
• Labelling. I want to be able to apply meaningful point in time labels to files or entire folders/branches.
• Mutli-user system. I want to be open to allowing others to access the code at some point, so multiple users are a must.
• Easily backed up database. I need to take regular backups of the database to ensure that in the event of failure, little or no code is lost.
• Cost-efficient. I want a free or cheap system.
• Well-documented. The system needs to have good documentation for setup and usage
• Visual studio integration. The ability to checkin/checkout files via the visual studio UI would be very attractive.
• Ideal system will have work and bug tracking features built in

Over the course of the next few days I'll look at evaluating the following products for the purpose of this project. Of course, there are many more available, but I can't look at all of them.

• Perforce
• Ionforge Evolution
• Subversion (svn)
• CVS
• Visual SourceSafe
• Team Foundation Server
• SourceAnywhere Standalone

It's worth noting that Visual SourceSafe and Team Foundation Server (TFS) are likely to be discounted on cost alone, although my professional experience with TFS has highlighted how good it actually is.

Unit testing is one of those things that you always wish you'd done up front before starting work on something. Given that this new project will be kicked off soon, I should decide on a unit testing framework to use with C++ and approach the development in a test-friendly way. By covering the code in unit tests, you can help track down and solve many bugs as well as proactively ensure that what you're writing is of high quality. Unit testing in C++ is something I've probably tried to avoid in the past, often relying on the old test harness approach to development - add a feature, add some code to make sure it works as you thought, discard code, add next feature, etc. Whilst good in terms of you're actually doing testing as you go along, this approach doesn't truly let you test components in isolation, especially as the system grows in size and becomes more integrated. This will often result in the test code being discarded or left as being out of date. One issue with unit testing is that it can often be tedious and can hold you up when you feel like steaming ahead; however in my recent experience, unit testing can really save you from yourself by eliminating stupid bugs early on.

Deciding on a decent framework is key to keeping the pace of the project and keeping you actaully interested in testing it. The features I'm looking for are as follows:

• Tests must be quick easy to add. If it takes an age to add a test to a complex framework, I'll stop adding tests
• Tests must be non-invasive. I don't want to have to add #ifdef UNIT_TEST declarations into my production codebase as it'll end up making a mess and worse, could actually change behaviours. The framework and test code will be in an externally compiled project
• Tests must be run automatically. I want to be able to compile and run these tests without thinking as as matter of course. Without it, they'll be forgotten.
• Tests must be visible. I need to know if tests are passing or failing immediately. I don't want to have to wade through a logfile to see what worked and what didn't. The Nirvana would be to have them show a report in Visual Studio (note: I'm not using the full VS here, but the Express editionm so I can't use any of the in-built Microsoft stuff).
• Free or low-cost. I don't want to have to spent lots of money on a testing framework.

A cursory glance around the various forums and websites show up a few useful links to frameworks that I'll try out and evaluate in a later update. The frameworks I'll look at are as follows:

• UnitTest++ 
• CppUnit 
• boost::test
• CppUnitLite 
• NanoCppUnit 
• Unit++ 
• CxxTest

It's worth mentioning that the site Games from Within has posted an excellent critique of some c++ frameworks that will be useful in my evaluation process.

I'm starting up a new, as-yet undisclosed project that I'll be talking about and documenting in great detail here over the next few months. The core of this system is to bring together several working prototypes that I've put together in the past and provide a stable core for use in various different types of project. The main driver of the system is to provide a framework for data-driven entities and game logic in a way that's suitable for almost everything.

 To focus on the entity concept itself, I've looked at a few ways of doing this in the past. The main concept was that of defining an entity as being just that, a unique identifier to the system. Entities themselves are nothing but a basic handle and on their own have little use until they are decorated with properties and/or methods. The interesting thing about these entities are that these are all assigned at runtime, meaning that the actual source code has little or no concept of the properties or even 'types' of entities that it is working with.

A key decision point here is whether we wish to give the entity a concept of 'type' or not. One thing I've considered doing is to treat 'type' as either a series of 'tags' on the entitiy, or allow the user to create collections of properties and methods under the banner of a 'type' and then build the entity by mixing in the various components that make up the entity itself. The key difference here is that the second option would allow us to always know which properties are on a given entity for a a given type/component - "Positional" would always give the properties "X, Y, Z", for example. Tagging would simply be labelling an entity but will provide no guarantee that the entity with the "Positional" tag would have X, Y or Z at all. Tagging does have merit however; it would allow entities to be labelled by group. So the mixin method provides the "is a" relationship to type, but tagging would provide a "belongs to" relationship.

 A thing to consider is whether the concept of property in itself is typed or untyped. Should systems have to deal with somebody setting the X property to a string value, or should we always know that it's a float? Typed data would help things considerably, but the interoperability of the system with external scripting languages (such as GameMonkey Script of Lua) would have to be considered. Being that entities must be serialised down to byte data or xml at some point for storage/transmission, the typed argument seems to hold more weight. Perhaps they should be untyped until declaration and then only the value can change but not the type of value.