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.
Top Related