1. SE320: Introduction to Computer Games Week 8: Game Programming Gazihan Alankus

2. Outline Brief chat about projects Game programming

3. Outline Brief chat about projects Game programming

4. Brief Chat about Projects How is it going? Three weeks left for your first presentation (December 13). What I expect: – A simple but playable version of your game – An in-class demo – (Optional) User tests (what you learned, etc.) Meetings that you want me in Help session

5. Outline Brief chat about projects Game programming

6. Game Programming Games – Multimedia – Interactive How you are used to program – Sequential – Text-based – Input/output

7. Game Programming High level, code independent, pseudo-code Low level, using a specific library Ideas Program

8. Anatomy of a Game Multimedia – Continuously changing visuals – Sound and music – Other forms of feedback Interactive – User input affects the program – Immediate results of user input

9. Let’s try to approach it the old way How you are used to program – Sequential – Text-based – Input/output Let’s think: how would you code a game? – Multimedia – Interactive – 10min practice int main() { printf(“hello world”); return 0; }

10. What should the computer do? Render many times every second, like a movie Between the render calls, update what needs to be updated – Advance animations – Simulate physical things (velocity, acceleration, gravity) Whenever user does something, take the appropriate action

11. What should the computer do? State (variables) Render (visualize the state) Update (change the state) Handle input (let user change state)

12. When should these be done? Render time Update

13. When should these be done? Render time Update Handle input int main() { printf(“hello world”); return 0; } How can I make this happen? void render() void update() void handleInput()

14. Sample game main loop while(1) { wait for some time so you don’t loop too fast. did enough time pass since last render? render(); did enough time pass since last update? update(); did the user press a key or moved the mouse or something? handleInput(); } Problem? Where do you get the input here?? Instead, need to listen to input. If we do that it blocks (stops and waits) Need a thread that is listening for user input.

15. Sample game main loop and event listener while(1) { wait for some time so you don’t loop too fast. did enough time pass since last render? render(); did enough time pass since last update? update(); } while(1) { wait for user input handleInput(the input that I got); } One extra thread Things are getting complicated… That’s why we like to use libraries that do the dirty work for us This way we can concentrate on what’s important: the game logic These run at the same time

16. What should the computer do? State (variables) Render (visualize the state) Update (change the state) Handle input (let user change state) void render() void update() void handleInput()

17. Game Libraries All game libraries should somehow do these three things – Find how the game handles these three things – Find where it provides you functions to fill in – Fill them in, remember how they work and where you should do what void render() void update() void handleInput()

18. Some rules of thumb Determine which variables, objects, etc. are your game state. Code your render function so that you only reflect the game state on screen – Do not change the game state in the render function! Use time in your update function to update your state. – Do not assume that the update function will be called with regular time intervals. Never change things with fixed values. Always make changes depending on the current time, or duration since last update. – Do not draw anything in your update function Make your input handler very simple. Only change values of game state. – Do not do any rendering in the input handler – Do not make any long update work such as simulating physics. Updates to state should be done in the update function.

19. Some rules of thumb Determine which variables, objects, etc. are your game state. When you add new state variables, make sure you know it is a part of game state Initialize your state well State (variables)

20. Some rules of thumb Make your render function simple – Only reflect the game state on screen. – Do not change the game state. – Do not make it depend on time. Render (visualize the state)

21. Some rules of thumb Make your update function depend on time. – Do not assume that it will be called with regular time intervals. Never change values with fixed values. Always make value changes depend on the current time, or duration since last update. – Location = Location + timeSinceLastUpdate * speed Do not do any rendering in your update function. Update (change the state)

22. Some rules of thumb Make your input handler very simple. – Only change values of game state. – Do not make any long update work such as simulating physics. – Updates to the actual state should ideally be done in the update function. (unless they are very simple changes) Do not do any rendering in the input handler. Handle input (let user change state)

23. The library can take over some work State (variables) Render (visualize the state) Update (change the state) Handle input (let user change state) Game Object

24. “Smart” objects Add me to the game and don’t worry about anything! – I’ll render myself when the time comes. Just tell me how I look. – I’ll update my animations. Just give me the high level details. – I’ll follow the mouse, if you want. Fill my own render(), update(), handleInput() functions – They will be called from the actual ones automatically Game Object

25. Exercises on the board Side-scroller space shooter Platform

26. Let’s actually implement them! Next week, if no time is left.

27. Help Session After Class You are welcome to stay for the Java + Slick2D help session