Week 9 Development Diary – Crunch time

This week we had an Alpha milestone to strive for. By the end of the week, Friday, we hoped to have all of the features on the list implemented into the game in some form or another. Unfortunately as we should have expected this did not happen as well as expected. During the week I had an interview at a games company in Newcastle, which meant that I had a day less contribution to the project. Luckily my part was only really accessed and changed by myself and since it had been a good week previously there was not much trouble caused by this. On the other hand another one of my team mates had an interview on the same day as me and his work was at a crucial stage and needed to be completed as soon as possible. This caused quite a few problems and lots of panicking from the rest of the group which cause the whole week to slide a day behind schedule. This close to the Alpha Milestone it was not a good thing to happen.

At the start of the week my task was still on collision and getting it at a reasonable frame rate. After trying most of Wednesday with Joe to get a reasonable thing working we had no luck still. I told the project manager I should really work on something else since it was getting close to the milestone and this was not a crucial part of the project that i was working on at the time. He agreed with me and I started working on the menu system all Friday before the deadline. 3 people in the group were working in 3 different menu’s. I was the first to complete my menu and another member of the group was struggling with his and was stressing out since today was the deadline. I took the work off of his hands since i had already completed a menu and i though i would be able to complete another one without any troubles. I got this menu done in no time and everything was looking promising.

An hour before the deadline we decided that we needed now to merge the versions we had been working on so that we had something in by the deadline that reflected our current position. Little did we know that our source control method, SVN, was not on our side today and with half an hour to go we still hadn’t merged anything since one member of the team was having large issues with SVN. After 2 merges between 2 different versions time had already ran out and we now had 5 minutes to go. The project manager was adamant to get all the features we had been working on today into the alpha milestone so we carried on merging. When it came to my turn to merge my menu’s I got the latest version and found that the merges before had conflicted slightly and we lost some features. In a hurry i merged my work but due to the hurried nature of the whole process all the work i had done for the day became broken in the merging process. I got it running slightly fine but by that time it was past 5pm which was the deadline and we were late. After sending my version off to the last merger it took another 30 minutes to get the Alpha version uploaded and sent off.

Overall this day has been one the most stressful days encountered in my University time and would wish not to have another day like this. In the end our Alpha version had all the functionality that it had before Friday an non extra, which was a huge disappointment as it all got lost in merging and we all worked our hearts out that day.

The team is still working stongly together but i think this week a bad call by all of us let down the team and our Alpha Milestone was handed in late.

Week 7 Development Diary

This week in the team project i have been working on collision still, with the not so good luck last week in getting the world collisions to work i have still been focusing on getting them to work. As i said last week i feel that the problem has something to do with the mesh since everything that i am doing seems to be right and with the documentation.

After playing around with the 3dsMax file I could see no way of adding collision to the mesh other than bounding boxes all the way around the mesh, I thought though that this would be very time consuming. So after finding nothing in the mesh that was editable I looked towards exporting from 3dsmax to .nif which is the gamebryo mesh format. There were some special extracting properties that could be set and after trying a few different versions of them I found a profile that saved the mesh in a way that could be used for triangle collision. Great success!

After making the exportation discovery I exported the mesh with this new setting and loaded it into my collision code. It worked very well and was perfect, the only problem was the frame rate. After playing around with the new collision I discovered that when you fly away from the mesh its self the frame rate jumps up dramatically as it no longer has any point in calculating the collision since the ship and the world are too far apart. With this discovery I asked the lead artist, Joe, to find a way to split the level up into separate Mesh’s but within the same .Nif file. After many different versions of the level have been given to me none of them yet worked. This concluded this weeks exploration into Collision in Gamebryo, I made a lot of progress at the start of the week with my discovery about the Mesh’s but have yet to find the best way to make it work at playable frame rates.

This week the team has still been working very well together and we are all pleased with the progress. I have personally been working closely with Joe the lead Artists, we are begining to understand each other a lot better and i enjoy working closely with an artist to get his perspective on the group and programming in general.

Design Patterns

Design patterns are a set proven standards for producing high quality and well designed code. A Design pattern is not Code, its not an Algorithm and its not a Data Structure. What a pattern is is a description of a problem and a set of rules that describe a solution to that problem. In 1995, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides attempted to document a series of tried-and-true object-oriented approaches in “Design Patterns – Elements of Reusable Object-Oriented Software”. This book has become a classic for software Development.

A Pattern has four elements in general:

• The patterns name which gives it a unique identity,
• The Problem at hand,
• The Solution the the problem described in abstract terms,
• The Consequences of the solution and what to look out for.

Design patterns in Object Orientated Software development are usually split up into 3 different categories:

• Creational – Patterns to outline rules when creating class instances
• Structural –  Patterns to outline rules for the structure of classes and objects and the relationships between them.
• Behavioural – Patterns related to the communication between classes and objects

There are many different Design patterns and I am currently looking into these patterns a lot more on behalf of our team. I will post my findings up in the form of a .doc file when I complete this.

Week 6 Development Diary

This week while working in my AGD team I have been working on Collision again. This time I had to find a way of getting collision with the world to work. The way that i wanted this to work to start with was just with basic triangle to triangle collision to make sure that it works, and if it did work without causing much slow down then it would be used in the final. Unfortunatly i came up with many problems on the way while trying to get this to work.

Collision in Gamebryo is done using Collision Groups which you have to add Mesh’s to this collision group to get the collision to work. The problem that i was having was that while trying to add this mesh to the group it would not allow it and was throwing up and error all of the time. After plenty of searching around i have come to the conclusion that it should be working and the only thing i can think of the would be causing such a problem is the mesh it’s self. Next week I will try and get it working as soon as possible.

Everything in the group is going very well and i feel that we are making a great deal of progress and we are working very well in a team. No arguments have yet been heard between members of the group since we all do the work asked of us and every puts all the effort possible into making it work well.

Week 5 – Development Methodologies

No Methodology

There are many different development mothodologies, but the most basic of them all is having No Methodology, which is kind of a methodology in its self. No methodology means that there is no control over the project and if you are not using any methodology at all the end product usualy suffers for it. With no methodology programmers are just writing code and throwing it into the project usualy creating lots and lots of bugs and relying heavily on the debugger and can also be known as “Cowboy Coding” or “Code and Fix”. This is fine in small projects of less than 3 – 4 people but in larger groups it does not work at all and if no methodology is used in a large project it will be lucky to see the light of day on schedule!

Waterfall Methodologies

In the waterfall Methodologies, Development is done in separate, clearly-defined stages:

1. Determine the requirements
2. Design the architecture
3. Develop the code
4. Test the software
5. Deploy the software
6. Maintain the software

In this methodology each section above is done after the step above it has been completed, so for example designing the architecture before determining the requirements can not be done since it is further down the list. This is the reason it is called ‘Waterfall’  since each step is done one after the other just like water falling from top to bottom. This method is also called ‘Big Design Up Front’ (BDUF) since all the design is done at the start of the project and can not be altered when development has begun.  This method is usually preferred by the less IT capable managers since it is the easiest to keep track of and it resembles projects in the real world like building bridges and other physical buildings, but unfortunately it does not work for software development and especially not for games development since the design is best to be always changing and you should be testing the code as you go along while developing the code.

One of the core reasons that waterfall fails is because it takes to long to run a project like this with rigid set tasks and you can not possibly see all of the troubles that will be ahead. If the design has a fundamental flaw in it such that the coders could not implement in then the design can’t change at that point and the coders are left struggling to implement a part of the project which is seemingly impossible. Games Development is an iterative process so this methodology is one of the worst available for games development and should be avoided, but the main problem is that it is appealing to publishers that have not worked with games before and therefore it can be used quite a lot today still.

Rapid Application Development

This was methodology was developed in response to the downfalls of the waterfall methodology. This methodology usually consists of a small team of developers no more than 6 which use rapid development software, this used to be programs such as Visual C++ and Visual Basic but would now be game development tools such as XNA. This method usually incorporates Timeboxing which is a method to ensure things get done on time, Timeboxing means that a feature has a fixed time slot in which to be implemented, if this time runs out then the feature is canned or re-evaluated if the feature is key to the success of the game. This method is more iterative also as it uses mini waterfalls for each feature, so each feature goes through a waterfall methodology before being implemented.

This method is usually tied into prototyping of games as it is quick and rapid. The downside to this method is that it will more than likely have less features in the end product due to some of them being killed and also this prototype could be used to be taken into full scale development which would end up being a ‘Big Ball of Mud’, this means that all of the code has just been piled anywhere and its not very readable or scalable.

Iterative Development

Iterative development is much more suited to game development, in Iterative Development each feature is incrementally improved over time. You start of with nothing and first create an Alpha build which has all features but may be rough and buggy. There should then be incremental milestones before release which shows incrementally better features. This method also allows for redesign and as part of the plan allows for redevelopment of features.

Agile Development

• Short timescales based around features, rather than the product as a whole (a few weeks each)
• Fast, repeated iteration
• Close, ongoing interaction with users and/or project stakeholders
• Emphasis on mechanisms and attitudes that embrace ongoing change
• A focus on adaptability rather than predictability
• A minimum of documentation; a maximum of working code.

This is the best methodology available for Game Development, it is very flexible and works perfectly alongside developing games. The only downfall with this is that it is hard to convince publishers to use this method as there are no hard deadlines and it can be difficult to see what is happening and when.

Development Diary – Week 5 Team Progress

This week we got our main level model from the artists! The game is now starting to look a lot more like we wanted it to. The map we have now is a canyon based map which was the map that we asked the artists to complete first as we felt that it looked the best out of their concept art which we were given. ( I will upload the pictures when I personally get them).

This week programming wise my task was to refine the waypoints so that you can collide with the outer ring and yet fly through the center of them without colliding. Also I had to position the rings in the new level that we got. As I was again working with collision and trying to refine the collision Ihad to work very closely with Joe, the lead Artist. Joe thought that he could just take a copy of his mesh and change its name to NDLCD and it would create a perfect collision mesh. This was not the case of course and after looking around in the Gamebryo documentation for quite a while and playing around in 3dsMax ( Which is not my strong point ) i managed to find out how to create multiple bounding volumes in a single mesh. We needed multiple bounding volumes because one volume how ever we created it would always cover the center circle so you couldn’t fly through it. The way that we used to create multiple bounding volumes was to create a Bounding Union which by using the 3DSMax hierarchy tab you can link multiple bounding volumes to the union and in Gamebryo it then recognises that there are more than one bounding volume and it works perfectly! After creating tightly fitting bounding boxes around the outer ring we tested it in game and it worked very well.

Also after lots of trial and error i had positioned the waypoints into some respectable positions and the game started to feel a lot more like our original idea!

UML and Use Cases

UML stands for Unified Modelling Language which is a general-purpose visual language that can be used to describe an object-oriented system without reference to any particular programming language. They are used to effectively capture all of the user requirements, so people developing the game can look at this single source to see what they need to implement. It can also be used to explain technical designs to non-technical participants, such as management, designers and artists.

The UML diagram that we are most concerned about as programmers is a Class diagram, this diagram can be used to show the programmers what is needed in each class, such as function and member variables, and also shows the relationships between classes.

A Use Case is a textual description of an element in the game from a users point of view. A complete set of use cases describes an entire system. Use cases are very useful as they are a tool to make sure that both users and developers agree on the set of use cases so it serves as a starting point and a guide for development of the game.

A Use Case should describe how the system shall be used by an actor to achieve a particular goal. I should also provide sufficient detail that a user regards it as complete for the purpose at hand but does not include extraneous details, for example you should not talk about memory usage and other technical details.

Week 4 – Development Dairy and Team Progress

This week in our team we have yet again made rather a lot of progress. This week since i know the most about the collision have been assigned the task of creating some waypoints / checkpoints for the game. I quickly created a simple waypoint that had basic collision and came up against a large problem with the collision.

The collision as it was called a function – a Callback function – which was passed through an Intersect. The problem which i had was how to get from the Intersect to manipulate the objects that actually collided. After probing the Intersect class i figured out that it held 2 objects inside of the Intersect object and Object 0 was always the object in which has the callback function set to the one you are currently in. Since i was in the ship’s callback function at the time i knew that Obj0 was the ship. The problem now is faced with Identifying the Obj1 as in the Intersect class it is declared as an AVObject which does not hold all of the information that i needed.

After looking around at how it was done in a few samples I realised that you can give each NiNode a Name of its own. you can then compare this name with a string of your own to see if it is the right class. So now when each Object is created it is given a Name to describe what it is. For example the ships name would be “Ship” – basic right? Now that each object has its own unique name you can compare the names with the name you need and if they match then you know what obj1 is and can now cast it as the object it is so that you can access the member functions and variables.

Sorry if that was all a little confusing! I’ll read over it later when I get time and will change it if it needs to be changed.

The other people in the team also worked hard this week and the game is starting to look very nice! I will try and get a video of the game at its current state and upload it if possible!

Coding Standards

Coding standards are a key feature in the software development industry. They are used to make sure that all people working on a single code base write their code in the same way, this can help the project immensely due to the fact that every ones code will look very similar and people can go from their code to another persons code with the minimum of fuss. Coding standards are a set of rules and guidelines when writing code, they generally specify:

• Positioning, style and use of comments,
• Indentation style – ( Tab? 3 Spaces? etc… ),
• Spacing – ( Spacing in If statements and other use of brackets ),
• Variable nameing conventions – ( m – Member or _ for member or both? ),
• Function / Procedure naming conventions,
• Class / type naming conventions,
• Use ( or not ) of deprecated constructs e.g. goto etc…
• Accessibility of member elements ( public / private ).

All of these standards ( and more… ) are used to improve the readability of code and to make the code a lot easier to understand for all people working on the same code.

Something that happens in companies with good coding standards is a Code Review, this is a systematic examination of all of the source code to ensure that coding standards are met, it also improves the team familiarity with the code base as they look over other peoples code and it checks for flaws, vulnerabilities and just general refactoring. Also pair programming can also be considered a form of on-the-fly code review as 2 people writing code is more efficient and if one person makes a mistake the other will hopefully spot it!

Week 3 – Dev Diary & Team Progress

This week in our project we have made a huge amount of progress. I have been working on the Collision and have got basic collision working. The collision works by having collision boxes and collision data stored in each model. For this to happen correctly I have had to have a good amount of communication with the lead artists to figure out how to get collision working in Gamebryo from the models and exporting the models with the correct collision Data. After a few hours of trying lots of stuff, we got no where. We turned to the documentation only to find that all along there was a section for the artists and it told you word by word how to get the collision working. After reading over how to make collision in 3dsMax we tried it out. The way that the documentation specified was to create a basic box or sphere and name it a special name – NDLCD – NDL Collision Data followed by 2 letters which describe the collision such as BN for Box and Never Propergate. After applying this to our own models the collision worked fine.

Now that the basic collision was sorted i neatened my code up and commented it a lot so that people could understand how to apply collision to their own object. When i had done this i had a few requests from people over my Game Object class that i created last week that people wished me to add a little bit more functionallity. Overall i was please with the progress this week.

The team as a whole also worked hard and quickly this week and by the end of the week we had a lot toshow which was different from the week before.