1 / 32

Lecture 8

Lecture 8. Announcements. 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. CS195U: 3D Game Engines. Running next semester! Timeslot probably 3p-5:20 Wed

lefty
Download Presentation

Lecture 8

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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!

More Related