Placement Year

While I’ve been neglecting my Blog, I’ve been on my Placement Year for my Computer Games Programming course. My situation with the Placement Year was a little unusual, people would usually expect you to go out into the industry, join a big company for a year and gain experience that way, but I was a little different.

I was approached by my Course Leader, who wanted to set up his own games company, and employ me and one other student on their placement year (Justin Alexander) to work alongside him! Of course, this was an offer I could not turn down, working on iPhone and Xbox Live Arcade titles would be a great year, in which I could no doubt learn a lot. The games company that I worked for, and helped build, is ‘We Are Colin’ (www.wearecolin.co.uk), we’ve published 9 games over the year (and a bit):

Screw the Dealer – Card game – iPhone

To start of with, we started on a pretty easy game type to develop quickly. Screw the Dealer is a card game similar to ‘Whist’ or ‘Spades’. We released 2 versions of the game, one was Free and had adverts in it. The other was Paid for and had more content with no Adverts. We thought that this business model would work quite well, but unfortunately it didn’t fair very well in the App Store. People who played it said it was good, but not many people did play it.

Check out the game(s) here: http://www.wearecolin.com/screwthedealer/main.php

Cavemen Vs. Aliens – Strategy – Xbox Live Indies

Cavemen Vs. Aliens was the next game to come from the Studio, this was mainly developed by my work colleague, Justin, and I helped out after completing Screw the Dealer. It’s a tricky game to explain, so I’ll just point you to the website. The game didn’t do as well as we’d hoped, since we spent a while refining the Graphics and Sound to make it an appealing game. Once again, lots of people liked the game, but not many people could find the game in the first place!

Website: http://www.wearecolin.com/cva/main.php

WordSearch Rush – Word Game – iPhone / XBLIG

Next to be developed was WordSearch Rush, a game prototype that our Boss had originally developed and we all thought would be and awesome game on the iPhone. This of a WordSearch Game, without the word list, and with a Topic for which you have to find words related to. For Example, Colour may be the topic, so you have to find colours in the word search grid.

This game did remarkably well! We marketed this game a little more, got a few posative reviews from websites and most influential of all. APPLE FEATURED IT! That’s right, our game was on the Front page of the App Store in the UK and featured under the ‘Hot Games’ in the US and worldwide. GREAT SUCCESS!

Website: http://www.WordSearchRush.co.uk/

This game also got made into a few sequals, which did not sell as well. We created WordSearch Rush GOLD, which had all of the downloadable packs already built into the game, WordSearch Rush: HD for the iPad and WordSearch Rush on the Xbox Live Indies. None of these sold extremely well, but they we’re, in all admitance, slightly rushed.

iSevens World Tour – Card – iPhone

While developing our first game, Screw the Dealer, for the iPhone, we also partly developed another card game, iSevens which is a iPhone version of the card game Sevens. This is a more fully fledged card game, with a whole world tour and character system. It was a very good game, but sold poorly since not many people were that interested.

Website: http://itunes.apple.com/us/app/isevens-world-tour/id375968132?mt=8

Gravity Runner – Action – iPhone

To finish our year off, we both worked together on an Action game for which we both though up the ideas for. Gravity Runner is a really great game, and I’m extremely pleased with how it turned out. Very much praise from a huge amount of people, almost every website covered the game in some way or another, and 90% of them loved it!

I’d recommend checking it out asap =P: http://www.wearecolin.co.uk/gravityrunner/

What I Learnt

So much was learnt over the year (and a bit) when it comes to development of games.

• First and Foremost, iPhone App Development. We used Torque Game Builder for the iPhone to create our iPhone Games, so we had to learn how to use this engine from scratch. Also this didn’t stop me looking into the Objective-C and C++ code behind it, lots of editing of the Engine was needed and a learnt a huge amount about how massive game engines are built and work.
• Mac OS X – Never been used before by myself, and I found it quite a challenging experience. Not because it’s a bad OS, but the budget of the Studio never allowed us to get a decent monitor / keyboard / mouse combination, and it was a pain to work on. Jokes aside, it was a learning experience still. Seeing how all of the signing of certificates works.
• Xbox Live Indie Development – I’d used XNA before, but not on this scale, to create a fully fledged game. It was a great experience. Also the process behind deploying the game to the Xbox Live marketplace was a completely new experience and was great to learn about.
• Marketing, Marketing, Marketing!!! The main thing when developing Indie Games is getting the game noticed! It’s extremely difficult, but I actually found the Marketing component of making a game enjoyable. I made lots of contacts in the iPhone space! All will be useful for any future projects I may think about doing.
• Conferences – While working at  We Are Colin I went to a couple of conferences, which was a great learning experience. The Apple Developer Conference was the first we went to, in which they shared secrets about developing Successful Apps. We also went to the Develop Expo in Brighton, not a huge amount was going off in the Expo section, but was a good experience whatever.
• Running a Buisness! – This has gave me a great insight as to how businesses are ran. It’s even made me think long and hard about creating my own business at the end of Uni and when I’m financially stable .

End

Well, a big blog post to start a new year at University and describe what has happened over the past year! Keep an eye out for a post on what’s been happening so far at University this year, and a few pictures and demo’s of what’s been created!

Thanks for Reading!

Dave.

and a Trailer of the game from the project manager Dan Carter:

As you can see, the game is looking quite good! To say that we hadn’t touch Gamebryo until the start of the 2nd semester, and we’ve only been working on the game for around 3 months alongside our other university schedule.

Unfortunately, code cannot be shared, since it uses Gamebryo source code, which can not be distributed under any circumstances!

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.

After last weeks success with the World collision I was tasked with making the collision response reasonable so that it did not look funny when crashing into the world and yet again working with Joe the artist to get the Mesh split up so that it ran over 60fps.

The way i started looking at the how the collision response would work was that it would bounce off the walls like a reflection vector and would reduce in speed so that there was a penalty for crashing into the wall. I started looking into reflection vector calculations and eventually got that working after plenty of frustration with the code. The problem now was to get this reflection vector to be the direction that the ship is traveling in. The way that the ship moves at the moment is rather weird in that it does not have a direction vector and the direction is calculated solely on the world matrix’s first column. This gave me a slight problem when trying to alter the direction of the ship since I would have to create rotation matrices rather than just change the direction vector which was the way that i though it would be done.

Using the reflection vector i found the angle between the incoming vector and the reflection vector to find out the angle to rotate the ship around. I then took the cross product of the incoming vector and the reflection vector to get an axis of rotation which i could rotate the ship around. Using some simple functions built into gamebryo i could create a rotation matrix around my newly made rotation axis. I set the angle to be the angle between the 2 vectors that i had used and was hoping that it would work well like that. Unfortunately rotating in that angle did not work as i had hoped since if the angle was 0, it would carry on going the same way, which is wrong as it should bounce at 180 degrees. So to get the result that i was looking for i had to take the angle away from 180 degrees to get the angle i had to rotate the ship. This works well and looks ok for the time being and i will need to look into refineing it later in the development process, but as for meeting the requirements it does its job at the moment.

The  next problem we still had was the frame rate. After plenty of new mesh’s came from Joe, each with different settings and meshs we still didn’t have a .nif with the world split into different mesh’s. This was becoming one if the largest problems and i will have to work closely with Joe to get this to work well.

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 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.

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 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!

This is my First post about Mobile Development so this is what Mobile Development is going to be about this semester.

During Mobile Development this semester I will be using Java ME to create an application for a Mobile Device, such as a mobile phone or a PDA. Using Java ME the assignment is to create an application of your choice, of course this means that I will be creating a game on my mobile phone but what kind of game I am still unsure of.

Week 1

Week 1 of this module was a bit chaotic, we had no lecture due to a timetable slip up and the software needed was not installed in the rooms we had to work in, luckily the first week was just an introduction and was how to set up your development environment, I am using Netbeans 6.5 and Java ME plugin, alongside the JDK – Java Development Kit. All has been set up and I created a basic Dice game in Java in Windows Console.

Week 2

In this week we learnt about how to develop on a Mobile Platform, the basis of which revolves around creating a Midlet for your mobile device, a Midlet is a program that runs using the Java Micro Edition set of API and extending Midlet for your own class gives you a new program which you can run at will.

The task this week was to create an Insurance application which asked the user to input his or her Name, Address, Phone among some other pieces of information. I had a screenshot given to me by the lecturer and we were told to go away and try and recreate it. To start creating something visual the first thing needed in my newly created Midlet is a Form, a Form is a blank canvas in which different types of objects can be placed upon and attached, such as text boxes. Once a form is created it then needs some TextFields which are fields of text which can be edited by the user and also some ChoiceGroups were added, which are multiple choice answers with either buttons or tick boxes. Once all the Text Fields and other object are set up they need to be attached to the Form and then the Form needs to be displayed. Also for the midlet to be able to Exit an exit Command needs to be initialised and added to the form, a Command is something that appears at the bottom and can be pressed by using one of the buttons on the phone. Here is my Final version of the first page of the Insurance Application:

Insurance Application First Screen

As you can see there is also a Save command at the bottom too, this command should take you to a new form which displays all of the information entered. This is as simple as creating a new Form and adding StringItems to it, a StringItem is a basic label which can not be altered and just displays text. Once all of the StringItems have been set up with the text entered into the textfields on the first form they can then be appended and the new Form can then be displayed to the screen. This is the final result:

Insurance Application Final

This is quite a basic start but we will soon be moving into Graphics and eventually making a game! I will keep you posted.

Height Based Lighting

Height based lighting is very straight forward and easy to implement it is basically just getting the height of the terrain at the vertex and then normalising the value between 0 and 1. This value is then used as the R, G and B values for the color of the terrain, and with lighting turned off the result is visible:

Height Based Lighting

As you can see the result is not the best if you want to light a terrain correctly but the result is quite nice and could be quite useful if for example you are creating terrain that is under water, the lower you get the darker it gets.

Slope Lighting

Slope Lighting is a little bit more complicated. The way it works is that the colour of a vertex is worked out from the height of the vertex in front of it. By in front i mean that the vertex is in between the light source and its position. Using Slope Lighting like this has a major downfall in which you can only specify light at 45 degree intervals (45, 90, 135, 180 etc…). The reason for this is if you think about a Grid, each vertex is surrounded by 8 other vertices arranged at 45 degree angles, so if you are using these other vertices to work out the height in that direction you can only specify 45 degree intervals. The result is much better than the Height Based Lighting for creating realistic terrain but it not yet as good as Hardware Based Lighting! Here are the results:

Slope Lighting

As you can see the results are slightly off from what you would expect but the final lighting is not too bad, with a bit of texture on the terrain this would hardly be noticeable, which is a good thing as it is much cheaper than Hardware Lighting as the Colors of the verts are set at initialization.