Tuesday, 24 February 2009

Blog 5 - Alternative Game Concept

My Games Concept


The game is set in the year 2041, and begins when an evil corporation start developing advanced weaponry and technologies and then start using them to conquer the land around them. The player then comes into the game, in control of a Lieutenant from the British military, whose job is to take seize some enemy weapons, and use them to destroy the corporation and bring an end to their scientific pursuits.


The game is being created in Macromedia Flash 8, and is a 2D side-scrolling shooter


The Challenges


The main challenges I faced were related to the coding in Flash. Some things were not as simple as I thought at first, such as shooting in both directions. To complete this I had to find more sources and manipulate them in different ways to achieve the effect I wanted. Through this I learnt more about reading and understanding code in Flash, I have also learnt more about different ways the code can be manipulated and implemented.


Another challenge I faced was graphics related. Flash is not a great graphics engine. Unless you have access to things such as graphics tablets the art work won't come out looking great if you try to draw them in great detail. To overcome this I kept the characters in the game small, but still kept them within a reasonable scale to the game. This meant things such as facial expressions or weaponry didn't have to be incredibly detailed. With the right basic details and shape objects would look normal.


Another challenge was animation. Animation in Flash can be very time consuming, especially with things such as walk cycles. If the timing is slightly wrong in these the animation does not look good either. The only way to get through this was trial and error, and practice.


I have also had to learn things such as how to transition from one level from another easily. But this worked mostly in the same way as it did for enemies to attack, which I already understood.


New Concept

My new concept is to create a 2D platforming game in Flash. The game would involve moving through levels, jumping on and off of platforms, while avoiding, destroying and finding ways around enemies. The aim would just be to get from point A to point B, while collecting items and killing enemies to gain points.

The player would have a set number of lives, and could gain more lives by gaining more points. The game would finish with a high score table, so if used online it could support a very small section of multi-player, even if it is just competing with people for the highest score.

Levels would start off easy, and get harder as the game goes on, requiring the user to solve some complex puzzles to avoid losing lives.

This could easily be used to showcase some of the skills I have learnt throughout making my game, and could include some of the things I learnt while making my game, that didn't go into the final game, such as using gravity.

I would need to use the same sorts of animations to show people walking, jumping, dying and so on. This would be good practice, since the only way to become better at this is through practice. The new game would be able to demonstrate what I can already do and the improvements that I would be making.

At platforming game would also need a lot more, shorter levels. I learnt how to do this using triggers(1) in my current game, and it could be easily implemented into a new game.

A platforming game would require the same sort of graphics as my current game, and would show how I could create graphics using something that isn't a great graphics engine.

This game would also require most of the same coding as my current game. It would be capable of showing that I have learnt about using hit tests, to determine how things react, it would show I understand how to make things move, it would show I know how to trigger events, make animations stop, start and wait at a certain frame. It should be able to show all the things that I learnt about Actionscript throughout making my game.

(1) Something that the player cannot see that triggers an event, such as an enemy appearing or the level ending

Blog 4 - Game Sketching

Game Sketching

"A game sketch is a virtual play that allows the game designer to explore the order of the interactions with the NPC's, to observe the behaviour of the NPC's and to evaluate the timing of the game."

Game sketching technology is "rather primitive"

Focus on "ideation" not building

Game sketching can help create new ideas for games since it is done at a very early stage

Game sketching is not supposed to consume a lot of time or resources. This is so if something goes wrong with it it's not a big deal.

This is because they wanted to relate back to early game production, where games would have a small budget and only usually take around 3 weeks to make. If something went wrong with them, the game designers were not bothered by it, since they could immediately start another small project with no major loss.

The idea of this was that it should be fun to do. The idea of making games is that it is something people should enjoy to do.

The value of game sketching

Game sketching gives teams a clear idea shared vision of their game. Having a shared vision of the game then helps them deliver "stronger worlds"

Game sketching allows teams to learn how levels should work, how people should interact with things and how characters within a game should act. It allows team members to focus on how the game should work, not how it looks.

Where Game sketching comes in

Game sketching does not replace any of the the current activities that take place during pre-production.


The diagram shows that it would come in around the same time as the design document, or just after it. For game sketching to work games teams need a script. This can be made during the design document. So once the sketching team has this information, they can start sketching.

Sketching does not require any artwork or assets that would go into the final game. This means sketching can be done before any artwork is started.

Limitations

No assets created during a game sketch are used in the actual game

Artwork needs to remain basic

You cannot build things with the software used for game sketching, although the aim of game sketching is not to build things

Game sketching only really works in a game with a linear narrative

"Primitive" software can be frustrating

Monday, 16 February 2009

Business Rules for Developing Games

The Game Project Triangle

The benefits of using a game project triangle are;

  • It is a useful device for analyzing the goals of your project
  • Can help manage cost, time and quality of a project
  • Can help you realise what you should focus on
  • Since a game can only meet 2 of the 3 criteria, it will help you realise what your main focus is
  • It will also help you know which of the three things you need to sacrifice in order to make your game successful

Questions for me to answer

What are you trying to accomplish with this game?

I
I am trying to implement my games concept into a basic games engine, which is Flash. The game doesn't need to be too long, and only has to show enough to demonstrate what I can do.

When must you complete this game project?

20th March

How much money do you have to produce it?

£0.00

Who do you have to get the job done?

Just me

Ultra Low Budget Games

These are the main things you need to achieve for an ultra-low budget game;

  • A few key features of a game done well instead of a lot of features done poorly
  • Games should be simple
  • Games should be polished to a high level
  • If you are making a mod of an existing game engine you should try and make it new in a new and exciting format
  • Can easily be made as a casual hobby and gradually built up

Primary, Secondary and Tertiary Features

Primary features - Your project must support all of your primary features. These are the most vital parts of your project, which need to be completed in order for the project to have a decent quality

Secondary features - These are not as important, they are usually completed when you have some spare time, or when all the primary features are complete. Primary features may be moved into this category if time is running low

Tertiary features - These are the least important features of a project. If time is important these will more than likely be ignored, and should include the things the project can easily run without. If a project had as much time as they wanted, the tertiary features would be used, giving the project higher quality, but also costing more.

Categorising games in this way can support your development because it can help you realise what the important things are that you need doing. This way you can focus on putting the key aspects of your game in, and doing them well. Once this is done you gone go on to the secondary

Sunday, 8 February 2009

Game Assets

Definitions of an asset

"Things you own"
Link 1

"anything of material value or usefulness that is owned by a person or company"
Links 2

Definitions of a Game Asset

"artists develop game assets such as sprites or, more often today, 3D models of game elements"
"Game assets are the "things" that go into a game"
"Sometimes the terms content or objects are used interchangeably with the term assets."
Wikipedia

"Game assets are everything that contributes to the visual appearance of the game"
"from the drawing board into production, where concepts materialise into game assets"
Link 4

"game assets, which are the collection of data files used to support gameplay such as bitmaps, models, textures, or sounds"
Link 5

In my opinion game assets are basically everything that makes up a game that supports the gameplay. They include everything you can see and hear, including both basic and complex character animations, facial expressions, skins, textures and many more things. Games assets are also associated with content, which backs up the idea of games assets being everything you would need to support the gameplay. Without assets a game wouldn't be anything.

Monday, 2 February 2009

Games Crit Sheet

The following is my template design for a games crit sheet, based on the crit sheet from the lecture.

Game Title

Short description of the games concept


Rate each section out from -2 to 2. -2 being poor, 0 average, 2 good.

1. How clear is the concept? Did you understand what you had to do?

2. How clear were the interactions? Could you easily see what options you had?

3. Implementation - Did the game feel smooth? Was it easy moving to where you wanted to go?

4. Playability – Was the game fun/interesting/compelling. Did the user look like they were enjoying it?

5. Visual – Were the graphics good? Could you tell what everything was supposed to be?

6. Feedback – Did the game give you feedback on your actions? Did you know what was happening when you interacted with things?

7. Contextual Gameplay – How did you find the interfaces for interaction?

Overall score

-14 to -10 - Extremely Poor
-9 to -4 - Poor
-3 to 3 - Average
4 to 9 - Good
10 - 14 - Extremely Good


Games Crit Sheet 1

Game Title

4 of Clubs

Short description of the games concept

A soldier loses money in a card game, has a drink and then decides he has to kill the 3 people he was playing cards with quietly and without being found out. To do this he must find the right weapons and distract the appropriate people.

Rate each section out of 5. 1-poor 3 average 5-excellent

1. How clear is the concept? Did you understand what you had to do?

2, the concept is easy to understand, although not particularly interesting

The whole concept in a sentence. After being forced to watch a long, text based cut-scene.

2. How clear were the interactions? Could you easily see what options you had?

-1, wasn’t obvious where all exits were or what could be interacted with at times. After selecting an option, you always went back to the walk option, making the game slightly annoying

You are told you cannot leave the room, for a reason that you later find out is pointless. You must click on the rifle and find out you are not allowed to use it, before carrying on with the game.



3. Implementation - Did the game feel smooth? Was it easy moving to where you wanted to go?

-1, the game didn’t feel smooth, it looked like it took too long to do certain things. Some of the interactions didn’t feel smooth and seemed awkward.

4. Playability – Was the game fun/interesting/compelling. Did the user look like they were enjoying it?

-2, the player did not get far into the game before becoming bored with it. An error occured twice during testing. Both errors led to the game having to be restarted.


The error message after a second unknown problem

5. Visual – Were the graphics good? Could you tell what everything was supposed to be?

0, didn’t stand out as being terrible, you could tell what was what, but there was nothing impressive about the graphics

6. Feedback – Did the game give you feedback on your actions? Did you know what was happening when you interacted with things?

0, the game gave appropriate feedback for some situations, but not all. Sometimes further explanation could have helped.

7. Contextual Gameplay – How did you find the interfaces for interaction?

-2, tabs were easy to find, but always went back to the walk command after use. Making the game frustrating


Overall score
-4. The game is poor. Nothing stands out as being particularly good. The only thing you could claim as being good was the story not being too had to follow. I do not think the crit sheet worked well for this game, this is because although it did show that the game was poor, -4 still seems like a generous mark to give the game. This is because it was just as easy for the game to gain marks on less important things such as grpahics, than it was to lose them on thinkgs such as playability.

To fix this next time, I would consider weighting the questions, so that more marks can be lost or gained on sections such as playability.




Games Crit Sheet 2
(Please Note: Whenever I attempted to take screenshots for this game they came out completely black with some white outlines to a few things, so screenshots could not be provided for this game.)

Game Title

6da
Short description of the games concept

Your character is about to receive some very important information from someone, when they are shot by a sniper. You must make your way around the room to retrieve equipment without being shot.

Rate each section out of 5. 1-poor 3 average 5-excellent

1. How clear is the concept? Did you understand what you had to do?

1, the user understood the basics of what to do. But did not understand what the actual aim of the game was. Was it to escape? Was it to kill the sniper? Was it to find out the important information?

2. How clear were the interactions? Could you easily see what options you had?

2, the interactions were not obvious, but once you found them they were not hard to use. The game is supposed to be a puzzle, so if you could see all the interactions easily, the game would not be a challenge.

3. Implementation - Did the game feel smooth? Was it easy moving to where you wanted to go?

1, most things about the game felt smooth and that they worked well. But one problem was when you observed things in the room, the character would speak. Sometimes he went through 2 or 3 blocks of text, making the game break up a bit.

4. Playability – Was the game fun/interesting/compelling. Did the user look like they were enjoying it?

1, the game was fun at first, but was very difficult. If you get stuck at the start of a game, it makes you want to continue less. So the game could have been improved with a better learning/difficulty curve.


5. Visual – Were the graphics good? Could you tell what everything was supposed to be?

0, the graphics were good enough to help the user understand what was what and what they could interact with. They didn’t stand out as being anything special though.

6. Feedback – Did the game give you feedback on your actions? Did you know what was happening when you interacted with things?

2, if you tried to interact with something that you shouldn’t, the character explained why he couldn’t do it. If you picked something up, the character made a comment. It was generally easy to understand what was going on.

7. Contextual Gameplay – How did you find the interfaces for interaction?
1, it was easy to see which interactions did what. The exit logo could have been better though. The user clicked it more than once wondering what it does.


Overall score
8 - The game is good.The only real problem with the game was that it started off a little too difficult. I believe the crit sheet was okay for evaluating this game, but could have done with another section about difficulty within the game. But this could have been covered in the playability section anyway.

What I have done

To complete this task I have created my own crit sheet based on the crit sheet we used in Lecture 9. Since the crit sheet is being used for the same type of thing, there is not much difference. Although I did add in an extra section about the game giving feedback, since this is usually a very important part of games, especially ones with limited graphics capabilities.

To fill in the crit sheet I asked someone else to play the game, while I took notes. I then asked some basic questions after about what they thought. I then played through the games a little to take screen shots and see if I felt the same way about the game as them.

I used the same rating system for my crit sheet as the the one from the lecture because, it is simple and easy to use. The positive and negativ results help show whether a game is good or bad.

This studio helped me realise what sort of things need to go into an AGS game to make it more enjoyable and succesful. It also helped me realise what sort of things you should be looking for when analysing a game, and helped me realise what ele would need to go into a crit sheet if I were to do this task again.

Monday, 24 November 2008

Studio 7 - Exploring Playability

The 4 Fun Keys create games' four most important emotions:
1. Hard Fun: Fiero - in the moment personal triumph over adversity
2. Easy Fun: Curiosity
3. Serious Fun: Relaxation and excitement
4. People Fun: Amusement
From http://www.xeodesign.com/whyweplaygames.html

Game 1 - Spin the Black Circle

Aim: Get a ball from one location to another, by spinning a black circle to change the gravitational pull.

www.onemorelevel.com/game/spin_the_black_circle

Notes
Hard fun

Challenging
Game can be frustrating, but happy at the end of each level - sense of accomplishment.
User feels like they have achieved something when they complete a level.
User eventually become frustrated with a harder level and gave up
High learning curve, few tips.

Types of fun

This fits in with hard fun because the main sense of achievement came when the user completed the level.


This does not fit under, Easy fun because games that count as easy fun are usually relaxing and easy to play, with very little challenge


This does not fit under, Serious fun because it is not an exciting type of game, and the main enjoyment comes from completing levels.


This does not fit under, People fun because there are no other people to play with. There is nowhere to submit high scores and there is no multi-player option, so you can't compete or with work with anyone else.


This does not really fit under the flow theory because once you get to a certain point, you can become stuck easily, and with the lack of competition, there is no real reason to carry on. Once the main enjoyment factor of being able to complete levels is taken away, you are mainly left frustrated.
It is also, not engaging for a long time, there is a steep difficulty curve, which can make the game too hard, which is shown by the player getting stuck at certain points for a long time.

Game 2 - Blueprint

Aim: Use a range of devices to move a ball from one place to a target

http://www.teagames.com/games/blueprint/play.php


Notes
Hard fun
Serious fun
Flow Theory

Challenging
User looked frustrated at times, but looked like they were having fun at others.
Best part of the game appeared to be completing the level, which is when the best sense of achievement came.

Types of fun

This fits in with hard fun, because some levels can be frustrating while trying to figure out how to complete them, and the main enjoyment from the game comes from completing it.


This fits in with serious fun to a certain extent because it can be exciting to see how your designs play out. Parts of the game can be relaxing, but it wouldn't be a good work to describe the game with.


This fits in with the flow theory because you know what your goal is throughout the game, and there is a good balance of the difficulty, which is helped by being able to select which level to play.


This does not fit in with Easy fun, because the main aspect of easy fun is learning new things and exploring, which this game doesn't offer much of.


This does not fit in with People fun because you cannot talk to, play against or play with other people. There is no social interaction. The only part that comes close to this is a high scores table.

Monday, 17 November 2008

Studio 6 - Exploring Playability

Part 1 - Summary

  • Every game development project is unique
  • All games need new content and must focus on improvements
  • The game development process consists of two main parts
  • The first part is going from an idea to a plan, the plan will change as it moves into the production phase
  • During preproduction, the team prepare all the elements that are involved in the main process
  • The idea gets put into a design document, which is used as an outline throughout the development process
  • Having the right development team is the most important ‘resource’ of game development
  • Members of most teams are put into their positions during preproduction, and each team has a leader, and each group of teams will have a leader
  • The project leader will be the one who produced the ‘high concept’
  • Before anyone begins work, everyone must understand the main aims
  • The design document is a blueprint for the game, it describes everything, including how the game will be played
  • A design document should have a world diagram or mission flow chart, which maps out where the player should go. These will usually start out as a list of locations and objectives.
  • Level designers use the design document as a guide to create a level diagram

Part 2 - Similarities

  • Both readings state that the design document is extremely important
  • Both think that the design document shapes the idea
  • Both readings say that the design document includes everything about the game, including the characters, the controls, what you do and how the game is played
  • The design document is where games designers get to ‘flesh out’ their ideas
  • A design document requires input from the entire team, it is very hard to finish one(for a big project) on your own

Part 3 - Differences

  • Bethke states that the design document should be used to answer further questions about the game.
  • Bethke doesn’t mention mission flow charts
  • Bethke does not go into as much detail about how all the members of each team have to communicate with there ‘leaders’, so that the design document can be continuously improved until everyone is ready to move forward with the development process.