AI indicator

Over the past couple of weeks, the game has gone through numerous play tests. While it was clear that the game has potential and many positive areas, there were a few issues that kept becoming apparent.

One of the main ones was the location of the AI character. As described in previous posts, I have the AI following and looking at the player. However, as the camera is set on a side viewpoint, it makes it impossible for the player to see the enemy if they are travelling towards the screen. With the AI automatically damaging the player if they get too close, this was a real problem.

To combat this, a number of solutions were discussed. These included a mini map showing the enemies position at all times as well as a warning sign above the players head when they were close to an enemy. It was finally decided upon that there would be an enemy indicator within the scene. This would be a small arrow that is placed at the edge of the screen which moves to show you the direction the enemy is coming from.

As I had completed previous work on the AI I decided that I would like to undertake this task. This week I looked at other games which use an enemy indicator to see how best to implement one. Jet Fighters, an iPhone game, stood out as an important one. It was clear in that game, you had a single viewpoint camera and without the indicator it would have made the game frustrating and too difficult to play. I've since looked into some tutorials and theory behind the code needed for the indicator and hope to implement it over the coming weeks. With these new coding challenges, I really feel that my skills are progressing.

Written by Phil

Weekly Update

This week, Tom and myself have been working on the game together as most of the tasks we have undertaken have been based on level design.

For my part of this project over the last week I have worked alongside Tom in creating the easy route for the first level of the game. The route has been designed after finishing off the layout of the base level.

One of the main parts of the week for me was applying the Navigation Mesh to the level after Tom had finished modeling it so that the enemy could navigate all of the obstacles. After completing this work for the base level, I found it quite straightforward to apply the same techniques to this level. It did, however, need some tweaking in order for the enemy to roll along the floor at the perfect height. This issue was quickly resolved though. I also found that special consideration had to be given to some of the corners as enough space had to be left for the enemy to comfortably navigate his way through.

The level itself went through some alterations with numerous playtests revealing a few errors. One of the big changes we made mid-way through creating the level was the start point for the main character. It was decided early on that it was important that the player could see the entire level upon starting the game so they had a rough idea of where they needed to travel. With the starting area positioned where it was, it made it difficult for the player to see the necessary objects they needed to collect. After some altering of the start base position, it was decided the start the player from a position where they could see all the collectable and the enemy.

The enemy starting position and speed was also changed. It was felt that the enemy was initially too fast and that it was difficult for the player, especially on an easy route. This was a change that I applied quickly and slowed the enemy down. The starting position for the enemy was altered too, with it being decided to start the enemy where the player could see him. We felt that having the enemy start moving towards the player straight away added a sense of urgency to the game making it more exciting. Because of this, we made the enemy start the opposite side of the level so the player could always watch the enemy moving towards him.

Next week, I plan on rectifying the issue of having the player unable to see the enemy when travelling towards the screen. I will try and implement a detector arrow, which will show the position of the enemy relative to the player.

Written by Phil

AI and Navigation Routes - Complete!

This week has been a breakthrough week for me on this project. After finding out how to add the menu code into the game, I have now managed to code in the Navigation routes for the enemies to walk along.

I did this using Unity's in built navigation tool. It allows the user to set out paths that the enemy can walk along and follow the player. I had spent a long time researching the topic and finding out the best way to go about completing this task. Having never undertaken a task like this before, I dedicated a lot of hours into learning how to code this set up and it has now paid off. Some basic code that i have written for the enemy movement is below.

#pragma strict

var agent: NavMeshAgent;

function Start ()

{

agent.destination = transform.position;

}

function Update ()

{

CheckLocation();

}

function CheckLocation()

{

agent.destination = transform.position;

}

What this does is check where the navigation agent is (the enemy) and transform his position to the agents destination (the player). This allows the enemy to follow the player, although only on the highlighted routes. If the enemy reaches an area they can't get to, they will find an alternate path.

Firstly I tested out the navigation routes in a simple test scene. As you can see below, the blue highlighted areas are where the enemy will walk and follow the player.

Within Unity the user is able to make certain parts of the level not walkable for the enemy. This will be key during gameplay and will mean we can give the player certain safety areas within a level. All the navigation routes are able to be tweaked, meaning each level that we design will need special consideration for the enemy movement.

I then went one step further and tried to get the enemy to jump over gaps and obstacles. I was eventually able to do this after a few hours of testing and trailing.  Below is how the final areas look that I have applied the jump navigation to. Notice the arrows which show where the enemy will start and land.

So, once I had completed all of this work I then went on to add a navigation route onto the game itself. I started with the base of level one, and added a mesh over the scene so that the enemy would follow the player whilst avoiding all of the obstacles. This took a while as it needed to be tweaked multiple times to get it right.

After I had done this, I then went and added a navigation mesh onto the easy route of level one itself. This, again, needed a bit of tweaking but I managed to get it into place. Coding was added to both scenes to make the enemy move. These scenes now need multiple play tests to see what changes, if any, need to be made.

The next stage for me will be to add navigation routes onto the other difficulty routes within level one and then play test them.

Written by Phil

Main Menu Code

Since writing my last blog post I have been working on the AI and the menu code within our dissertation game as well as another one for this module.

I have been able to get the menu codes working to a level that I am happy with. This is a really helpful piece of code as it allows me to be able to use it across multiple games that I am undertaking on this course.

The basics of it are that when the user is presented with a menu screen, they can click on the play button and be taken straight into the game. Also, if they click on the Quit button, it will quit the application for them. This code will also work for taking the player to an options screen as well as any other screens we decide to implement on the main menu.

I completed this work using the code C#. Unfortunately, I was unable to use my preferred coding method, which is playmaker. This was due to a lack of tutorials that I could find on the subject.

The process of getting the menu buttons to work is quite simple once trail and error has been used. First an empty game object is brought into the Unity scene; next it is resized and shaped to form the play button on the menu. The code is then written and then dragged and dropped onto the button.

It was decided that each level and screen would be in a different scene. This is to make the game less demanding on the machine it is running off. Because of this, each scene that we make must be named correctly in the build settings for the menu code to work. The code is below:

var isQuitBtn = false;

function OnMouseUp()

{

     if(isQuitBtn)

     {

          Application.Quit();

     }

     else

     {

          Application.LoadLevel(1);

     }

}

To summarise this code, it works by sending a message to the scene where when the mouse button is clicked and released, the game will either quit or play depending on which button the player has targeted. The number in brackets after ‘Application.LoadLevel’ relates to level that is started upon the play button being selected. This may look very simple, but as I am still new to coding, this was very pleasing to complete. What is even more rewarding was seeing it work and understanding the processes behind it.

Next, I plan on using the knowledge I have learned whilst working on the AI, to create routes within the game that the enemy can navigate. I hope to progress on this work over the weekend so that next week Tom and myself can start planning out the first level design.

Written by Phil

Weekly Update

This week I have continued work on the AI as well as thinking about the best way to implement difficulty into the first level. With the initial level having three different difficulty levels, it is going to be important to change how the AI interacts with the player to allow for experienced players and new players to enjoy the game.

A few ideas I have come up with that can vary between difficulty levels are:

• The number of enemies
• The speed of the enemies
• The sight range and vision of the enemies
• The damage dealt by each enemy

These points can all be tweaked in the game code to change how easy or hard a level is to play. As with the other games I am currently working on, it will be imperative to play test each difficulty level to find the right balance of the above points.

As stated in previous posts on this blog, I have already figured out how to code the line of sight, vision, player detection and enemy movement. The part I am now focusing on is laying out paths on the levels so that the AI finds routes around objects, rather than just floating through them.

Unfortunately, after numerous hours of research and tutorials, it seems apparent that this will require a complex piece of coding to achieve. The program that is being used for this project does not support the navigation routes that we require. Because of this, I am setting out more time for this part of the project to allow me to learn it. I have already begun and have looked at online tutorials and visited numerous forums and blogs that give different examples.

The difficult part here will be to adapt what I am learning to our game. I am however already making progress with this and I believe it is a good thing that I am being forced into learning yet another new skill on this module.

The outline for the this coming week will be to set aside a lot of time to improve my knowledge in this area and to try and get some of the enemy navigation sorted.

Written by Phil

Dissertation Proposal

Below is the final version of my dissertation proposal that was submitted on Friday 9th November

Action Adventure Platform Game Development: Rusty & the Cog Bots

by

Philip Rozier

Brief Outline of the Work

For this dissertation module, I plan on developing an action adventure platform game with a user-friendly interface.  The success of the project will require creative design work, sound mixing and the coding of characters, objects and levels within the Unity game engine. The coding within the game will be completed by using Playmaker; a plug-in for Unity.

I am working with a fellow student on the same project and we will contribute equally to the entire project, demonstrating as much technical and creative skill as possible. My personal input will be to implement code into various parts of the game and assist in level design and the creation of small graphics for use throughout the levels.

The tasks that I have selected to undertake are an honest reflection of what I believe I can both achieve and be challenged by throughout this semester.  I am combining my knowledge of the essential elements of core game design with my understanding and appreciation of what constitutes an enjoyable and achievable gaming experience.

Rationale for the Project

The game we have designed has been given the working title ‘Rusty and the Cog Bots’: an action and adventure platform game that can be targeted at all ages.  It was decided to select this style of gameplay as, through my previous studies of genres, I understand it to be a recognised favourite; popular across gender and culture groups and very adaptable for the mobile and on-line markets.  It will also provide great scope for challenging our own ideas and interpretations.

The project will be managed in such a way as to allow for opportunities to add or remove components that we may find manageable or too taxing. Being new to this style of development, I believe it is crucial to adopt a positive, creative and open-minded approach for the success of the module.

Managing enemy movement and behaviour will be an integral part of the development, as it will determine how a player is challenged throughout each level. It will be imperative to balance the increase in difficulty at each level with the manageability of completion, whilst avoiding any frustration or dissatisfaction from the player.

Initial work on Artificial Intelligence will take place within a tech demo and by completing the coding duties in this level first, it will be possible to test the outcomes for suitability and success and make any necessary modifications at this early stage.  Completing this process will allow for player tests and feedback processes to take place.

To allow the enemy to interact more frequently with the player, each level will require more challenging code. This will ensure my coding abilities are stretched and developed, as they will be with the coding for the player pickups.  Within the game, a number of pickups will provide the player with the opportunity to improve qualities such as health, game speed and jumping ability.  This will be repeated for all the power-ups and boosts within the game.  Special consideration will also be given to the pickup placement and accessibility, the success of which will be reviewed following numerous player tests.

For the game to appeal to all audiences, each level will feature multiple difficulty levels. It is intended to incorporate three strands of difficulty per level, thus allowing both inexperienced and seasoned game players to enjoy the game equally. It is accepted that this will be challenging to complete, as it will require multiple enemy difficulties.  However, it will be a necessary element to enhancing the enjoyment and challenge for the player. 

Level design will be the cornerstone of success for this project: creative and imaginative design will make for an enjoyable experience whilst uninspired or dated features will make for a tedious and uninspiring player experience. Therefore, consideration will be given towards entertaining those players who are playing through on the earlier levels and stimulating and challenging the advanced players who win through to the more tricky levels.

As with all good games, our game will make full use of player testing and user feedback in order to refine and modify the game to a high standard.  A number of avenues will be explored to achieve a balance of age, gender and ability amongst the focus groups.

The personal challenge of this task will demonstrate my current skills for the development and design of in-game objects whilst at the same time develop new skills and extend my own learning boundaries.  I will be fully utilising my acquired abilities in creative design as well as undertaking new and more advanced challenges in coding. This will give me an opportunity to display as many talents as I can throughout the project, allowing me to develop into a more complete, all-round game designer and a strong candidate for future employment.  The finished game will sit alongside earlier, successful examples of my work, providing a major contribution to my professional portfolio.

Career opportunities presently advertised for which this work would prove valuable include a post with FULLFAT Games based in Coventry, West Midlands.  The position involves designing and creating 2D Artwork and Graphics for the UI Interface as well as other 2D items on various mobile applications.    Two Junior Developer posts are also advertised: one with Feral Interactive, a publisher and developer of both Mac and iPhone based games and another with AVM, an entertainment company making games for social online & mobile platforms.  These companies seek new graduates with knowledge and creative ideas.  My work lends itself fully to this type of role in the industry.

In conclusion, this project proposal aims to demonstrate the level of acquired knowledge and firm understanding of the elements that go towards the successful development of an action adventure platform game.  It not only incorporates the professional theories and tested practice that exists as success criteria for such games but also recognises the pitfalls and shortcomings that can come about as a result of the inexperience or lack of knowledge and understanding on the part of the developer.  Ultimately, the intention of the entire project is to showcase my own learning, skills and development for the purposes of achieving a successful academic goal and future employability.

Timeline for Action Adventure Platform Game Development: Rusty & the Cog Bots

End of August 2012 –

·      Idea for the game to be finalised.

·      Begin work on learning Playmaker

·      Create tech demo

End of September 2012-

·      Begin work on coding the pickups and AI. 

·      Research articles for use in development.

·      Full review meeting with partner before start of semester

Early October 2012 – Begin work on dissertation proposal: first drafts.

End October 2012 - Complete work on:

·      enemy movement

·      following the character

·      looking at the character

·      first dissertation proposal

November 5^th 2012 – submit proposal for advice

November 9^th 2012 (or before) – Hand in final proposal

End of Nov – Complete work on pickups and enemy navigation

Mid-December 2013 – Meet with specialist tutor

End of December 2012

·      Have a playable level that has been play tested and polished.

·      Work on presentation update for January

Wb.January 21, 2013 – PowerPoint presentation (date to be given)

End of January 2013 –

·      Complete work on a further level

End of February 2013 –

·      Have multiple working levels in place.

·      Broaden scope of playtesting (possibly with school pupils)

·      Use feedback to modify game

End of March 2013 – Have a number of polished levels completed

End of April 2013–

·      Have a finished game with polished levels,

·      Have evidence from finished and complete playtest sessions on the final game from as wide an audience as possible including Suffolk University Waterfront Games website.

Early May 2013 –

·      Present work to specialist tutor for review and advice before final submission

·      Modify/final adjustments to be made

Mid-May 2013 (by 17^th May) – Final Submission

Regular events throughout the project:

·      Weekly meetings with partner

·      Making 2D assets

·      Creating sound

·      Play testing new features

·      Tutorials for Playmaker and Unity

·      Research articles for use in development

·      Meet with specialist tutor when required

Annotated Bibliography

1.  Various Authors & Contributors, Difficulty Level, Giant Bomb.

This webpage information details reasons why game developers use difficulty levels as a way of allowing a player to make choices.  In my own game I recognise that if the player is to get the maximum enjoyment they need to have some control over the amount of challenge they want to feel as they play through a game. By adding difficulty levels to a game it offers multiple choices to a player so that they can choose a level that is close to their level of skill, or just choose a level that suits their playing style best.

Accessed 14^th October 2012. http://www.giantbomb.com/difficulty-level/92-183/

2.  Various Authors & Contributors, Difficulty Level, Giant Bomb.

The advice given here on changes to difficulty levels matches my own understanding about why these are necessary.  Changes to the game that different difficulty levels make are different in every game, but some common characteristic elements include those already detailed in my dissertation such as the amount of health or the speed a player has.  Others quoted include the amount of enemies encountered and the amount of damage enemies deal.

Accessed 14^th October 2012. http://www.giantbomb.com/difficulty-level/92-183/

3.  Jack Arnott, (June 17^th 2009), Take 5: Platform Game, Guardian News Agency plc.

This Guardian news article champions the platform game genre.  It is because of the very reasons given in this text that our own game development chose a platform style.  It is because a platform game offers such simple, controllable fun that any gender, age or ability can easily access it.  Despite technology taking massive leaps the platform genre remains a winning favourite and for that reason it has been selected to represent our ideas.

Accessed 20^th October 2012. http://www.guardian.co.uk/technology/gamesblog/2009/jun/17/best-

platform-games

4.  FlipC, (February 24^th 2011), Video Game Collectables: notes for designers, Blogspot.

This article on video game collectables explains why these are so necessary to gaming.  In developing Rusty and the Cog Bots the inclusion of Pick-ups mirrors what is suggested in the article: that they are to extend the playing time of the game and to add variety to the whole experience.  It is recognised that of the two main categories of collectables mentioned in the article, we have selected what is termed here as ‘World difference’ only, as it is felt that ‘No world difference’ collectables do not generate the same level of satisfaction to a game.

Accessed 7^th October 2012.     http://flipc.blogspot.co.uk/2011/02/video-game-collectables-notes-for.html

5.  FlipC, (February 24^th 2011), Video Game Collectables: notes for designers, Blogspot.

The details in this article provides a number of excellent suggestions about the use of collectables and how best to utilize them to best advantage for the game.

From the suggestions made here our own game development was modified to include risk taking, placement for exploration, positioning, marking and numbering.  This was useful advice and helped to redirect some aspects of our decision making.

Accessed 7^th October 2012.  http://flipc.blogspot.co.uk/2011/02/video-game-collectables-notes-for.html

6.  Laura Parker, The Science of Playtesting: UK Gamespot.

This webpage article outlines clearly the reasons why play testing is so important to game developers.  It was already an important feature to be included in our own game development but this article confirmed our thinking and also reminded us to test at regular intervals with a variety of testers.  It also taught us that with testing comes subjective opinions that can alter the course of a game considerably.  The article also reminded us that testing will be important to prevent us, as developers, losing sight of how the game will play to the gamer as opposed to the developer.

Accessed 7^th October 2012.  http://uk.gamespot.com/features/the-science-of-playtesting-6323661/

7.  Ed Fear, The Top 10 Game Engines, No. 4: Unity 3D.

This article confirms my understanding that Unity is a recognized, well respected and well-used game engine amongst game developers.  Its compatibility with a range of devices is particularly useful, saving time and money when developing for a variety of platforms.

Accessed 4^th November 2012.  http://www.develop-online.net/features/516/THE-TOP-10-GAME-ENGINES-NO4-Unity-3D

8.  Blake Snow, Why Most People Don’t Finish Video Game, Finishing Video games.

The evidence presented in this article is a timely reminder about the need to respect the interest level of the player.  It lists a number of reasons as to why players abandon games e.g. difficulty, repetitiveness, duration, lack of time.  It is important to pay attention to this article in order not to forget how important player testing is in the successful development of games.  Games must be worth players’ time and money to be rated well.

Accessed 27^th September 2012.

http://articles.cnn.com/2011-08 17/tech/finishing.videogames.snow_1_red-dead-redemption-entertainment-software-association-avid-gamers?_s=PM:TECH

9.  James Wexler, (May 7^th 2002), Artificial Intelligence in Games

This interesting article details how AI has evolved over many years from ‘Pong’ ‘Market simulators, logic systems, and economic planners’ are listed as some of the different fields of computer software that rely heavily on elements of artificial intelligence.  It then explains that as video games have become more complex, interesting and engaging AI now shapes gameplay in a major way.  One game in particular, “Black and White” by Lionhead Studios is exampled as how advanced and complex video games can now be with the use of AI.  I found this article particularly interesting in view of the fact that this area is one I am involved in developing for my own project.

Accessed 20^th October 2012. http://www.cs.rochester.edu/~brown/242/assts/termprojs/games.pdf

10.  Julie Weed, (November 6^th 2012), Video Games for All Ages, Seattle Times.

In understanding of how to make my own game as appealing to as wide an audience as possible I was interested in reading this latest article about games and families.  I was astounded at 20 million players playing simple games such as ‘Words with Friends’; a version of Scrabble and Draw Something which is like Pictionary.  It reminded me that to be accessible to the audience I am targeting I need to keep my game fun, simple to understand and relatively easy to play without losing the thrill and excitement of challenge and humour.

Accessed 6^th November 2012. http://seattletimes.com/html/businesstechnology/2018025676_ptteentween21.html

Word Count without Annotated Bibliography or timeline: 1032

Word Count without Annotated Bibliography: 1323