November 1, 2010

I am still alive!

Posted in Uncategorized at 23:04 by markcampbellprogrammer

I’m currently back at University after spending the summer working at Identity Games, a local indie game developer from Derby! I have loads to talk about 🙂 but so little time :(. I’m having a blast so far looking at AI techniques, Networking, Advanced 3D graphics and my own personal research project which I will post all about after I break up around Christmas time.

Mark

Advertisements

March 8, 2010

What makes me a Games Designer?

Posted in Games Design at 17:31 by markcampbellprogrammer

I found this questionnaire on the internet and thought it would be a nice exercise to consider my current views on games design.

Why are you interested in becoming a part of the games industry?

Working in the games industry is something that I have always wanted to do from a very young age. Even before I had any understanding of computing I was interested in writing stories, creating characters and developing rule sets for games during my early school years. It was also around this time I began to want a deeper understanding in how computer games were made and began jotting down game ideas and creating characters which I would one day hope to see in a game. After deciding to study games programming and design at University, I found ways to bring my child hood ideas to life and am now ready to build a career. 

What games are you currently playing?

I’m a regular Street Fighter player and am eagerly awaiting Super Street Fighter 4 later this year. I have recently played through Heavy Rain, Bioshock 2, Call of Duty Modern Warfare 2 and casually play Guitar Hero with friends. I tend to play through previous generation titles if there is an aspect of design I’m interested in researching.  I enjoy playing through titles on the Sega Dreamcast, Nintendo Gamecube and the original Xbox when I am not playing anything on current generation hardware.

What is one of your favourite games, how would you make it even better? 

I have played a lot of great games over the years but one that stands out in particular is Bioshock. The sense of immersion felt whilst playing that game is unparalleled with anything else I have ever played. The story, characters and environments created a haunting atmosphere which was easy to get lost in. As great as Bioshock was, there was some issues with the game. The fantastic atmosphere quickly disappeared when I realised how pointless it was to be scared of anything. The vital chambers scattered around everywhere meant that when you died, you never really had to learn from your mistake. You could get into a fight with more challenging foes and just grind them down by respawning and attacking them until they’re defeated. I would either give the player the choice to use the vital chamber (at some sort of cost) or just allow the enemies health to be restored if the player was killed.

What genre of games do you prefer?

I try to play as many games from as many genres as possible. I enjoy casual gaming such as guitar hero, rock band and peggle just as much as I do FPS’s and Adventure games. I have a soft spot for 2D beat em ups as well as adventure/fantasy games.

Do you prefer PC or Console games? Why?

I don’t favour one over the other. I like to play RTS games on PC as I find using a mouse is quicker and easier than using a pad but prefer playing shooters and adventure games on consoles. One thing I enjoy about PC gaming is being able to create content using tools such as Epic’s Unreal engine and level editor.

Have you done any scripting or programming before?

Throughout my time at University I have used C#, C++, Java and C to make games with. I have experience with Microsoft’s XNA platform and their DirectX API aswell as scripting experience with Epic’s Unreal 2004 Engine. I am comfortable with object orientation and encapsulation.

Have you done any game, mission or level design before?

I have written games design documents from a young age and constantly try to keep an up to date documentation on any ideas I have. I have used UT2004’s level editor to create a map for a University project as well as personal projects outside of university. I have recently discovered methodologies for creating puzzles and getting a better understanding of player psychology. 

List some elements you have used to make your missions exciting if any

I am a keen believer in the risk/reward pattern used in gaming and have incorporated it into many of my projects. I tend to start with these first and then insert moments in between for the player to take part in. I like to make the risk/reward as clear to the player as possible as it can drastically affect how they choose to play. I believe chance, skills and rules should be carefully considered and implemented accordingly.   

What 3D packages are you familiar with?

I have only used Maya and 3DS Max and with both have very little experience. I am however hoping to get more experience with them over the next year. 

What role do you yourself doing in the future?

I try to stay as open to all aspects of game development and get as much experience in all areas. This gives me a better understanding for when working with people from other areas of development.

February 24, 2010

Great stuff I’m reading at the minute (Feb 2010)

Posted in Reading resources at 22:43 by markcampbellprogrammer

Programming Pearls by Jon Bentley

AI Game Engine Programming by Brain Schwab

Beginning Game Level Design by John Fiel and Marc Scattergood

24/02/2010 – Engine nearly finished

Posted in Work Placement - Identity Games at 22:31 by markcampbellprogrammer

After spending an awful lot of time and effort, we’re finally closing in on the last part of the engine. Its been a real challenge to get as far as we have and now we can look on making our first game. It seems moral has picked up again after being quite low for the past few weeks, which I guess is down to finally being able to create games. It really has been tough at times due to various reasons such as –

Communication

One of the most important and often difficult skills is being able to effectively understand what each other is saying. It is as important to understand the other person and how the perceive what it is you’re trying to say. A lot of disagreements and petty arguments often occurred late in the day when people couldn’t be bothered to explain things properly. I’m hoping this has been fixed now as it has been brought up in numerous meetings. Also writing things down for reference is also a good method to help people remember/plan what they are going to say.

Snow

I really have had enough of it now! so much all the time making travel impossible and causing everyone to work from home which then contributes to the communication problem. Hopefully we have seen the last of it now.

No visual feedback

Engine programming is a lot of fun and the benefits of being involved in something so complex really makes you carefully consider your methodologies when writing code.  However looking at the same thing over and over again as well as performing constant unit tests offers no visual satisfaction. This can be really difficult when judging how much work you have done both individually and collectively.

Roll on game number 1!

January 31, 2010

Introduction

Posted in Work Placement - Identity Games at 15:28 by markcampbellprogrammer

As a part of my University Course, I am required to complete a  9 month placement at a games company to gain valuable experience and a taste of what working in the games industry is like.

After finishing my second year in June of 2009, I spent the next few months contacting games companies all over England trying to secure a placement to start in September. It was reported that 95% of students in the previous year had secured placements either in the games industry or even in software development and I was optimistic that I could secure an internship at a top company.  

unfortunately 2009 was not a good year due to economic circumstances and opportunities were limited to say the very least. It seems the industry was not willing to take risks and responses from companies were generally negative. I was lucky enough to get 2 interviews at different companies as some people on my course didn’t even get responses,  however was unsuccessful loosing out to other students from my course. After applying to around 20 games companies and 30 software, I was unsuccessful and was considering moving straight to my final year.

During a meeting with some other students in September, we considered the possibiltity of setting up our own company and spending the next 9 months creating our own games.  We talked with some of our lecturers about it and discussed possible funding options from schemes within the University. The fact that we would also have to be responsible for the business side of things was something that concerned me as I knew how much work and knowledge was required to successfully run a business.

We each went away and spent some time thinking about whether we could all commit to the idea of working for ourselves and what we all wanted to achieve during our time as a part of this project. For me there was a number of personal goals that I wanted to work towards as well as being able to get some solid programming for  9 months which would give me an advantage for the final year.

After deciding on the name “Identity games”, we finally moved in on December 1st, 2009

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.

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.

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.

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!

Scorched Wings – Emergent’s Gamebryo Project

Posted in Gamebryo Project - Scorched Wings at 16:49 by markcampbellprogrammer

As a part of my “Applied Game Development” module I was placed in a group with 4 other programmers and 5 artists and given the task of producing an exciting racing game using Emergent’s Gamebryo engine. The emphasis was as much on team work and getting first hand experience of working as if I was a part of a real company. We decided on roles, a name and were given weekly tasks to complete as a part of our final project. At the end of the 12 week development period our projects would be graded by David Braben and his team from Frontier games in a show reel at the university.

Features of my project

  • Voted as the best game overall by David Braben, his team and my lecturers out of all 8 groups
  • Final game met almost every of the 20 requirements set by my lecturers
  • Full game polished to a high level with both single player and time trials mode
  • Full xbox 360 control pad support
  • Selection of different planes all with unique attributes
  • Full A.I ships to race against
  • In realistic game collision
  • Ability to refuel/run out
  • Damage system affecting ship manoverability
  • Full music and sound support

This project is by far one of my greatest achievements during my time at university. No actaul teaching was given, instead all knowledge was done through documentation, online tutorials and a lot of hard work. Please head over to my development area to see my development diary for more information.

Next page