Key Concepts of The Guide To Building a Browser Game

guide-key-concepts.md

Key Concepts of The Guide To Building a Browser Game

Coders!

Before this morning's Rock-Paper-Scissors code-along and before you begin to code your amazing games for project 1, it's worthwhile to refresh the KEY CONCEPTS of the Guide on How to Build a Browser Game...

The Guide on How to Build a Browser Game is a proven PROCESS that helps students be successful by producing:

• Well structured code that closely mimics the popular MVC (Model-View-Controller) pattern
• More concise code (often, less is more)
• Less buggy code
• An app that's easier to add new features to
• Code more likely to impress prospective employers

KEY CONCEPTS

• Data (state) is the single-source of truth of any application! The visualization of that data is secondary to the data and the logic that manipulates it. First and foremost, we must think of the app's functionality from a data perspective, i.e., when a user interacts, you must ask yourself and focus on, what state (data) needs to be changed and how...

• In response to user interaction, such as when a user clicks something, the event/click handler function's responsibility is to update all impacted state (data), then call render().

• The init() function's responsibility is to initialize the state (data). It is the only function that is called when the app loads. It also can, in many cases, be provided as the callback handler function for the "Play Again" button as well (like when the player goes broke in Blackjack - the init() function will only be initializing the bankroll and building the main deck of cards - other state has to be initialized before each hand).

• The render() function is responsible for rendering state and other information to the DOM. Don't modify/update the DOM elements outside of render function(s). An exception to this would be if you had a "timer" that you want to update with each tick of a setInterval - in this case, it would be fine to update the DOM to display the time outside of the render function(s).

• Don't add unnecessary state when it can be computed. For example, in the game of Spaceman we need a state variable, named something like wrongLetters, to keep track of the incorrectly guessed letters so that we can render those button letters differently, ignore them if clicked (since the letter has already been "used"), etc. Do we also need a state variable to keep track of the number of wrong guesses? No, because we can access the length property of the wrongLetters array anytime we need to know how many wrong guesses the player has made.

Happy Coding!