ProjectReport.txt

Meta
 - Our team for Project 2 was comprised of Bryce DeWitt, Noah Kennedy, Bach-An (Bach) Nguyen, and Cristian Stransky.
 - The app is deployed to our VPS and is available at dndgame.cstransky.com
 - The source code for our app is available at http://www.github.ccs.neu.edu/cstransky/dndgame
 - The app is deployed to the VPS and is fully functional
 - 	Bryce DeWitt – VP of Front End and API President of National Outreach
	Noah Kennedy – VP of GenServer/Channels and Co-President of Backend Logic
	Bach-An Nguyen – Co-President of Frontend Logic, VP of Schema, Musical Director
	Cristian Stransky – President of Schema, Co-President of Backend Logic, Game Director
App

 - For our Project 2 app, we were initially torn between creating a productivity app that would give users some benefit provided through an external API that was not convenient to access directly through the external service itself, or alternatively creating a game app that would use external APIs in an unexpected but still practical way.  Ultimately, after considering the available APIs and the precompiled frameworks available for them, we decided to develop a game that could integrate multiple external data sources to dynamically alter a user’s game experience based on real-world conditions.  We created the “D&D Game” app to fulfill this goal by allowing our users to generate a game world based on the current weather conditions of the location they selected, and having the dynamic nature of that location’s weather alter the in-game logic over time. Our app offers a web-based implementation of the popular role playing game game, Dungeons & Dragons, allowing users to create customized characters for their party based on pre-determined frameworks and attributes, create a game based off various real-world locations, and ultimately move through that world and battle monsters until they reach the final boss.
 - The initial user interaction with our applications comes from our methods of authentication.  While unregistered users may view our app homepage, their access is limited to the index and registration pages.  To register a new users, we offer both local and Google OAuth verification.  After registering and authenticating through Google or our local verification system, users are permitted to access all areas of our website.  In order to initialize a game, a user must first navigate to our character creation area to generate the customizable characters that will be used to populate the user’s “party” when entering a game. In this area, we offer options for users to select a full range of attributes for a character, ranging from race and class to weapons and armor, ultimately generating different attributes for every character.
After character creation, users may enter a game by selecting three of their characters from the dropdown and the world location.  Once in game, users will interact with our app using their keyboard to navigate through the game world and select options while in battle.  As a turn-based RPG, the overall nature of our app is highly interactive and customizable by our clients; while the game area allows users to actually play the game, the character creation menu gives them full control over the way they will approach the game from a strategic sense.

 - With respect to the scale and ambition of the project, this is easily far more complex and involved than any homework or project we have completed in the past; while our app uses the same processes and methodologies used in previous assignments, our game has been significantly more difficult to develop based on the magnitude and complex nature of data we’re moving around.  This app utilizes GenServers, Backup Agents, Supervisors, multiple Rooms and Channels, Sockets, AJAX requests, Ecto schema/migrations/queries, External APIs, Sessions, Controllers, ect.
 Like previous assignments, our app was built with an Elixir backend and JavaScript client side.  Since the entirety of the game logic for D&Dgame is processed on the backend, there is a very significant amount of logic to process user interaction and make the necessary database calls to generate the rather large game state that is provided to the client in order to render the world and enable user navigation through our nested menu system.
This project has been successfully deployed to the VPS of a member of our team, and uses it to host the majority static assets locally, where reasonable.  Though we offer Google OAuth user authentication, we also offer a standard local registration using Argon2 to provide secure registration and authentication.  These users are stored locally on within postgres database.  Locally-registered users are stored using their email and a hash of their password, while externally-registered users are stored with their email and Google’s unique token.  In addition to the Google API that requires authentication through a key and secret generated by us, we also use the DarkSky API, which similarly requires authentication through a uniquely-generated developer API key.  Our app has no client-side API calls.  Channels are used extensively to handle any interaction a user has with the game, as well as to push through updates to the game state when our external weather API detects changes in weather that should correspond to changes in game logic.  Additionally, channels are used push one user’s events to all other members of the same game room.  Our team of 4 has all developed code and will contribute to the presentation.
 - Beyond project requirements, by developing a game fully integrated with a database, server-side logic and client-side rendering, we have added a large layer of complexity and necessitated a significantly larger code base than what would have been required for a smaller app that didn’t have such a large game state, back-end game engine, and front-end rendering logic. Additionally, our app has a very thorough use of the HTML5 Canvas element, delegating a majority of the preprocessing of raw data before rendering to internal functions, then relying on multiple switch statements and onKey events to determine exactly what to render.  While not strictly challenging in the actual rendering of an image or component to the canvas, the logic required to determine exactly what to render or where to render it demonstrates high proficiency with this function of HTML5.
Furthermore, though we have used simple data stores in past assignments, our backend database is significantly more complex than what may have been anticipated for this product.  With 10 tables, multiple numbers and types relationships within them, stringent data integrity checks, and a large number of views and corresponding routing, this has been more difficult to manage when making modifications to the migrations than it has been in previous assignments.
 - The most complex aspect of our app has been the server-side logic, which can accept user interaction events to perform complex operations on our game state.  When a user generates a new game, there can be upwards of 300 or 400 unique variables describing the game, comprised of everything from the name of a user to the current wind speed to the current SP of the 3rd monster in a battle.  Handling the computation of all these variables after an event, while also maintaining the user’s current position within a game “flow” has proved to be difficult.  For instance, we initially had difficulties determining a way to indicate to the client-side rendering script who’s turn in a battle it would be next, something we solved by generating an array and replacing the tail with the head, then indicating if it was the beginning of a turn or the end.
Since we knew the size of this component would make it difficult to develop/read/debug, we prioritized simplicity and quality code from the very beginning.  Additionally, in a structural sense, we grouped together related functions within the layout of the function to make it easier to see how they were related.  This was made simpler by the fact that we prioritized core functions from the very beginning of our development process, allowing us to begin with an efficient and well-designed framework, subsequently expanding it with the additional functionality we required.
Furthermore, the client-side canvas rendering logic ended up being largely more complicated than we initially expected as we slowly unloaded certain user interaction logic to it.  For example, while we first planned to generate the menu options within the server and simply display them from an array in the client, we wanted to limit the number of unnecessary server requests when a user was only moving through potential options, so we offloaded the responsibility for generating menus and tracking a user’s location within them to the client.  To this end, we were able to send only a single “attack” command to the server, but at the expense of a larger JavaScript function.  While this component has gone through several iterations as we added additional functionality to accommodate limitations of the server or optimize UI performance, we continued to uphold quality coding practices with iterative development and consistent commenting.
 - Our most significant challenges were less related to the actual implementation of functions and more with respect to communication and coordinating the code development and interfaces between aspects of the application.  For instance, an dialogue we had ongoing throughout the entirety of the project was with respect to the game state and what was required for the client JavaScript functions to render the view of the game vs. what was necessary for the server to process it in the back end. Since the .JSX file using React to render the game state necessitated a unified game state between the client-view passed in by the server and the fields in the state needed by the client in order to render the game, our teams working on both sides of the development process had to constantly update the data structure we were using within our state in order to make sure they would integrate when we merged our branches together.
In order to centralize our communication, we explored a few different communication options, but ultimately turned to a Slack workspace.  Using Slack, we were able to work remotely but collaboratively, create separate channels based on various components being developed to prevent messages from being lost, as well as allowing us to dump code into the conversation to discuss it and allowing us to return back to it later.  Additionally, we used GitHub for version control, developing components on separate branches and organizing in-person meetings during the merges in order to make sure the integration of functions would be smooth and clean by having the person most familiar with it on hand.  We also discovered that we could get significantly more development work done by organizing in-person meetings to ensure everyone was aware of what they were assigned to work on and being able to set deadlines for deliverables, thereby encouraging group members to manage their time and work effectively.
With respect to our largest strictly technical challenge….