Zeplin Title Screen

Blue Team

Evancharacter artist

Wyattprogrammer

Jamesmusician

Michelleenvironment artist

Chadprogrammergame concept

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.

Origins - initial sketches & concepts

Villainous Characters

Evil King RommisNPCs

Origins - initial sketches

& concepts

Rob Corona Puck Spite

Heroic Characters

Origins - Environment and size considerations

Reference art :turboencabulator

Interface designThe 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 spellpoints. Creating a graph helped theartists determine the size of the sprites relative to each other. The tilesused for the ground were 16x16.

Final T.E.

Origins & Final concepts

Interface/instructions

Final instruction page

Final cast interface

NPC’s

Zephyr

Bug

Spider

Rommis

Writhe

Worm

Sprinter

Spirit

Slim

Hopper

Brawler

RommisCasting

Charge

die

flinch

move

standing

Spider

die

Casting

Charge

flinch

move

standing

Puck

cast

charge

standing

die

move

flinch

Start - enter through portals

Houses

Snowland

Rommis’ Domain

Grassland

Rocks and Bushes

Trees

Screen shots

Game Play - Health Points

Musical InspirationMusical 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 (Beethoven (MoonlightMoonlight SonataSonata))• Brahms’ LullabyBrahms’ Lullaby• Character biosCharacter bios

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

Things that went WrongProgramming 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

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.

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.