Comparative differences between games design and simulation design - Part 4: TLE Breakdown and how it relates against games design pipelines
Introduction
One thing that was introduced to me within the first two months at working within the new industry is the process of life cycles. Now life cycles are not unknown to me within my time in my previous jobs and games design education to this point but my knowledge on engineering styles was very vague which would allow me to learn a different style of process especially life cycles as the idea is based around process and product refreshing which including games design is something that needs to be done, else the process of becoming stagnant within engine and mechanics can happen which can be seen in games such as Activision Blizzard destiny engine that is been promoted as poorly designed which means building environments need to constantly happen which is a diminishing return.
Terminology Notification
As you'll probably noticed in my last few blogs, I may have written or used certain phrases in presenting games design terminology. In games design, the wording is different but there is a similarity for engineering. The main one i use is the following:
PIPELINE – In Games design, Pipeline is used a lot but the overall premise is the same. Pipeline is a process of a set of steps, processes, stages from start to finish. It is essentially the same as a cycle or stage development but it is normally defined as an overall phrase for the process.
So what is Through Life Engineering (TLE)?
Louis Redding defines TLE as a service that provides product support throughout each stage of the product-lifecycle; from conception, design, manufacture and operational life to end of life disposal.
They are defined as natural stages in the evolution of product support and maintenance, repair and overhaul strategy.
The engineering or technical parts of the project need to be well defined to allow optimum risk reduction and efficient delivery. This works against the Business lifecycle
The stages that are the “typical” stages are the following:
So i briefed it over and the process and to make it understandable, the best way I could interpret it is using an example of constant refreshing on an annual basis. After a bit of research, I thought of the following:
It's interesting then as there are set requirements and then changes from the year previously. For example in the terms of games design. A set of requirements could be derived to a genre or specifically for mechanics for a game. To break this down, if we used a game genre of Call of Duty with each cycle being a new year, the mechanics can change or be improved specifically for each genre such as crouch aiming, weapon aiming or additional extras.
The rulings are then broken down to a set rules of standards that must be adhered to requirements and rule settings, so below is a set of the rules that are set specially for the fair play.
So from a breakdown and looking at an overall perception of the TLE process; the similarities are very dissimilar within the two industries but also within the projects time lines themselves. However; when looking at the process of development to how products are made in regards to TLE, a correlation can been seen within the development cycle within games design and an engineering project.
Games design although not set as in written by a customer or internally, has to adhere to certain requirements such as TLE with the engineering world. Such criteria as polygon limitations and mechanics. Although not in the same premise of ISO certifications, the necessity to research and develop, offer mature products, push creativity and problem solving correlate strongly within the two different industries.
Although dissimilar in certain points, the TLE and games design pipeline changes at the beginning with the two parts changing specifically due to the process of a prototype is needed before pitching for the full game instead of knowing what the product is before developing it.
One thing that was introduced to me within the first two months at working within the new industry is the process of life cycles. Now life cycles are not unknown to me within my time in my previous jobs and games design education to this point but my knowledge on engineering styles was very vague which would allow me to learn a different style of process especially life cycles as the idea is based around process and product refreshing which including games design is something that needs to be done, else the process of becoming stagnant within engine and mechanics can happen which can be seen in games such as Activision Blizzard destiny engine that is been promoted as poorly designed which means building environments need to constantly happen which is a diminishing return.
Terminology Notification
As you'll probably noticed in my last few blogs, I may have written or used certain phrases in presenting games design terminology. In games design, the wording is different but there is a similarity for engineering. The main one i use is the following:
PIPELINE – In Games design, Pipeline is used a lot but the overall premise is the same. Pipeline is a process of a set of steps, processes, stages from start to finish. It is essentially the same as a cycle or stage development but it is normally defined as an overall phrase for the process.
So what is Through Life Engineering (TLE)?
Louis Redding defines TLE as a service that provides product support throughout each stage of the product-lifecycle; from conception, design, manufacture and operational life to end of life disposal.
They are defined as natural stages in the evolution of product support and maintenance, repair and overhaul strategy.
The engineering or technical parts of the project need to be well defined to allow optimum risk reduction and efficient delivery. This works against the Business lifecycle
The stages that are the “typical” stages are the following:
So i briefed it over and the process and to make it understandable, the best way I could interpret it is using an example of constant refreshing on an annual basis. After a bit of research, I thought of the following:
Example of TLE using TLE - Customer Requirements / Rules for the F1 Car:
So every year the FIA presents changes to each part of the car that the car manufacturers must ahdere to, to be able to race the next season. Main areas of research are based around the following parts as an example:- Bodyworks, Dimensions and cockpits
- Tyre and Wheels
- Power units and ERS
- Gear box
- Scrutinising and weighing
- Brakes System
- Drag reduction system
- Safety equipment
- Fuel, Fuel usage and refuelling
- Suspension and steering systems
- Electrical systems
- Television cameras and timing transponders
It's interesting then as there are set requirements and then changes from the year previously. For example in the terms of games design. A set of requirements could be derived to a genre or specifically for mechanics for a game. To break this down, if we used a game genre of Call of Duty with each cycle being a new year, the mechanics can change or be improved specifically for each genre such as crouch aiming, weapon aiming or additional extras.
The rulings are then broken down to a set rules of standards that must be adhered to requirements and rule settings, so below is a set of the rules that are set specially for the fair play.
- The overall width of a car, excluding tyres, must not exceed 2,000mm.
- Bodywork between the front and rear wheel centre lines must not be more than 1,600mm wide.
- In order to prevent tyre damage to other cars, certain pieces of bodywork (such as front wing end plates) must be at least 10mm thick.
- No part of the car can be more than 950mm in height.
Updating the versions
So as a brief example to what the changes are like in a visual statement; although small, the changes are significant per year. These small changes are deemed as necessary for either to push for more speed for less fuel, traction or more control abilities for the cars for the manufacturers to edit into their cars.
That's all well and good looking at it from a basic imagery breakdown but why is that important?
Games design although not set as in written by a customer or internally, has to adhere to certain requirements such as TLE with the engineering world. Such criteria as polygon limitations and mechanics. Although not in the same premise of ISO certifications, the necessity to research and develop, offer mature products, push creativity and problem solving correlate strongly within the two different industries.
Although dissimilar in certain points, the TLE and games design pipeline changes at the beginning with the two parts changing specifically due to the process of a prototype is needed before pitching for the full game instead of knowing what the product is before developing it.
So breaking down the process into sections. It'll be based around the same parts and although the GDP is much more detailed, it is *at the time of writing this* what each section would have as part of each section.
Overall Conclusion
Although not a massive difference in the two styles and process. The problem is that, after researching into this, there isn't that much of a difference. Although that is disappointing in some aspects, this is a view of an overall viewing and not breaking down the process into the more smaller refined pieces, the idea that the similarities are not so distinctive.
The process for TLE is more informative in the documentation that flows alongside the TLE which will be looked at in a different section. The idea however behind the premise of the TLE within the flow of the life cycle clearly presents a strong concise process that can be used as a whole with the added internal cycles (excluding retirement) for constant updates and developments necessary when something new is added.
Another strong point is that the development process for the TLE lifecycle is that it's for shorter processes but for longer durations. Example could be a year to develop the software but for it to last for a 5 year span than a video game which could have a 2-4 development cycle but with the issue of unknown lifecycles.
Overall, the differences will be more orientated within the document and development process. This will be interesting over my time in the future to develop and see if there is a strong process to allow for a hybrid that can follow alongside both styles but allows for diversity. Such as the QA HEP and PLAY framework for testing all criteria.
Comments
Post a Comment