1. Zeplin Title Screen

2. Blue Team Evan character artist Wyatt programmer James musician Michelle environment artist Chad programmer game concept

3. Gameplay Mechanics Original concept was very featureful. It included vast randomly generated worlds, a rich spell casting system, and possible puzzle elements. Random map generation didn’t work out. Spell selection was pared down considerably due to time constraints. Gameplay became more focused on combat with linear progression.

4. Origins - initial sketches & concepts Villainous Characters Evil King Rommis NPCs

5. Origins - initial sketches & concepts Rob Corona Puck Spite Heroic Characters

6. Origins - Environment and size considerations Reference art : turboencabulator Interface design The size of the screen is 800x 800. The game play area is 650x600. The right side is 150x600 and shows who is playing and their health and spell points. Creating a graph helped the artists determine the size of the sprites relative to each other. The tiles used for the ground were 16x16. Final T.E.

7. Origins & Final concepts Interface/instructions Final instruction page Final cast interface

8. NPC’s Zephyr Bug Spider Rommis Writhe Worm Sprinter Spirit Slim Hopper Brawler

9. Rommis Casting Charge die flinch move standing

10. Spider die Casting Charge flinch move standing

11. Puck cast charge standing die move flinch

12. Start - enter through portals

13. Houses Snowland Rommis’ Domain Grassland

14. Rocks and Bushes

15. Trees

16. Screen shots

17. Game Play - Health Points

18. Musical Inspiration Morrowind: Explore/BattleMorrowind: Explore/Battle Square: FF7/ XenogearsSquare: FF7/ Xenogears Soul Calibur 4Soul Calibur 4 Joe HisaishiJoe Hisaishi Requiem for a DreamRequiem for a Dream Beethoven (Moonlight Sonata)Beethoven (Moonlight Sonata) Brahms’ LullabyBrahms’ Lullaby Character biosCharacter bios

19. Things that went Right haXe. Inline functions so we don’t spend entire frames just sorting the z-buffer. Templates allow type-safe generic data structures that are easy to write. Loading architecture. Referring to assets as strings rather than identifiers. Also, being able to choose between embedded loading and runtime loading is a good thing. All group members were able to use their strengths in contributing to the game creation. Wider variety of instruments in Logic Pro than Garageband Composition flexibility

21. Things that went Wrong Programming Issues -Flash is not multithreaded. This was a Bad Thing. - Tile engine design. There has to be a better way. -Lack of physics library support for ignoring bodies that are off- screen or not nearby. -Artist’s not understanding the programming limitations made it difficult to collaborate. More group discussions about game play and what could happen might have helped. Other -Logic Pro: Learning new program

22. Grid Optimization Physics over many thousands of objects takes seconds per frame. Optimization allows physics and render code to ignore off-screen stuff. Meticulous bookkeeping. Quick implementation is error prone.

23. Lessons Learned Think big, then shrink. Stick to the schedule - continuing to add and develop means there’s no time for testing. In this case, making two schedules would have been a way to meet class deadlines and create a method of expanding at a future time. Communicate early Team workflow and dynamics differ drastically between teams.