Welcome to Unit 71
Object Oriented Design

What is object oriented design? is it coding? Jargon important in OOD? UML? NO CODING!! object oriented comes in three diffent forms we have,

• object oriented + Anaylsis (Understand)
• object oriented + design (Plan)
• object oriented + Programming (Build)

Lets look at these areas, Anaylsis and design come together in most cases and are possibly one of the most important stages either combined or seperately.
So lets look at the the elements, Anaylsis we at this stage look to at "Understanding the Problem" "What it is we need to do", Design but not in the term of visual appearnace but more of the "plan, Conceptual, how we are going to do it!" at the design stage there will NOT be code/programming but there will be sketches on paper, whiteboards, written descriptions and diagrams.
 

In order to understand OOD lets use an example!

So lets look at these enemys from an OOD point of view, the enemy is the same but the different "instances" of it have alterantive behaviours however they have the same roots. So this is where we refer to instansiation (this will be covered later in this unit).

Lets start at the beginning

Software Development Methodologies

There are a number of different software development methodologies available these are listed below, these are varied in the SDLC as some are lose in there approches as some could be used for large systems such as banks others are more suited to small applications such as an IOS app.

1. Scrum
2. Extreme Programming (XP)
3. Agile Unified Process
4. Adaptive Software Development
5. Rapid Application Development

Our Approach to developing software in games

We sould firstly look at the way in which we look at our software development in games.
Agile itterative VS Waterfall approaches
 

Waterfall

Used in the first few decades of programming around the 1980 the usual approch to software development was using the "waterfall" approach, a strict liniar approach that has a series of steps that were followed step by step, and each of these steps were signed off at each stage once complete. What are they and how do they work? 

• Stage One, Planning, what and where we need to go/do
• Stage Two, Analysis, We need to gather our information to the requirements of our clients, this is vital for us to understand the problem
• Stage Three, Design, Create a proposal of the intended outcome based on the information provided.
• Stage Four, Implimentation, Creation of the product based on the agreed designs.
• Stage Five, Matainence/Operation, ensure smooth functionality of the finalised product

The problem is that this DOESN'T work! The momment that you get to the implimentation stages where code is written the likeliness is the problems that you hadnt thought of will be hit. These could be customers changing thier minds, you could change your mind, factors beyond your control may have changed. These changes may make the original elements planned earlier in the SDLC (systems development life cycle) approach look stupid.
This approach just will not work on a software development project however it could work on the building of a house.
 

Agile Approach

What is an Agile approach?, Responsive, adding of new features, patching, debugging, supporting continual development thus supporting continual anaylsis and design.
So begin Agile allows for iteration, this is where any development included a number of cycles, and each of these include analysis, design and programming, and these can be done multiple times in one stage. 

ACTIVITY
Using the File in the resource are and the video, list the Goombas, and the common properties and behaviours that they have.
Using sheets of paper, review the process of creating a cake! Show these to a small group of people and see what they think.

Anonymous Assessment - Learners assess an anonymous piece of work containing deliberate mistakes against given success criteria.

Understanding Object Oriented Programming

So how does it work? Object oriented programming came about after the year of linar procedual programs that became large and full of events and behaviours that may/may not be triggered however these were required to be built in to the sytems. Over the decades OOP (object oriented programming) became more favoured and popular, this meant the large long continual pages of code and programming could be built in to small self containted objects that acted like mini programs. Each object could contain its own data and its own logic, and each object can communication between themselves. So each of these objects could represent elements of a system such as players, enimies, platforms, power-ups e.t.c.

Understanding What an Object is!

So to understand what an object is you could think of everything that is tangable (something that can be seen, hear or touched), so this could be the desk that your sitting at, the monitor your using to read this text or the chocolate bar that you purchased from the shops this morning.
However objects can also be intangible things that exist but are not physical in nature these are things like, Bank accounts, Leaderboards, Open worlds, Players, Weapons, Power-ups. Therefore anything that "EXIST" can be an object.

Although that objects are vital in OOP the most important part to start with is that of the "Class".

Understanding What an Class is?

The term class is stated as being .."The collection of Properties and Methods". These classes act like a template/stencil that are used to create an Object.
Object Oriented Design make use of images and diagrams to help present the concept of the program visually so that the programmer can create the code for the project.

So what do these classes look like in a diagram?

The image below shows the typical layout of a class, however in this instance there are three classes, two of the classes (Child Class)"inherit" from the other (Parent Class), we will cover "Inheretance" later in these tutorials.

+-----------+
| ClassName |  ← This is the title of the class
+-----------+
| data1     |  ← This is the data of the class, these can be, ID, DOB (date of birth), Address
| data2     |
+-----------+
| method1() |  ← This is any methods that may be used, this could be having a bank account, 
| method2() |        to enable the open, close of the account or deposit/withdrawal of cash.
+-----------+

1.Now that you have some understanding to the use of classes carry out a decontructive analysis of Mario World level 1-1. (You may have access to the emulator of the game). Using the game first create a simple bulleted list of the attributes you can see in the game, then add further information once you have gathered the points that you think are there. You shoulf use the Class Diagram above as a guide, try and create a simple class diagram of the Mario game (Mario world 1-1). Think about all elements of the game. E.G Character (Hero, Enemy) You may use a tool to create this diagram, such as Visio


2. Now that you have looked over the game and have created a diagram, you are to create the story of the level using the information gained from the level demonstration by your tutor. This narative/story will enable you to review the NOUNS in the narative and to ensure that your orriginal diagram has the correct classes.


3.Fill in the Gaps!

Anonymous Assessment - Learners assess an anonymous piece of work containing deliberate mistakes against given success criteria.

Understanding Object Oriented Programming

There are a number of key terms that we must consider and fully understand when using classes. These are Fundimental, and these are

• Abstraction
• Polymorphism
• Inheritance
• Encapsulation

an easy way to remember this is A PIE (Yum) 

Understanding What Abstraction is!

Time to clear your head, think of nothing, now, im going to say a word, this word may not be some thing that would generally talk about but bare with me.
A Trainer You know what i mean, however you have an idea of a trainer, it may not be the same as the trainer i have in mind, size, colour, velcro or lace but you understand the idea of the trainer, the "Absraction" of the Trainer. You have seen many trainers "Abstract" the understand them. So the absration of the product is to focus on the essential qualities of the item and not the specifics of an example, therefore we get of the irelvant information.
So lets look at the absration of a class, we can use the example of an back account. Lets suppose that we have two bank accounts as below,

+-----------+      
| Bank Acc  |      
+-----------+    
| Account No|  
| Balance   |
| Date Open |
| Acc Type  |
+-----------+      
 
+-----------+        +-----------+
| Ab002     |        | AB003     |  
| £-250     |        | £2000     |
| 12/12/69  |        | 25/06/12  |
| Checking  |        | Savings   |
+-----------+        +-----------+
    Joe                   John

Understanding What an Encapsulation is?

The use of encapsulation in OOP is best covered by first understanding of the word encapsulation. If you think of the word encapsulate this refers to a container this could be a bowl, a medical capsule, a bottle, so what do these do?, they not only keep the components within the capsule together but they also protect them. Takes the attributes and the behaviours and puts them in to a unit/class.

+-----------+      
| Bank Acc  |      
+-----------+    
| Account No|  
| Balance   |
| Date Open |    ← Attributes
| Acc Type  |
+-----------+  
| Open ()   |
| Close ()  |
| Deposit ()|   ← Behaviours
| Withdraw()|
+-----------+    

 

So within these classes we may wish to hide the data, this is known as "information hiding/data hiding" the idea is that the object should NOT reveal any information about itself except only that what is necesary to enable other parts of the application to work.


Example;

+--------------+      
| Player       |      
+--------------+    
| Player ID    |  
| Name         |
| Date spawned |    ← Attributes
| Lives        |
+--------------+  
| Alive ()     |
| spawn ()     |
| lives ()     |   ← Behaviours
| Power up ()  |
+--------------+    

 

We dont want any other part of the application to reach inside this object and change the lives of the player without going through the lives behaviour. These behaviours are designed to reduce the lives of the player if they are hit by an enmy. So with data/information hiding we can hide that attribute which means we can control access to it so that it is only accessable from with within that object itself.
This is commonly refered to a "Black Boxing"

Understanding What an Inheritance is?

The use of inheritance is widely use accross a number of coding language and the concept is based around efficency, and this is based on the reuse of coding. So, where a new class is required and is based on an existing class. Lets refer to an example to assist you in understanding this.

	+--------------+      
	| Player       |      
	+--------------+    
	| Player ID    |  
	| Name         |
	| Date spawned |    ← Attributes
	| Lives        |
	+--------------+  
	| Alive ()     |
	| spawn ()     |
	| lives ()     |   ← Behaviours
	| Power up ()  |
	+--------------+   

You have in this class set up your understanding to the needs of the characters in the game that you wish to create however at a later date you understand the you will need to introduce enimies and heros, these classes will have attributes that are identical to those that are created in the player area, so, why would we repeat these? The only difference is that they may have some additional attributes. So we wouldnt add these to the player class as this is not required, we are trying to use "Abstraction" and remove all un-required information and only have the essentials.

 
			+--------------+      
			| Character    |      ← (Parent Class or Super Class)
			+--------------+    
			| Player ID    |  
			| Name         |
			| Date spawned |  
			+--------------+  
			| Alive ()     |
			| spawn ()     |
			+--------------+ 
				↑
			Inherits from  

 	+--------------+    	+--------------+      
	| Hero         |    	| Enemy        |    ← (Child Class or Sub Class)  
	+--------------+    	+--------------+    
	| Lives        |    	| type         |
	+--------------+    	+--------------+  
	| lives ()     |    	| lives ()     |  
	| Power up ()  |    	+--------------+ 
	+--------------+    	

When we use the use of inheritance in UML we must ensure that we use the correct symbols, these are hollow directional arrows

Understanding What an Polymorphism is?

The definition of Poloymorphism in OOD is "many forms" this allows a class to automatically do the correct behaviours even it takes one of many forms. The area of Polymorphism can be a complex area and the best way to understand how it works is by looking at the addtion sign (+), if we are adding the contents of A + B as integers we could end up with 5 + 6 = 11, however if we consider what happens with strings is that it will concatenate them therefore presenting "Hello + World" as HelloWorld. So both are doing the correct behaviour but different behaviours.

Lets look in to linking this our classes. In this instance i will be looking at using the example of a bank account. We all have bank accounts however these can be different.

		+-----------+      
		| Bank Acc  |      
		+-----------+    
		| Account No|  
		| Balance   |
		| Date Open |
		| Acc Type  |
		+-----------+      
		| deposit ()|
		| Withdraw()|
		+-----------+
 	↗		↑	     ↖
+-----------+        +-----------+      +-----------+      
| Check Acc |        |Saving Acc |      |Invest Acc |      
+-----------+        +-----------+      +-----------+      
|All from   |        |All from   |      |All from   |
| (Bank Acc)|        | (Bank Acc)|      | (Bank Acc)|
| Last Check|        |Interest   |      | accountRep|
+-----------+        +-----------+      +-----------+
|           |        |           |      |withdraw ()|   ← Overriding  
|           |        |           |      |           |
+-----------+        +-----------+      +-----------+
                       

So if we look at the three accounts these all are sub classes of the parent class of Bank Acc, however these are all specialised but inherit from parent.
But lets look at when the investment account has money widthdrawn from it, there are penalties that are applied which means that the orriginal widthdraw behaviour will need to be different, so currently the nature of the "Inheritance" of the original widthdrawal will need to overriden and this is done by adding it to the subclass.
So we have in this example polymorphised the withdraw behaviour so that we can do the right action at the right time.

 http://www.visual-paradigm.com/VPGallery/diagrams/Sequence.html

Review the video using the following link VIDEO and create notes to support your controlled assessments. Fill in the Gaps!

Anonymous Assessment - Learners assess an anonymous piece of work containing deliberate mistakes against given success criteria.

UML

Now that we have looked over the use and creation of Class diagrams we should now look over the rest of the other UML (unified modelling language). These diagrams are often used to support other UML documentation and supports things like the flow of data and the conversation between modules, states and objects.
The UML models that we have at our disposal are as below;

1. Class Diagrams
2. Sequence Diagrams
3. Use Case Diagrams

Sequence Diagrams

The diagrams are common kind of interaction diagrams that focuses on the message exchanged between objects. This is commonly used to look at how users and the system interact.

Sequence diagrams model important runtime interactions between the parts that make up the system, these show object instances that play the roles defined in a collaboration.
How these work are that they show the order of the interaction visually by using the vertical axis of the diagram to represent time what messages are sent and when.
A sequence diagram is made up of a collection of participants
Participants – the system parts that interact each other during the sequence
Classes or Objects – each class (object) in the interaction is represented by its named icon along the top of the diagram
 

Lets break it down

Looking at the sequence diagram example you will see a number of points, firstly lets look at the top.
as you can see in the image there are a collection of boxes, these boxes are representitve of objects, the "Participants". These are the points of which the communication and interaction happen.
Underneath these boxes you will see a number of vertical dashed lines, these are representitive of the "life Lines" the time line of the object. So we look at the timeline as the conversation line/ interaction between the objects.
Let's look over this in the example above. We can see that the example is of a simple process that is making a phone call.
The image displays the break down of the process well and the steps in which the objects interact, this would be process such as picking up the reciever, hearing the dial tone,dialing the number,ringing once the full number has been dialed,audio prompt of the ringing sound,recipent answers, discussion begins.
 

Sequence diagrams describe how objects interacts in performing an activity.
Tipically a sequence diagram desccribe a single Use Case!

Adding a picture to Flickr (or any online image database). Login, pick an album, upload a picture, etc… Think about the software classes that would be involved – WebGUI (think of this as reporting what the user does), UserAccount, Album, AlbumList, etc…

Don’t forget to check and update their current disk usage. For this diagram show the check coming back as acceptable.. you would do a second diagram for them running over quota.

Sketch a sequence diagram for the “normal” operation of an ATM (i.e. a customer inserts the card, enters his/her PIN, enters the amount, takes the card, and takes the money). The sequence diagram should show the interaction between the different components of the ATM. The ATM consists of the following components:
•screen
•keyboard
•card reader
•money tray
•money output device
•interface to banking server (for modifications of the account data of the customer)

The scenario begins when the player chooses to start a new round in the UI. The UI asks whether any new players want to join the round; if so, the new players are added using the UI.
All players' hands are emptied into the deck, which is then shuffled. The player left of the dealer supplies an ante bet of the proper amount. Next each player is dealt a hand of two cards from the deck in a round-robin fashion; one card to each player, then the second card.
If the player left of the dealer doesn't have enough money to ante, he/she is removed from the game, and the next player supplies the ante. If that player also cannot afford the ante, this cycle continues until such a player is found or all players are removed.

Anonymous Assessment - Learners assess an anonymous piece of work containing deliberate mistakes against given success criteria.

Usecase Diagrams

A use-case diagram is a uml diagram of how different types of users/actors interact with the potential system. The diagram describes the goals of the users, the interactions between the users and the system, and any required behaviours of the system in satisfying these goals. A use-case model consists of a number of model elements. The most important model elements are: use cases, actors and the relationships between them.

Association

Association is a broad term that encompasses just about any logical connection or relationship between classes. For example, passenger and airline may be linked as above

Directed Association

3 Directed Association refers to a directional relationship represented by a line with an arrowhead. The arrowhead depicts a container-contained directional flow.

Reflexive Association

Reflexive Association occurs when a class may have multiple functions or responsibilities. For example, a staff working in an airport may be a pilot, aviation engineer, a ticket dispatcher, a guard, or a maintenance crew member. If the maintenance crew member is managed by the aviation engineer there could be a managed by relationship in two instances of the same class.

Multiplicity

Multiplicity is the active logical association when the cardinality of a class in relation to another is being depicted. For example, one fleet may include multiple airplanes, while one commercial airplane may contain zero to many passengers. The notation 0..* in the diagram means “zero to many”.

Aggregation

Aggregation refers to the formation of a particular class as a result of one class being aggregated or built as a collection. For example, the class “library” is made up of one or more books, among other materials. In aggregation, the contained classes are not strongly dependent on the life cycle of the container. In the same example, books will remain so even when the library is dissolved. To render aggregation in a diagram, draw a line from the parent class to the child class with a diamond shape near the parent class.

Composition

is very similar to the aggregation relationship, with the only difference being its key purpose of emphasizing the dependence of the contained class to the life cycle of the container class. That is, the contained class will be obliterated when the container class is destroyed. For example, a shoulder bag’s side pocket will also cease to exist once the shoulder bag is destroyed. To depict a composition relationship in a UML diagram, use a directional line connecting the two classes, with a filled diamond shape adjacent to the container class and the directional arrow to the contained class.

Inheritance / Generalization

Inheritance refers to a type of relationship wherein one associated class is a child of another by virtue of assuming the same functionalities of the parent class. In other words, the child class is a specific type of the parent class. To depict inheritance in a UML diagram, a solid line from the child class to the parent class is drawn using an unfilled arrowhead.

Realization

Realization denotes the implementation of the functionality defined in one class by another class. To show the relationship in UML, a broken line with an unfilled solid arrowhead is drawn from the class that defines the functionality to the class that implements the function. In the example, the printing preferences that are set using the printer setup interface are being implemented by the printer.

So lets recap on what we have covered over the past few weeks, to simplify OOD and OOP, we use OOD to enable us to create a collection of diagrams and documents to enable us to organise our understanding of a system or game to then enable the programmers to use a defined programming style used to organize code in OOP.

Video games can have anywhere from a few thousand lines of code, such as the example of Cut the Rope of wich has 15,000 lines to millions of lines of code Crysis has over a million.

https://lh5.googleusercontent.com/IFB_KaDWAkmDX9HNB-nxrLFw89Nd5OVNEW3RZCzUoj23cSRMqVLkJ5Lkck2XfOwUuiDc1rlQ=s640-h400-e365

States are the characteristics of the object, or the words you would use to describe it, and usually take the form of is or has descriptors. (Remember our video) A computer is either on or off, a chair has four legs, and you have a name.
Behaviors are the things the object can do, or the actions the object can perform, and are usually verbs that end in "ing". You are sitting, using a computer, and reading this article.
We must remeber that the whole purpose of OOD and OOP is to create reusable code by following the DRY (Don't Repeat Yourself) method: write the code once and then reuse it, rather than copying and pasting.

Uk Creative Industries - International Stratergy driving global growth for the uk creative industries is a plan to double creative industries services exports by 2020 to £31 billion (UK GOV)

Asteriods

To identify what the objects are in Asteroids, try describing it. Wikipedia describes Asteroids as follows: The objective of Asteroids is to score as many points as possible by destroying asteroids and flying saucers. The player controls a triangular-shaped ship that can rotate left and right, fire shots straight forward, and thrust forward. As the ship moves, momentum is not conserved – the ship eventually comes to a stop again when not thrusting.
Think about what in this description could stand alone, or the things that are described that could have state and behavior. These become our objects.
The objects for Asteroids are: a ship, an asteroid, a flying saucer, and a bullet (can't forget those!). The cool thing about objects is that we normally describe things in terms of objects in everyday talk, so they usually reveal themselves through a description.

The classic game of Asteroids
Now that we have identified our objects, let's define the state and behavior for one of them: the player's ship. Think about what attributes describe the ship; these are its states. Then think about what the ship can do; these are its behaviors.

A ship has states of:
rotation
momentum
thrust

and behaviors of:

turning
moving
firing

I'll let you determine what the remaining objects' states and behaviors are.

OOD and OOP in action, Click Here

The Uk games development sector is reported to contribute £1 billion to the UK Gross Domestic Product per year. (TIGA)

The original Pac-Man arcade game

The player controls Pac-Man through a maze, eating pac-dots or pellets. Four enemies [ghosts] roam the maze, trying to catch Pac-Man. Near the corners of the maze are four larger, flashing dots known as power pellets that provide Pac-Man with the temporary ability to eat the enemies. The enemies turn deep blue, reverse direction and usually move more slowly.
For Pac-Man, there are three objects:
Pac-Man,
a ghost,
a pac-dot.
A power pellet isn't really its own object because it's a special pac-dot (we'll talk about what to do about this in a later article). We'll describe the ghost object because it's more interesting. The ghost has states of: color name (+1 if you can name all the ghosts off the top of your head) state (eatable or not) direction speed and behaviors of: moving changing state

Using your newly gained skills from the previous weeks activities in the sequence diagrams, now start to construct a sequence diagram for your Mario worlds 1-1 walk through.

The Uk games sector is generates £2 billion in global sales each year. (TIGA)

Anonymous Assessment - Learners assess an anonymous piece of work containing deliberate mistakes against given success criteria.

Coursework Prep

So lets simplify our understanding to the use of OOD in to chunks,

Why?

Why do we use UML? What purpose is it, is it not better to get straight in to the coding and construction of the game or board game?

Here we make our arguments to why we agree that it is the place to start any game development, it is a point that we can enable our team and potential financial backers to see and understand the scope and size of our game proposal and potential future improvements and releases. The UML allows you and the team to split the project in to groups sections and specialisms based around the clear identification of elements within the game. As Shigeru Miyamoto states;

A delayed game is eventually good, a bad game is bad forever

Factoid
The Nesta & Ukie study counted 1902 video games companies in the UK, employing approximately 9,200 creative staff and indirectly support more than 16,800 jobs.
Nesta & Ukie, September 2014.To see the article Click Here

Therefore we know that it is essential that we use these UML tools to save time repairing something that should have been identified at the initial planning stages using the UML to identify things like polymorphism in classes and objects and to identify occurrences where inheritance is used. Remember that we are using UML to not only help us plan out our proposals but for us to also outline opportunities to reuse instances of code and reduce the need to copy and paste commonly used elements. By using these opportunities of creating modular blocks of classes and system objects we can save time and money, therefore making the whole process more efficient. If we think back to our Mario example the cartridge of the game was limited to its size, a common issue still to this day (hence Downloadable Content or DLC) therefore using objects of inheritance we can minimalize the code footprint on the shipping platform.

When looking at the whole process, we can allow our developments now to creating the objects to be the platform to the improvements in the next release of the game, this would then save the recreation of game elements such as the character power-ups and the enemy’s to enable the improvement of these without completely rewriting the entire object again.
 

A software library is a good example of code reuse. Programmers may decide to create internal constructs so that certain parts of their program can be reused, or may create custom libraries for their own use. Some characteristics that make software more easily reusable are modularity, loose coupling, cohesion, information hiding and separation of concerns.

• Modular programming is a software design technique that emphasises separating the functionality of a program into independent, interchangeable modules, so that each contains everything necessary to execute only one aspect of the desired functionality.
• Coupling: A loosely coupled system is one in which each of its components has little or no knowledge of the definitions of other separate components of the system.
• Cohesion is used to describe the degree to which the elements of a module or system belong together.
• Information hiding is the principle of separation of the design decisions in a computer program that are most likely to change, thus protecting other parts of the program from extensive modification if the design decision is changed.
• Separation of concerns is a design principle for separating a computer program into distinct sections, such that each section addresses a separate concern

The objects within our games will all have properties, some of which can be inherited from other objects and some are overwritten and superseded by the behaviour of that new instance of the object. It is work remembering that the heros and enemy’s may share properties that could enable them to be linked to a parent class (refer to week 2 if this term has no meaning) therefore reusing code elements and making them efficient. Properties could be, size, speed, movement, sounds, health and lives. The classes may have behaviours and events that are triggerable, these could be the creation of a new spawn, the destruction of an enemy using a destroy behaviour, a detection of a collision between two sprites, timers that set a level completion or the scoring of the player in the game.

 

Real World Modelling

Real World Modelling is one of the most powerful aspects of object-oriented programming. This is making objects that you know in the real world into objects in your system. Because we all live in the real world, it is easy for others to immediately understand what an object is and does if it is based off of something real world.

A customer, shopping cart, and product in an e-commerce store are immediately recognized and their interactions between each other are understood easily, because we can see the same interaction in our daily lives. We know that there can be many products in our shopping cart. We know that each customer may have a shopping cart to put their products in. We know that customers have names and addresses, and that products have names and prices. The programmatic shopping cart however may have related functionality that a real shopping cart may not have. It may be able to tell us the total price of all the products in it, where a real cart can’t do anything but roll around (something not needed in an ecommerce store).

The first thing you might do when developing a system is to discover all the real-world objects in that system. Whether it is employees, supplies, offices, text characters, documents, buttons, or rubbish bins, they all help us think of the system easier and model it better. We already know many of the objects’ interactions and who “owns” what (the customer owns the shopping cart and the cart owns the products). These real world objects may even be the groupings of objects instead of the objects themselves. Or they may be objects that help group others. You might have a department object with its employees and manager. Once you have the real world objects you can then group them. The shopping cart, order, and checkout might go into the same section. You may put products and categories into the catalogue group. Customers and store admin may be their own group.



Looking back over the past few weeks we have now discussed UML and have created some examples of UML linked to systems that we use and to games that we have played now is the time to put your knowledge and understanding down in response to your provided assessment brief.

Now that we understand how that games are constructed from a number of objects such as characters; weapons; rooms; walls; scenery; instances; rewards, eg bonuses, power-ups we are on our journey to become games developers, planners and designers and not just gamers.

Remember the use of terminology and the analysis of words in your report are key areas in the level of your grades.

Good Luck.

Factoid:
Some 160,000 UK computer science and engineering students graduated in 2011, alongside 176,000 creative and design graduates. Although only a fraction of these will enter the games industry, these statistics illustrate the depth of the talent base constantly being refreshed in the UK.

Factoid:
A helpful piece of insperation; GAMES, WHY THE UK?

You have now been issued with your assignment, you should use your time in class effectively and use your notes and other sources of information to deliver the requirements of the task in hand.
Remember that this is a Controlled session and the appropriate rules MUST be followed when working.

Anonymous Assessment - Learners assess an anonymous piece of work containing deliberate mistakes against given success criteria.

Having now demonstrated your understanding to the use of UML we will now be applying this knowledge to our ideas of games and game design.

A Fantastic Article

found on http://superprofundo.com/, written by Mathew Preziotte.

What is Object Oriented Programming?
OOP is a programming paradigm. Not all languages support OOP, but most major languages do at this point. It exploits the idea that sometimes a computer programmer might want to code a “thing.” Let’s call that thing an object. That object might need to exist more than once, so why bother explaining it more than once? An “object” in this context, is a collection of data, functions, and logic that ties a single idea together. When an object is created, the blueprints for making that object is consulted, and some initial configurations might need to be set. These blueprints are called a class, and creating an object from this class is considered an instance of the object. Each class has a constructor, the function that runs by default when an object is created.
But when is this useful?

Example Videogames lend themselves nicely to a quick example. Super Mario World is full of objects! Let’s take that item block for example:

There are hundreds of shiny question mark blocks floating around Mario levels. It would be pretty wasteful and redundant not to use OOP here. In order to do so, we must ask ourselves what kind of data each block must hold. It needs a position (x-coordinate, y-coordinate), it needs to store the contents of the box itself (a mushroom, a coin?) , and it must have a state (has it been opened yet?). The item box also has several images associated with it, an animation, and a sound effect.

Now, how can this box be interacted with? It can be hit from underneath in order to open it. This would call a single function that will play the appropriate sound, trigger the appropriate animation, change the state of the box, reveal the contents of the box, and change the contents of the box to nothing. While the actual syntax for creating a class will vary from one language to another, the same general concepts will always apply.

See the Pen BjBKZV by james farrington (@jamesfarrington) on CodePen.

This basically encapsulates everything that would need to be in the blueprints for an item block. Now that we have our blueprints, how would we go about creating a new block? We must simply ask ourselves, what needs to be specified in order to create one? Each box needs a position in the level, and an item inside of it (most likely a coin). This tells us the parameters that need to be passed while declaring a new object. The following could be a declaration of a new item block containing a fire flower (which could itself, be thought of as an item object):

new ItemBlock("900px", "37px", "Fire Flower");

Well there you have it. We have successfully abstracted the concept of an item box. Maybe this will change the way you see videogames forever.

Some Vocab
A class can be thought of as the blueprints for an object. It contains all the data structures, logic, and functions associated with creating that object.
An object is an instance of the thing you can make with the blueprint. You can make multiple objects from the same blueprints, obviously.
Methods are simply the functions that a class has. They are sometimes also called subroutines. The concept of inheritance should be taken quite literally. It is the idea that one class can extend the definition of another. A trout might inherit a more generic “fish” class, which it can use to build from.

Programmers will often try to isolate specific ideas and functions from one another, in a concept known as abstraction. This is thought of as an ideal in computer science, which makes code more accessible for others to manipulate.

Polymorphism is a feature built in to programming languages that allows one type of variable to appear as, and be treated like, another type.
A constructor is the function in a class that runs by default when an object is created.

Discussion:
Is Object Oriented Desgin (OOD) really worth it? is it better to just get on with it and develop the game/project/product?
How do these drawings help?

The Use of Object Orriented programming can be found in Adobe Flash

Using the game above list the objects that could be considered in the level, identify how many times that instance appears in the game.
This is a task that may work well in small groups, organise your selves in to teams and select the objects that you will be counting to support the task.

Using the link below impliment some of the code snippets in to Flash
Adobe Flash OOD and OOD
Using the link below use Alice and create an anmiation
Alice OOD and OOP

To further explore the implimentation of OOD in practice we are able to use programming languages like Java to create objects, of which can have many instances and polymophs of them, whilst having libruarys of pre-defined methods and behaviours that can be accessed when required without the need to create them.

To see this and to play with a form of programming language use the button below
Game Development

Anonymous Assessment - Learners assess an anonymous piece of work containing deliberate mistakes against given success criteria.

C++ can be intimidating to new programmers. The syntax does at first glance look like it was designed for robots to read, rather than humans. However, C++ has some powerful features that speed up the process of game design, especially as games get more complex. There's good reason C++ is the long-standing standard of the game industry, and we'll talk about a few of its advantages in this lesson.
 

Object-Oriented Design

C++ is an object-oriented language. This means that instead of using a lot of variables for different aspects of each object, the variables that describe that object are stored in the object itself. For example, a simple C++ class might look like this:
 

class Car
{
public:
    float speed;
    float steeringAngle;
    Model* tire[4];
    Model* steeringWheel
};

We can pass the Car object around and access its members, the class variables that describe different aspects of the object:
 

Car* car = new Car;
float f = car->speed

Object-oriented design compartmentalizes code so we can have lots of objects, each with its own set of parameters that describe that object.
 

Inheritance

In C++, we can create classes that are built on top of other classes. The new class is derived from a base class. Our derived class gets all the features the base class has, and then we can add more in addition to that. We can also override class functions with our own, so we can just change the bits of behavior we care about and leave the rest. This is extremely powerful because:
 

1. We can create new classes that just add or modify a couple of functions, without writing a lot of new code.
2. We can make modifications to the base class, and all our derived objects will be automatically updated. We don't have to change the same code for each different class.

In the previous lesson we created a base class all our game classes would be derived from. All the features of the base GameObject class are inherited by the derived classes. Now I'll show you some of the cool stuff you can do with inheritance.

Consider a bullet object, flying through the air. Where it lands, nobody knows, but it's a good bet that it's going to do some damage when it hits. Let's use the pick system in Leadwerks to continually move the bullet forward along its trajectory, and detect when it hits something:
 

void Bullet::Update()
{
    PickInfo pickinfo;
    Vec3 newPosition = position + velocity / 60.0;
    void* userData;

    //Perform pick and see if anything is hit
    if (world->Pick(position, newPosition, pickinfo))
    {
        //Get the picked entity's userData value
        userData = pickinfo.entity->GetUserData();

        //If the userData has been set, we know it's a GameObject
        if (userData!=NULL)
        {
            //Get the GameObject associated with this entity
            GameObject* gameobject = (GameObject*)userData;

            //==================================
            //What goes here???
            //==================================

            //Release the bullet, since we're done with it
            Release();
        }
    }
    else
    {
        position = newPosition;
    }
}

We can assume that for all our GameObjects, if a bullet hits it, something will probably happen. Let's add a couple of functions to the base GameObject class that can handle this situation. We'll start by adding two members to the GameObject class in its header file:
 

int health;
bool alive;

In the class constructor, we'll set the initial values of these members:
 

GameObject::GameObject() : entity(NULL), health(100), alive(true)
{
}

Now we'll add two functions to the GameObject class. This very abstract still, because we are only managing a health value and a live/dead state:
 

void GameObject::TakeDamage(const int amount)
{
    //This ensures the Kill() function is only killed once
    if (alive)
    {
        //Subtract the specified amount from the object's health
        health -= amount;
        if (health<=0)
        {        
            Kill();
        }
    }
}

//This function simply sets the "alive" state to false
void GameObject::Kill()
{
    alive = false;
}

The TakeDamage() and Kill() functions can now be used by every single class in our game, since they are all derived from the GameObject class. Since we can count on this function always being available, we can use it in our Bullet::Update() function:
 

//Get the GameObject associated with this entity
GameObject* gameobject = (GameObject*)userData;

//Add 10 damage to the hit object
gameobject->TakeDamage(10);

//Release the bullet, since we're done with it
Release();

At this point, all our classes in our game will take 10 damage every time a bullet hits them. After being hit by 10 bullets, the Kill() function will be called, and the object's alive state will be set to false.
 

Function Overriding

If we left it at this, we would have a pretty boring game, with nothing happening except a bunch of internal values being changed. This is where function overriding comes in. We can override any function in our base class with another one in the extended class. We'll demonstrate this with a simple class we'll call Enemy. This class has only two functions:
 

class Enemy : public GameObject
{
public:
    virtual void TakeDamage(const int amount);
    virtual void Kill();
};

Note that the function declarations use the virtual prefix. This tells the compiler that these functions should override the equivalent functions in the base class. (In practice, you should make all your class functions virtual unless you know for sure they will never be overridden.)

What would the Enemy::TakeDamage() function look like? We can use this to add some additional behavior. In the example below, we'll just play a sound from the position of the character model entity. At the end of the function, we'll call the base function, so we still get the handling of the health value:
 

void Enemy::TakeDamage(const int amount)
{
    //Play a sound
    entity->EmitSound(sound_pain);

    //Call the base function
    GameObject::TakeDamage(amount);
}

Once the enemy takes enough damage, the GameObject::TakeDamage() function will call the Kill() function. However, if the GameObject happens to be an Enemy, it will kill Enemy::Kill() instead of GameObject::Kill(). We can use this to play another sound. We'll also call the base function, which will manage the object's alive state for us:
 

void Enemy::Kill()
{
    //Play a sound
    entity->EmitSound(sound_death);

    //Call the base function
    GameObject::Kill();
}

So when a bullet hits an enemy and causes enough damage to kill it, the following functions will be called in the order below:

• Enemy::TakeDamage
• GameObject::TakeDamage
• Enemy::Kill
• GameObject::Kill

We can reuse these functions for every single class in our game. Some classes might act differently when the health reaches zero and the Kill() function is called. For example, a breakable object might fall apart when the Kill() function is called, and get replaced with a bunch of fragments. A shootable switch might open a door. The possibilities are endless. The Bullet class doesn't know or care what the derived classes do. It just calls the TakeDamage() function, and the behavior is left to the different classes to implement.
 

Conclusion

C++ is the long-standing game industry standard for good reason. In this lesson we learned some of the advantages of C++ for game development, and how object-oriented game design can be used to create a system of interactions. By leveraging these techniques, you can create wonderful worlds of rich interaction and emergent gameplay.

 

About the Author(s)

Josh Klint is the CEO and founder of Leadwerks Software, an advisor for the IGDA Sacramento chapter, and was a speaker at the GDC 2013 mobile summit.
 

License

GDOL (Gamedev.net Open License)

Anonymous Assessment - Learners assess an anonymous piece of work containing deliberate mistakes against given success criteria.