October 14, 2009

Module : Applied Game Development Personal Reflection

Posted in Development Report - Applied Game Development at 17:07 by markcampbellprogrammer

Introduction

The purpose of this document is to reflect over my own personal experience and development through this module. It is a summary of week by week events taking place within my group and how those events affected the outcome of our project. I shall be providing my own interpretation and using social dynamic models and theories to provide an analysis of my involvement, and consider what I have learned in preparation for my future career.

The Project

The project I shall be working on is to produce an exciting racing game as part of a team of programmers and artists for my applied game development module. We are to produce an exciting racing game based on a list of requirements to present to an established games company at the end of the semester. Each team must delegate roles to be taken and tasks related to that role to be completed week by week. These roles require individual contribution and responsibility, as well as group development through weekly meetings and scheduled development sessions.

The Roles

As our team consists of 5 programmers and 4 artists, we are required to split out the roles necessary for the project to work. The programming roles included

• Project Manager – General manager responsible for the entire development
• Design – Responsible for the design of the game in general
• Bug Fixing – Fixes problems and bugs in code
• Tools Programming – Develops or uses tools to aid in development
• Maintenance Programming – General programmer covering most areas

These were the first suggestions as possible roles for our team and we initially decided to uses these as guidelines for the roles we would take.

My Role

Initially during the first group meeting, I decided to take on the project manager role as I have previous relevant experience in motivating people and being responsible for the development of team based projects. However after consideration I decided I would prefer to be involved with the programming side of the project as I felt working in a team based programming setup would improve my skills and knowledge. I also felt that not taking on a role I would have perhaps have been more comfortable in would be more of a challenge and thus motivate me to succeed. It was agreed that I would take up the design role temporarily, and that throughout the project I would do as much programming as possible.

My role as part of a team

After taking Meredith Belbin’s self perception test (see appendix) I identified my suggested role as being a “Plant”.  This representation I feel is an accurate description of my general attitude and involvement in teams. However I feel that the “Shaper” description also applies to me. I think the Shaper role is a reflectance of my desire to attain new challenges during this project. Taken from – Belbin, Management Teams, 1981

1. Plant – “A creative, imaginative, unorthodox team-member who solves difficult problems. Although they sometimes situate themselves far from the other team members, they always come back to present their ‘brilliant’ idea.”
2. Shaper – “A dynamic team-member who loves a challenge and thrives on pressure. This member possesses the drive and courage required to overcome obstacles.”

Although there are flaws in the Belbin model used to describe roles in a team, I feel that for me personally these team roles are accurate explanations of how I am perceived and function within a team.

Before coming into this project I had previous experience of working in part of a team and was fully aware of how important attributes such as good communication, honest participation and the ability to listen to others are in the development process. However I was open to taking new approaches to this particular project and suggested to the group methods for team building which I had previously not used. In relation to team building, we decided to hold weekly meetings which were used as a method for team building. This would include –

Instructions – This involves introducing the team to the instructions for the weekly exercises.

Activity – This is the exercise itself. This is when the team utilizes the instructions and begins to participate in the actual activity.

Debriefing – A debriefing is important to reiterate the purpose of the exercise and to keep the team focused on the positive outcomes from the exercise.

Each week we would get together and assess the current state of our project and what we needed to do to make it progress. During each meeting we discuss and document current concerns and delegate tasks to each member to complete each week. During these meetings I often felt that my participation was well received but also was willing to take on board other team member’s contributions to the project and trusted my project manager in terms of decisions he made about the development of the project.

As being identified as taking the initial design role, my creative elements including my unique ideas could be expressed and utilized. However the fact that I was motivated to do more programming and challenge myself to improve technically allowed me the freedom to be more involved in the project from a coding perspective. This allowed me to work to all my strengths and thus my personal strengths were utilized by the team.

Conflicts

 The Thomas and Kilman model 1976 describes five basic ways of addressing conflict as described below –

•  Accommodation – Surrender one’s own needs and wishes to accommodate the other party.
• Avoidance – Avoid or postpone conflict by ignoring it, changing the subject, etc. Avoidance can be useful as a temporary measure to buy time or as an expedient means of dealing with very minor, non-recurring conflicts. In more severe cases, conflict avoidance can involve severing a relationship or leaving a group.
• Collaboration – Work together to find a mutually beneficial solution. While the Thomas Kilman grid views collaboration as the only win-win solution to conflict, collaboration can also be time-intensive and inappropriate when there is not enough trust, respect or communication among participants for collaboration to occur.
• Compromise – Find a middle ground in which each party is partially satisfied.
• Competition – Assert one’s viewpoint at the potential expense of another. It can be useful when achieving one’s objectives outweighs one’s concern for the relationship. 

The fact that there was very little conflict in our group meant that there was often no need to address this model. Our group mostly worked through any problems that occurred and due to the nature of individuals in the group meant that we was able to simple talk our way through problems. The strength of having our weekly meetings meant that we had chance to talk about any problems we were having individually or had encountered through development. Being in a group environment gave everyone the opportunity to talk in confidence and without having to worry about direct confrontation. I feel that the other members from my team often expressed their concerns during these meetings and any slight concerns were always resolved. I honestly can’t recall a serious conflict between members. I can recall different opinions and conflict of idea’s but never a serious conflict of almost any kind.

How conflict was avoided

The top reasons for how I think conflicts were avoided in our group were –

• Mixture of personalities – The group identified from an early stage each other’s technical and personal strengths and as a team worked with them. Technically and team-based. It was healthy for the group to have a mixture of different people who shared a common goal.
• Egoless approach – As a group we left ego’s at home and unconditionally agreed that the outcome of decisions was not a personal reflection of an individual.
• Common rules structure – We agreed to work a set amount of hours a week and everyone adhered to it.  We also agreed to attend meetings and complete tasks for specific set dates.
• Common goal – As a team we are working to a common goal and intend to meet it as a collective group.

Permalink Leave a Comment

Module : Applied Game Development Dev Diary Part 3

Posted in Development Report - Applied Game Development at 17:03 by markcampbellprogrammer

Week 8 – Alpha Deadline is coming!

For the upcoming week, everyone is focused on working towards the Alpha deadline set for the end of this week. This means that everything done up until this point will be what the project is graded as no new features can be included after this deadline.

The plan seems to be to get as many features in the game prior to this deadline and then “polish” them up for the final hand in. As mentioned in the previous week, as a team we had slowed down last week and production had been slow and so this week we had some catching up to do. I was feeling like the next weeks contribution would determine the outcome of the overall project as the toughest task would be to pull ourselves back up to the standard of which we was working at a few weeks ago.

We had a progress review earlier in the week and had explained our plans and current state of development to out manager. During the meeting we all expressed our desire to be “the best” group and to push our project as far as we can. As cliché as it sounds it worked and we all hammered as much code and features as we could. I used an external audio program called FMOD to implement sound streams allowing sound effects and music to included giving our game more feel. This was done using an online tutorial and modifying it slightly to work with our files. Then in the main .cpp file I simply create an instance of the sound manager and call “instance” which creates opens a new stream. A state system was implemented a long with a HUD interface by the other programmers and collision seems to be coming along well. It is important for us to keep adding as much in as possible at this stage so that when we come to the Alpha deadline we have as many features added as we can. This allows us to polish the weaker ones up before the final hand in and thus include more features.

I am slightly worried about the weapons system as I have been working on it for a while and am still having the problem or creating new instances during run time using the same mesh. After looking at the NiClone function which allows the cloning of an object and its behaviours (I hope) I may be able to just pass a pointer to a newly loaded mesh and then pass that to the instance of on object. If this doesn’t work then I’m going to have to ask for help from our lead programmer and discuss it with project management as I have spent a lot of time trying to get this system working.

If the methods I have been using are actually working then it may be a simple mistake or some small error however, if it isn’t then it might be better to try re- writing the system again. This could be a huge task if there is a fundamental flaw with the system itself.

 Week 9 – Alpha deadline hand in

With the alpha deadline due this week, the group was working as quickly as possible to get everything as close to working as possible. The key to getting everything handed in was to just leave broken features and cram as many features in as possible. The broken features can be bug fixed later on and polish added to the features finished. We decided to delegate tasks in our group meeting based on the outstanding requirements and each work as quickly as possible to get as many ticked off for hand in.

My task was to split the generic ship class into team based classes each with their own individual statistics. This meant loading in a different model for each team and to setting the teams own individual values for velocity, max speed, max fuel, fuel consumption and boost speed.

This was simple enough as it was just a case of creating a header and class file for each team and using the variables stored in the main ship class. Each separate team uses the main ship as a base class and gets passed the parameters to load a model and add its own collision group. Then in the constructor for each team, each attribute is set. These attributes affect how each ship handles in the game which is one of the requirements. I also tinkered with the sound manager and changed some of the music tracks that play in different game modes.

I had finished all of my work with around an hour to spare before submitting to our source control checking station when some strange errors started occurring when trying to submit my changes. This resulted in me being “locked out” and not being able to integrate my work with the groups. Other members of my team also had a similar difficulties and this resulted in a massive problem when merging our work together.

After eventually getting all our work merged, we found massive bugs based around the changes I had made due to me deleting the main ship class’s variables which resulted in our project being handed in past the due time. It was a difficult day as everything went as wrong as it could have and we all by our own admittance had under-estimated how long it would take to merge all our code together.     

Week 10 – Back after Easter

Since coming back after Easter we were able to look at the project for the first time in a few weeks and consider what else we could do before hand in. This week I wrote up the testing document but was slightly unsure about the best way to do it as initially I thought that the best way to lay it out would be how what the tester finds reflects how the game meets the requirements. After thinking about this it may be better to re-design the document to be more user – friendly to testing the game in terms of its functionality.  Code wise not much was done this week except the logging of bugs and making sure we all worked off the same versions from now on i.e. no individual private builds. This means lock down on implementing new features and working to improve and maintain the ones we currently have.

It seems that there is no possible way to fix my weapons class. Although it did initially work it has some serious bugs relating to memory leaks and a huge frame – rate decrease nearly to a point that it was unplayable. I am slightly disappointed because I spend so long and got so close to having it working but in the end it can’t be fixed in such a small amount of time left before final hand in. I don’t take this as any personal reflection on my part as it’s for the benefit of the team and I know that the method in which I approached it would have been correct if I understood more about Gamebryo memory allocation and why it doesn’t like creating new instances of cloned meshes.

As the final deadline closes in I’m happy with the experience I have had working with these particular individuals and feel that my programming approach has changed drastically over these 10 weeks. It’s now a case of major bug fixing and keeping everything locked down.

Week 11

The only day spent on development was the Thursday all night session in which we all went into University and spent the night crunching away. At this point we seem in a really good position and have been fixing some minor bugs and all catching up on documentation. One bug I found was with the sound manager I implemented was that it would only play certain bit rate mp3s and so I had to tinker with a few of the files. I also tried to write up as much of the design document as I could before helping other members in pair programming.

The week before hand in consisted of all of us doing “all nighters” and making the last push before hand in next week. I have been happy with both my team and contribution to the project and feel that by next week we will have a great game to hand in and present.  The dynamics of the team individually worked really well together as we all contributed something equally in terms of effort and commitment. In reflection it has been fun working on such a project in which all our skills have been collectively recognised and implemented. I feel like we are in a strong position for the final hand in and still remain focused for next week.

The Final Week/Evaluation

For week 12 I think we have mostly completed our project and are now making the final adjustments to what we have at this moment. I am truly proud of what we have accomplished in such a small amount of time with limited resources and ever changing constraints. Our game is almost complete and will serve as a great example of what can be accomplished by having a great mix of people and the desire to reach a common goal. I think I have contributed to the project as much as every other member and would say the same about them as well. The art team have been fantastic, especially the lead artist as he has attended all meetings and constantly motivated his team to produce assets of high quality as well as offering input and opinions on aspects of design and the development of the game from its early stages. The team of programmers I have worked with have helped me technically develop which has improved my confidence in my own ability which was not as high as it was before this project. I have also re-enforced my previous approach to team based situations and feel that when I move into full time employment either for my placement or when I graduate I can take this experience and apply the same outlook and attitude to my job.

Permalink Leave a Comment

Module : Applied Game Development Dev Diary Part 2

Posted in Development Report - Applied Game Development at 16:57 by markcampbellprogrammer

Week 5 – Weapon Development part 2

Development was slower this week as we hit a few problems in particular with my weapon base class. One of the methods that were implemented early in development used a function to detach a weapon node. This then attached the weapon model back to the scene graph which meant I could then apply calculations on the weapon in terms of working out direction, speed, velocity etc. However when the weapon detached, it reset itself in the middle of the scene and resized itself to a huge size. This was the first problem as it was because when resetting, the model had been scaled back to its original size that it was defined in when the artist had been working on it. We eventually managed to rescale it back and leave it detached in the scene graph.

The next problem was that I need to gain access to a private variable in a class we had used from an example in Gamebryo. I had the choice of either making access to this public (however that means breaking encapsulation) or using a get and set method (another one I’m personally not that keen on using). After consideration and discussion with my lead programmer it was decided that I use a get and set method and store the private variable in a new one that I can access publically as a member variable. This worked fine and now I just need to set the direction and speed etc for each type of missile then the weapons base is completed.

We have decided that we can have a demo nearly completed by the end of week six and so are currently working towards that at the moment as we will be having a visit from Frontier games on Wednesday and would like them to be able to play a nearly completed game mode.

The team continue to work well together however some of the art team members are not seen as often as other members. This is obviously a problem that affects the whole project as it leaves our lead artist a lot more work to do. We are still waiting for a track however at the minute it is more important to sort out the problem of the artists who have contributed very little so far. This is more of a project manager responsibility but it affects all of us and should be raised so that everyone is aware.

Our team of programmers seem to have very little issues with each other which I think is down to the fact we all know what we are doing and usually how to do it. If not we just ask each other for help and try to explain methods and techniques in detail.    

We are due to have a scheduled progress review this week and will be pitching to a potential publisher with just a single power point slide. It will be difficult enough to pitch without having our game with us to show off and must instead rely on simply discussing key elements of our final product. Because we are not able to properly predict how much we will have by the time we finish, it is difficult to give an exact list of features that will be included. It would be better to have more features included by the end than promising more and not getting them in by the end.  

Week 6 – Crunch Time

Coming into this week we all thought that the project was going well and the group were looking forward to getting some feedback from Frontier in the coming week. We had pitched earlier this week to the potential publisher and had some feedback about the overall design of the project. This was noted and shall be implemented in a later edition of the design document.

The scheduled meeting with Frontier was cancelled and instead our work was assessed by another company who offered some advice in terms of how to manage the paper work and coding profession of the project. This is an important area and one that is often over looked as the team spends of its time coding and planning. The game is finally starting to take shape and with the alpha deadline coming up soon we all have to put extra time in. This particular project is taking priority over all others at the minute and the danger and fear of falling behind on others is always there. It can be frustrating knowing this but at the moment there is no other way around it.

After a change in the requirements section of for our game we realised we have a lot of work to do.  Our project manager had expressed his ambition to implement the Crazy Eddie GUI system that I looked at in the first week however I suggested we finished the main tasks of requirements first as they are more important at this time. I have continued with the weapons class for which I hope will be the last week as I have been cleaning it up most of this week. After getting the projectile working, I realised that the model may not have been deleting properly and was probably responsible for the memory leaks we have had and so decided to look at methods of storage to use for my missiles. Below is a list of methods I came up with –

• Vector list – This was my original thought to include a std Vector container to store each missile and then use an iterator to pick each object and deal with them separately.
• Map – Maps are sorted associative containers that contain unique key/value pairs.
• Array – Simple array system that moves along each frame until the object is off screen. Then simply destroy the model and move along back to the start of the array.

I have been experimenting with these methods today and will continue to throughout the week. My next job is to look through the picking demo and use a ray to check for collision between objects in a scene. I may instead set up a frustum for each ship and simply implement an “if seen kill” method for each ship. This may work out to be more efficient than sending multiple rays out in to the scene. This next week and probably the next one will be key development periods as we head towards the end milestone. It is important to stay focused during this time and complete tasks quickly and efficiently.   

Week 7 – Memory Leaks and slow down

The pace we had set earlier on in the project had almost grinded to a stop this week due to a combination of events and irritating bugs that had popped up during this week’s development. At the start of the week a number of us had been for interviews at Nottingham’s Monumental game studio and so had missed the main day for development. During the rest of the week we found various memory leaks and other little problems with meshes and pointers not being deleted properly. This lead to an agonising performance issue which almost made the game unplayable and also meant that the game didn’t exit properly. We are still currently looking at these issues and the best possible way to reduce them however I think I may be guilty of not deleting some meshes for my missile system.

As well as the fact that the time flies at an astronomical rate at University anyway, the additional Alpha deadline is starting to crawl up everyone’s back and a lot of other teams outside team ++ seem to be hitting rifts. I think our team is affected just as much however we deal with it a lot better. It’s vital at this point that we keep all levels of professionalism and make sure no ego issues creep in during this period as some design, art and even code features will be cut.

I have been thinking a lot recently about how the design is being shaped and what it is I’m learning from this project. I guess the most obvious is to be able to adapt to all roles involved such as design, programming and even certain art aspects. I am happy with the amount of coding I get to do at the minute as it helps me improve and give my confidence a lift. Design wise I have decided that I will evaluate that close towards the end of the project after Alpha.

The slow down this week has knocked us back a bit but I think we will more than make up for it in the following weeks as we are all working to the same goal.

Permalink Leave a Comment

Module : Applied Game Development Dev Diary Part 1

Posted in Development Report - Applied Game Development at 16:56 by markcampbellprogrammer

Week 1 – A new start

The first week in our new semester and the module I have been looking forward to the most. I have been assigned my team, which I have to say am very pleased based on the fact that I know we will get on well together professionally and share a similar view on the approach to making games. We decided quickly on a name and what sort of role we each will be playing in the development of Scorched Wings. As a group we decided on when we would spend time developing each week as well as organising meetings and how we will tackle issues and concerns.

We decided on specific days for development and meetings, as well as a policy for how much time we would spend a week each. We have tried to cover as many issues in terms of design in designated meeting slots, allowing the rest of the time we have left spent on development. 

I spent this week working through the tutorials provided with Gamebryo itself and worked towards producing the first spike demo. Eventually between combinations of all our efforts we managed to meet the first requirements being to have a controlled vehicle on screen. I then decided to branch off and continue researching and looking at code. I found an online document providing a simple framework for a game application using Gamebryo. I printed the document and spend 3 hours working through the code and trying to get a menu system set up. The document makes use of an additional art system called “Crazy Eddie’s GUI system”. This was written by one of Emergent’s support staff and is integrated to work with Gamebryo. It provides additional classes for buttons and list boxes etc and is described as being better than the NiUI* classes. After reading through the document I noticed some similarities between working on other development platforms such as XNA and its update and draw methods particularly, and also from some state based AI programming that I looked at in my Game Development Techniques model from last semester. If we are granted permission to use the Crazy Eddie GUI system then I have agreed with the other members in my team that I will start trying to get a User Interface system up and running in the next few weeks. This has been included in our current schedule and will be an important feature to get working as soon as possible.

The basic layout I am starting to work towards with the help of the tutorial is –

• StartupSplash – Display a static full-screen image showing the game title and information that the game is loading.
• StartNewGame – Display a box containing a level selection, which at the minute will be just one.
• MainGamePlay – load the selected level and player’s ship.
• GamePaused – Display a window UI of a section of the screen labelled “Resume”

Away from programming, I wrote up a proposed design document and specification for our current game template. I proposed ideas on actual game design and mechanics to my group which were met with approval and as the week developed I felt that I was contributing a significant amount as to how the game design will be done. I also made use of good contacts I have in audio production by finding an audio engineer willing to produce audio tracks and any voice acting needed as soon as we send him a proposed design document.  

What next?

• We are due to meet the artist team soon and so a formal introduction and role assignment will be done in our next session.
• The custom GUI system will need to be discussed with my manager and whether or not we can use it. If not I will have to speak to my lead programmer about another part of the game I can work on.
• Get a hold of the book “Large-Scale Stack-Based Machines, “Game Programming gems 5 by James Boer.
• Set up a weekly video blog.

 Week 2 – Project progression………..Kind of

After the first meeting with my manager the proposed idea got the green light and we began setting to work. One of the first decisions I made was to give up the role as project manager which I had been allocated in the first week. After thinking long and hard about it I thought it better that somebody else with less experience would be better suited. Personally I have been in a position of responsibility before and although I am confident I would do a good job, I would prefer to work on my technical and design skills. I am happier in this position because it allows me to work closely with other programmers in my team which will help me improve individually and allow me to gain experience working in a team of programmers. After discussions with my lead programmer and manager we decided as a group it was more important at the moment to work on game play elements instead of trying to get a GUI system working. The GUI system will be needed later on but for now I decided to work with 2 other programs writing basic game classes. I started working on a weapons base class, whilst the respected programmers started working on a ship and game object class. I used the Gamebryo Metal Wars examples as a starting point to get a header file written and began discussing with the other programmers shared variables and methods from their classes.

Unfortunately that’s where my coding ended this week as the UK was hit with snow for the next few days which resulted in my being unable to get to university. I will have to continue with my weapon base class and work with the other guys to get more of the game complete. I instead looked at the design document I had written for the previous week and modified it slightly to studio standards. This will serve as the base for any written information about the game and its development from now on. We met our art team who seemed very keen on our idea and suggested more ideas which was a relief as we now are Woking with people on a similar wavelength.

Finally I got in contact with an audio production group who happen to be personal friends of mine and got a full written contract for them to produce audio and sound for our game. This will have to be doubled checked with my manager to make sure we can outsource additional files.

Week 3 – Solid Progression

This week as a group we have made a solid progression in terms of development. The actual development is ever changing with each group member contributing in equal measures. I paired up with another team member as it was important for the sake of the project to get the main ship class completely finished for this week as it would affect future development in all areas of the game. I implemented a simple boosting mechanism which was simply mapped to a trigger on the Xbox 360 pad allowing the player to accelerate. This still requires some modification, mainly to the values being passed into the function. At the moment the player seems to accelerate and then stop dead. Instead it would be better if the player slowed down to a gradual stop and would make the game seem more realistic. The ship also has a levitation mechanism implemented based on a sine wave function which shows the ship appearing to levitate. This enhances the game play experience because it gives the feel that the ship is in fact airborne.

Now these ship elements have been incorporated I can push on with the weapon mechanics. For this I have been researching polymorphism and how I can use my weapon base class. Using my weapon base class as an abstract base class I can instigate specific weapons from it without having to create an object of type weapon base. The fact that weapon base is such a generic class means I will never need to create instances of it directly and so using it to create an instance of say, missile and call a member function to set specific properties for it. I am still learning about polymorphism and will try to fully understand it through developing the weapon system.

Our lead programmer issued a copy of coding standards that are to be used throughout the project which means I will have to code to a certain standard using a specific style. This is good practice because I imagine that when I go to a placement company I will have to adhere to their standards and so using this as good practice now will surely benefit me in the future.  I feel that as a team we are working very well together as there is never any need for arguments because we simply communicate honestly and professionally. If we are not happy about a certain aspect of development we talk to each other about it in meetings and all try to appreciate the point raised. We trust each other to get work completed and everyone is always there to offer help and advice. So far so good!

Week 4 – Weapons 😉

Again this was another good week for development with most proposed tasks going to plan. I put some solid time in to the weapons manager and got some decent results. I created as many functions and member variables as I could think of, then I started coding away. Communication between me and the other coders from neighbour classes has been good and we are regularly in contact discussion each other’s code. I can honestly see the end in sight as we work towards our first big mile stone in which we hope to have a fully playable time trial mode implemented.  We now have –

• A custom loaded model into a scene graph;
• A fully controlled model via a Xbox 360 pad;
• A separate camera;
• A boosting mechanism for the ship;
• Collision detection;
• A way point system;
• A weapon system;
• A timer function;
• Text being outputted to the screen;

The time I spend last week looking at polymorphism gave me some ideas about how to tackle issues with my weapon system but I found that simply writing everything down on paper associated with what I wanted to achieve was very useful as I then had a more clear idea of what it was I was trying to achieve.

Considering that we have been working on this project for just 4 weeks as well as having to dedicate time to other modules, I feel our progression has been good.  The artists should have a track ready for the following week which means that when we have this then loaded in we will have a basic time trials mode completed.

From a design point of view I have decided not to change anything as myself and the team are working hard to get our code working as quickly as possible. Later on in the project we may decide to change the design elements but for now we are happy with the basic idea we had at the start of the project.   

We also received some audio tracks from my friend’s production group and have had a good listen to them. We offered the group a number of influences for the type of sound we wanted and the specific genre and so far they seem to have done a fantastic job. The tracks are loud and fast paced with a real futuristic feel to them. They suit our game perfectly and will almost certainly be included in the final version of our game.

Finally, we tried pair programming this week as well and I particularly found this to be a good method for learning how other people code. This helps improve your own perception of how tasks should be tackled and also offered a fresh pair of eyes which is useful when debugging at 8pm at night!

Permalink Leave a Comment