Presentation is loading. Please wait.

Presentation is loading. Please wait.

CSCE 552 Fall 2012 Language and Programming By Jijun Tang.

Similar presentations


Presentation on theme: "CSCE 552 Fall 2012 Language and Programming By Jijun Tang."— Presentation transcript:

1 CSCE 552 Fall 2012 Language and Programming By Jijun Tang

2 Design Procedure Waterfall method  Development methodology  Design and production are broken into phases Iterative development  Practice of producing things incrementally  Refining and re-refining the product  May iterate many cycles before get it right

3 Waterfall vs. Iterative testing

4 Programming Teams In the 1980s programmers developed the whole game (and did the art and sounds too!) Now programmers write code to support designers and artists (content creators)

5 Different Programs Game code Anything related directly to the game Game engine Any code that can be reused between different games Tools In house tools Plug-ins for off-the-shelf tools

6 Methodologies: Code and Fix Unfortunately very common Little or no planning Always reacting to events Poor quality and unreliability of finished product “Crunch” time normal

7 Methodologies: Waterfall Very well-defined steps in development Lots of planning ahead of time Great for creating a detailed milestone schedule Doesn't react well to changes Game development is too unpredictable for this approach

8 Methodologies: Iterative Multiple development cycles during a single project  Each delivering a new set of functionality  Refinements are needed The game could ship at any moment Allows for planning but also for changes

9 Methodologies: Agile Methods Deal with the unexpected Very short iterations: 2-3 weeks Iterate based on feedback of what was learned so far Very good visibility of state of game Difficult for publishers or even developers to adopt because it's relatively new

10 Leveraging Existing Code A lot of code that games use is the same It's a total waste of time to write it over and over Instead, spend your time in what's going to make your game unique Avoid Not Invented Here (NIH) syndrome!

11 Where Are Existing Codes Reuse code from previous project  Easier in a large company if you have an engine and tools group Use freeware code and tools  No support  Make sure license allows it Middleware  Companies provide with components used in game development physics, animation, graphics, etc Commercial game engines  You can license the whole engine and tools and a single package  Good if you're doing exactly that type of game

12 Languages C/C++ Java Script: Flash, Python, LISP, etc. C# XNA for PC and Xbox

13 C++ C/C++ used to be the most popular language for games Today, C++ is still the language of choice for game development (according to wiki)

14 C++: Strengths - I Performance  Control over low-level functionality (memory management, etc)  Can switch to assembly or C whenever necessary  Good interface with OS, hardware, and other languages High-level, object-oriented  High-level language features are essential for making today's complex games  Has inheritance, polymorphism, templates, and exceptions  Strongly typed, so it has improved reliability

15 C++: Strengths - II C Heritage  C++ is the only high-level language that is backwards-compatible with C  Has APIs and compiler support in all platforms  Easier transition for experienced programmers Libraries  STL (Standard Template Library) Comprehensive set of standard libraries  Boost: widely used library with wide variety of functionality  Many commercial C++ libraries also available

16 C++: Weaknesses - I Too low-level  Still forces programmers to deal with low-level issues  Too error-prone  Attention to low-level details is overkill for high-level features or tools Slow iteration  C++ is fully compiled into binary format from source code  Compiling large numbers of files is very slow  This will only become more of a problem as games become more complex

17 C++: Weaknesses - II Too complicated  Because of its C heritage, C++ is very complicated  Long learning curve to become competent with the language Lacking features  No reflection or introspection features  No method of object serialization  No native support for message passing

18 C++: When to Use It? When performance is crucial If your current code base is mostly C and C++ If you have a lot of in-house expertise in C++ Avoid using it for high-level code, such as tools

19 Java for Game Development Why use Java?  It's a high-level OO language that simplifies many C++ features  Adds several useful high-level features  Easy to develop for multiple platforms because of intermediate bytecode  Good library support

20 Java Performance Has typically been Java's weak point Has improved in the last few years: still not up to C++ level, but very close Uses Just-In-Time compiling and HotSpot optimizations Now has high-performance libraries Also has access to native functionality

21 Java Platforms Well suited to downloadable and browser-based games Dominates development on mobile and handheld platforms Possible to use in full PC games, but more likely to be embedded into a game

22 Commercial Games using Java Downloadable games like those from PopCap Games: Mummy Maze, etc Online card games PC games using Java as a scripting language: Vampire: The Masquerade, Star Wars Galaxies PC games fully written in Java: You Don't Know Jack, Who Wants to Be a Millionaire

23 C# Developed by MS, now ISO standard A simple, modern, general-purpose, object- oriented programming language Support for software engineering principles:  strong type checking  array bounds checking  detection of attempts to use uninitialized variables  automatic garbage collection. Software robustness, durability, and programmer productivity are important.

24 Strength and Weakness C# is intended to be suitable for writing applications for both hosted and embedded systems Source code portability is very important, as is programmer portability Although is intended to be economical (memory/processing power), it cannot compete directly with C or assembly language.

25 Scripting Languages Why use scripting languages?  Ease and speed of development  Short iteration time  Code becomes a game asset  Offer additional features and are customizable

26 Drawbacks of Scripting Languages Slow performance Limited tool support Dynamic typing makes it difficult to catch errors Awkward interface with the rest of the game Difficult to implement well

27 Popular scripting languages Python Lua Other off-the-shelf options such as Ruby, Perl, Javascript Custom scripting languages  UnrealScript, QuakeC, NWNScript

28 Lua Example

29 Choose a Scripting Languages Consider whether you need one at all What features do you need? What kind of performance do you need? What debugging facilities does the language have? On what platforms does it need to run? What resources and expertise are available?

30 Programming Fundamentals

31 Data Structures: Array Elements are adjacent in memory (great cache consistency)  Requires continuous memory space They never grow or get reallocated  Use dynamic incremental array concept  GCC has a remalloc function In C++ there's no check for going out of bounds  Use vector if possible  Keep in mind of checking boundaries Inserting and deleting elements in the middle is expensive

32 List Very cheap to add/remove elements. Available in the STL (std::list) Every element is allocated separately, not placed contiguously in memory  Lots of little allocations  Bad cache awareness, but can use arrays to hold pre-allocated items Single/Double linked list

33 Lists

34 Dictionaries Maps a set of keys to some data. std::map, std::hash, etc Very fast access to data Perfect for mapping IDs to pointers, or resource handles to objects May waste space, need to design comparison operators

35 Hash Table

36 Others Stacks  First in, last out  std::stack adaptor in STL Queues  First in, first out  std::deque  Priority queue is useful in game to schedule events

37 Stack/Queue/Priority Queue

38 Bit packing Fold all necessary data into a smaller number of bits Bool in C++ may use up to 4 bytes, thus is very expensive Very useful for storing boolean flags: pack 32 in an integer Possible to apply to numerical values if we can give up range or accuracy Very low level trick  Use shifts to handle the operation or use assembly  Only use when absolutely necessary

39 Bits

40 Inheritance Models “is-a” relationship Extends behavior of existing classes by making minor changes Do not overuse, if possible, use component systerm UML diagram representing inheritance

41 Polymorphism The ability to refer to an object through a reference (or pointer) of the type of a parent class Key concept of object oriented design C++ implements it using virtual functions

42 Multiple Inheritance Allows a class to have more than one base class Derived class adopts characteristics of all parent classes Huge potential for problems (clashes, casting, dreaded diamond, etc) Multiple inheritance of abstract interfaces is much less error prone (virtual inheritance) Java has no multiple inheritance

43 Dreaded Diamond It is an ambiguity that arises when two classes B and C inherit from A, and class D inherits from both B and C. If a method in D calls a method defined in A (and does not override the method), and B and C have overridden that method differently, then from which class does it inherit: B, or C?

44 Component Systems Component system organization

45 Object Factory Creates objects by name Pluggable factory allows for new object types to be registered at runtime Extremely useful in game development for passing messages, creating new objects, loading games, or instantiating new content after game ships

46 Factory Pattern

47 Simple Sample Factory - I

48 Simple Sample Factory - II

49 Singleton Implements a single instance of a class with global point of creation and access For example, GUI Don't overuse it!!!

50 Singleton Example

51 Adapter Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces Real interface

52 Adapter Pattern

53 Adapter Example - I

54 Adapter Example - II

55 Observer Allows objects to be notified of specific events with minimal coupling to the source of the event Two parts  subject and observer

56 Observer Pattern

57 Composite Allow a group of objects to be treated as a single object Very useful for GUI elements, hierarchical objects, inventory systems, etc

58 Composite Pattern

59 Composite Pattern Example - I Add many more inherited classes

60 The Five Step Debugging Process 1. Reproduce the problem consistently 2. Collect clues 3. Pinpoint the error 4. Repair the problem 5. Test the solution

61 Expert Debugging Tips Question assumptions Minimize interactions and interference Minimize randomness Break complex calculations into steps Check boundary conditions, use assertions Disrupt parallel computations Exploit tools in the debugger (VC is good, purify) Check code that has recently changed Explain the bug to someone else Debug with a partner (A second pair of eyes) Take a break from the problem Get outside help (call people)

62 Game Architecture

63 Overall Architecture The code for modern games is highly complex  The Sims: 3 million lines of code  Xbox HD DVD player: 4.7 million lines  MS Train Simulator has 1GB installed, with only 10MB executable With code bases exceeding a million lines of code, a well-defined architecture is essential

64 Overall Architecture Main structure  Game-specific code  Game-engine code Both types of code are often split into modules, which can be static libraries, DLLs, or just subdirectories

65 Overall Architecture Architecture types  Ad-hoc (everything accesses everything)  Modular  DAG (directed acyclic graph)  Layered Options for integrating tools into the architecture  Separate code bases (if there's no need to share functionality)  Partial use of game-engine functionality  Full integration

66 Ad-hoc

67 Modular

68 DAG

69 Layered

70 Overview: Initialization/Shutdown The initialization step prepares everything that is necessary to start a part of the game The shutdown step undoes everything the initialization step did, but in reverse order

71 Initialization/Shutdown Resource Acquisition Is Initialization  A useful rule to minimalize mismatch errors in the initialization and shutdown steps  Means that creating an object acquires and initializes all the necessary resources, and destroying it destroys and shuts down all those resources Optimizations  Fast shutdown  Warm reboot

72 Overview: Main Game Loop Games are driven by a game loop that performs a series of tasks every frame Some games have separate loops for the front and the game itself Other games have a unified main loop Must finish a loop within 0.017 second

73 Tasks of Main Game Loop Handling time Gathering player input Networking Simulation Collision detection and response Object updates Rendering Other miscellaneous tasks

74

75 Sample Game Loop

76 Main Game Loop Structure  Hard-coded loops  Multiple game loops: for each major game state  Consider steps as tasks to be iterated through Coupling  Can decouple the rendering step from simulation and update steps  Results in higher frame rate, smoother animation, and greater responsiveness  Implementation is tricky and can be error-prone

77 Execution Order of Main Loop Most of the time it doesn't matter In some situations, execution order is important Can help keep player interaction seamless Can maximize parallelism Exact ordering depends on hardware


Download ppt "CSCE 552 Fall 2012 Language and Programming By Jijun Tang."

Similar presentations


Ads by Google