Lecture 7

1. Lecture 7 Announcements

2. Mid-Semester Feedback • We’re happy that you’re happy • Top complaint: “I feel behind” • Retry system has you covered • …and we did warn you about the snowball

3. Mid-Semester Grades • Your current grade reports have been sent • Email or ask at hours with questions/problems • Keep up the good work

4. Special Topics Lectures • Covering engine features from final projects and mid-semester feedback • Keep your eyes out for an email survey this week

5. Announcements Questions?

6. Zynga Guest Lecture • Kate Bambino, Senior Product Manager

7. Lecture 7 Content Management II

8. Content Management II Game Logic Management

9. Recap • Why are we doing this again? • Prevent excecutable bloat • Quickly make asset changes • Some content is already separated • Graphics are out • Maps are out

10. What is Game Logic? • Game logic dictates the rules of your game • Consider a chess game • Maps set up a chess problem • Images define how the game looks • …but game logic controls how the pieces move • You probably hard code this

11. Why not hard code logic? • Programmers aren’t game designers • And they shouldn’t be game designers’ personal assistants either • Game logic should be reusable • Imagine multiple games in a series • Convenience – it’s faster

12. Content Management II Some Possible Solutions

13. Put Logic in Config Files • Logic is defined in external files, sort of like Tac maps • Good for static information • Unit stats, like how much health tanks start with • Game settings, like screen size or default level • Trickier when trying to define interactions • How would you define the M2 grenade?

14. Embed a Scripting Language • Logic is defined by a scripting language, then loaded at runtime • Good for complicated behavior • Wouldn’t Tac AI have been so much easier? • Lots of overhead • Need a well-designed API • Designers have to learn API

15. Make a Game-specific Editor • Logic is defined in a settings application tailor-made for the game • Very easy to use • Engines can even be aimed at non-programmers (RPGmaker etc) • Inherently not portable • And you have to spend all that time writing it again!

16. What Features do we Need? • Shouldn’t be tied to any specific game genre • Because our engine isn’t either • Need to define entity interactions • For instance, how would we make a weighted button?

17. Content Management II QUESTIONS?

18. Lecture 7 Entity I/O

19. Entity I/O WHAT’S ENTITY I/O?

20. Introducing Entity I/O • Strategy for logically connecting entities • Connections are defined by designers and dictate game logic • Popularized in the Source engine When button is depressed, release rock

21. Inputs and Outputs • Entities have outputs • button.onPress() • timer.onFinish() • camera.onSeen() • Entities have inputs • door.doOpen() • bomb.doExplode() • lights.doToggle() onPush() doOpen()

22. Some Example Uses • Light switch • switch.onFlip() → light.doToggle() • Puzzles • ocarina.onPlay() → timeCube.doRaise() • Automatic door • camera.onPlayerSeen() → door.doOpen()

23. Connecting Entities • An output can be connected to an input to define a behavior • An output is connected to any number of inputs • This might seem backwards, but think of connecting wires • Programmer defines inputs/outputs • Designers connect inputs/outputs onPush() -> doOpen()

24. Invisible Logic Entities? • Entities need not be physical • What about an invisible hitbox that performs some logic when the player enters the box? • …and a Timer doesn’t physically interact at all!

25. Special Logic Entity: Sensor • Sends a signal when some other entity touches it • Not necessarily physical • Triggers when a player enters an area, etc • Can you think of some uses?

26. Special Logic Entity: Relay • Think of it as a pipe with a valve • Relays a signal from one entity to another • …but only when it’s received some other signal doEnable()/doDisable() doFire() onFire() Relay

27. Entity I/O Implementing Entity I/O

28. Engine Objects • An Output, to send a pulse to all attached inputs • An Input, to hold and run arbitrary game code • Potentially a Connection to go between them • Allows passing connection properties as input arguments Pulse Arguments

29. Setting Up Connections • Connections are defined outside the game code • These are loaded from data • Data needs to be turned into your Output and Inputobjects • Then these objects fire at their appropriate times in game Key/value pairs Connection objects

30. Some Sample Contracts public classOutput {privateList<Connection> connections;public void connect(Connection c) { connections.add(c) } public void run() { for (Connection c : connections) c.run() }} public classConnection {privateInput target;privateMap<String, String> args;public void run() { target.run(args); } } abstract public classInput {public abstract void run(Map<String, String> args);}

31. Game Code • Need to read connections from data files and then initialize them • Entity subclasses can have outputs/inputs • But there might be some common ones: onCollide etc • Inputs need game-specific logic public classDoor extends Entity { private Output onDoorOpen; public OpenDoorInputdoOpenDoor; private voidopenDoor() { // … door open code … onDoorOpen.run(); } classOpenDoorInputextends Input { public void run() { openDoor(); } } }

32. Content Management II QUESTIONS?

33. Lecture 7 Tips for M3

34. Reflection and Friends • Avoid Class.forName() • What happens when code is refactored? • Have to sync data and code • Instead, map from strings to classes • Map<String, Class<?>> • (Also, cs195n publisher obfuscates demos, breaking most reflection)

35. Connections, not Logic Gates • Connections send discrete events, not electrical signals • These events occur at some exact point in time; they don’t become true • Can’t be “evaluated” like state machine transitions • So they require a different structure

36. Tips for M3 Java Tip Of The Week

37. Functions aren’t objects… • In some languages, functions are first class objects • In Java this is not the case • So functions (and arbitrary code) can’t be stored so easily void map(List list, Function lambda) { for (Object o : list) { lambda(o); } } // in your connection code… map(connections, Connection.run);

38. Introducing Anonymous Classes • Essentially an in-line subclass • Looks exactly like a subclass in another file, minus the name • All anonymous classes are inner classes • And therefore have a reference to their superclass interface Mappable{abstract void run(Object o); } void map(Listlist, Mappablelambda) {for(Object o : list) {lambda.run(o);} } map(myList, new Mappable() {void run(Object o) {doCoolStuff(o);} });

39. Use: Adapter Classes • Adapters pass some code or function to another object • Hey, this sounds a lot like an Input… • Subclass them in-line to avoid having to write new classes each time public classDoor extends Entity { private Output onOpen;public Input doOpen= new Input(){public void run() {openDoor(); }};private voidopenDoor() {// … door open code …onOpen.run();} }

40. Use: Listener Classes • Listeners wait for events from other objects • Subclass them in-line to avoid writing new designated listeners • A lot more elegant than having a logic class implement ten interfaces! // inside, say, a JPanel somewhere addActionListener(new ActionListener(){actionPerformed(ActionEvente) {// handle the action as normal } }

41. Some Restrictions • No way to use extends or implements • No non-final static fields • No constructors • Instance initializers exist for exactly this reason!

42. Pitch Your Game! Impress us!

43. Presentation Order 1. wyegelwe2. cody3. kkutt4. jslu5. ebirenba6. aabouche7. sswarr8. kloh9. istrickm10. lelberty11. jhertz12. jte13. gtrousda14. gamyers15. jqtran

44. M2 Playtesting Let’s do it!