Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Game development (Game Architecture)

2.209 visualizaciones

Publicado el

This is a last chapter in BEIT syllabus from mumbai university Engineering Old syllabus

Publicado en: Educación
  • Justin Sinclair has helped thousands of women get their Ex boyfriends back using his methods. Learn them at: ■■■ http://scamcb.com/exback123/pdf
       Responder 
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí
  • ➤➤ https://tinyurl.com/y4urott2
       Responder 
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí
  • Like to know how to take easy surveys and get huge checks - then you need to visit us now! Having so many paid surveys available to you all the time let you live the kind of life you want. learn more...●●● https://tinyurl.com/make2793amonth
       Responder 
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí
  • Your opinions matter! get paid BIG $$$ for them! START NOW!!.. ●●● https://tinyurl.com/realmoneystreams2019
       Responder 
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí

Game development (Game Architecture)

  1. 1. Development
  2. 2. 6.1 Introduction – Comparing to other phases development phase is very small in whole development process – Coding phase is very important – Important aspect of game development is its creativity – Creativity should be applied on proper place
  3. 3. 6.2 The development process • In earlier days, game projects were very small and a single programmer or small team was developing game • Nowadays with a power and capabilities of game platforms, large teams had to work for the game project • Code developed by all members must be of high quality and some coding standard need to be followed • Game engines are divided into a number of distinct types • For a good quality code, a number of general techniques are applied from code inception to system integration
  4. 4. 6.3 code quality • With a large team, there is every possibility for members to different coding styles • This would affect quality of coding and its maintenance • To ensure that coding style should be uniform 6.3.1 follow coding standard • As a part of team, the code has to be understood by every member • This mandates use of standards • The software factory model suggest the use of code across various projects
  5. 5. Comments and documentation • A comment should make the reader understand how the code does its task rather than what it does • Comment are made to explain what the statement of code will have on the rest of the object • Commenting can help preventing bugs and promote code understanding • Good commenting reduces the error in the code and speeds up the code review process • “Work in progress” in the code shown with comments “TODO”
  6. 6. Naming and coding conventions • These conventions are for two main areas: 1. Files and directory structures 2. Classes, functions and variables – A sensible naming practice makes the purpose of variable and functions easier to understand – Example: bSuccess_ is a reference to the Boolean variable – Trailing underscore in bSuccess_ indicates that it denotes the return value and differentiate it from the local variable
  7. 7. • In C++, a class has all members private by default and a structure is a class that has all members public • The class naming conventions are as follows: – Class name has a name prefix C ex. Cball – Interface name has a name prefix I ex. Idrawable – Structure name has a name prefix S ex. Sconfig • The prefixes to variable scope indicates are as follows: – Global variable ex. g_uiRefCount – Class member ex. m_uiRefCount – Static variable ex. s_uiRefCount – Constant ex. c_uiInitialCount – Enumeration ex. eStateOk – Static member ex. ms_uiRefCount • The prefixes to variable type indicates are as follows: – Signed Integer i or n – unsigned integer ui – Signed short s – Signed char ch – Array a – Pointer p
  8. 8. 6.4 Coding priorities • Coding priorities have to be established as a part of technical design • The various aspect of game to be considered are speed, size, flexibility, portability and maintainability 1. Speed 2. Size 3. Flexibility 4. Portability 5. Maintainability
  9. 9. 6.5 Debugging and module completion 1. Class A • These bugs are the most severe bugs • These can occur during installation or crashing the game at the beginning of the first level 2. Class B • These bugs may not crash the game but affect the quality • Example: failure of an event such as the gun may not fire when used 3. Class C • These bugs are minor bugs and can be fixed without much of problem • These are called cosmetic bugs • These could be spelling mistakes or user interface glitches • Priorities assigned according to the higher level severity a. Logical errors b. Programming errors c. Data errors
  10. 10. • Out of the three types of errors mentioned above, programming or code errors easiest to detect • Instead of testing for each of the other type of errors a generic test harness is done 6.5.1 Test harness – Install and run the module under test in a test environment, with input data in the expected input format – Generate stubs to emulate the behavior of subroutine modules; – Capture the actual outcome as generated by the unit under test and log or display it in a usable form – Compare the expected outcome with the actual outcome and log a test verdict for each input test – Tester is allowed to use all possible options in the user interface for this – Test harness application is integrated with the source control system to log test results and log results are used for audit purpose – This can also be used for regression testing, as old result can be compared with new result to check any bugs that have been introduced into previous working modules – Testing harness could also be scripted, so that it can automatically run a whole series of tests
  11. 11. 6.6 The seven golden principles of effective design 6.6.1 Reuse • In game development, code, design patterns are reused • Software architecture, non functional requirement (speed, flexibility, portability, etc.) can also be reused • Mostly common reused classes are foundation classes • Developer have to used all plug-ins in the early stages of the development to make quick build+ • This enables the modules to act as black box allowing the internal changes without affecting the rest of the system 6.6.2 Document • Documentation is imp for overall success of software development
  12. 12. 6.6.3 Design first before implementation • Game design is an ongoing process • It starts with an idea; a vision that often develops into a concept 6.6.4 Schedule tasks • It is difficult to go with a schedule because of many reasons • Non-essential tasks are identified and cut down • A realistic schedule has to be developed with the available resources; the various resources are as follows: • List of reusable components • List of tools and utilities • People (game designer, programmers, artists, sound engineers, internal support team) • Hardware / software resources
  13. 13. 6.6.5 Fix errors early – The cost of repairing the errors are manifold, if found late then these are fixed early – Also the errors propagate if they are not fixed early – Some useful tips for fixing errors are as follows: 1. Always fix the error first; often this one can correct most of the others 2. Save the file once the error is fixed, and for each change compile and run again 3. Testing (verification of specifications) should start in the pre- production stage itself 4. Testing should be done as often as possible by developer in production stage before delivery 6.6.6 Control the degree of R&D – To control the degree of research by game developers on latest technology – Hardware and game consoles also improve at good speed – Since developers work on tight schedules, they will have very little time to try out untested technologies – For a sequel new technology can be tried – It is advisable to have backup plan in case new technology has to be tried/used
  14. 14. 6.6.7 Focus on right areas for right amount of time – In a structured development methodology, project review happen at specific, high impact points involving top management – If the development process is inefficient and slow, products are often late-to-market over cost and not well aligned with user needs
  15. 15. 6.7 Five important aspects in game development 1. People – Talented, experienced and motivated people deliver any kind of management – They will find right way around processes or structure where there is disorder 2. Production Vs creativity – Production pressure from the business is the need to deliver a product on time and within the budget – For this we need to be able to quantify the work and risks by planning and rescheduling – Creativity is the heart and soul of game development and drives us to create better games – It is a process of curiosity and exploration – There are no guaranteed outcomes or fixed timeframes and this is not acceptable from production perspective – We need to find a way to balance both with the clear objectives and within the boundaries of each project
  16. 16. 3. Phases of production 1. Preproduction • It is the most creative period of any game, where it is decided what the game is and how to make it • The initial stage of preproduction is exploratory and later technology specifics have to be given for production 2. Production • It is the period in which the game is being developed • This is process driven and so more controlled 3. Postproduction • It is a period in which the finished game is made into a shippable product • This is done in two stages: Alpha(making the gameplay fun and balanced, therefore iterative) and beta(fixing the bug, is process driven)
  17. 17. 4. Skill sets – Skill set involved in the game development are code, art and design – Artwork is more of a deterministic discipline – Work can be split into independent modules, hence adding more people can complete the job faster – This estimates can not be very accurate in case of code and design – Because they need to respond to change requests more often, fix bugs or deal with hidden complexity – Hence the job con not finish faster by adding more people 5. Clients – In games, the stakeholder is an external producer who acts as a spokesperson for interested parties on the publishers side – Understanding the external forces is vital for planning the strategy and management style – A few things that contribute to the environment in which the project must survive are as follow-how much trust and freedom will EP extend
  18. 18. 6.8 The three lead balloons 1. Bad Management – Instead of finding ways to manage people, it is better to build a process into the team so that imposed management becomes unnecessary – The process should promote best practices and conceptual integrity – Bad management can affect the process in the following manner: • Increase the cost and reduce the performance through bureaucratic overhead • Hamper the ability of the team to change or adapt to new situation • Suppress the team’s capacity for innovation and creativity – Good management allows flexibility, identifies what is important – Handle the situation carefully – Every game, every team, every company is unique – The factor that can affect a project are the size of the team, corporate culture, internal politics, budget limitations, physical constraint, etc
  19. 19. 2. Rapidly expanding features – Give extra features that what is planned(beyond scope) probably to increase popularity and thus sale – The best way to manage this situation is to priorities features and keep up the schedule – Dos and don’ts are as follows: • Do not write system critical code towards the end • Represent project progress as a “% complete” of total work • Give the schedule for lower granularity tasks for accuracy in estimates • In each working build, mark features that will work (enable) and that would not be (disable) work • Map list of classes to concepts • Added features can be released as different versions • Do not add any major feature after first iteration • Defer lower priority tasks until more than 50% of the project is complete
  20. 20. 3. Coder never open up – Games are creative processes that involved interaction among multitalented people such as coders, designers, artists and writers – Coders are generally loners, self taught people unlike artists who generally respect each other’s work and work very well as a team – If a coders has insecure feeling and does not open up, then it will become difficult for others to work with him/her – Constant motivation and encouragement can boost up their moral – Incentives are awarded for sharing resources, mentoring, etc to make coders work environment comfortable

×