Gameplay/Engine: Wireframe (but solid/blocking obfuscating) graphics, with the player racing around in a high-speed hovermech over a lumpy outdoor planet, blowing up alien vehicles while trying to avoid stray fire hitting cities. The player can switch between first or one of several third person cameras. Emphasis is on mid-90's action, conveying a sense of speed, and an outdated-futuristic style.

Story: There's an intense blizzard outside your hovermech, and you need to loot all the enemy vehicles for fuel cores to stay warm long enough for a dropship to come to your rescue. All turrets also need to be removed in order for the dropship to land, though destroying them doesn't offer any heat. Be careful to not damage the cityscapes, though - those are the recently discovered ruins of long-past civilizations that human scientists are eager to return to for further analysis just as soon as weather permits!

Number of playersEdit



Outdoor vehicle Shoot'em Up, a bit like Rogue Squadron, the Hoth level from Shadows of the Empire, or Star Fox 64's 360 battle areas. 3D but really low detail (like BattleZone).


Unity, for download (not releasing for web player, except possibly as tiny promo-demo)


Pitch approved. Core gameplay prototype functional in Unity.

Team MembersEdit

  • Chris DeLeon - Project Lead, Engine Programmer, Core Enemy Design, Crap Artist
  • Looking for 1-2 "Artists," 3D very low-poly (It's even ok to build using Unity's primitives - concepts are more important here than execution)
  • Looking for 1-2 Designer/Programmers to help come up with, lay out, and program battle environments, each with 1-2 weird, surprising, central features
  • Looking for 1-2 Sound Designer / Musician

Weekly GoalsEdit

(Create a detailed plan for completing your game in a 13 week time span. BE DETAILED! Include things like "have player character animations completed and implemented", "Have the main menu and level selection screens implemented", "Have all sound effects the the player will make", etc)

  • Week 1: ( 1st Round Pitches ) Other people pitched
  • Week 2: ( 2nd Round Pitches ) More people pitched
  • Week 3: Pitch. At this point I've got a crude, early mock-up to show which is a bastardized modification of my Mech thing I've been working on in Unity
  • Week 4: Player weapons do damage. All player weapons implemented (nothing fancy/complicated). Placeholder enemies show up via waypoints on HUD, plus radar for nearby objects.
    • Enemy models or primitive-shape-hierarchy prefabs due from each artist.
    • Rough music sketches, just enough to decide on instrumentation and tempo
  • Week 5: Enemy types implemented and functional as prefabs (nothing fancy/complicated). Give player ability to autopilot chase a locked-on enemy.
    • Building sketches made from primatives, and evidence that everyone on the team knows how to build a landscape in Unity suitable for this type of game
    • Sound effects week, try to get the most common sounds at first-pass
  • Week 6: I have to submit a draft of my thesis this week, so I don't have much new to show here.
    • All developers on team now able to test main ship movement, weapons, and enemy types on their environments, iterate on their level's "key feature"
    • Secondary sound effects
    • At least 1 song completed (ideally the main gameplay loop)
  • Week 7: Playable beta build! Levels winnable when all units destroyed or objectives met. Heat power-ups dropped by destroyed enemies. Countdown-til-freeze timer. Every world that we're going to include now exists in some crude, first-pass functional form.
  • Week 8: Menu for world selection built-in. Intro screen for each level describes any non-obvious instructions. Tuning of difficulty in terms of freeze-rate and heat-benefit for each level. Begin testing with outside players.
  • Week 9: Accounting for feedback from initial round of testing. Polish attention to visual effects.
  • Week 10: My thesis is due this week, so I won't have anything new to show here.
    • Programmer/designers to polish and iterate on their levels.
    • Second song (for menu, or alternatively to replace our game song and bump that one to menu) done
    • Any sound effects we missed earlier in the schedule (ex. depending on how our menu comes out)
  • Week 11: Testing and polish, making sure the game runs well on a variety of resolutions etc.
    • This week is also our time to ensure that win/loss states are handled in a suitable fashion
  • Week 12: The game should be essentially done by this point here.
  • Week 13: Game is complete, bug fixes


Pitch PDF

Project Leader AgreementEdit

I, Chris DeLeon, as project leader agree that I will finish the game (in some form) alone in the case that all of my team members can no longer work on the project.