1 / 24

Zeplin Title Screen

Zeplin Title Screen. Blue Team. James musician. Evan character artist. Chad programmer game concept. Wyatt programmer. Michelle environment artist. Gameplay Mechanics. Original concept was very featureful.

fauve
Download Presentation

Zeplin Title Screen

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Zeplin Title Screen

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

  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 NPCs Evil King Rommis

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

  6. Origins - Environment and size considerations Reference art : turboencabulator Final T.E. 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.

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

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

  9. Rommis Casting die move standing flinch Charge

  10. Spider Casting flinch die move Charge standing

  11. Puck flinch charge cast die move standing

  12. Start - enter through portals

  13. Houses Rommis’ Domain Grassland Snowland

  14. Rocks and Bushes

  15. Trees

  16. Screen shots

  17. Game Play - Health Points

  18. Musical Inspiration • Morrowind: Explore/Battle • Square: FF7/ Xenogears • Soul Calibur 4 • Joe Hisaishi • Requiem for a Dream • Beethoven (MoonlightSonata) • Brahms’ Lullaby • Character 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

  20. 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

  21. 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.

  22. 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.

More Related