No more engine requirements! From now on everything you work on is designed by you. Congrats!

Size: px

Start display at page:

Download "No more engine requirements! From now on everything you work on is designed by you. Congrats!"

Penelope Farmer
6 years ago
Views:

2 No more engine requirements! From now on everything you work on is designed by you Congrats!

3 Design check required Ben: Thursday 2-4 David: Thursday 8-10 Jeff: Friday 2-4 Tyler: Friday 4-6 Final III

4 Don t forget about old projects! Don t forget, you need a working version of each project s primary requirements

5 Announcements QUESTIONS?

7 Not Swing What is OpenGL? java.awt.swing is what you have been using to draw your shapes/sprites Instead of drawing shapes, you pass vertices to draw shapes Loading images into memory is done by binding textures instead of storing BufferedImages OpenGL will replace all Swing components in your rendering engine It s much faster, and allows the use of shaders Native to C++ Using libraries such as JOGL or LWJGL, we can use OpenGL in Java

8 Integrating into your existing engine Create a Graphics interface loadtexture(string path) drawtexture(string name, Vec2f posn, Vec2f dim, Vec2f imageposn, Vec2f imagedim) Shape drawing! drawrect(myrectangle r) drawcircle(mycircle c) Etc. Now your World and Screens can use a generic Graphics object Game is agnostic of implementation Game doesn t need to know if Swing or OpenGL is being used SwingGraphics Graphics GLGraphics

9 LWJGL Light Weight Java Game Library Wrapper library for OpenGL Gives you a window, event polling, access to drawing calls You can use OpenGL and an orthographic projection to draw your 2D game Gives you OpenGL as a set of static methods within static objects according to which version s methods you want to use Use LWJGL 3 Closely mirrors what using OpenGL is actually like in C++

10 Last time on 1971 public class Application extends SwingFrontEnd { public void ontick(long nanos) public void ondraw(graphics2d g) } public void onkeypressed(keyevent evt) // more device and event types... public void onmousedragged(mouseevent evt) Your job is to replace SwingFrontEnd with your own implementation

11 The Loop. public void start() { try { Display.setDisplayMode(new DisplayMode(screenSize.x, screensize.y)); Display.create(); } catch (LWJGLException e) { e.printstacktrace(); System.exit(0); } initgl(); // set up your OpenGL environment long lasttick = Sys.getTime() * / Sys.getTimerResolution(); while (!Display.isCloseRequested()) { pollinput(); // you will write this method to find out what events have happened, and call their methods if (Display.wasResized()) onresize(new Vec2i(Display.getWidth(), Display.getHeight()); long time = Sys.getTime() * / Sys.getTimerResolution(); long delta = time lasttick; lasttick = time; ontick(time); // abstract method, overridden in Application ondraw(g); // abstract method, overridden in Application, g is a graphics object of your making GL11.glFinish(); // OpenGL is an object, GL11 is OpenGL 1.1, you can use whichever version you like Display.sync(60); // tries to stabilize your game at 60fps } Display.destroy(); AL.destroy(); System.exit(0); } // Display, DisplayMode, Sys, and AL are all objects given to you by LWJGL

13 Deferred Lighting Called deferred lighting because we draw a fully lit world, and then defer the lighting to a second drawing pass where we multiply each pixel by the light value (from 0-1) at that pixel This second pass is done in a shader, which for our purposes is a small program that is applied to each pixel on screen and returns a color for that pixel

Deferred Lighting Overall strategy (simplified for

Use an OpenGL FrameBuffer for this Draw all the

value of the circle with the scene texture, thereby

14 Deferred Lighting Overall strategy (simplified for 2D): Draw the scene, storing the color in a texture. Use an OpenGL FrameBuffer for this Draw all the lights as circles use a shader to combine the light value of the circle with the scene texture, thereby revealing the underlying scene Geometry Lights Combined

15 Deferred Lighting Things that the lighting shader will need to know about: Scale and translation of the viewport Radius, color, and position of the light being drawn The texture that the world was rendered to

16 What is a particle? A particle is a tiny entity that is used in massive quantities to create a visually pleasing effect Usually don t affect the gameplay in any significant way Commonly used for explosions Particles

17 What makes particles look good? Fade out or get smaller linearly over their lifespan Once the particle is completely gone or transparent, it can be removed from the world Adding some kind of randomness to how they move Starting position, velocity, acceleration, color, size, shape Particles

18 Particles are great But they are very slow if not done correctly Things that make them slow: It s a lot of information to tick It s a lot of information to draw There are way too many of them to consider doing collision detection against each other Particles

19 Particles Optimizations? Get ready. Reduce the amount of information in your particles Vec2f position, Vec2f velocity, boolean alive maybe some noise values to make them scatter Less information to tick Don t make your particles Entities Keep them in a separate list so that you can tick and draw them all at once If you are using OpenGL, then binding the particle texture once and then drawing all your particles without unbinding and rebinding the texture is a HUGE improvement Don t collide them with each other That s a lot of math If you must have your particles collide, have them collide only with entities, not with each other This means they also don t need a shape, so they take up less space Keep them in an array This limits the number of particles you can have (which might be a good thing) Keeps all the memory contiguous Once you are trying to allocate more particles than you have room for, the oldest ones are kicked out first Tick them in your draw loop But you said to never do that! I know, sorry but in this instance the speed gain of only having to iterate over them once is worth the terrible design

20 Used for foregrounds and backgrounds Each background is scaled by a little bit less, and then translated so that it is offset Something that is scaled by.5 will translate half as much as something scaled by 1, making backgrounds that are farther back move slower Parallax

22 Settings User profile Game settings Game state Progress through the game Maybe the state of the world or current level What to Save?

23 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!

24 Data Persistence PERSISTENT CONFIGURATION

25 Player name Custom controls Other In-game preferences Considerations Need to save per user Should be able to export between game instances User Settings

26 Saving Game Settings Preferred resolution Graphics detail level Considerations Need to save per installation of game Should not go in cloud storage machinespecific, can t sync

27 Serialize a Java object Java properties file XML/JSON file Easy for humans to read Harder to parse, but can use libraries Custom text format Even harder to parse Strategies

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

29 Data Persistence SAVING GAME STATE

30 When to Save Game Only at checkpoints Easier to implement Potentially more frustrating for player Ensure they re frequent enough

31 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)

32 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)

33 Automatic Saving A good idea if the player is responsible for saving Just because saves are available doesn t mean the player 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)

34 Save slots Easy, simple, annoying Native file browser Easy way to allow arbitrary saves Doesn t mesh well with game, unprofessional User Interface

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

36 What if the save file is corrupted? Don t exit with a stack trace Error Handling

37 Data Persistence QUESTIONS?

39 Tips for Final 3 JAVA TIP OF THE WEEK

40 Constructors are Lame Superconstructors put restrictions on the order complex calculations can be performed Leads to duplicate code in constructors We d also like to have initialization near the variable source public class MyClass { private int i; private String str; } public MyClass(int i) { this.i = i; str = I m number + i; } public MyClass(OtherClass other) { // We can t put code before this this(0); for (...) i += 1; str = I m number + i; }

41 Initializer blocks! Unlabeled blocks of code directly in the class body Initializer blocks solve problems with duplicated constructor code and allow initialization to be performed at the variable declaration Executed from top to bottom when the class is instantiated public class InitBlockExample { } public static final String s; static { String temp; // complicated logic here s = temp; }

42 Field initialization shorthand Field initialization is just shorthand for initializer blocks public class MyClass { private static int i = 12; private String str = ; } public class MyClass { private static int i; static { i = 12; } } private String str; { str = ; }

43 Good uses Immutable final collections Lists, maps, etc. Keeping complicated initialization code near field Debugging! public class GoodUses { static final Map<String, String> m; static { Map<String, String> t = /* */; // lots of puts here m = Collections.immutableMap(t); } } int complicatedinit; { // complicated init code } GoodUses(int ap) {} GoodUses(int ap, String s) {} GoodUses() {}

44 Other Fun Stuff 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 Don t ever do this public class Mainless { static { String s = Look, ma! ; s += No main! ; System.out.println(s); System.exit(0); } }

45 Tips for Final III QUESTIONS?

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

Playtesting Reminders. Don t give hints or instructions Watch your playtesters: more useful than their feedback Turn in handwritten signatures 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 Playtesting Reminders Don t give hints or instructions