October 14, 2009
Module : Game Development Techniques Asset Creation
As a requirement for my game I was required to include a picture of myself and a model made using a 3D rendering program such as 3DS max or Maya.
Asset Creation for my game
My texture was done by changing the colours of a photograph of myself and adding another image to it. This is then skinned onto an existing static mesh in game and displayed as so –
This is an in – game shot taken whilst using the magnifying glass pick up.
My model was made in Maya and is also placed in my level as so –
It goes without saying my future lies in programming and not art 
Module : Game Development Techniqes RISK and PERT
Pert Schedule and Risk management plan
Risk Management Plan
This document is prepared by me as if I am the project manager for my assignment. It is used to measure the risks, effectiveness and plans to reduce them. It is used in conjunction with a risk matrix.
Risk Matrix
A Risk Matrix allows severity of the risk of an event occurring to be determined like so –
Consequences are defined as
- Catastrophic = multiple deaths
- Critical = One death or multiple severe injuries
- Marginal = One severe injury or multiple minor injuries
- Negliable = One multiple injury Example
| Negliable | Marginal | Critical | Catastrophic | |
| Certain | Busy Street | |||
| Likely | Car | |||
| Possible | Piano | |||
| Unlikely | Burst Dam | |||
| Rare | Locust Swarm | Stampede | ||
4 Choices with variation in risk management –
Accept – take a chance Mitigate – lesson impact through steps
Avoid – change plans Transfer – out source risk to third party
PERT- Program Evaluation and Review Techniques
This is used as a model for the project management and is used to analyse and represent tasks in the project. This can be applied to my Famous Five game and be used to plan out how long it will take me to complete each section.
The above example was taken from http://en.wikipedia.org/wiki/Risk_matrix and the original source is on there.
a = Optimistic
p = Pessimistic
m = Most Likely
TE = Time Estimated
PERT Schedule
| Optimistic | Most Likely | Pessimistic | Estimate | |||||
| 1 | Code | 22 | 37 | 71 | 37.5 | |||
| 2 | Art | 12 | 20 | 33 | 20.8 | |||
| 3 | Level Design | 16 | 23 | 52 | 26.6 | |||
| 4 | Sound | 8 | 23 | 47 | 24.5 | |||
| 5 | Research | 18 | 33 | 54 | 34 | |||
| 6 | Polish | 13 | 17 | 22 | 17.1 | |||
| 7 | Testing | 4 | 8 | 13 | 8.1 | |||
| A.I | ||||||||
| 1.1 | Interaction | 3 | 4 | 8 | ||||
| 1.1.1 | Behaviour | 3 | 4 | 7 | ||||
| 1.1.2 | Modification | 2 | 5 | 7 | ||||
| Unreal Script | ||||||||
| 1.2 | Language | 3 | 5 | 10 | ||||
| 1.2.1 | OO Recap | 2 | 3 | 8 | ||||
| 1.2.2 | States | 2 | 4 | 7 | ||||
| Players | ||||||||
| 1.3 | Items | 2 | 3 | 7 | ||||
| 1.3.1 | Inventory | 3 | 5 | 9 | ||||
| 1.3.2 | Ability | 2 | 4 | 8 | ||||
| In Game | ||||||||
| 2.1 | Characters | 2 | 3 | 6 | ||||
| 2.1.1 | Items | 2 | 3 | 7 | ||||
| 2.1.2 | Environment | 6 | 10 | 13 | ||||
| Static | ||||||||
| 2.2 | Menus | 1 | 2 | 4 | ||||
| 2.2.1 | Loading screens | 1 | 2 | 3 | ||||
| Building based | ||||||||
| 3.1 | Brushes | 2 | 3 | 7 | ||||
| 3.1.1 | Volumes | 2 | 3 | 7 | ||||
| 3.1.2 | Construction | 3 | 4 | 9 | ||||
| Landscape | ||||||||
| 3.2 | Terrain | 1 | 2 | 4 | ||||
| 3.2.1 | Lighting | 2 | 3 | 5 | ||||
| 3.2.2. | Volumes | 2 | 2 | 4 | ||||
| 3.2.3 | Decoration | 1 | 3 | 7 | ||||
| Machinima | ||||||||
| 3.3 | Intro clip | 1 | 1 | 3 | ||||
| 3.3.1 | Additional | 1 | 1 | 3 | ||||
| 3.3.2 | Outro | 1 | 1 | 3 | ||||
| Music | ||||||||
| 4.1 | Sources | 2 | 4 | 10 | ||||
| 4.1.1 | Recording | 1 | 3 | 5 | ||||
| 4.1.2 | Ambient | 2 | 2 | 4 | ||||
| Sound Effects | ||||||||
| 4.2 | Ambient | 2 | 2 | 4 | ||||
| 4.2.1 | Character | 1 | 2 | 4 | ||||
| 4.2.2 | Environment | 1 | 2 | 4 | ||||
| 4.2.3 | NPC | 1 | 2 | 4 | ||||
| 4.2.4 | Narration | 1 | 2 | 4 | ||||
| 4.2.5 | Voice Acting | 2 | 4 | 8 | ||||
| Available | ||||||||
| 5.1 | Similar games | 2 | 4 | 7 | ||||
| 5.1.1 | Mechanics | 2 | 5 | 8 | ||||
| 5.1.2 | Mods | 4 | 7 | 13 | ||||
| 5.1.3 | Mutators | 2 | 2 | 3 | ||||
| 5.1.4 | Examples | 3 | 6 | 11 | ||||
| 5.1.5 | Tutorials | 5 | 9 | 12 | ||||
| Project | ||||||||
| 6.1 | Paperwork | 5 | 7 | 9 | ||||
| 6.1.1 | Game | 8 | 10 | 13 | ||||
| Game | ||||||||
| 7.1 | Bug test | 1 | 2 | 4 | ||||
| 7.1.1 | Flow | 1 | 2 | 3 | ||||
| 7.1.2 | Internal | 1 | 2 | 3 | ||||
| 7.1.3 | External | 1 | 2 | 3 |
TOTAL = 175 hours.
I think considering paper work and teaching time my PERT is hopefully quite accurate for what I want to achieve in my game.
Total for final game = 227.98 hours
227.98 – 175 = 52.9 hours not accounted for and it also doesn’t for items that didn’t get implemented such as an inventory system.
PERT 2.0
| Predicted | Average | Spent | Total | ||||||
| 1 | Code | 37.5 | 41.9 | 46.3 | |||||
| 2 | Art | 20.8 | 26.5 | 32.2 | |||||
| 3 | Level Design | 26.6 | 28.4 | 30.2 | |||||
| 4 | Sound | 24.5 | 26.75 | 29 | |||||
| 5 | Research | 34 | 42.71 | 51.42 | |||||
| 6 | Polish | 17.1 | 43.86 | 26.76 | |||||
| 7 | Testing | 8.1 | 10.1 | 12.1 | |||||
| 175 | 201.49 | 227.98 | |||||||
Module : Game Development Techniques Report
*Please note that my development diary was submitted as a part of my design document. If you would like to see my design doc, please email me*
Pre development
I felt that my pre development was quite good and I learned the basics of level design before I began development. Due to this my level was built quickly and I had the knowledge to fix things when setbacks popped up. I grasped the basic concepts early which gave me a head start when the work started. My design document was clear and written very early on and so I had a good idea of what I was doing from the start. It also gave me a reference point to look at when analyzing my game during production.
I would have liked to have spent more time looking into the art side such as animation and static mesh creation to give my game a more artistic polished look. This is something I can develop in the future and hopefully allow my game to visually improve.
The Schedule
It was hard to keep to such a definitive schedule as my game had a few setbacks. I found that instead of using such a fully laid out plan I instead set myself a number of tasks and decided to do them when I wanted to. This had both good and bad effects on the production of my game as it meant that jobs could be started in no particular order. This was good as it allowed me to have free choice over how I structured my game and it allowed me to spot potential problems earlier on. It had a negative effect because it meant job often became “half finished” and I ended up with a collection of tasks incomplete. Other setbacks included personal issues that contributed to me requiring extra support and space to work in a different state of mind. This also later became a motivation to work as well as I could and use this module as an outlet for closure, something that I did.
Consideration
After seeing how each task went each week I gained a better understating of how I wanted my game to grow. I decided against implementing the CSD talk tree system because I didn’t think there were enough characters to justify using it. I did manage to get it to work but felt it was not needed as the only interaction I wanted was sound based or text drawn triggered by events. I also decided not to make my map to big and stick to traditional action adventure style area. I included a ladder and water area as well as allowing the player enough room to explore and get a good feel for the level. My Idea for the level came from the first level on Tomb Raider (hence the soundtrack). I remembered playing that first level and being really pleased with how the level suited the game type. I hope this is reflected on playing experience as I consider this to be well done on my behalf.
Play testing report
I allowed a number of people to test my game including family, friends and fellow university students to get as wide response as possible. Below is a list of bugs reported from testing at 90% completion-
- Slight bugs within level layout resulting in wrong character animations and sticking to level
- Odd AI behavior meaning characters get in each other’s way
- The torch and magnifying glass not always working correctly
I fixed these by reworking my AI system slightly and re-arranging meshes to reduce collision with player models. I am still working on my torch and magnifying glass to produce better results in the future
Good point highlighted include –
- Controls feeling very natural and responsive
- Visual feedback being clear
- Great sounds and audio
- Challenging, yet not too hard
- Fun to play
The obviously most important good point is the fact almost every person who tested my game enjoyed some aspect of it. If this is achieved then I know I have succeeded in terms of presenting my Idea to the audience.
I also decided to add another NPC as players often felt they were unsure about who was talking to who during conversation exchanges. This may have been prevented had I included the talk tree system from CSD. I may include this in the future if it is still an issue later on in development.
What went well?
The time spent with unreal and especially the editor itself has given me a better indication of what I am especially interested in for when I go into the games industry. I have overall enjoyed my experience and am very pleased with how my game turned out. To have produced a modification in 12 weeks is something I am very proud of, and I hope to further improve my game in the future. One thing I am proud of is my AI interaction. I spent a lot of time working with and look at it deeper than others have.
I managed to include game tools such as a magnifying glass and torch pick up. Both of these are used in by the player in game and give the mod a real game like feel to it. I also made 2 levels from scratch and gained experience with the unreal level editor and machinima tools.
Perhaps the best thing of all is the fact I have built my own game (granted with additional resources and game engine) but now I have my own game. This is something I am very proud of and I hope is a stepping stone to further projects.
What went wrong?
On more than one occasion I ran into problems with the editor itself and ended up losing work or corrupting my map files. This affected my time schedule drastically and meant I had to find even more time to catch up on work. This is has in a way however taught me the value of backing up work and making sure I do this in bigger future projects will almost always be a certainty.
My map is not as good artistically as I would like it to be, neither are my machinima skills. These are things that can be modified in the future and the experience of using these skills will certainly pay dividend in the long run of my development career.
I feel I could have perhaps spent more time planning my puzzles and game flow a bit better and being more disciplined to stick to them rather than trying to change them later on as I have done. I would also like for my game to have a more cohesive structure however I think for that to be implemented I would require a longer demo and more resources.
What have I learned?
Gaining an insight into how a real games company would operate and all the additional areas has been highly beneficial and also opened my eyes to other areas which previously I knew little about. The thing that stood out most is how important and influential good level design is in the action/adventure genre. Looking at some of the classic games such as Tomb Raider, The Legend of Zelda series and even more recent games like Fable 2, the level design in these games is brilliant. I think this is one of the things that my game could use improvement on as my caves aren’t as good as I would like them to be. They need a wider area and more variety in terms of room style and layout. This would then allow puzzles to be based around the level itself and would give my game a wider scope.
Future development
As this game is an action adventure game, I would like to add more puzzles to my level and expand the map out a little bit to give the player more reason to explore. I would also like –
- A customized fully working inventory system. This would have been implemented if I had had a week longer as it was already being coded and will be added very soon.
- A wider range of items including a spade, map, compass and notebook.
- Improved AI and mini games based around it.
- A better HUD and menu system fully animated and packed with labels.
- Co operative play including a fully playable Timmy.
- Professional quality music and sound acting.
- To implement the impersonator modification, using models with wire bone structures in their faces.
- Slicker lighting and art, as most was taken from other mods and the original Unreal game.
- To turn the project to a full game rather than just a short demo.
October 11, 2009
Unreal 2004 Total Conversion – Unreal Script
As a part of my “Game Development Techniques” module I was required to produce a ten minute demo using a commercial games engine to demonstrate a range of development techniques similar to that of an actual games studio.
The focus of this module was to look at all aspects of game development and implement features which could be supported by epic’s Unreal 2004 engine. Another important area of this module was the importance of scripting and how it can be used effectively when developing games.
Features of my demo
- Fully playable demo complete with training mode
- Full Xbox 360 pad and keyboard support
- Implemented soundtracks
- Original voice acting
- Multiple A.I
- Fully working HUD
- Original implemented art and mesh creations
- Matinee sequences
- Multiple scripted sequences
- Full development diary, games design document, PERT schedule and report
As with my other projects please head over the development report section where you can read about how I implemented these features.
June 17, 2009
Module : Game Development Techniques Part 1
Game development techniques was introduced in the first semester of the second year at Derby university. The focus of this module was on introducing us fundamental issues in game development and state of the art development technologies for modern game production. Although formal teaching started from when we went back in September, we was given a heads up form our lecturers over the summer to start looking at the modding community and get some practice in using Epic game’s UT2004 editor. Later on in the summer we were sent a description on what we were going to be doing in terms of course work and what we should have done for when we start back.
The Project
The assignment for this module was to create a total conversion based on one of Enid Blyton’s Famous Five books. In 12 weeks we were required to have a full finished 10 minute demo based on what we had learned from the module playable via a Xbox 360 controller on the PC. We were required to make the level in the Unreal level editor and then using unreal script, make a new framework for which the new game code we wrote would work with. We was given certain assets but was required to create some of our own as part of the requirement such as at least one model made on 3DS max and include a picture of yourself somewhere in the game. The game itself was to be based around a chapter from one of the books which the player would then play out. Slight alterations to the story were allowed to an extend, however it had to follow the book with relative accuracy.
Why the famous five? was the first thing I thought ” Because it’s my choice ” was the explination from my lecturer.
So the first thing to do was to start painfully reading some of the books and even whatching video adaptations on the Internet to decide which book and chapter I was going to base my game around. At this time I started to research the action/adventure genre to look for inspiration and ideas I could use as mechanics, as well as writing up a design document. My aim was to have a design document written before I went back as I knew this would be a time consuming module and I would need every minute to work on it. Once I had written up the document and decided on a book and chapter I started to get to grips with Unreal Ed by following on-line tutorials at www.3DBuzz.com and slowly building up a few maps of my own before I went back to university. I started by following the tutorials before branching off and trying to make my own levels including the Gaurdian level from Halo 3. At first I found the Editor to be really useful and had loads of fun toying around with levels and making little maps of my own but eventually I found some really, really odd bugs with it that absolutly drove me mad. For some unknown reasons Unreal Ed loves to crash and close itself on an almost regular basis often deleting or undoing hours of work. I know that saving work often does help, but as ever there comes a time when you forget. Luckily I found this out before starting my main project and so was prepared for it when starting my assignment (not to say it I didn’t loose any work because I did).
