Lecture 11

1. Lecture 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. Announcements Questions?

5. Lecture 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 • OggVorbis • 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 Uncompressed Sound Files Record as much as possible of sound wave Much larger file size Usually high quality Faster to decodeand play Used for sound effects • 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

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 Sound device Buffer Decoding Sound file

12. Sound in Java • Lines, DataLines, andClips • 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 AudioInputStreamstream = AudioSystem .getAudioInputStream(new File(“mysound.wav”)); Clipclip = AudioSystem.getClip(); clip.open(stream); clip.start(); AudioFormatformat = stream.getFormat(); SourceDataLineline = AudioSystem .getSourceDataLine(format); line.open(format); intnRead=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 • MidiSystemis like AudioSystemfor MIDI files Sequence song = MidiSystem.getSequence(new File(“mysong.mid”)); SequencermidiPlayer = MidiSystem.getSequencer(); midiPlayer.open(); midiPlayer.setSequence(song); midiPlayer.setLoopCount(0); midiPlayer.start();

14. Sound Questions?

15. Lecture 11 Data Persistence

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

17. Data Persistence Settings

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. Data Persistence Game state

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. Data Persistence Questions?

31. Lecture 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. Tips for Final III Java Tip of the Week

34. The Many Uses of final • Did you know? finalcan 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}; publicExample(String name, float mass) { this.name = name; this.mass = mass; } }

36. Warning: finalObjects Aren’t Immutable • finalmakes object reference constant, not object itself • Can still change a finalfield if object is mutable • Arrays are objects public class FinalContainer{ publicfinalList<Integer> stuff; publicfinalString[] things; publicFinalContainer(List<Integer> stuff, String[] things) { this.stuff = stuff; this.things = things; } } … FinalContainercontainer = newFinalContainer(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 classVec2f { public final float x; public final float y; publicVec2f(float x, float y)… } public class Results { public final boolean collision; public final Vec2f point; public final Vec2f mtv; publicResults(boolean collision, Vec2f point, Vec2fmtv)… }

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 publicfloatdoStuff(int[] nums) { intsum = 0; for(final intnum : nums) sum += num; final floatave = sum / (float) nums.length; //illegal: ave += 1; finalList<Float> list = newArrayList<Float>(); list.add(sum); list.add(ave); returnave; }

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) { finalTextFieldfield = new TextField(text); field.setVisible(false); this.add(field); Buttonbutton = newButton(“Click to show”, newButtonListener() { 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 intstart, final int end) { //illegal while(start < end) { start++; … } //legal for(inti = 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(finalVec2f point, final float dist) { Vec2fendPoint = point.plus(dist, dist); float mag = Math.sqrt(dist);//many more computations… //much later in the method floatsqr = 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 intcount; 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 classTree<E extends Element> {public final boolean add(Eelem) { Node<E> newNode = new Node<E>(elem); Node<E> parent = getParent(elem); parent.addChild(newNode); rebalance(parent); } publicNode<E> getParent(Eelem){…} public void rebalance(Node<E> changed) {…} }

45. Tips for Final III Questions?

46. Final II Playtesting Your games are playtestable now!