Stop the Logger – Scratch Game Whitepaper

“Stop the Logger” Whitepaper

Using the ADDIE Model for “Stop the Logger” Scratch Game Development

Avi Megiddo

April 2 – 9, 2023

 

OVERVIEW

This document is a whitepaper/documentation for a game created using the ADDIE model for instructional design. The game involves catching a tree logger or “arresting” the logger using a “catchable” button in Scratch. The game was inspired by a button script from years ago and the birds outside my window. The trees in the game are from PNGTree.com and PNGWing.com, and the code randomly chooses one, “plants” it in a random location on the screen, and grows every second with a bit of accounting for upward and outward growth, but not downward. 

Analysis:

I was inspired initially by the button script from years ago, where it moved away from the mouse pointer as you tried to click it. This inspired me to create a “catchable” button in Scratch, which I used in the development of the game. After thinking about what makes sense to “catch” and still be educational, I came up with catching a tree logger, or “arresting” the logger. 

I found an animated gif of a logger/lumberjack on Dribbble.com,  by searching for synonyms of logger/lumberjack/tree logger and ‘gif’, and used a web-based tool to make all the gif images have a transparent background. Importing them as a new sprite took one click, and that was the basis for the game.

I was also inspired by the birds outside my window while creating the functions, and used bird call sounds from ZapSplat.com to reward the player after 10 trees were alive. Additionally, a student’s project inspired me to use the number 20 for a “winning amount” of loggers to catch.

 

Design:

 

In terms of design, I made the “caught” version of the logger by taking an image from the logger gif, and copy+paste+flip horizontally to make the arms look like they were handcuffed. I also created handcuffs in Google Drawings and finalized the design of the handcuffed tree logger using the Scratch costume editor. When the user successfully clicks on the logger, I decided to show a funny utterance instead of educational content to reward the user. I used my resizing concept to make the logger shrink as he rose to the top of the screen to join his other caught logger friends. 

 

The trees were also made using the ‘clone’ feature in Scratch, and some of the hard challenges included managing the clones, creating actions upon starting as a clone, deleting at the right time, and stopping other scripts in a sprite upon certain actions/states of the game, such as trees equalling zero and 20 loggers being caught.

Development:

 

To develop the game, iteration was key. I revisited the code for 30 minutes to 2-hour sessions, adding features, debugging, iterating over the project, upgrading, and saving to the computer stable backup versions, about 10 times. 

A random tree is chosen every second, with a random location on the screen, size adjusted based on position, and growing every second with a bit of accounting for upward and outward growth, but not downward. I used the size of the tree to make trees smaller or larger, depending on how high their randomly chosen y-values are, using the formula (180 – y-position) times some coefficient.

A recent iteration/upgrade was to how the trees fall when they die. Initially, I just rotated a tree 90 degrees when the logger touches it, but the upgrade involves repeating 10 rotations of 9, and a random choice of clockwise / counterclockwise rotation.  Further, the tree moves down as it rotates, to simulate rotation from the root, not the middle.

Implementation:


During implementation, I continued to test the game and made adjustments as needed. I added scoring functionality, where the player earns one point for each logger caught and loses one point for each tree lost. I also used the stamp tool as a way to delete each caught logger clone. I made the game more challenging by having the trees grow faster and adding more loggers to catch over time.

Evaluation:

In terms of evaluation, I tested the game with several individuals to get feedback on the gameplay and design. Based on the feedback, I made further adjustments to the game to improve the user experience. Overall, the game has been well received and has provided an engaging way to learn about deforestation.

 

MILESTONES

  1. Getting the button to move away from the cursor at a custom speed, based on a custom distance.
  2. Finding and importing the logger .gif 
  3. Dynamic sizing based on height.
  4. Creating the “caught” logger.
  5. Tree growth and death upgrades.
  6. Changing frequency and speed of logger based on # of catches.
  7. Adding educational messages upon loss/win.
  8. Adding a trophy/badge and music upon win.

A Wordle for Google Sheets Adventure

 

Introduction:

Creating a Wordle game in Google Sheets, with ChatGPT was a real back-and-forth. ChatGPT, with its vast pool of knowledge and ideas, was a huge help. But in the end, it was the practical skills—knowing what makes a good user experience and applying design thinking—that shaped the project. Every iteration brought new challenges and things to learn, highlighting the value of patience, persistence, and paying attention to the small stuff in making digital tools that people might enjoy using.

Inspiration and Research:

This project was part of my ongoing exploration of how to leverage AI for programming, education, and fun. My project was inspired by the widespread appeal of Josh Wardle’s original Wordle game. His creation showed how a straightforward concept could engage a wide audience, sparking my interest in developing something similar.

Two particular resources significantly shaped the direction of this project: Tyler Robertson’s Zapier article revealed the potential of Google Sheets to host a Wordle-like game without Google Apps Script (incredible!).  He creatively uses formulas, data validation, and conditional formatting, reinforcing my appreciation for Google Sheets as a versatile platform for creating interactive experiences.

Equally inspiring was Sajad Deyargaroo’s GitHub project, which uses Google Apps Script. I emulated his cell layout for the color-coded feedback keyboard. 


Software Development:

The script function selectRandomWord randomly selects a word from the ‘Words’ sheet to serve as the challenge for the game session. In terms of implementation, here’s a simplified pseudo-code representation of the selectRandomWord function:

In detail:

  • Accessing the Spreadsheet: The function begins by getting a handle on the active spreadsheet using SpreadApp.getActiveSpreadsheet(), which allows the script to interact with the spreadsheet content. 
  • Locating the Words Sheet: It then identifies the specific sheet named ‘Words’ where the list of words is stored. This is done through getSheetByName(“Words”). 
  • Random Word Selection: To select a random word, the function first determines the number of words available by finding the last row in the ‘Words’ sheet with getLastRow(). This is essential to ensure that the random selection is within the bounds of the word list. 
  • Generating a Random Number: A random row number is generated within the range of available words. This is where Math.random() comes in, which generates a number between 0 and 1, and then it’s multiplied by the lastRow to scale it to the size of the word list. The Math.floor() function is used to round down to the nearest whole number, ensuring you get a valid row index. 
  • Retrieving the Word: With the random row number in hand, the script retrieves the word from the “Words” sheet using getRange() and getValue(). The range is dynamically constructed using template literals to incorporate the row number. 
  • Formatting the Word: Finally, the selected word is converted to uppercase with toUpperCase() to maintain consistency throughout the game, as user input will also be converted to uppercase for comparison purposes.

Version 1 of selectRandomWord:

At the start of each game or round, this function is called to set the challenge word that players will attempt to guess—more on how this function changed later when I discuss word categories.

User Experience:


I initially considered using a checkbox that, when checked, would trigger the onEdit function which calls the checkGuess function. However, this required the user to perform multiple actions: typing the guess, navigating to the checkbox, and then clicking it. This method, while functional, did not offer the most fluid experience.

The original onEdit trigger:

I didn’t want users to have to type a word and then click the mouse — I wanted to allow players to just type a word and press ‘Enter.’

To refine this, I made pressing ‘Enter’ trigger the onEdit function. This single-step interaction mimics the ease of the original Wordle game, where a guess is submitted with just a keystroke, thereby maintaining the user’s focus and flow (note that clicking outside of the edited cell would also trigger the function).

The enhanced onEdit trigger:

Incorporating this functionality reduces the cognitive load on the user, allowing them to remain engrossed in the game rather than the mechanics of the game’s interface. It’s an example of user experience (UX) design principles; by recognizing that minimizing the number of user actions leads to a more enjoyable and engaging experience, you’ve made the game more accessible and enjoyable, particularly for users who may not be as comfortable switching between keyboard and mouse actions.

Dealing with Duplicates

In creating Wordle in Google Sheets, a key challenge was managing duplicate letters—both in players’ guesses and the puzzle words. This required refining the updateUI function. Initially, it color-coded cells based on the correctness of guesses. The twist came with handling duplicates, where the game logic had to discern between excess and correctly placed letters.

The solution involved a dual-pass approach:

  • First pass: We mark the correctly placed letters and decrement their counts from the correctLetterCounts map.

Second pass: We deal with misplaced letters and excess letters. A letter is colored yellow if it’s in the correct word and we haven’t used up all its occurrences yet (as per the correctLetterCounts map). If it’s not in the correct word or we’ve used up all its occurrences, we color it gray.

However, this can cause the letters and their color coding not to be revealed from left to right. Adjusting the logic to reveal each letter from left to right, regardless of whether they’re correct, misplaced, or incorrect, required rethinking the two-pass approach. To achieve the sequential reveal effect similar to the real game, I had to integrate the logic for determining the color into a single pass. This way, each cell is updated one by one in order, maintaining the suspense of the game.

Modified updateUI function:

In this revised approach:

First Pass: Initial Coloring and Occurrence Tracking

In the first loop over the guessed word, the function performs several tasks for each letter:

  • Visual Update: It updates the corresponding cell in the Google Sheet with the guessed letter, setting its font size and weight for clarity.
  • Occurrence Tracking: It increments the count of each guessed letter in guessedLetterCounts.
  • Initial Coloring: It assigns an initial background color to each cell based on a simple check:
    • Green (#6aaa64) if the guessed letter is in the correct position.
    • Yellow (#c9b458) if the letter is present in the correct word but not necessarily in the right place or the right quantity.
    • Gray (#787c7e) if the letter is not present in the correct word at all.

After setting the initial color, it decrements the count in correctLetterCounts for green letters, acknowledging that one correct occurrence of the letter has been accounted for.

Second Pass: Correcting Colors for Misplaced vs. Excess Letters

The function’s second loop over the guessed word adjusts the initial color assumptions to handle the nuances of duplicate letters and their placements:

  • It reevaluates cells initially marked as yellow to determine if they represent misplaced letters or excess letters. This step is necessary because the first pass might incorrectly mark an excess letter (one that appears more times in the guess than in the correct word) as yellow.
  • For each guessed letter not in the correct position, the function checks if the number of guesses for that letter exceeds the number of occurrences in the correct word. If so, it changes the cell’s color to gray (#787c7e), indicating an excess letter, and decrements guessedLetterCounts to reflect that one of the excess occurrences has been accounted for.

Key Mechanisms

  • Two-Pass Coloring Logic: This approach allows the function to initially mark potential matches as yellow and then refine those marks by distinguishing between correctly placed, misplaced, and excess letters. This is crucial for handling words with duplicate letters accurately.
  • Occurrence Tracking: By tracking the occurrences of each letter in both the guessed word and the correct word, the function can accurately determine when to mark a letter as excess (gray) rather than misplaced (yellow).
  • Delayed Visual Feedback: The SpreadsheetApp.flush() and Utilities.sleep(50. This was a design choice inspired by the original Wordle;  including a delay between the reveals of each letter as a UX consideration. By revealing each letter one by one, we allow for brain processing time, preventing cognitive overload, and mirror the pace at which the human brain processes information, creating suspense and drawing the player into the game experience, hopefully enhancing anticipation/drama/engagement/fun.  More on why this was removed later in the article.

In summary, the updateUI function adeptly handles the complexities of Wordle’s coloring rules, especially in the context of duplicate letters, through a methodical two-pass system that first assigns preliminary colors based on simple matches and then refines those colors to accurately reflect the actual state of the game.

First Pass: All letters are placed and initially colored. Correctly placed letters are immediately marked green. Letters that exist in the word are temporarily marked as yellow, and incorrect letters are marked gray. This creates the left-to-right reveal effect.

Second Pass: Adjusts the color of letters marked as yellow if they are found to be excess. This pass refines the initial guesswork by turning excess letters gray.


Accessibility

Introduction of Categories:

To diversify the Wordle game, I decided to introduce categories, allowing players to choose words from specific themes like Animals and Cities. By importing different word lists by category, I could potentially broaden the game’s educational scope, using it as a tool for language learning. This necessitated modifications in how words were selected based on the user’s chosen category. Here’s a summary of the process.

Word List Organization:

The ‘Words‘ sheet was organized with different categories in separate columns: Column A for all words, Column B for Animals, and Column C for Cities. Each column had a header indicating the category, facilitating easy identification and selection of words from the desired category.

Conceptualization:

  • Category Selection: The first step was selecting broad categories with ample five-letter words. Categories such as Animals, Cities, Foods, Colors, Tools, Sports, Music, and Brands were chosen for their rich vocabulary and accessibility to a diverse audience. 
  • Word Sources: For each category, legitimate sources were identified to compile the words. These included online dictionaries, encyclopedias (e.g. Wikipedia), GitHub repositories, educational resources, APIs (like Datamuse for programmatically fetching words), and community contributions.

Implementation:

  • Removing Duplicates: An optimized script function removeDuplicatesOptimized was developed to process large datasets efficiently, ensuring that unique words remained. This script employs batch processing techniques, significantly reducing execution time compared to row-by-row operations. 
  • Filtering Five-Letter Words: A script filterFiveLetterWords was created to cleanse the imported lists, removing any words not exactly five letters long or that were compound words. This script streamlined the process of preparing category-specific word lists for the game. 
  • Loading Category Words: The loadCategoryWords function was introduced to dynamically load words from the specified category into the game, enhancing the game’s flexibility. This function used the spreadsheet headers to identify the correct column for each category, loading the words into an in-memory cache for quick access. 
  • Category-Specific Gameplay: Functions like playWordleAnimals, playWordleCities, etc., were implemented to allow players to start games with words from their chosen categories, enriching the gameplay experience with variety and customization. 
  • Changes to selectRandomWord: The key improvement here is the dynamic determination of the word list based on the given category, allowing the game to draw from different sets of words depending on the user’s choice. This not only diversified the gameplay but also showcased the flexibility of Google Apps Script in handling data dynamically in Google Sheets. 
  • Using a helper function, columnToLetter, I converted column indices to letters, enabling the script to work with the A1 notation that Google Sheets requires. This utility function was essential in mapping the 1-indexed category position to the corresponding column letter in the sheet.

Current version of selectRandomWord:

 


Efficiency and Optimization:

  • Batch Processing: Emphasized throughout the implementation was the use of batch processing for reading and writing data to Google Sheets, significantly enhancing performance, especially for large word lists. 
  • Cache Utilization: The strategic use of a cache (categoryWordsCache) minimized repetitive reads from the spreadsheet, further optimizing the game’s responsiveness and efficiency.

Function Modifications for Category Selection:

Given the need for functions that would select a random word from the user’s desired category, I modified the existing selectRandomWord function to accept a category parameter. This adjustment allowed for dynamic word selection based on the category chosen by the user.

Incorporating User Selection through UI:

To enable users to choose a category directly from the Google Sheets UI, I added a custom menu with options for each category, using Google Apps Script:

Dynamic Range Calculation:

To accurately select a random word from the desired category, it was essential to calculate the last row for each specific column, addressing the varying lengths of each category. ChatGPT suggested an updated selectRandomWord function that dynamically calculates the range for the specified category column:

Handling Function Overloading:

In Google Apps Script, which adheres to JavaScript’s limitations, the concept of function overloading—where multiple functions with the same name differ only by their parameters—is not supported. Initially, this project included two distinct functions for the selectRandomWord task: one without parameters for selecting a default word, and another accepting a category parameter for category-specific selections. Due to the scripting environment’s constraints, attempting to use both functions led to a TypeError when the no-parameter version was called, highlighting the limitations of function overloading in this context.

To overcome this, the solution was to merge these functions into a single, versatile selectRandomWord(category) function. This unified function adeptly checks for the presence of a category argument. Based on whether a category is provided, it either executes category-specific logic for word selection or falls back to a default operation, typically selecting words from a predefined column (e.g., column A) when no category is specified:

This approach ensures a single selectRandomWord function can handle both scenarios: selecting words from a specific category or a default list, enhancing the script’s manageability and user experience.

Moreover, the playWordle function was refined to accommodate an optional category parameter. This modification enables dynamic category selection for the game. If a category is provided, playWordle invokes selectRandomWord with the given category; otherwise, it defaults to the general word list. This flexibility is crucial for supporting a variety of word categories without the need for separate functions for each category type:

This code structure not only simplifies adding new categories by merely adding a new column to the ‘Words’ sheet but also enhances the game’s versatility. Players can now enjoy a tailored game experience with categories ranging from “Animals” to “Cities,” facilitated by the dynamically adjusted playWordle and selectRandomWord functions. To reflect these changes and new category options in the Google Sheets UI, users must refresh the UI after script updates, ensuring the custom menu accurately presents the new categories available for gameplay. This design philosophy promotes ease of expansion and user engagement by seamlessly integrating new word categories into the game.

Why I removed Utilities.sleep

Earlier, I discussed delayed visual feedback as a design choice, including a delay between the reveals of each letter to allow for brain processing time, suspense, and engagement. In practice, I noticed that it was not necessary given the latency already occurring. Google Apps Script runs on Google’s servers, meaning that every operation, especially those that modify a Google Sheet, requires communication between the user’s device and the server. This communication incurs a natural latency that can vary based on several factors, including network speed, server load, and the complexity of the operations being performed. Human perception of delays in user interfaces is an important factor to consider. Research in human-computer interaction suggests that users can perceive delays as short as 100 milliseconds and that delays of around 200-300 milliseconds are generally perceived as instantaneous. Given the natural latency involved in the script’s execution and the UI’s update process, these delays might be sufficient to create a staggered update effect without the need for additional artificial delays introduced by Utilities.sleep().

 

SpreadsheetApp.flush() is a method that forces the execution of all pending changes in the script to be applied to the spreadsheet immediately. Normally, Google Apps Script batches changes and applies them at the end of the script execution to optimize performance and reduce the number of calls to the server. By calling flush(), you are explicitly telling the script to apply all queued changes up to that point, which can be used to create a real-time update effect in the spreadsheet.

If you were to remove SpreadsheetApp.flush() from the script, Google Apps Script would revert to its default behavior of applying all changes at once, at the end of the script’s execution. This means the entire word’s color coding would appear simultaneously, removing the sequential reveal of each letter’s status. The removal of flush() would effectively batch all updates together, which might be less engaging for users who expect a more dynamic interaction, akin to the original Wordle game experience. Removing Utilities.sleep while keeping SpreadsheetApp.flush() creates a balance between responsiveness and the dynamic reveal of updates, leveraging Google Apps Script’s server-side execution model. This setup offers a practical compromise between performance and user experience, demonstrating the nuanced interplay between script execution speed, network latency, and UI update mechanisms within Google Sheets.

 


Extensibility

This code structure allows users to add categories by simply adding a new column to the ‘Words‘ sheet, updating the onOpen function, and creating a new playWordleCategory function, mirroring the structure of the existing category functions:

Challenge: Try to add your own category of words to your copy of Wordle for Google Sheets!

  • Adding a New Category Column: In Wordle for Google Sheets: Add a new column to your ‘Words’ sheet. Let’s say you’re passionate about ‘Plants’. Rename the ‘Your Category’ header as ‘Plants’ and fill the column with relevant five-letter words like ‘tulip’ or ‘ferns’, one word per cell.


  • In the script: You’ll need to update the onOpen function to include your new category in the custom menu.  The first quoted phrase is what appears in the Wordle menu in the sheet.  The second quoted phrase is the function name.

Also in the script: you’ll need to add a function with the exact function name you chose to add to the onOpen function.

  • Refresh the Sheet: After saving your script, refresh the spreadsheet for the new menu item to appear in the Wordle menu.

By carefully following these steps and ensuring that function names and sheet headers match, you can add endless categories to your game, making it a customized, robust educational tool. The addition of each new category not only expands the vocabulary but also the breadth of knowledge that players can gain from engaging with your Wordle game.

Conclusion:

The development of Wordle in Google Sheets illustrates the practical application of computer science principles and design thinking in an educational setting. This project underscores the iterative nature of design and the effective use of Google Apps Script to elevate teaching tools within a platform that’s familiar to both students and educators.

Educational Value: This project not only provides a fun and engaging game but also serves as a practical example of applying computer science concepts such as data structures, algorithms, and optimization techniques.

Design Thinking: Students and educators are encouraged to think critically about user experience and game design, considering aspects such as category selection, user interface, and gameplay dynamics.

Customizability: Allowing users to edit/add new words/categories fosters a collaborative environment, providing a platform for students and educators to contribute creatively to the game’s development.

Collaborating with AI, particularly through exchanges with ChatGPT, is akin to having a skilled partner. I directed the project, while the AI provided support with code suggestions and troubleshooting. To conclude, this Wordle project is a testament to the potential of conversational coding and instructional design. It demonstrates how Google Apps Script can be an excellent resource for educators introducing interactive coding projects. Innovating within Google Sheets offers a myriad of opportunities for those aiming to blend coding and app development into their curriculum. This endeavor goes beyond coding; it fosters a design-centric mindset for problem-solving that I hope my students will use in their future projects.