lecture 10

76
LECTURE 10 Announcements

Upload: aubrey-livingston

Post on 30-Dec-2015

26 views

Category:

Documents


0 download

DESCRIPTION

Lecture 10. Announcements. Final 1 Feedback. Almost completely done with your 2D game engine! Congratulations! Feel free to use it/improve after the class is over (some of us have/still are) Time to start showing off your product ~2.5 weeks of gameplay coding! Content creation! - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Lecture 10

LECTURE 10Announcements

Page 2: Lecture 10

Final 1 Feedback• Almost completely done with

your 2D game engine!– Congratulations!– Feel free to use it/improve after

the class is over (some of us have/still are)

• Time to start showing off your product– ~2.5 weeks of gameplay coding!– Content creation!– Tons of playtesting!

• More on public playtesting later…

Page 3: Lecture 10

Hours change?• For specific problems you

should be talking to your mentor TA

• We’ll hold hours for issues with finishing up late projects– What times work best?

• Will announce times after grading meeting today

Page 4: Lecture 10

Special topics AI lecture!• It’s the week after

thanksgiving• It’ll be great

Page 5: Lecture 10

Next Week Doesn’t Exist• No lecture• No hours• No assignment due

• Final II due the next week

• Doesn’t count against retries• Final I retries due the

next week

Page 6: Lecture 10

Deadline Approaching• Course policy: you must turn in a working

version of all projects• Deadline for incomplete projects is

December 20• Same day as Final V• Make sure to email the TA staff when you

re-turn in!

Page 7: Lecture 10

QUESTIONS?Announcements

Page 8: Lecture 10

LECTURE 10Sound

Page 9: Lecture 10

SOUND APPLICATIONSSound

Page 10: Lecture 10

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

Page 11: Lecture 10

Sound File Formats• Many ways to encode

and store sound• Open standards

– Ogg Vorbis– FLAC

• Closed standards– mp3– m4a– wav

Page 12: Lecture 10

Sampled Audio• mp3, wav, and most other

familiar extensions• Usually recordings of live

sounds• Samples of sound wave at

regular intervals• Prevalent in modern games• Refers to data type, not

origin– Touchtone telephone is

generated but still sampled11001001101010110111010110010001

10101

Page 13: Lecture 10

Generated Audio• MIDI• File provides information on

instruments and notes– Similar to sheet music

• Sound cards translate from instruments/notes to sound

• Can instruct computer to play something even if you can’t play it

• Used to be popular to save space, not as common now

Page 14: Lecture 10

Compressed vs. UncompressedCompressed 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• Often 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• Often used for sound

effects

Page 15: Lecture 10

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

Page 16: Lecture 10

SOUND IMPLEMENTATIONSound

Page 17: Lecture 10

javax.sound.sampled• AudioSystem: Provides factory

methods for loading audio sources

• Clip: Any audio that can be loaded prior to playback

• Line: Any source of streaming audio

• DataLine: An implementation of Line with helpful media functionality (start, stop, drain, etc)

• Other classes for mixing, ports, and other utilities

File file = new File(“mysound.wav”);InputStream in =

new BufferedInputStream(new

FileInputStream(myFile));

AudioInputStream stream = AudioSystem .getAudioInputStream(in);

Clip clip = AudioSystem.getClip();clip.open(stream);clip.start();

Page 18: Lecture 10

javax.sound.midi• MidiSystem: The

AudioSystem for MIDI files• Sequencer: Plays MIDI

sounds• Other classes for

manipulation of instruments, notes, and soundbanks– So you can create MIDI sounds

in realtime– Much harder to manipulate

samples

Sequence song = MidiSystem.getSequence(new File(“mysong.midi”));Sequencer midiPlayer = MidiSystem.getSequencer();midiPlayer.open(); midiPlayer.setSequence(song);midiPlayer.setLoopCount(0);midiPlayer.start();

Page 19: Lecture 10

Alternatives?• Some drawbacks of the built-in

sound classes…– Imprecise control over exact

playback start/stop positions– Almost impossible to manipulate

or even examine samples in realtime

– While Java offers pan and reverb, other libraries offer more varied effects

• But it’s very effective for simple background music and sfx!

Page 20: Lecture 10

OpenAL• Cross-platform audio API

modeled after OpenGL• Pros:

– Built for positional sound (distance attenuation, Doppler shift, etc all built in)

– More fine-grain control available

• Cons:– Single listener model– Modeled on OpenGL

Page 21: Lecture 10

Others• Most other libraries are

platform-specific or wrappers for OpenAL

• …except for synthesis libraries!– Jsyn, Beads, etc– Useful for composer

programs and the like, not so much for sound playback

Page 22: Lecture 10

QUESTIONS?Sound

Page 23: Lecture 10

LECTURE 10Data Persistence

Page 24: Lecture 10

What to Save?• Settings

– User profile– Game settings

• Game state– Progress through the

game– Maybe the state of

the world or current level

Page 25: Lecture 10

Where to Save?• Data should be saved somewhere that

is always accessible by your program!– Oftentimes the user’s home directory can

be used for this purpose

• Saving data to the current directory will not work, as your program can be run from anywhere!

Page 26: Lecture 10

PERSISTENT CONFIGURATION

Data Persistence

Page 27: Lecture 10

User Settings• Player name• Custom controls• Other In-game

preferences• Considerations

– Need to save per user– Should be able to export

between game instances– Ideally put in cloud sync

Page 28: Lecture 10

Saving Game Settings• Preferred resolution• Graphics detail level• Input source (keyboard,

peripheral, etc)• Considerations

– Need to save per installation of game

– Should not go in cloud storage – machine-specific, can’t “sync”

Page 29: Lecture 10

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

Page 30: Lecture 10

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

Page 31: Lecture 10

SAVING GAME STATEData Persistence

Page 32: Lecture 10

When to Save Game• Only at checkpoints

– Easier to implement– Each checkpoint is a

level, reload level when player dies

– Potentially more frustrating for player

– Ensure they’re frequent enough

Page 33: Lecture 10

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)

Page 34: Lecture 10

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)

Page 35: Lecture 10

Automatic Saving• A good idea if the player is

responsible for saving– Just because saves are

available doesn’t mean user will use them

• Don’t set user too far back when they fail

• Depending on implementation, can simplify saved state (ie, only save when no enemies are around)

Page 36: Lecture 10

User Interface• Save slots

– Easy, simple, annoying

• Native file browser– Easy way to allow

arbitrary saves– Doesn’t mesh well

with game, unprofessional

Page 37: Lecture 10

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

Page 38: Lecture 10

Strategies• Save serialized copy of game world

– On restore, use serialized data as the world

• Save information about which level the player is on and where entities are located– On restore, load the level fresh and then apply changes

• Save some concise file with relevant state information– On restore, act accordingly… like warp to nearest

checkpoint, or load the level and place player at save point

Page 39: Lecture 10

Gotchas• Serializing the world…

– Whoops! We just serialized input states, the screen stack, player preferences…

– Solution: correctly label with Serializable

• Saving generated levels…– Can’t just store level file name!– Solution: Either save the seed

and a list of changes, or convert generated map into some savable format

• The same error-handling warnings from Tac apply

Page 40: Lecture 10

QUESTIONS?Data Persistence

Page 41: Lecture 10

LECTURE 10Procedural Content II

Page 42: Lecture 10

CLASSIFICATIONProcedural Content

Page 43: Lecture 10

What is procedural content?• Procedural content:

game content generated in an algorithmic way rather than by a designer

• Procedural content generation: the generation of this content via a semi-random process

Page 44: Lecture 10

Generated Content• “Procedural generation”

in common usage usually refers to any randomized aspect of game content

• All procedural content need not be generated, or generated randomly– Content deterministically

inferred from other content

Page 45: Lecture 10

Why use procedural content?• Historically: memory

restrictions required it• Generating by hand is

tedious and/or expensive• In the case of procedurally

generated content, provide a new experience with every game

• Provide a personalized experience

Page 46: Lecture 10

Online vs. Offline• Online

– Game content is generated on the fly

– Limitless potential!

• Offline– Game content is generated

by algorithm and then packaged with the game

– Can be perfected by a human designer

Page 47: Lecture 10

Necessary vs. Optional• Necessary

– Required by the player to progress in the game

– Must always be correct or useable

• Optional– Player can choose to

avoid or bypass– Some weirdness is fine

Page 48: Lecture 10

Random vs. Parameterized• All procedural content

performs some sort of expansion from compressed data to real content– What is the compressed form?

• Random– Compressed form is RNG seed

• Parameterized– Compressed form is a

parameter vector– Most often used for

personalized content

Page 49: Lecture 10

Constructive vs. Verified• Constructive

– Generate the content and be done with it

– Need to make sure it’s correct at every step

• Verified– Both a content generator

and a content verifier– Generate the content

until it’s suitably fit

Page 50: Lecture 10

QUESTIONS?Procedural Content

Page 51: Lecture 10

Classification quiz!

Page 52: Lecture 10

Classification quiz!

Page 53: Lecture 10

APPLICATIONSProcedural Content

Page 54: Lecture 10

Procedural Animation• Animating every pose

of a character can be difficult

• Generate poses by joints and constraints

• Can even animate each portion separately

• Could also refer to particle effects

Page 55: Lecture 10

Dynamic Lightmaps• Lightmaps are used to

store lighting information– Separate from textures– Provides significant

graphical speedup

• Rather than defining them for each object, generate them algorithmically

Page 56: Lecture 10

Natural Textures and Terrain• Perlin noise: generated

visual effect that simulates natural texture

• Even used in CGI for flames, smoke, clouds etc

• Computed by calculating distance to grid vertices then interpolating

Page 57: Lecture 10

Level Generation• Create random level

layouts at runtime• Can be used to make

dungeons, interiors, cities, maps, etc

• Algorithms are numerous and vary by purpose– Popular dungeon algorithm:

subdivide dungeon in a binary tree, add a room to each

Page 58: Lecture 10

Design of Level Content• Generate many enemies

or weapons with different attributes, then pick those that most satisfy the scenario

• Alternatively, generate many levels then evaluate them via a fitness function

• Underpins most sandbox games

Page 59: Lecture 10

Dynamic World Generation• Entire game world is

generated on the fly• No part of the world is

written to disk– Unneeded parts are

immediately disposed

• Hinges on deterministic generation and a single RNG seed

• Used in EVE Online as well as a variety of older games

Page 60: Lecture 10

Instancing In-Game Entities

• Each entity has some value randomized– All entities are similar,

but have some distinguishing feature

• Usually used to create names, faces, item or weapon properties

Page 61: Lecture 10

Dynamic Systems• Model complex behaviors

with simple sets of rules• Used for weather,

crowds, spreading fire, and other bottom-up effects

• Strong ties to certain areas of AI, like swarm intelligence

Page 62: Lecture 10

Plot and Puzzle Generation• Think of a game’s storyline as

a dependency graph• Graph dependencies can be

changed– For example, move a key to a

random accessible location

• Graph structure can be changed– Alters order of events

• Can also use natural language processing to create characters and stories

Page 63: Lecture 10

QUESTIONS?Procedural Content

Page 64: Lecture 10

LECTURE 10Tips for Final 2

Page 65: Lecture 10

EFFECTIVE PLAYTESTINGTips for Final 2

Page 66: Lecture 10

Finding Playtesters

• CS students are easy targets, try the sun lab or MS lab– Ask nicely– Don’t ask busy people

• Keep your audience in mind, however– It probably isn’t all CS

students

Page 67: Lecture 10

Don’t Interrupt!• Be a fly on the wall

– Say as little as possible

– Don’t offer hints or instructions

• Your game should speak for itself– You won’t be there to

offer instructions when your game is released

Page 68: Lecture 10

When to Interrupt• Player is frustrated or

taking too long in a single area

• You’re no longer getting good feedback

• If the player moves on, you will resume getting good feedback

Page 69: Lecture 10

Keep a Log• What is the player getting

stuck on?– Make it smoother

• What is the player enjoying?– Emphasize it

• What is the player ignoring?– Take it out if it’s unnecessary

• Consider having the game keep an automated log– Analytics is wonderful!

Page 70: Lecture 10

QUESTIONS?Tips for Final 2

Page 71: Lecture 10

JAVA TIP OF THE WEEKTips for Final 2

Page 72: Lecture 10

Default Visibility

• You already know public, private, protected

• What happens when there’s no visibility modifier?

• Then the field/method is visible to anything in the same package

Page 73: Lecture 10

A Helpful Table

Own Class Same Package

Subclass All Others

public Visible Visible Visible Visible

protected Visible Visible Visible No

(default) Visible Visible No No

private Visible No No No

Page 74: Lecture 10

Some General Visibility Tips

• Use private wherever possible– “Encapsulation”

• If you have a large amount of protected methods you want truly protected, consider separating them into an interface

Page 75: Lecture 10

QUESTIONS?Tips for Final 2

Page 76: Lecture 10

NO PLAYTESTING?

Playtest with random people this week!