BTEC Extended Diploma in
Computer Games Design
Unit 71: Object-Oriented
Design for Computer Games
-----------------------------------------------------------------------------------------------
Object-Oriented Design: What You Need to Know
Object-Oriented
Design, or OOD, is a design method that is used on singular objects to give
them their own abilities and uses. Each object within a game would have their
own state and behaviours. The state would include its colour, name, direction,
speed and various other elements. Whereas the behaviours is more focused on the
mobility of the object and the possibilities of it changing state. Object-Oriented Design helps to organize the coding, or blueprints, into their individual and respective objects, making it easier to identify any problems if they happen to occur. Each of the individual objects hold all of the information about the objects states and behaviours.
What are States and Behaviours of an Object?
States of an object, like stated previously, are the things that describe the object, such as colour, shape and size. There are many different things that determine the shape of an object, the list above are just a few of the more common ones. Again, like previously stated, the behaviours of an object focus on what the object does rather than what the object looks like. Not just the mobility but also how it moves as well as where and why. The behaviours of the object tend to be more important than the state, the behaviours determine the way the game works and flows. While states are also important, the behaviours are what make the game work to its full potential.
Re-usability of Object Oriented Design:
One of the best things about Object Oriented Design is that for common objects such as a door, you can take the state and behaviours and place it into any game you make. If you were coding the game using java or C++ saving the code for the state an behaviour of the object into a word document would be the most efficient way to reuse it in future projects. Whereas if you were to be using a blueprint to give the object its state and behaviours then you will find it to be more challenging than saving a word document.
By selecting the blueprint or the asset in the content browser of unreal engine, you should right click and then select "Asset Actions". This will bring up a side menu of which you should choose "Migrate".
Maintenance & Quality Assurance of Object Oriented Design:
With any game, coded or blueprints, there is a significant probability that there will be some issues within the script. Assuring the quality is of a high standard before releasing the game would be best done by having a few professionals to play through the game and write a detailed review on any bugs, problems, or improvements. This can help to make the game better, but also identifies any areas within the blueprints. Above to the left is a screenshot of Unreal Tournament glitching. This would have been reported to Unreal and they would have had to go into their blueprints, or C++, identify the problem and correct it. As this game is live, this would have been a time sensitive project. Maintaining the blueprints during the game making process as well as once the project is completed, aren't so different. Once the project is completed, like mentioned before, there may be times that bugs need fixing or glitches need resolving, but there will be times when the game is being updated. The same OOD's can be used again, if it's a simple change, then individually updating the OOD's would be best, however if it is a big update, grouping the OOD's that have similar assets and updates would be time effective.
Efficiency of Object Oriented Design:
Object Oriented Design is in a sense efficient in the way it can be re-used at such ease. As we already established, re-using not only blueprinted OOD's but also Coded OOD's is very easy to do and doesn't take too much time to do so. Both are easily saved and stored and provide good structure to any game. This is similar to that of Procedural Programming, more commonly used in coded variants such as C++. Procedural Planning creates a chronological sequence of events to be executed with detailed instructions.
Real World Modelling:
Object Oriented Design isn't just found in computing, for example a car or a toy robot also use OOD to function. Looking closer at a toy robot, this one to be precise.
If you look at the state of the robot you can see that the name is Robot, obviously, you can also see that it is mainly blue with small sections of red.The behaviours are likely to be controlled by the wind-up key to the left side of the Robot, but the behaviours would be leg movement mainly and any potential noises that it would make. The way in which computerized objects work is not so different to that of physical objects. If you take a door within a game and compare it to a door in the real world, they work the same way. A standard door, in both capacities, work by being pushed, or the handle being used. Or an automatic sliding door would be triggered by a person standing in the view of a sensor, the same within unreal can be preformed by the use of a trigger box and setting up a matinee and a blueprint, like below.
Collaboration and Sharing:
An OOD may be created via various parties, there are many different people who work on games, the main two being the programmers and the artistic developers. The OOD could start by having the object created by the artistic team and then being passed onto the coders/programmers, to then be passed to the developers to add it to the game.
Communication, The Theory of Blueprints and How They Work:
Blueprints are a simpler way to code a game, most commonly used in the Unreal engine. There's been many debates on Blueprints vs C++ within the engine, neither seem to have more support than the other however. As shown below, both look rather complex to understand and execute, however most people who post on the unreal forums commented on how Blueprinting is easier to execute and use.
Neither way of coding the game will effect the game play, it all comes down to personal preference and skill level. When trying to get two or more blueprints to communicate with each other within the game, the main blueprint, which is your working blueprint, needs to gain access to the target blueprint. This being the other blueprint you want to communicate with. To do this, within your working blueprint, create a variable for the target blueprint. Then within the level with the working blueprint selected, in the details panel you can then set the variable. The variable is set to none as a default, by using the drop down menu you can choose from a variety of options to set the variable as, according to the needs of the blueprints. Within blueprint mapping itself, there is a function option that connect the variable to the blueprint, like below.
Inheritance:
Similar to a genetic inheritance, an object can take assets from two other objects and merged them with their own and become a whole new object, just like a child taking certain aspects from each parent as well as having their own. In unreal terms a parent and child class are often referred to as Superclass and Subclass. The subclass tends to take the properties from the superclass as well as develop its own, new, states and behaviours.
States of an object, like stated previously, are the things that describe the object, such as colour, shape and size. There are many different things that determine the shape of an object, the list above are just a few of the more common ones. Again, like previously stated, the behaviours of an object focus on what the object does rather than what the object looks like. Not just the mobility but also how it moves as well as where and why. The behaviours of the object tend to be more important than the state, the behaviours determine the way the game works and flows. While states are also important, the behaviours are what make the game work to its full potential. Re-usability of Object Oriented Design:
One of the best things about Object Oriented Design is that for common objects such as a door, you can take the state and behaviours and place it into any game you make. If you were coding the game using java or C++ saving the code for the state an behaviour of the object into a word document would be the most efficient way to reuse it in future projects. Whereas if you were to be using a blueprint to give the object its state and behaviours then you will find it to be more challenging than saving a word document.
By selecting the blueprint or the asset in the content browser of unreal engine, you should right click and then select "Asset Actions". This will bring up a side menu of which you should choose "Migrate".
Then confirm the migration and save it somewhere safe and easily accessible. Once you have migrated the asset, you can then import it into any other unreal project you need it for.
Maintenance & Quality Assurance of Object Oriented Design:
With any game, coded or blueprints, there is a significant probability that there will be some issues within the script. Assuring the quality is of a high standard before releasing the game would be best done by having a few professionals to play through the game and write a detailed review on any bugs, problems, or improvements. This can help to make the game better, but also identifies any areas within the blueprints. Above to the left is a screenshot of Unreal Tournament glitching. This would have been reported to Unreal and they would have had to go into their blueprints, or C++, identify the problem and correct it. As this game is live, this would have been a time sensitive project. Maintaining the blueprints during the game making process as well as once the project is completed, aren't so different. Once the project is completed, like mentioned before, there may be times that bugs need fixing or glitches need resolving, but there will be times when the game is being updated. The same OOD's can be used again, if it's a simple change, then individually updating the OOD's would be best, however if it is a big update, grouping the OOD's that have similar assets and updates would be time effective.Efficiency of Object Oriented Design:
Object Oriented Design is in a sense efficient in the way it can be re-used at such ease. As we already established, re-using not only blueprinted OOD's but also Coded OOD's is very easy to do and doesn't take too much time to do so. Both are easily saved and stored and provide good structure to any game. This is similar to that of Procedural Programming, more commonly used in coded variants such as C++. Procedural Planning creates a chronological sequence of events to be executed with detailed instructions.
Real World Modelling:
Object Oriented Design isn't just found in computing, for example a car or a toy robot also use OOD to function. Looking closer at a toy robot, this one to be precise.
If you look at the state of the robot you can see that the name is Robot, obviously, you can also see that it is mainly blue with small sections of red.The behaviours are likely to be controlled by the wind-up key to the left side of the Robot, but the behaviours would be leg movement mainly and any potential noises that it would make. The way in which computerized objects work is not so different to that of physical objects. If you take a door within a game and compare it to a door in the real world, they work the same way. A standard door, in both capacities, work by being pushed, or the handle being used. Or an automatic sliding door would be triggered by a person standing in the view of a sensor, the same within unreal can be preformed by the use of a trigger box and setting up a matinee and a blueprint, like below.
Collaboration and Sharing:
An OOD may be created via various parties, there are many different people who work on games, the main two being the programmers and the artistic developers. The OOD could start by having the object created by the artistic team and then being passed onto the coders/programmers, to then be passed to the developers to add it to the game.
Communication, The Theory of Blueprints and How They Work:
Blueprints are a simpler way to code a game, most commonly used in the Unreal engine. There's been many debates on Blueprints vs C++ within the engine, neither seem to have more support than the other however. As shown below, both look rather complex to understand and execute, however most people who post on the unreal forums commented on how Blueprinting is easier to execute and use.
Neither way of coding the game will effect the game play, it all comes down to personal preference and skill level. When trying to get two or more blueprints to communicate with each other within the game, the main blueprint, which is your working blueprint, needs to gain access to the target blueprint. This being the other blueprint you want to communicate with. To do this, within your working blueprint, create a variable for the target blueprint. Then within the level with the working blueprint selected, in the details panel you can then set the variable. The variable is set to none as a default, by using the drop down menu you can choose from a variety of options to set the variable as, according to the needs of the blueprints. Within blueprint mapping itself, there is a function option that connect the variable to the blueprint, like below.
Inheritance:
Similar to a genetic inheritance, an object can take assets from two other objects and merged them with their own and become a whole new object, just like a child taking certain aspects from each parent as well as having their own. In unreal terms a parent and child class are often referred to as Superclass and Subclass. The subclass tends to take the properties from the superclass as well as develop its own, new, states and behaviours.
No comments:
Post a Comment