SE320: Introduction to Computer Games

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

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 Ideas High level, code independent, pseudo-code Low level, using a specific library 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? Update (change the state) Render (visualize the state) State (variables) Handle input (let user change state)

12. When should these be done? time Render Update

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

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(); } These run at the same time 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

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

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 Update (change the state) Render (visualize the state) State (variables) Game Object Handle input (let user change state)

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-scrollerspace 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