Archon Final Presentation

This is post is intend to be a project wrap up for team Archon and a overview of the points we discussed in our final presentation.


Part 1: What we were able to do

Part 2: What we didn’t do

Part 3: What we would change if we could do it all over again

Part 4: Archon Demo Video

Click Here for Archon Final Presentation Slides

Part 1: What we were able to do

  •  Game details
    1.  Three Mechs
    2.  Minions
    3.  1st – 3rd Person
    4.  Enemy Mechs and Minions
    5.  Spawners
    6.  Waves of Enemies
    7.  1st and 3rd Person Combat
    8.  Special Attacks
    9.  Advanced GUI Elements
    10.  Ally Commands
  •  Architecture
    1.  Abstract myMech
    2.  Each Mech Extending myMech
    3.  Controller Scripts
    4. Statemachine driving every game component

Our final game build features all of the key points we initially intended as an expected result, along with numerous extra elements we had not previous specified, such as advanced targeting capabilities, and expanded capabilities that we had only touched on in our design document, such as multiple modes of remote command for the mechs, 6 fully functioning mechs for player control, 6 fully functioning enemies, player and enemy flying capabilities and attacking from the air, 3 fully developed special attack mechanisms providing conical aoes damage-over-time, ranged explosion-based aoes, and aoe movement-modification specials.
Ultimately we set out to build a game where the player was given access to multiple different but similar game pieces – similar enough to not require re-learning a control scheme, while different enough in utilisation and feel to justify their existence – that would facilitate multiple styles of play in multiple usable and enjoyable points of view – 1st person vs 3rd person, take-control vs sit-back and command – against a diverse and changing enemy that was consistent enough for the player to understand the threat it posed while different enough to minimize the possibility of a single dominant strategy – if the smaller mechs spawned first and presented the player with a weaker attack, the player would be able to go on the offensive and attempt to destroy a spawner and accomplish a quick win, while if tanks and demons spawned first such a strategy would be imprudent at best.
We accomplished this with our game.


Part 2: What we didn’t do

  •  Extras

Our original design document included sufficient features that we knew we were not going to be able to implement them all in the final game. Our focus, however, remained on the core elements of the game we wished to achieve, which we had more than enough time to finish before the due date.
It was unfortunate that we were unable to implement multiplayer game play, along with some of the other minor features of the game, such as the mini-games or the big boss at the end of the fight, but as the stated purpose of the project was to provide a sampling of game play for a period of time of approximately 60 seconds, we focused our efforts on accomplishing this goal.

Part 3: What we would change if we could do it all over again

  • The biggest change to the process needed to be a few design meetings. Every member needed to understand their role as well as the entire codebase on at least a cursory level that the game was being built from. We needed every member of the team to have at least a basic understanding of the architecture, what was happening where, and why, so that they could correctly consume the code, or debug/recode it if necessary, and not clobber other people’s work. Much work was needlessly repeated, much good code was clobbered, and much contradictory functionality was implemented at cross purposes due to us not having the requisite knowledge of what we were all trying to do.

    Another thing that would need to be changed would be the necessary inclusion, at every level of design, of a more extensive and coherent OO design philosophy. It goes without saying that on any project of this size, or anything trying to do more than one thing at a time, the principles of OO design and OOP have proven themselves indispensible time and again for decades now, and such was the case for our project as well. As would be expected, all of our OO-design-based code was very easy to debug and deploy, while everything that was coded as a 1-off came back to bite us in the ass as we tried to implement the requirements of the project – things that were buggy in one way under certain circumstances had their “non-identical twin” implementations buggy in another way in other circumstances, and learning better ways of doing things did not pay dividends on previous work – instead of recoding existing code to match a better understanding of the environment and the requirements, other code was written that attempted to accomplish effectively the same thing as the old code with a better mechanism that might also be flawed but in a different way, precipitating a combinatorial explosion of potential bugs and issues. This was, for example, behind the need for a combat-code rewrite very late in the game, so to speak.

    At a more concrete level, we would have built the combat system around the floating reticle system from the start, and a more intuitive and easy-to-use user interface. We would have built the player command system to have a hierarchical scope, where player commands would apply to either a single minion, a squad of minions and their leader-mech, or the entire army, depending on whether the player was actively POV within a minion, a mech, or outside of all mechs as the archon alone, implemented with a command wheel that required a single keystroke and a selection from a pop-up wheel. Trivial to implement comapred to what we coded, but a massive improvement to both the functionality and ease of use of our current system. Here again design meetings early on would have been helpful – the details of such things could have been hacked out and specified early on and built into the design process from the very start.


    Part 4: Archon Demo Video:

    Click here for the video.

    Comments are closed.