ASSAULT & BATTERIES
Unreal Development Kit
Windows PC
My Role as Game Designer / Associate Producer
  • Served as Scrum Master
  • Developed and updated GDD
  • Led design meetings and kept core gameplay vision
  • Developed 2D art content including Scaleform menus and HUD
  • Approved content and gameplay
  • Administered team Sprint Retrospectives and Sprint Planning

About Assault & Batteries

  Assault and Batteries is a PC Capture-The-Flag first person shooter built in the Unreal engine.  Players take the role of rogue toys competing in team combat on a train set in a toy store at night.  Players can carry and use large batteries to power elements of the battlefield, including drawbridges and a toy train.  Assault and Batteries is a team-based multiplayer game for 6-10 players, but missing players can be replaced with computer-controlled bots.
Picture
Mini-Postmortem 
on my role on 

Assault and Batteries
What Went Well
  • Modest, reasonable scope
After our experiences developing FrankenFrenzy, I felt that downscoping (or even underscoping) our project design from the start would have a positive effect on the project as a whole.  Our idea was to have a modest scope and set aside time to add a higher degree of polish based on feedback.  Even though we did not get to add many significant features late in development like we had hoped, our scope did have a positive effect on the project overall, as more time for AI and HUD work was available to us.
  • Cross-team cooperation
Our "cohort" (graduating class) of students was artistically understaffed with only five artists out of twenty five students.  Because of this, our class decided to have all of our games have a common theme so we could share a significant number of art assets.  This took some coordination between the teams, but the games all looked good. 
  • Iterative design and planning meetings
As our first project in UDK, our ability to develop was constantly challenged by the learning process.  As such, adaptive development was useful.  We held design meetings as necessary and adjusted gameplay more often than our earlier projects.
What Went Wrong
  • Playtesting struggles
As a capture-the-flag shooter, Assault and Batteries playtesting was very difficult to plan and carry out.  Many aspects of the game could only be tested in multiplayer mode with a larger number of players, which were difficult to coordinate in our time frame.  Most of our multiplayer testing consisted of our small seven-member team, and precious few sessions including outside testers were acquired. 
  • Unclear initial vision and visibility
Our team's earliest level designs were relatively complicated, believing that communication of gameplay to the player would become more clear over time.  By our Proof of Gameplay milestone, however, I realized that our initial design was so complex that our own team members found gameplay confusing. Moreover, this milestone revealed discrepancies in vision among the team.  We held meetings to adjust to a more straightforward design and build out from there.
  • Underestimating critical tasks 
By Alpha, we realized that the amount of work necessary in parts of the game would far exceed our estimates.  I had been warned that our first attempts at making a useful UI and AI would be challenging, so work on these features was started early.  What I did not realize was how much this HUD and enemy AI work would persist throughout development.  This exacerbated some of our playtesting issues, as these features have a significant affect on communication and playability for the limited number of playtesters we managed to acquire.
What I Learned, as a Producer
  • Usefulness of spheres of responsibility
  • Value of level streaming as means of division of labor
  • When visibility is lacking, quickly correct 
  • Actively seek out ways to help 
  • HUD, AI, and player communication are going to take twice as long as you expect