Download
tower offense n.
Skip this Video
Loading SlideShow in 5 Seconds..
Tower Offense PowerPoint Presentation
Download Presentation
Tower Offense

Tower Offense

139 Views Download Presentation
Download Presentation

Tower Offense

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Tower Offense The Creeps

  2. Reverse tower defense. Build a path to avoid AI placed towers Get ‘creeps’ (units) from the top to the bottom to score Last as long as you can! Tower Offense!

  3. Mouse-based interface • 3 ‘map’ sizes • The goal is to get the high score • Build paths faster for a higher multiplier • Changeable game speed … More detail

  4. Leader / Architect • Cynic during the design process • ‘The Scope Creep’ • Programmer • Finite State Machine • Designed Core Objects (Creep, Tower, Board, etc) • Designed functions to divvy up • Interpolated Creeps across ticks • Scoring and High Scores Brett Hlavinka

  5. Drew everything. Need we say more? • Made the bone font Justin Kern

  6. Master programmer / Web designer • Implemented various core functions • Sounds … all of them • Implemented / fixed / beat the GUI into submission • Content / Input management • Enlisted playtesting Drew Reagan

  7. Programmer / Webmaster • AI • Augmented some core functionality • Path • Particle Effects • Made some presentations • Built website John Laky

  8. http://sites.google.com/site/toweroffense/ The website!

  9. We wanted a reverse tower defense game • Allows for more flexibility • User-controlled • Blend of puzzle / strategy games • Turn based • AI builds tower; you build path • Originally planned one path, one tower, one creep • Planned an ‘unbeatable’ design • Compete for high scores • Scoring mechanics weren’t written in stone The vision

  10. Implemented all essentials • Some peripherals didn’t make it • Forking/multiple paths • Projectiles • Multiple creeps • Multiple towers • Some did • Particle Effects • Bone text • Game speeds The Final Cut

  11. Path sorting algorithm has been strengthened • Buttons have been updated, improved • Added ‘invalid cell’ implementation • ‘Help’ and ‘High Scores’ states have been improved. • Implemented final sprites • Bug involving a persistent ‘exit’ button resolved • Implemented a font What was the ‘polish’?

  12. OUR TEAM ROCKS! • Group members are highly motivated, responsible • Eager to divide & conquer • We know our strengths/weaknesses • Humble in our ambitions • Good planners/brainstormers • All code was functional, quality code • Important to complete an assignment entirely • Few debilitating bugs • All artwork was divinely inspired Team Dynamics

  13. Early organization is paramount • Foundations of the program dictate its evolution • Foresight allowed for speedy implementation • Lack thereof wasted time (GUI) • Learning XNA was the hardest part • Except for Justin In retrospect…

  14. Finite State Machine design of the game really worked Game Over State Menu state High Score State Action State Help State Edit State What worked?

  15. Good communication/brainstorming • Consult the group on concerns • Group planning on structures/algorithms • Keeping track of the program’s structure • Code organization / reorganization • Code revision / cleanup • Well-organized queue of tasks to finish • Artwork • Mechanics • Features What else worked?

  16. Prioritize & define tasks well • Have realistic goals • Be cynical (but courteous) • Be wary of SVN issues • Synch often • Synch everything • Know what (or if) other people are working on • Try not to conflict files – something always goes wrong • Have a plan • Well defined roles & tasks • Think about assigning a leader Things to watch for

  17. Gameplay should not have been based on fixed windows • This lesson can be expanded into other things • Static, global data dependencies are bad • Should not have been addressed so late • Slow start in the organizing stages • Hard to get multiple people working on foundation • Buildings have 1 architect • Design was hasty (1-2 days) • Final implementations had little consideration • Some code ended up being ‘messy’ How to improve?