I recently installed it on a 64bit version of Windows running VS2010 and the 64bit version of Perforce. NiftyPerforce has issues with this, leading to the following dialog when you try to use it.

Could not find p4.exe installed in perforce directory? Well I know it’s there because I use it every day…

If you have a look at the NiftyPerforce output, there’s an interesting line in there…

Found perforce installation at C:\Program Files(x86)\Perforce\?

What? There is no ‘C:\Program Files (x86)\Perforce\’ folder since the 64bit version of Perforce is actually installed to ‘C:\Program Files\Perforce\’

I quickly Google’d the issue and was surprised that there are a few bugs reported on this issue but nothing else.

Anyway, the solution was actually quite simple (if a little hacky). I created a Symbolic Link to the actual Perforce install so to NiftyPerforce it looks like Perforce does exist in ‘Program Files(x86)’

> mklink /D "C:\Program Files (x86)\Perforce" "C:\Program Files\Perforce"

Interestingly it actually works if you remove the /D option too, but maybe that’s just a quirk of Windows?

Now when NiftyPerforce looks for our Perforce install via the (x86) directory, it’ll link nicely to the directory that actually stores the executable.

I’m waiting for this to blow up in my face as other tools start to get confused as to where my Perforce install is, but so far, so good…

Choice is a wonderful thing. Blind choice isn’t and when it comes to degrees listing themselves as a great place to do a ‘Technical Games Degree’ there’s a lot of choice and not a lot of information available to sort the good from the bad.

It’s this abundance of choice and the issues resulting from making the wrong choice that drives my involvement with SkillSet. Good courses need as many opportunities as possible to stand out from the crowd especially when prospective students may have to narrow down the Universities they’ll investigate let alone apply too.
 
 

What Is The Accreditation Process?

I’ve been a lead evaluator for the SkillSet accreditation process for quite a few years now. The process (I’ll keep it short) involves an application by the University to SkillSet, a paper based investigation into the University covering the skills taught, the attainment and employability of students (amongst other things) followed by an on-site visit by an evaluation team. This visit involves interviews with staff and students, examination of the work done and the facilities available with a recommendation to accredit based on their findings.

This evaluation team is always made up of active game developers working in the discipline the course focuses on.

Courses have and will continue to be rejected at various stages of the process if they are not up to scratch and the criteria used is often very strict with a high barrier for entry. Courses have to be producing quality graduates with the skills suitable for the industry before they can even start to think about applying for accreditation. Cross skill courses (those teaching programming, art and design in a single degree) have never been accredited and never will.

The process and documentation is publicly available so you can have a more detailed look here.
 
 

Student Choice

There are a lot of Universities in the UK and a large number of them provide a some kind of game related technical course. Unfortunately a lot of them don’t provide a high enough level of education to warrant the time and money students spend on them. Accreditation awards allows students to quickly narrow down the kinds of Universities they should be looking at and to spend the time they have investigating the best rather than trying to simply find the ones worthy of their time.

Word of mouth and past experience all goes into this but it still takes time that could be better spent especially when students will be applying to Universities at the same time as working towards their A-Levels, a period of time which may well be the most stressful time they’ve had in their academic career so far.

An accredited University at least gives them the knowledge that they’ll get the right kind of education allowing them to focus on finding one that best suits them rather than anything else.
 
 

Industry Involvement

A lot of developers want to get involved with the education of future game makers and University partnerships such as guest lectures and industry panels are one of the best ways to do that. Universities like industry involvement and some developers can end up being overwhelmed with requests especially if they are already working with other courses and word starts to spread. And because a developers time is so valuable, it helps to be able to target the Universities that we know are already providing the kinds of skills students will need in the future.

Building on a quality foundation allows much more scope for growth than having to start from the bottom and working upwards.

But you might think this is a path to ruin. If the industry only helps accredited courses surely none can become accredited because no-ones willing to work with them to get there!

But that’s not the case. Bigger companies such as Sony, MS, Blitz, Codemasters and others work with those up and coming courses, allowing them to get the point where they can apply for or work towards accreditation. Once that happens, it becomes a positive feedback loop, as the course gets better and gets accredited it leads to more industry involvement which leads to a better course…
 
 

It’s The Skills Stupid

The argument between game focused and traditional Computer Science courses is always the same and is usually spot on. Take a CS course over a game course because in a few years you may not want to work in the industry and the skills you learn on a CS could will put you in a stronger position should you want to do something else.

Without a doubt this is a good argument to make but one that I hope accreditation can resolve. In every evaluation I’ve taken part in the skills we look for and the modules on display show that the course could quite easily be rebranded as ‘Computer Science with a games slant’ rather than ‘Games Technology with a little bit of Computer Science thrown in’. As a result the skills taught will still put the student in a good position should they decided the industry is not for them and while a ‘Games Technology’ degree won’t look as good as a ‘Computer Science’ degree on a CV, accreditation should allow it to grow in stature depending on which University awarded the degree.

Here’s one a I found recently when trying something as simple as ‘Find and Replace’

Go to the search tab and search for something (preferably something that exists!). So in the following screenshot I’m searching for ‘defgroup’ which is a Doxygen documentation tab.

Now switch over to ‘Find’ and, as you would do if you did this a while later, change what you last searched for to what you want to replace. In this example, I’m now looking to change ‘client’ to ‘user’. Looking at the following screenshot, what would you expect to be replaced?

In my mind, I expected ‘client’ to be replaced with ‘user’. After all, that’s what I’ve put next to the Magnifying Glass icon – a universal icon for ‘search’ – and the results are for the last search I did, not this one.

But if I select Preview…

It’s actually replacing the results of the original search for ‘defgroup’ and not what I actually asked for, which was to replace ‘client’ with ‘user’. If I’d gone and selected Replace All then the same thing would have happened.

To get it to replace ‘client’ rather than ‘defgroup’ I need to either

• Go back to Find search for ‘client’ then switch back to Replace and do it again
• When entering the new search term, hit enter after typing ‘client’. This won’t do the replace, it’ll redo the search.

So, is this a bug or a failure of UI design? Should Preview and Replace All take what I’ve just put in the search box (in which case it’s a bug) or should it use what I last searched for (in which case it’s a UI issue).

Personally, I see this as a bug. As I work down the panel, I add what I what to replace with the new term then select Replace All. Since we read from left to right and top to bottom, information at the top of the screen is more important (the new term) than at the bottom (the results of the last search).

But then, some people could argue it’s a UI issue, and in that case an improvement to this work-flow from a UI perspective would cause this bug to never appear in the first place.

There has been a significant amount of press in the UK about the quality of computer related education at Key Stage 3 and 4 (Secondary School level with pupils ages 11-16 years old) and to a much lesser extent Key Stage 5 (college or 6th form students aged 17-18 years old).

As someone who used to teach ICT at these level I have first hand experience of the kind of topics, software and skills taught to children in classes across the UK, and agree 100% that, as a subject, ICT should be kicked to the kerb and approached from a completely different angle.

And we’re certainly heading in the right direction.

The Next Gen. report by Livingstone and Hope details how we can provide the skills our children require to take our industries to the next level and beyond and even the current Education Secretary Michael Gove is making moves in the right direction. Change is coming and it’s change for the better.

But we must be careful not to rush these changes and to make sure the structure and content is right, that suitable facilities are available and we have the right people in place before we start this process otherwise we’ll be back to square one within a couple of years.
 
 

You Can’t Teach What You Don’t Know

The largest problem facing the introduction of a new, highly scientific and difficult subject is getting the right people in place to teach. And the most important word in that sentence is ‘right’.

Sure we can use existing ICT teachers but it’s clear that the skills required to teach ICT are not the same skills required to teach a Computing GCSE. Also, don’t get me started on the number of ICT teachers who don’t actually know how to use a computer…

We can draft in science and maths teachers to teach elements of the course others are unable to but those teachers already have working place directives in place limiting how many hours they can teach and those hours will already be more than accounted for.

If we really want to create a next generation of developers is passionate and knowledgeable educators pushing that passion onto the open minds in front of them. Sure, anyone can learn enough to teach a subject, but it wont be exciting, it won’t be boundary defining and it won’t make those pupils crave more. Sure, some teachers will really take to this, will develop that passion along with their students, but the majority won’t and as a result the subject could easily be seen as stale, boring and dull.

So the ideal solution is to hire for the shortfall but with approximately 3,900 state run secondary schools in the UK and with many schools having the need for more than one or two teachers per subject that’s a big recruitment drive.
 
 

Custom Content Is Risky But Rewarding

One of the most interesting aspects of this push towards a more computing focused subject is the idea of having a more flexible curriculum. Now this could mean a myriad of things though I’m taking it to mean schools being given the ability to cherry pick the elements they want to teach and to ignore elements they don’t.

This is extremely useful especially with a lack of specialist teachers and it also tackles one of the main criticisms of the National Curriculum, that it creates boilerplate content and restricts creativity and freedom in the classroom.

So by allowing schools to be flexible with what they teach we allow our teachers to experiment and push the boundaries of our children’s imaginations, if they have the knowledge to do that.

But it also opens up the possibility of a (and I hate myself for using this awful and overused phrase) postcode lottery where some schools are teaching more valuable skills than others. It complicates the act of awarding consistent and meaningful grades across the country and it could lead to stagnation as some schools resist pressure to improve as technology moves on.

Though you could make that argument for the education system as a whole due to the varying levels of skills between teachers of all subjects in all schools.
 
 

We’re A Fickle Bunch

With the issues highlighted above there is every chance that if we rush headlong into these changes we risk the first years being less than stellar as people find their feet, new teachers are recruited and less talented teachers are let go.

And this one worries me the most.

With every change of Government, or in many cases with every change in Education Secretary, schools are given newer mandates, newer targets and newer goals. And it’s always in response to a perceived failure by the last Government/Secretary.

If the introduction of a Computer focused subject is seen as a failure in any way then the next Education Secretary will trip over themselves to ‘fix’ the situation. Not by removing the subject but by constantly tweaking and ‘refocusing’, leading to a course that drives schools (and good teachers) away from the subject and turns it into something resembling what we already have.
 
 

ICT Isn’t All Bad

ICT isn’t just Word and Excel. There’s some really interesting content in there that shouldn’t just be discarded out of hand.

I’ve taught lessons in web design and planning using both graphical editors (Dreamweaver at the time) and text editors. We used some rudimentary programming tools in the early years (getting frogs safely across the road by managing traffic light systems) and video editing tools in later years. All of these were exciting, interesting and (usually) generated some pretty interesting results!

I’m confident that these elements will not be lost no matter what comes next, but we must be careful not to discard what we have and what actually works for want of a ‘better’ system.
 
 

Word Processing Skills Are Important

Something we need to acknowledge is that (this might nark some people) word processing and spreadsheet skills, and the ability to use MS products, are important skills that pupils need to have. Whether we like it or not the majority of the world uses MS Office and while this might change in the future having the ability to use these tools improves a child’s employability, their work rate at school and their computer literacy in general.

But the removal of these ‘skills’ from a specific subject is nothing but good news. By teaching these skills as part of other subjects will lead them to be seen as more natural tools that can be used in a wide range of situations rather than just in their ICT lesson.

But we need to make sure that time is available in all subjects to do this and acknowledge that it’ll take a whole school approach to achieve, something that will vary greatly on a school by school basis.

 
 
I’m certainly excited about how these changes will alter how our children see and use computers on a daily basis and how that can only improve the industry in general. But there are significant challenges that must be faced before we can move forward, confidently, and create a true next generation of developers.

Successful communication is one of the most important aspects of a well functioning and productive team. Without good communication between peers, managers, publishers and anyone else involved in the game development process a team will not perform at it’s best.

If developers do not feel confident in the reasons behind their work, if they don’t fully understand how their work will fit into the project as a whole or indeed when it will be required, the team will produce lower quality work with last minute changes and requirements fostering an atmosphere of distrust and crunch.

But communication is one of the most difficult things to get right but so costly when it’s done wrong.

The following are methods I’ve used over the years to try and improve communication within the team. I’d be very interested to hear other ways people have tried too!

 
Team Wiki
Having an open Wiki that people can contribute information and notes is a good idea for documentation and persistent information. It is not a good tool for perishable short term information. Documentation on team processes (getting the latest build, creating submissions, setting up PC’s etc.) is usually the kind of information that finds a home on a wiki and while it’s useful it’s not something that affects the team on a daily basis.

And as it requires people to physically search for the information in the long term people don’t bother looking for new information on a regular basis.

As a result, the Wiki is useful but doesn’t actually improve the day to day communication on a team.

 
Blogs
We have a team blog that people update about 2 or 3 times a week, usually discussing their recent work, posting up screen shots or letting people know the state of the project. It’s a nice simple way to push information to the team, though it does require everyone to contribute to the blog to get good cross team communication going.

Discussions can take on a life of their own which is actually a good way to gauge buy in into a project but can’t be used to judge the success of the process.

But you’d be amazed how many people don’t have any kind of RSS feed reader set up…

 
Micro-blogging
Internal mico-blogging tools like Yammer or Status.net allow people to quickly thrown up what they’re working on, problems encountered or general team information. The best thing about micro-blogging is it’s push communication style with peoples updates being automatically feed to clients which people can update as much as they want (I usually recommended at least twice a day).

But so far I’ve had very little success with micro-blogging tools in a team environment.

Not because the idea was bad (when it worked it worked well) but I’ve yet to find a service where the official client is anywhere near usable and able to filter out the information people don’t want to read. Without a good way to filter and push information where you want it (like all the best third party Twitter tools do) it either becomes an information overload or a sea of noise, neither of which improve communication.

 
Wall Displays
Walls are valuable real estate especially in an Open Plan office and I’ve rarely seen them used to their full potential. But highly visible walls in the middle of a team area are one of the best ways to communicate information across a team.

As an example on my current project we have the entire timeline of the project (it’s only a short one) with dates/deliverables clearly indicated, a ‘where we are right now’ marker and a description – feature by feature – of what is required for a given milestone.

Next to that we have our sprint wall which is our most ‘live’ wall display. But position is key and in our case the sprint wall’s impact on the team is reduced due to it’s rather awkward position between a big TV, a constantly spinning fan and quite a lot of server machines. But I did say wall space is valuable real estate and it’s always hard to find a compromise between distance from team and accessibility.

 
Morning Meetings
Morning meetings are one of the best ways to push information across a team but I’ve found that you need to follow a few rules to make them really valuable.

• Keep the groups small. I’ve lost count of the number of 20+ people stand up meetings I’ve seen where the majority of the ‘participants’ are looking bored or simply waiting for their turn. If you’re groups are not small, the information is less targeted and much less relevant, meaning more information is lost than actually passed around the team.
• Keep them focused. There is nothing worse than 1 out of the 6 people speaking for 15 minutes about the most intimate implementation details, leaving everyone else itching to get back to their seats to carry on working.
• Don’t make them reporting sessions. If everyone is talking at a single person (usually their manager) take the manager out for a while and get people used to talking to each other as it makes it much more likely for people to take in what is being said.

 
Milestone Reviews
I love the concept of a milestone review. Everyone playing the game, lively discussions about what went right, what went wrong and what we can do better next time. But it’s easy for these to be less than stellar if not approached in the right way.

If these reviews are not focused, maybe even as structured as a schedule or points to cover, people may start to feel unsure as to what they can comment on or what exactly they should be doing. You’ve also got to make sure that people feel comfortable both giving and taking criticism and manage the situations when that goes pear shape (and sometimes it will).

I’ve found that when done right, when people contribute to discussions and when people can (importantly) see change as a result of these reviews, the quality of information coming out of them is invaluable. It also has the added bonus of making people feel like they are making a difference to the team and allowing their thoughts to be heard.

 
Sprint Planning
The days of managers sitting in a room building up a schedule and dishing it out to the developers is (almost) long gone. And there’s good reason for it.

Getting a group of developers (again with the morning meetings it needs to be small and focused) to discuss, schedule and plan the work ahead significantly improves the knowledge people have of what is happening across the team. Again, if people feel that have a say in how work will be implemented, how it will be assigned and when it’ll be done by is vital to spreading information about the project and the work being done.

 
So those are a couple of methods I’ve used to try and improve communication and information across the team. I’m sure there are plenty more (and I’ve tried a few which have been colossal failures) so what methods have you used and how well did they work out?

Title image by deathtogutenberg.  Used under license.

Refactor: Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.

I pretty much wish that word had never been invented. The above definition (taken from Martin Fowler’s Refactoring Home Page) seems to have lost nearly all meaning when used in day to day programming conversations.

To further describe the original definition of refactoring:

Its heart is a series of small behavior preserving transformations. Each transformation does little, but a sequence of transformations can produce a significant restructuring.

But when someone comes to me and says “I’ll just refactor that…” I can no longer assume to know what they’ll be doing. Based on how people now use this term it could be any one of a number of things including (in order of violence)

• Making small changes to make the system more understandable, simpler and easier to use without affecting it’s perceived behaviour
• Optimising elements of the system which should hopefully(?) not effect the external behaviour
• Making wide ranging changes to a system which will effect elements of its behaviour
• Deleting the whole thing and starting again without even looking at what we have now

It seems like there is a reluctance to use the words ‘re-write’, ‘modify’, ‘break’ or (in a some cases) ‘trash’ when discussing intentions towards an existing system. As a result what was a very descriptive and clear term has lost all meaning and resulted in something what can no longer be used to clearly describe a useful and often necessary development process.

Do I wish the word hadn’t been invented? Maybe I just wish it hasn’t taken on an image that ‘refactoring’ is somehow cooler or more elite than simply saying what you mean when describing what you’ll be doing.
 

I recently came across an interesting post over on Agile Game Development titled ‘Scrum Prohibits all Specializations’. The part that stuck me was the following:

I understand that Scrum has been applied mainly to software products and that the elimination of “specialties” means that the database programmer, UI programmer and QA engineer should all be able to perform each other’s roles equally. This is valid.

Now I’m concerning myself with only the technical side of an agile team but I’ve seen this raised in a number of different agile circles. In those cases there seems to be the impression that swapping a database, physics or audio developer with any other specialisation like UI, animation or graphics and an agile team should be able to roll up their sleeves and perform the different roles to the same level with the same level of outcome.

To me, this is emphasised in how the product backlog is often used, which is a priority and risk ordered document that doesn’t take into account the skill set of the team that’ll be working on the final product.

Processes such as pair programming, constant re-factoring and code reviews (to name but a few) seem to be seen as ways to not only communicate intent and project information but also skillset and ability across an entire discipline.

So What Do Specialists Bring?

But we have specialist developers for a reason. They are great at what they do, they understand the area in which they work and they know how to get the best results in the shortest amount of time. They have a passion for the area they are focusing in which usually means they’ll go a step further to research their area and keep up with developments which other developers may not have the time or the understanding to do.

By spreading your talent thin and assuming that people can fill each others shoes leads to the following issues

• You are not respecting the knowledge, skill, experience and passion that a specialist can bring to their work and as a result not respecting the developer themselves
• You’re reducing the impact these people can have on a team and it’s often the experienced specialists that inspire younger members of the team into an area they are interested in
• The ability of those specialists to learn more about their area and pass that onto others is drastically reduced.
• The ability for the team to push their development boundaries will be indirectly reduced as everyone on the team aims for the ‘generalist’ role to fit in

What About Pair Programming?

Now I’m a massive fan of the various agile techniques out there. Pair programming is an excellent mentoring, development and training tool but it won’t allow one developer to fit into the shoes of another. True, they will have a better understanding of the tools, pipeline and systems being developed which will allow them to fill in, but it won’t transfer the amount of background experience the specialist has.

The same goes for code reviews, constant refactoring and feature discussions. It spreads the knowledge which reduces the risk to the project should the specialist not be around when needed, but the core experience and drive that made the specialist who they are simply cannot be replaced by dropping in a new developer.

But Everyone Does A Bit Of Something Every Once In A While?

Of course, sometimes people do need to jump into another developers shoes (illness, staff turn-over, hit by a bus etc.) but this is not the same as expecting a people to be able to fulfil each others roles equally. We can take steps to decrease the impact this will have on the team using the processes mentioned above but it will not allow those specialists to be inter-changed as the project continues development.

We need specialists in any development field because it’s these people that can push their respective fields in directions we might not even be able to imagine. By treating them as interchangeable we might be gaining flexibility to schedule our staff, but we’re losing something far more important and vital to a development team and the products they are creating.

As I said to some one (in 140 character or less of course) when pointed out that people have done this, and even the author of the original post has done it (see the comments)

I’m sure he has done it, I’ve done similar, but it doesn’t mean we did both with the skill of an expert of either.

Quite a few years back I started developing a custom STL implementation which has eventually be adopted and used throughout our company. One of the most important things to get right when developing any kind of generic container library is the way memory is allocated. It needs to be lightweight, highly flexible and above all easy to understand so people are willing to experiment it.

But STL Allocators have a bad reputation and it’s for a good reason. They are complex, hard to understand and have some interesting behaviour that seems designed to confuse. As a result, I needed to look at how we were going to provide a custom allocation system that was both easy to use and simple to understand without restricting what people could do with them.

A Bit of History
A while back Bitsquid published a post entitled Custom Memory Allocation in C++. This excellent post covered how the BitSquid engine used an allocator model to perform memory allocation throughout their entire engine.

But the FTL requires a slightly different approach so I won’t be treading over already covered ground here.

FTL allocators are well hidden inside containers, the only control you have is specifying the allocator type which means it’s use, and how and when objects are allocated and created is completely fixed with only the allocator itself being able to effect the outcome. Because of this the allocator behaviour needs to be as customisable as possible without requiring any changes the container itself.

When the FTL was original started, it was quite small scale and only used by a couple of developers, so allocators were not a priority. The flexibility wasn’t needed so in-container malloc and free allowed us to concentrate on container creation but obviously this wasn’t going to last.

The follow just describes the various approaches we took, why we dismissed them and what we eventually ended up with.

The Initial Approach
Allocators should have a minimal over-head. What we didn’t want to do was increase the size of every container dramatically when we rolled out customisable allocators. As a result, we initially used an approach used by a couple of vendors and defined the allocator specification using only static members – removing the need for an internal allocator object.

// Completely made up code showing the use of a static based allocator
template <typename T, typename Alloc>
class vector
{
  void  push_back(void)
  {
    void* new_memory = Alloc::allocate( sizeof(T) );
    T* new_object = new(new_memory) T;
  }
};

I knew this would limit the flexibility of the allocators, but it had minimal over-head (especially using default template parameters) and wouldn’t effect those containers already being used. And besides, programmers are a creative bunch and I wanted to see what people did with this before resigning it to the scrap heap.

But while programmers were able to work around the main limitation of not having allocator state per container, they were having to jump through hoops to get the behaviour they wanted. Which made it less likely that other programmers would feel confident enough writing their own allocators and their ability to really customise their behaviour was too limited.

So we ended up adding allocator state on a per container basis, making it much easier for developers to do what they wanted though it did add at least 4 bytes per container. But I felt that flexibility and simplicity were much more important.

// Completely made up code showing the use of an instanced allocator
template <typename T, typename Alloc>
class vector
{
  Alloc m_allocator;

  void  push_back(void)
  {
    void* new_memory = m_allocator.allocate( sizeof(T) );
    T* new_object = new(new_memory) T;
  }
};

Allocator Specification
The allocator specification is complicated. While I’m sure there are good reasons for some of the decisions I wanted ours it to be much simpler. So removing the type information (since our allocators work on raw memory and nothing else), removing the rebind(!) and exception handling (which we don’t use) we ended up with the following.

typedef ftl::pair<void*, size_t>  allocated_memory;

class Alloc
{
public:
  allocated_memory   allocate(const size_t alloc_size);
  void               deallocate(void* ptr);
};

And for the basic allocator, that’s it, it doesn’t require anything else to work, but it does have one interesting aspect.

typedef ftl::pair<void*, size_t>  allocated_memory;

As we can have all sorts of allocator types, what it allocates might not be exactly what you asked for. If it can’t allocate all the memory you requested, that’s fine, it simply returns allocated_memory(nullptr, 0) but it can also return more than was requested (for example, fixed sized block allocators will do this). This return type simply allows the allocator to return not only the allocated memory, but also how much was allocated, which allows calling objects to take advantage of this additional memory if possible.

Most of the time this isn’t queried and only what was asked for is given, but it offers an additional level of information which might allow better memory usage in some containers.

So a container will most likely end up with something like the following when adding and removing elements.

// Creating a new object in a container
allocated_memory new_memory = m_allocator.allocate( sizeof(T) );
if (new_memory.first)
  T* new_object = new(new_memory.first) T;

// Losing the object now we’re done with it
old_object->~T();
m_allocator.deallocate(old_object);

This is fine and gives us a very simple entry point for allocators. But by forcing the use of placement new and the destructor call in the container itself, we are limiting what an allocator can do. While the allocators are required to return raw memory, that doesn’t mean that it has to internally. Some allocators might pre-create the objects before returning them so creation is front loaded but the forced placement new could mean we’re over-riding an object that has already been created.

Construction Functions
As a result, we want developers to be able to not only over-ride the memory allocation, but also the object creation. 99% of allocators won’t need to do this so we don’t want to add additional requirements to the allocator so instead we can create non-member, non-friend functions, specialised on the allocator, which will do the creation for us.

template <typename TConstruct, typename TAlloc>
TConstruct* construct(TAlloc& allocator);

template <typename TConstruct, typename TAlloc>
TConstruct* construct(TAlloc& allocator, const TConstruct& obj);

template <typename TConstruct, typename TAlloc>
TConstruct* construct(void* allocated_mem);

template <typename TConstruct, typename TAlloc>
TConstruct* construct(void* allocated_mem, const TConstruct& obj);

template <typename TConstruct, typename TAlloc>
void destroy(TConstruct* ptr);

template <typename TConstruct, typename TAlloc>
void destroy(TConstruct* ptr, TAlloc& allocator);

So our point of allocation/creation now becomes something much simpler and much more powerful.

// Creating a new object in a container
T* new_object = alloc::construct<T>(m_alloc);

// Lose our existing object and return it back to the allocator
alloc::destroy(old_object, m_alloc);

The default version of construct performs the allocation and placement new within the construct function, but should the allocator need something more (or less), simply over-loading the function on the allocator type allows complete control over both memory allocation and object creation. The same goes for the destroy function and the automatic call of the objects destructor.

No Base Allocator
One thing I didn’t add to the allocators was a base allocator interface. The allocators are created within the container, with their type defined at the point of the containers declaration. The addition of a base interface (and the associated virtual functions) would have increase the size over-head of the allocator which is something I wanted to avoid and something I thought didn’t add enough to warrant the overhead. I was less worried about the overhead of calling a virtual function as that would be insignificant compared to the overhead of everything else what was going on.

Conclusion
So by introducing an allocator model that is much simpler (only 2 required functions) with more extensible customisation should an allocator should need it, developers have complete control over all the memory allocation and importantly the object creation itself. Due to it’s initial simplicity, developers have no problem creating new allocators that improve both memory and container use in a project and can start to experiment with better and more efficient allocators quickly.

Title image by Squeezy.  Used with permission.

Having a Continuous Integration server running is one of the most useful and powerful tools a development team can use. Constantly checking the state of the code, building assets which might otherwise take hours and generating stats on build quality are all really useful things to have running in the background hour after hour and day after day.

But if it’s not done with care, a CI process, while still providing some useful information, will stop being an important part of a development teams tool set.

The main problems usually stem from a single CI step taking to long. For example, it might take hours to build all the game assets or it might take 40 minutes to build a single configuration. You might have additional build steps (like copying files to a network drive) which can take quite a while if you’re dealing with gigabytes of data.

As soon as a CI step takes to long, you lose the main benefit – the fast turn around of information.

For example, when we first start a project, our simple CI process will consist of the following steps

• Detect modification
• Build code
• Build game assets
• Copy to network drive
• E-mail developers (who’s mailed depends on success or failure)

This is fine as a new project is tiny and the whole process doesn’t even take 5 minutes. And we need to build the whole thing constantly as we’re adding so much content the artists and designers need to be on the bleeding edge of what the programmers are creating.

But after a month (or probably less) this stops being suitable. A whole build might start taking 20 minutes then 30, an hour and then two hours, and if we leave it as is, the programmers are not getting the benefit of continuous turnaround and the designers spend ages waiting for a new build.

So what can we do about it?

The first thing is to look at what the CI process is doing, and exactly what we want to get out of it.

• Continuous Build – We need the process to constantly compile the source, all configs, all platforms. This is so we can detect any compile errors quickly without having to build everything manually.
• ‘Designer’ Builds – Creating an executable the designers, artists, animators etc. can get with the latest code changes. Ideally one they can request as required and one that is built as quickly as possible.
• Full builds – A complete build of the game including executable and all in-game assets along with anything else needed to run the game.
• QA Builds – QA could use the full build if needed, but this is an additional step which packages the build as it would be submitted allowing a better QA pass (DVD emulation, submission content etc.).

From my point of view, those are the four main things I want to get out of a CI process that having a single build stepl won’t give us. You might have other requirements and I’d certainly be interested in hearing what those are.

So what can we do to try and improve the initial process and still get what we want out of our CI machine?

Continuous Build
The first step is easy. We want a Continuous Build process with nothing to integrate, nothing to deploy and nothing to copy. This can be much quicker if we alter our repository modification checks to only monitor source code folders and not the entire repository.

For example if our repository contains scripts, configuration files or (shudder) game assets and executables we shouldn’t kick off a build if these changes as the CB results won’t be any different from last time.

We might also want to reduce the configs we’re interested in building (usually a debug and master build, the profiling builds might be skipped for speed reasons and due to them rarely being using). If we have a decent machine we might get the individual platforms (X360, PS3) to build in parallel as there will be no conflict between the temp files they generate – or even stick them on separate machines if we have the capacity.

The process only ever needs to notify on failure as no one is going to be using this build, it’s a sanity check pure and simple.

So already we have a much faster turn around time between check-in and ‘all clear’. In the past I’ve managed to reduce this from 60 minutes to 5.

‘Designer’ Builds
Initially it might be tempting to use the results of the ‘Continuous Build’ as the aim of this step is to provide the designers and artists with a new executable to take advatage of any new features (very) recently added.

This might be the right idea at the start, when the CB process is taking less than 5 minutes, but that doesn’t last, so we need a faster, more iterative, process to make sure our non-programmers are not hanging around waiting for the latest builds.

Most of the time, designers will use a ‘release’ build (‘release’ being a bit of a misnomer – it’s not releasable in any way, but it has just enough debug information to make it useful but still run at a ‘releaseable’ frame rate). So we only need to concentrate on a single configuration which means we can drastically cut down the length of time between when a modification is detected and a new usable build is generated.

As this is the fastest CI step we have and can often have the most people dependent on it, it’s the first one to run when a modification is detected.

In our case we don’t e-mail people when a new designer build is enabled. This is being built many times in an hour, and people will just end up sending the mails directly to the trash (I know I’ve done that on particularly spammy CI set ups). Simply allowing them to check the build status and update when it’s green works well enough.

Full builds
Developers generate a lot of content for games. Even small games can balloon in size depending on the scope and quality of the final product. As a result, we need a full integration build for a number of reasons

• It would take every member of the team far to long to rebuild all the assets themselves
• When a build gets out of sync with the assets, developers need a quick way to get everything back on track
• When testing the build it needs to have been built on an independent build machine

A full build could be brute force (just builds everything every time) or smart (it concurrently builds executables and assets on multiple machines). This really depends on how long a full build would take. Less than an hour and I personally stick with a brute force approach but any longer and a more intelligent build step would be needed.

Full builds always e-mail the entire team, since it’s rare they happen. This allows people to get latest as they become available (usually at the start of the day) without having to check the status of the build.

QA Builds
The QA build is a special build. It doesn’t rebuild any assets or executables and is automatically kicked off when the daily build has finished successfully. This step packages the build up as it would be presented as part of a final submission along with any submission assets that would be required.

But why not just use the full build as the QA build to save time?

Simply put when testing a build it’s vital that we test under the same situation that our final submission will be tested under. Making sure we run under DVD emulation and use the same assets the manufacturer will use is an important part of the process. Having our CI machine generate these builds for us makes sure we’re doing this from the very start.

Requesting Builds
In every case we give all members of the development team the ability to request any build. If the ‘Designer Build’ is to far out of sync, they might need a full build to get them back on their feet. An asset change might alter the executable but not trigger a ‘Designer Build’ so a designer might need to trigger one manually.

In our case using CCTray allows us to do this very easily, so a new build can be requested by anyone (including QA) at any point of the day without any input from a programmer, allowing them to concentrate on making the game rather than just enabling others.

Technically anyone in the company could request and get a new build (very useful for getting demo builds together without getting the team involved) but I’ve not seen that happen yet.

What I Haven’t Covered
One major thing I’ve not covered here: self testing builds. This can range from simple unit tests running after every build to a scripted run through of the game after every full integration. The scope of this will very much depend on the size of the game and the time you have available to add them. Since this is a big topic in it’s own right, I’ve left that for another time.

Conclusion
So by simply reviewing what we actually want to get out of the Continuous Integration process we’re able to streamline it down to be much faster and much more useful. Complete integrations still happen (and happen when needed) but the common information needed by the team is generated quickly and allows teams to get short turn-around from the CI machine throughout the day.

I’d be very interested to know what other uses people are getting from their CI processes and how they are still making sure the speed and quick turnaround is happening all the time.

Title image by highgroove.  Used with permission.

But review adoption doesn’t always stick.  I’ve seen the process taken up and then fizzle out on a number of teams usually for the same set of reasons.  The following are some of the reasons why a code review process can fail to take hold within a team.

Never Following Through
This is the biggest moral killer while trying to establish a code review process on a team.  What will generally happen here is that when code is put up for review, the author simply takes no notice of the comments or suggests and checks in the code without modification or without any follow up changes.  When other developers are taking the time to examine code and make positive suggestions they will quickly realise if they are simply being ignored.

And this kind of behaviour is both demoralising and infectious.

If developers see their comments being ignored they will very soon start to wonder why they even bother.  And if other developers don’t have to take the time to act of good suggestions, why should they.  Pretty soon you have one of the two following situations – people don’t even bother posting because nothing will come from it or you have review after review being raised and all of them being left uncommented and open for everyone to see.

Developers need to know they have the time to respond to feedback.  If they feel under pressure to move onto the next thing then they won’t have the desire (or ability) to actually respond to suggestions.  While not always possible, in the long term quality should take priority over speed, and if suggestions improve the code there should be an environment where reacting to these is important.

Reviews should always be classed as ‘finished’ when the feedback has been acknowledged and by tracking the number of open reviews it allows people to see what feedback still needs to be acted upon easily and allows people who are slipping to be picked up sooner rather than later.

Lack of Buy In
This is one of the hardest hurdles to overcome.  When a team simply doesn’t buy-in to the idea of code reviews, it will be difficult to get anything useful out of a review.  People won’t post reviews (often stubbornly refusing) or when they are the reviews will be superficial at best – finding very little of note and eventually killing the process through sheer apathy.

This can often be an attitude that is based on other problems in the team.  I have rarely met a programmer who didn’t want to talk about code, or who didn’t want to offer you a suggestion on how something could be improved or optimised.  The lack of desire to talk about their work, when it’s across the entire team, could be systematic of wider problems in the team.

But if the attitude of the team is generally positive and code reviews are the only sticking point, then it’s going to be less of problem trying to resolve these when trying to introduce a process into the team.

If there is a general malaise towards a process, strong leadership is one of the best ways to get other members of the team interested in a process.  Notice that I didn’t say strong management.  Leadership is a whole different ball game.

You can also start with those who are interested, keeping reviews small but public (they should rarely be private anyway).  As other members of the team see people in animated discussions on how something was implemented, it’s a unique programmer who doesn’t want to get involved at some level.

Unrealistic Expectations
I’ll go on record and say that you will rarely find bugs in code you review, especially if you are reviewing all or most of the code being written.  Or, at least you shouldn’t because your ‘bugs to code written’ ratio shouldn’t be high enough otherwise you have more serious problems.  But when a team is new to code reviews they can often have an expectation that issues will be found and they will be found often.  Which can cause a team to question what they are getting out of reviewing everything that’s being written.

But I’ll also go on record and say that code reviews can prevent bugs.

Code reviews benefit teams in the long term more than they do in the short term.  You might not be finding bugs on all your reviews but over time, if people are talking about code and sharing their experience, your team on the whole will become better programmers.  They’ll think that little bit longer before committing code if their peers are going to be looking at it, and they’ll have their bad habits smoothed out review after review.

And all this will lead to less bugs being added to the code base – but this is one of the hardest things to grasp when a team starts out and is looking for short term gain.

Peer Fear
This can manifest in a number of ways.

The first is through a fear of criticism where a developer is simply fearful of the criticism they will receive when putting their code up for review.  Unfortunately this isn’t always in the hands of the poster.  If a team has even one aggressive reviewer, this can effect the entire process, with people hesitant or even refusing to post their code, and when one reviewer starts to control the process, the ability to share knowledge decreases drastically.

The other side of the coin is where developers are worried about disagreeing with each other.  Comments on reviews are not always correct and not always the best course of action.  But if the team has developed a routine of automatically acting on suggestions (either from a subset of developers or all of them) then in effect any productive discussion is squashed and if people are afraid to say no, the code base isn’t always going to go in a good direction.

When this happens, the process can quickly lose steam.  If reviews cannot start a worthwhile discussion then the worth of reviews will decrease drastically.  If people see the code base is not improving (or even worse, degrading) they will not continue to post up reviews and the process will simply die out.

This is usually a management issue.  Domineering peers will destroy any process, but this can usually be resolved by taking that peer to one side, discussing the reasons behind the process and explaining how they can still be part of it while not taking over the discussion.  For those times where one developer is lacking the confidence to disagree, then it will often fall to other developers or the team lead to do the disagreeing for them, at least from the start.  As they start to see that disagreeing isn’t a negative trait in a review, they will start to feel more comfortable in reviews and discussions will start to flow.

Solutions?
Everyone likes a quick fix solution, but as with anything worth doing, it’s not always easy to solve these problems, especially one as difficult as a lack of buy in into a new process.  But I’ve generally found that most problems, like many team issues, are beaten by strong leadership and by being open about why the process is being introduced and how, in the long term, the developers lives will improve as a direct result of being part of it.

But to be honest, if you’re trying to solve these problems and you don’t buy into it yourself, then you’re onto a losing streak either way.  If you don’t believe in the process, then chances are you’re not to worried if it falls by the way side.  Which is fair enough.  Code reviews are not a mandatory part of software development and if the literature on the benefits of code reviews doesn’t persuade you, then nothing will.

Though I’d recommend you read them all again.