The Final Project

1. The Final Project As you arrive, please sit in your project groups.

2. “Your design exemplifies a strong command of the design concepts discussed in this course. You have chosen a good balance between useful default functionality and providing the ability for custom expansion. Your design is sophisticated, involving several different classes interacting in an interesting way that goes beyond a single pattern. Your explanation is clear and shows effort, including code samples and diagrams where appropriate. Your design document shows a detailed command of the terminology and discusses several design alternatives each of which is a viable design in its own right.” -Final Project Grading Standards

3. The Goal of the Final Project • To let you show your design skills in an unconstrained but challenging environment • To give you experience with working with a larger group on a large project • To give you a showpiece you can be proud of to talk to potential employers

4. Go to the course website and check out the final project details

5. 3 Parts • The Library (also potentially called the framework, the API, or the Engine) • The Level Editor • The Demo Game

6. What is an API • API stands for “Application Programmer Interface” • Technically it just refers to just the interface that an external programmer uses • So if I say “my code uses the Java collections API” it means that I use the collections classes as specified in the Java standard (there could be multiple different implementations…e.g. Oracle’s JDK verses Google’s Andriod java) • So in theory, you can specify an API without ever actually implementing it at all

7. API/Library/Framework/Engine • In theory, you can have a API without a particular implementation • In practice API, Library, Framework, and Engine all generally refer to big collections of OO classes that are designed to found and reused • Framework and Engines tend to imply that you’ll have to build your application within them (e.g your code is a small bit of a larger framework) • I’ll use library, but your can design your library/framework/whatever to be as big as you like

8. Your Goal: Create a Library to Make Creating a Specific Genre of Game Easy • Not to make a specific game…you want many games to be creatable with your library • You’ll obviously have to write a lot of code to solve annoying problems within the genre • You’ll also have to decide on the API – that is how will ordinary game developers use your framework?

9. Example: Fighting Games • Classes I might think about: • Fighter • Level • FighterSelectScreen • Move • FightStatusBar • Maybe weapon?

10. What would the Ideal Interface Be? Fighter ryu = new Fighter(“Ryu”); AttackMoveryuPunch = new AttackMove(); ryuPunch.setAnimation(“RyuPunch.animation”); ryuPunch.setDamage(23); ryu.addMove(ryuPunch); public class Ryu extends Fighter { //inherited from abstract superclass public List<AttackMoves> getMoves() { OR

11. A Balance Between Functionality and Extendability Fireball f = new FireBall(); f.setImage(“fireBall.png”); f.setSpeed(3); f.setDamage(22); But what if somebody wants a fireball that doesn’t move in a linear way? Maybe the fireball class has an updatePosition function I can override? Or maybe there’s a general class BattleObject I ought to be subclassing? • The essence of the Open/Closed Principle: • It’s never possible for your design to be “open” to every possible extension • But by choosing your abstractions carefully, it can be open to a variety of different improvements

12. Level Editor • Lets you place the different elements in a game to create levels • Also lets you modify the properties of stuff in the game to customize enemies, items, etc. • http://www.youtube.com/watch?v=OxhIWz2q19M

13. Demo Game • A sample so that you can show off the features of the framework • Exercises everything the framework can do • Exercises the extendibility as well as the “default” behavior • Must use levels created by the level editor

14. You must find 1 hard problem for yourself • The Library (also potentially called the framework, the API, or the Engine) • The Level Editor • The Demo Game • One hard design problem • Your final design to solve this problem is ~25% of your overall Vooga grade Everybody’s Problem Your Individual Problem

15. What makes a good design problem? • A bad problem: fighter selection screen Too Straightforward – No Interesting Design

16. Regions of Attack Moves as the animations progress Often have different priorities (e.g. one move beats another, or beats blocks) Multiple attacks can hit at once What’s the new state?

17. How Could I Solve This • Maybe make an abstract class like MoveHitArbitrator that returns the resultant state from a move collection • Built some simple Arbitrator like SimpleMovePriorityArbitrator, but also possible or developers to add more • Maybe we have a MoveAffectRegion classes that actually determine if the move touches • Seems like we might want to control the whole dang thing from a config file of some sort…but how would custom developers add new types of hit regions to the config file format? Seems complicated – Interesting Design!

18. Individual Design Contributions versesThe Overall API • Sometimes there are really useful features that don’t warrant a design contribution – do these if they really help your developers but make sure your main features are individual design contributions • Sometimes there might be design contributions that don’t affect the external API – a really cool GUI framework for the level editor for example • BUT most of your individual contributions should (at least in part) be part of the overall API • The focus of your individual design doc verses group is different though…the overall design is not just 8 individual docs stapled together

19. Due Next Monday 8am • [Team] Come up with a first stab at your overall big picture design (focus on what features you want to have and what your hypothetical game developer’s code will look like) 33% of grade • [Team] Code a basic “round trip” where the demo game (using the framework) loads a level built in the level editor and “plays” it. (Does not really need to be a game but it should be at least displayable, maybe have one enemy) 33% of grade • [Individual] Come up with a written proposal about the hard design problem you’d like to work on (I highly recommend you talk with you TAs beforehand, kick around ideas, before the “official” proposal) 33% of grade

20. After Next Week 3 Intermediate Milestones All graded the same (all this stuff is individual): • 25% Coming to meetings (1 1-on-1 meeting, 1 group meeting) • 25% Writing Functional Code • 25% Writing Clean, Signoffable Code • 25% Revising your final Design document about your hard problem All milestones due 8am on Friday. No late submissions.

21. Last Friday of Class (4/27 8am):Final Submission • 25% Overall Team Functionality • 25% Overall Team Design • 25% Your Overall Code Contribution • 25% The quality of your final design document

22. General Suggestions • Code Together – regular established coding times • Use each other as resources/sounding boards for designs • Avoid analysis paralysis: Don’t try to design everything up front – get a feature and try to implement it…but then be willing to refactor to make the code cleaner • This is supposed to be realistic – in that you have unlimited resources to help. Use them!

23. Pair Programming • Two programmers looking at one shared computer • One typing (“driving”) the other observing (“navigating”) • Driver focuses on implementing particular function, navigator focuses on larger considerations • Switch off frequently (although if one programmer is stronger/knows the codebase lots better, they should frequently navigate) • You can keep focused longer, get fewer bugs

24. Heroism • Sometimes something will happen • Mysterious bug • Somebody gets sick • Tool the whole team needs • Feature that’s not in anybody’s design problem • Be that person who steps up and gets it done • But don’t be unsung – be sure to let your UTA with your weekly submission • You need evidence

25. Inter-group Problems • Making your team’s project a success is your individual responsibility • BUT if there’s trouble your UTAs and myself are here to help • Deal with problems early – before they become critical • Don’t send angry emails – meet in person

26. If You’re In Over Your Head • Start earliest • Get help, discuss designs, pair program • Under *no* circumstances stop coming to meetings (those are easy points you’re guaranteed to get) • Realize that this project is designed to challenge you and increase both your programming and design skills

27. What I’d Like You to Do • Get into your project groups • Start talking about your individual design problems • Work out a set of problems so that: • Everyone has a genuinely challenging design problem they are excited about • Nobody is working a design problem that’s too close to anybody else • All the design problems together make the shape of a overall solution to both the framework and the level editor • Talk to me if you’re stuck or you’d like to know if something is challenging enough (but of course ask your group first!)