1. L ECTURE 11 Announcements

2. Deadline Approaching Course policy: you must turn in a working version of all projects Deadline for incomplete projects is December 19 Same day as Final V

3. Playtesting Reminders Don’t give hints or instructions Watch your playtesters: more useful than their feedback Turn in handwritten signatures

4. QUESTIONS? Announcements

5. L ECTURE 11 Sound

6. Sound in Games In the real world, computers have sound Background music Sound effects Can be an important part of gameplay – Listening for footsteps – Dramatic music

7. Sound File Formats Many ways to encode and store sound Open standards – Ogg Vorbis – FLAC Closed standards – mp3 – m4a – wav

8. Sampled Audio mp3, wav, etc. Recordings of live sounds Samples of sound wave at regular intervals Can be any sound that exists in real life, but must create & record it More common in today’s games 1100100110101011011101011001000110101

9. Generated Audio MIDI Instructions for computer to play music Sound cards have tables of note sounds Can instruct computer to play something even if you can’t play it Used to be popular to save space, not as common now

10. Compressed vs. Uncompressed Compressed Sound Files Lossy or Lossless? – Lossy remove “least important” parts of sound wave – Lossless just use smart compression on raw wave Smaller file size (esp. lossy) Lossy is lower quality Slower to decode and play Used for music Uncompressed Sound Files Record as much as possible of sound wave Much larger file size Usually high quality Faster to decode and play Used for sound effects

11. Buffering Decompressing and decoding is slow Read sound into buffer, play back from buffer Size of buffer depends on speed of system Playback delay while buffer is filled Buffer Sound file Sound device Decoding

12. Sound in Java Line s, DataLine s, and Clip s – Sources of audio for software audio mixer – Clip is preloaded samples, DataLine is streaming audio from buffer AudioSystem – Provides factory methods for loading audio sources AudioInputStream stream = AudioSystem.getAudioInputStream(new File(“mysound.wav”)); Clip clip = AudioSystem.getClip(); clip.open(stream); clip.start(); AudioFormat format = stream.getFormat(); SourceDataLine line = AudioSystem.getSourceDataLine(format); line.open(format); int nRead=0; byte[] data=new byte[4096]; while(nRead > -1) { nRead = stream.read(data, 0, data.length); line.write(data, 0, nRead); }

13. Sound in Java Sequencer plays MIDI sounds MidiSystem is like AudioSystem for MIDI files Sequence song = MidiSystem.getSequence(new File(“mysong.mid”)); Sequencer midiPlayer = MidiSystem.getSequencer(); midiPlayer.open(); midiPlayer.setSequence(song); midiPlayer.setLoopCount(0); midiPlayer.start();

14. QUESTIONS? Sound

15. L ECTURE 11 Data Persistence

16. What to Save Settings – User profile – Game settings Game state – Progress through level – Various styles of saving

17. SETTINGS Data Persistence

18. Saving User Settings Custom controls Player name Considerations – Need to save per user – Should be able to export between game instances – Ideally put in cloud sync

19. Saving Game Settings Preferred resolution Graphics detail level Considerations – Need to save per installation of game – Should not go in cloud storage – machine- specific, can’t “sync”

20. Strategies Serialize a Java object Java properties file XML/JSON file – Easy for humans to read – Harder to parse Custom text format – Can be more concise, easy to parse

21. User Interface User probably doesn’t need to know file location – Still make it easy to find so user can back it up Don’t save automatically, revert graphics changes if no response

22. GAME STATE Data Persistence

23. When to Save Game Only at checkpoints – Easier to implement – Each checkpoint is a level, reload level when player dies – More frustrating for player – Ensure they’re frequent enough

24. When to Save Game Any time at save stations – Like checkpoints, but user can go back and resave – Better for nonlinear games – Need to save level state/ progress, but not exact positions (save room usually empty)

25. When to Save Game Whenever user wants – Harder to implement, need a “snapshot” of current game state – Good for difficult games with frequent failure – Can still restrict when user can save (e.g. not during combat)

26. Automatic Saving Always a good idea, even when user can choose when to save Just because saves are available doesn’t mean user will use them Don’t set user too far back when they fail

27. Strategies Serialize and restore entire game world Save some info about player progress and reload level Concise save file that can be unmarshaled into game world

28. User Interface Save “slots” – Easy, simple, annoying Native file browser – Easy way to allow arbitrary saves – Doesn’t mesh well with game, unprofessional

29. User Interface Custom save-file browser – Harder to implement, but most flexible/featureful Features – Screenshot of saved game – Show only current player’s saves – Sort by time & type of save

30. QUESTIONS? Data Persistence

31. L ECTURE 11 Tips for Final III

32. Gameplay is Important Implement most of your game logic this week Playtest early and often Use the feedback you’re getting

33. JAVA TIP OF THE WEEK Tips for Final III

34. The Many Uses of final Did you know? final can be applied to: – Instance variables – Local variables – Method parameters – Classes – Methods

35. Final Instance Variables Value never changes Can be set in constructor or initializer block – Must be set by the time an instance is created Can be different between instances of same class public class Example { private final float mass; private final String name; private final int[] values = {1, 2, 3, 4, 5}; public Example(String name, float mass) { this.name = name; this.mass = mass; } }

36. Warning: final Objects Aren’t Immutable final makes object reference constant, not object itself Can still change a final field if object is mutable Arrays are objects public class FinalContainer { public final List stuff; public final String[] things; public FinalContainer(List stuff, String[] things) { this.stuff = stuff; this.things = things; } } … FinalContainer container = new FinalContainer(myList, mySet); container.stuff.clear(); container.things[0]= “oops”;

37. Final Instance Variables Denote fields that should never change over lifetime of object Safe(r) to make final fields public Useful for ensuring objects are immutable Useful for making “structs” public class Vec2f { public final float x; public final float y; public Vec2f(float x, float y)… } public class Results { public final boolean collision; public final Vec2f point; public final Vec2f mtv; public Results(boolean collision, Vec2f point, Vec2f mtv)… }

38. Final Local Variables Must be set immediately at declaration Value can’t change Can assign new final variable with same name Same warning: Object references can’t change, objects are still mutable public float doStuff(int[] nums) { int sum = 0; for(final int num : nums) sum += num; final float ave = sum / (float) nums.length; //illegal: ave += 1; final List list = new ArrayList (); list.add(sum); list.add(ave); return ave; }

39. Final Local Variables Help guarantee a value doesn’t change after being computed Allow inner classes to access local variables – Inner class “saves” state of local variables, only works if they don’t change public void addShowField(String text) { final TextField field = new TextField(text); field.setVisible(false); this.add(field); Button button = new Button(“Click to show”, new ButtonListener() { public void onClicked() { field.setVisible(true); } }); this.add(button); }

40. Final Parameters Special kind of local variable, same behavior Set by caller, can’t change once in method Note that changing parameters wouldn’t affect caller anyway public boolean contains(final String query, final int start, final int end) { //illegal while(start < end) { start++; … } //legal for(int i = start; i < end; i++) { … } } if(sequence.contains(“stuff”, 0, 5))… if(sequence.contains(“things”, 8, 60))…

41. Final Parameters Guarantee that parameters always represent caller’s values If you need to compute something, use a local variable Easier maintainability in long methods public void compute(final Vec2f point, final float dist) { Vec2f endPoint = point.plus(dist, dist); float mag = Math.sqrt(dist); //many more computations… //much later in the method float sqr = dist * dist; Vec2f extend = point.smult(sqr); //do more stuff… }

42. Final Classes Can’t be extended Useful for designing libraries Ensures clients can’t break other classes by changing expected behavior public final class Data { private int count; private float total; … public float getAverage() { return total / count; } public void add(float datum) { total += datum; count++; } }

43. Final Methods Can’t be overridden Selectively allow inheritance In a final class, all methods are final Abstract classes can have final methods abstract class Parser { //can’t be overridden final void loadFile(File file) { //(read file into memory) } //can be overridden boolean validateFile() { boolean success = true; for(String line : fileLines) success = success && validate(line); return success; } //must be overridden abstract boolean validate(String line); }

44. Final Methods Also useful for libraries – Can even guard yourself against bad design Prevent subclasses from changing some behavior Guarantee important setup happens More useful if your code is modular public class Tree { public final boolean add(E elem) { Node newNode = new Node (elem); Node parent = getParent(elem); parent.addChild(newNode); rebalance(parent); } public Node getParent(E elem){…} public void rebalance(Node changed) {…} }

45. QUESTIONS? Tips for Final III

46. F INAL II P LAYTESTING Your games are playtestable now!