Lecture 8

1. Lecture 8 Announcements

2. on Sunday • 3pm in the CIT lobby • We’ll be contrib-combing! • Sign up to get a shirt at http://tiny.cc/bgdshirts • The more signups we get the cheaper they’ll be

3. CS195U: 3D Game Engines • Running next semester! • Timeslot probably 3p-5:20 Wed • Requires 123 and one of 195N or 32 • Topics include physics, world/level representation, pathfinding over navigation meshes • 4 projects: warmup, minecraft, platformer, final • http://cs.brown.edu/courses/cs195u/ • See the website from last semester for more details • You can run the project demos in /course/cs195u/demo

4. cs195n_editor • We’ve received very little feedback about it • Not sure if this is a good or bad sign • How has using it been? • What’s missing? • Is there anything unnecessary in it?

5. Final Project Group signups • They’re out now! • 1-person groups must sign up for a 15min slot • All others must sign up for two adjacent slots (30 minutes total) • No explicit preparation necessary, but think about engine feature breakdown

6. Announcements Questions?

7. Lecture 8 Entity I/O Case Studies

8. Entity I/O Case Studies DISCLAIMER

9. Entity I/O Case Studies AdvanCed Entity I/O

10. Existing system • Every entity (that wants to take part in I/O) has to have a name • All inputs/outputs hardcoded in • All connections defined point-to-point on map load

11. Limitations • Targeting multiple entities requires a new connection for each • Impossible to target entities that are: • Nameless • Dynamically created • No way to change connections at runtime

12. Targeting multiple entities • Target doesn’t have to be a single entity name • Comma-separated list • Wildcards: * ? • Or even regexes • Even entity classes • But be careful!

13. Special targets • !self • Entity the input is being fired on (good when duplicating entities) • !caller • Source entity of the connection that fired this connnection • !activator • Entity that started the chain of I/O events • !picker • Entity the cursor is over (good for debugging) relay.onFired -> wall.doRemove sensor.onPlayerTouch-> relay.fireIfEnabled relay !self !caller !activator wall sensor

14. onUser and doUser • Every entity has outputs onUser[1,n] and inputs doUser[1,n] • doUser2 simply fires onUser2 • Allows for “dynamic dispatch” • Different entities have different “implementations” • Only really useful combined with multiple/special targets

15. doAddOutput input • Input that dynamically creates a new connection with the current target entity as the source • New connection’s other data is defined as properties of the connection • Output to bind to • Target • Input to target • Useful whenever using a relay is impractical/impossible

16. Entity I/O Case Studies Entity Case Studies

17. Counter entity • Keeps track of an integer internally that can be incremented and decremented • Fires outputs accordingly when the value changes • Sample inputs: • doIncrement • doDecrement • doReset • doEnable, doDisable • Sample outputs: • onMaxHit • onMaxLeft • onValueChange

18. Physics entities • Force volumes • Apply a force to all entities contained within it • Useful for making wind, fast-moving water, areas with different gravity... • Physicsplosions • Basically what your M III “grenades” did push

19. Filter entity • Referred to by other entities (as a property) to restrict activation • Esp. sensors, force volumes • Can filter by entity name, entity class, or any other property • Can combine filters with e.g. AndFilter, OrFilter

20. Template spawner entity • Has references to one or more “template entities” via properties • Removes template entities from world as soon as level loads • doSpawn input spawns a copy of the template entities • Appends # to end to distinguish between copies • Can also copy connections with source = a template entity

21. Further inspiration • CS195N entity I/O is based on the entity I/O system of the Source engine • For more information and inspiration, entity I/O is fairly well documented the Valve developer wiki : • https://developer.valvesoftware.com/wiki/Targetname • https://developer.valvesoftware.com/wiki/Inputs_and_Outputs • https://developer.valvesoftware.com/wiki/List_of_entities

22. Entity I/O Case Studies Questions?

23. Lecture 8 Tips for M IV

24. This week is very open-ended • This week you can pick from a large number of reqs to implement • If you have an idea not on the list, just ask a TA to approve it! • You’ve built a very extensive engine over the past several weeks • Time to enjoy it!

25. Tips for M IV Java Tip of the Week

26. Initializer blocks! • Constructors alone leave a few things to be desired • Repeated code in constructors • No “static” constructor • Would be nicer to have initialization code near field declaration • Initializer blocks solve all of these • Unlabelled blocks of code directly in the class body • Concatenated and run in order when • an instance is made, for non-static blocks • when the class is loaded, for static blocks (usually right before first instantiation) publicclassInitBlockExample{ { System.out.print(“what is this”); } public static final String s; static { String temp; // complicated logic here s = temp; } { System.out.println(“i don’t even”); } }

27. Field initialization shorthand Field initialization is just shorthand for initializer blocks publicclassMyClass{ privatestaticinti; static { i= 12; } privateStringstr; { str = “”; } } publicclassMyClass { privatestaticinti = 12; privateStringstr = “”; }

28. Order of evaluation classSuper { publicSuper() { System.out.println(“Superconstructor!”); } } publicclassInitBlockExampleextendsSuper { { System.out.println(“Regular init!”); } static{ System.out.println(“Static init!”); } publicInitBlockExample() { super(); System.out.println(“Constructor!”); } publicstaticvoid main(String[] args) { System.out.println(“Main!”); newInitBlockExample(); } } • What output does the code on the right yield? • Answer: • Static init!Main!Superconstructor!Regular init!Constructor! • Why?

29. Main-less Java Programs • When you specify a main class to run, the JVM: • Loads class via reflection • Calls main() via reflection • Thus, static initializers are actually run before main() • Can System.exit(0) at the end of the static initializer to exit gracefully rather than crash with NoSuchMethodException • But never actually do this publicclassMainless { static{ String s = “Look, ma! ”; s += “No main!”; System.out.println(s); System.exit(0); } }

30. Good uses • Immutable final collections • Lists, maps, etc. • Keeping complicated initialization code near field • Debugging! publicclassGoodUses{ static final Map<String, String>m; static { Map<String, String>t = /*…*/; // lots of puts here m = Collections.immutableMap(t); } intcomplicatedInit; { // complicated init code } GoodUses(intap) {} GoodUses(intap, String s) {} GoodUses() {} }

31. Tips for M IV Questions?

32. M III playtesting! Woohoo!