Game On

Template:EventLinksBox Game On is a Division B event for the 2020 season. It was a Division C event for the 2016, 2017, and 2018 seasons before becoming a Division B event for the 2019 season. It was held as a trial event at the 2015 National Competition and the 2014 National Competition.

The objective of Game On is to create a game with the program Scratch. Scratch is a program designed by MIT Media Labs that allows non-programmers to experiment and play with the basics of programming. It is a visual event-driven language in which you drag and drop blocks of code in order to create scripts.

For a list of Game On blocks, please see Game On/Scratch Blocks.

Overview

At the competition, students are given a theme which they must incorporate into their game. Possible themes (that are not intended for tournament use) are listed as Wave, Fire, Gravity, Silly sports, Frogs, and Newton's Second Law.

In 2018 (but not 2019 or 2020), the games must also follow a game type. The possible game types are:

• For the regional and invitational tournament, Collection, Maze, and Avoidance.
• For state tournament, the regional types, and Shooting, Racing, and Building.
• For the national tournament, any two of the above themes or a two-player game may be used.

Teams of 2 are given 50 minutes to complete their game. The entire competition is conducted offline (in the offline editor). Students are allowed to bring writing instruments, headsets, and a microphone. Other computer programs (such as Photoshop), external resources and pre-constructed game assets are NOT allowed.

Rubric

Kid-friendly rubric

The Game On grading rubric for the 2019-20 season can be found here and is explained here. Because of the open-mindedness of this event, there are not many explicit rules or explicit requirements in grading.

Game Types

Game Types are not a part of the 2019/2020 rules for this event but may be added back in later years. They are left here for future reference.

The rules for 2018 specified specific types of games that could be assigned for different competitions. The following descriptions come straight from soinc.org. They are very broad, leaving most of it up to interpretation - as long as the game meets the basic requirements listed here, feel free to get innovative.

Invitationals and Regionals

• Collection – the user-controlled sprite is involved in the collecting of objects to complete the objective of the game.
• Maze – the user-controlled sprite must navigate through a series of static obstacles, borders, boundaries or lines to complete the objective of the game
• Avoidance – the user-controlled sprite must avoid moving autonomous sprites to complete the objective of the game

State

• Shooting – the user-controlled sprite must shoot or direct an object(s) during the game to complete the objective of the game
• Racing – the user-controlled sprite must complete the objectives of the game before the autonomous sprite does
• Building – the user-controlled sprite must be involved in the assembling of smaller parts or components to complete the objectives in the game

Nationals

• Combination of any two of the previous game types
• Two player game of any one of the previous game types

Event Advice

Since the Scratch program is free, it is recommended that students experiment with the program so that they are not learning how to use it at the competition. It is free to download here. If students can not use the downloaded offline program, the online editor can be utilized. However, it must be kept in mind that at the competition, students may or may not be using the offline editor. Consider brainstorming game ideas for different themes as practice. Have a team member give you a topic, and time yourself (50 minutes) to complete it.

Practice getting a basic set of code that you will start with or incorporate for different situations. Documentations on the different blocks can be found under the Scratch Wiki. Practice making sprites move smoothly with user control, making sprites slide across the screen with specific speed, stimulating gravity, turning Sprites, and making one sprite move toward another one; Practice creating the Introduction, Help, and Gameplay screens and adding the buttons between them as quickly as possible. Finally, create a few games for each game type.

As for game ideas, play other games and see what the theme of each game might be. Perhaps that will be the theme the judges choose at the competition! You can also look inside pre-existing projects made by experienced Scratchers (courtesy of Creative Commons) to determine specific mechanics of a project. It also doesn't hurt to ask other users for help in the Scratch community by commenting under projects or posting in the Scratch Forums.

Game On requires two partners to work together, rather than just splitting a test in half. Partners should develop roles for themselves, much like many teams do in Experimental Design. Practicing together is crucial for being prepared to work efficiently during a competition. While every partnership is different, many teams start off with one partner doing the initial set up (such as introduction, help screen, backdrops, sound, etc) while the other partner plans out the actual game and other aspects such as scientific applications. In the end, teams must find something that works for them.

Tips

Remember to practice and include:

Introduction Screen. The introduction screen will be the first thing the judges see, so make it catchy to start with a good first impression. Be sure to include a title and a background relating to the game.

Help Screen. Your help screen should clearly explain to the judges how to play the game. Avoid creating a game with very complicated rules because it will be harder for the judges to understand. Many times, these instructions can be concisely written on the introduction screen.

Scorekeeping. How points are awarded in your game should not be confusing and should be clear. Clear rules on scorekeeping will make it easier to play the game.

Code Organization. The judges will have to understand your code, so try to organize it into sections based on the code's function. It is often difficult to understand someone else's code, so name objects appropriately. Use good practices such as adding comments and organizing large scripts using functions. Organize critical steps in your code using broadcasts.

Time Management. Make sure that you complete a working game first before making it look pretty. Form follows function, so finish your coding first! (Time management comes with practice so...PRACTICE!)

Prioritization. Prioritize the core game mechanics (a functional game is crucial to a high score) before any cosmetics. The particular order in which you program your game can depend on personal style, so try to practice to see what works best for you. This also goes hand-in-hand with time management since you don't want to spend too long doing a particular task (e.g. customizing sprites, searching for sounds, etc.).

Testing. If anything, this is one of the most crucial parts of the coding process. TEST YOUR CODE TO MAKE SURE IT WORKS! Testing is crucial in figuring out syntax errors, fine-tuning variables, setting difficulty levels, etc. Make sure your game is accessible, and can be beaten by someone who only has a few minutes to take a look at it, not a professional gamer.

Cosmetics. Custom sprites and backgrounds are essential to achieving a higher score. Practice using the Scratch Costume/Background editor in both Bitmap and Vector mode. Bitmap is more pixelated than Vector and is mostly just drawing. Vector allows you to size and manipulate individual shapes and tends to be much cleaner. The editor is limited in capabilities, and combining both modes increase the quality and decrease the production time of the sprite.

File:Bitmap Vector Difference.png

Examples of both modes.

Sounds. While sounds don't make a large impact on the game itself, adding background music and/or sound effects is pretty simple and can help out quite a bit, seeing as 6 points are dedicated to sound. As stated above, completing a working game is far more important than adding the extra 'fluff'. Look through the sound library and find some sounds that seem plausible to use: there won't be time to try to find new songs in the competition, so know some by name.

Memorization. Both partners should have the rubric memorized, including the decoded rubric. Knowing specifically what is needed to get points can help save a few minutes that would be wasted adding unnecessary items.

Extra Tip: To test a particular string of blocks without running the whole script, double-click the group. This works for isolated blocks too-- you can reset position, broadcast messages, rotate sprites, etc., by double-clicking.

Creating the Game

Game Mechanics

Introduction

The introduction will be the very first thing that the graders will see, so make it catchy - first impressions are important for a subjective event like this one. Make sure to have the title of the game and buttons for starting the game and also going to the help/instructions menu. The title should be specific to the game itself, not the game type. Naming the game "Collection Game" will not get the Game title conveys the idea of the game point. This section will remain pretty much the same no matter what topic/game type is given (except the title of course), so it is best to have one partner just brute memorize how to create the introduction as fast as possible. Also as a side note, many teams forget to add background music to the intro: make sure to add some sort of music to your introduction. It may not seem like a big deal but small details like this can help get that extra judges impression point.

Help/Instructions

There are 3 things you must explain in your instructions: the objective of the game, the movement controls, and scoring. Sometimes the game is not clear to the graders, so a detailed instruction page can save a lot of points. In addition to this, many teams elect to have a 'science' page that goes along with the instructions that explain what scientific topics were implemented in the game. The science section will be discussed in further detail below.

User Controlled (UC) Sprite

While this will be described in Game Play, always make a custom sprite - no matter how bad it is, it will always guarantee more points than using a stock sprite. To begin, make sure to enclose your sensing blocks in if statements in a loop (forever or repeat while), as this allows for smoother movement than the "when key pressed" block. Diagonal movement can be created simply through having if statements for clicking an arrow and moving a certain number of steps in that direction. Diagonal movement is a rather easy function but still gets the advanced movement point. Another option is to have acceleration. This can be achieved by having an 'x' velocity and a 'y' velocity variable, and increasing this constantly if the arrow is key is continually held down (or vice versa for slowing down). Have the UC sprite move with a function dependent on the velocity variables that is smooth and reasonable. As for Sprite Orientation, set the location of the sprite under the 'When the (Green) Flag is Clicked', even if it is not being used until later. This will ensure that the character always returns to its original position when restarting the game. Also, keep in mind to hide/show the character as needed - leaving the UC sprite shown during the intro/debriefing will lose a significant amount of points. Always add some sort of reference point to the character if it is an object like a circle (something like a nose or mouth). This will ensure that the direction that the character is facing is obvious, and might even score some points for the quality of custom sprite.

Autonomous Sprites

Autonomous Sprites are extremely similar to User Controlled Sprites, except that they are automated (of course). One way to implement autonomous sprites is to have them act as an avoidance object (even if the game type is not avoidance), and if touched the game ends. The logic for implementing this is relatively easy (just have an if touching character block inside the forever loop) and is the most straightforward way to have autonomous sprites, as well as earn points for collision management in the next section. Also, autonomous sprites must have movement complexity (4 points on the rubric), which can be done using glide motion blocks or if time allows, giving the autonomous sprite its own x & y velocity variables for acceleration.

Collision Management

Collision management has two sections: sprite interactions and environment interactions. Sprite interaction can be achieved easily through the autonomous sprites mentioned in the previous section. Environment interaction is a little more tricky and is dependent on the game that is being made. Creating a 'playing field' that is enclosed by walls is something that could be implemented in most situations. There are a number of ways to stop the sprite from going through walls - one method is the following:

(Set the touching color to the color of the walls, which was black in this case)

Another less buggy and simpler method in which you can implement environment interaction are to have the UC sprite speed go down while touching the color of the environment, or even lose the game when touching the color of the environment.

Score Keeping

Scorekeeping is pretty self-explanatory, but make sure to stop the score counter once the game is over. Significant amount of points will be lost if the score counter is not reset/stopped when necessary. Creating a variable for the score and having it appear on the screen during the game will guarantee all the points from this section.

Here are some example/suggested score variable types for various game types at the invitational and state levels of competition. Time is usually acceptable for all game types, but some game types have more applicable scoring types:

Collection: # of ___ collected
Maze: Time taken to complete the maze
Avoidance: Time avoiding autonomous sprites until loss
Shooting: # Score or # of ___ shot
Racing: Time taken to complete the race against the autonomous sprite
Building: dependent on what your building game type is, but possibly time

Debriefing

Once the game has been won/lost, display the following:

• A "You Win" or "You Lose" Message
• Final Score

Hide/stop the following:

• All UC and autonomous sprites
• Stop the score counter

Once again, make sure to include appropriate background music for the ending.

Documentation

Be selective in what you comment - there is no need to comment items such as 'setting size' or 'setting initial location'. Instead, comment on the more advanced pieces of code, and explain what is being done in a clear and concise manner. Instead of writing a large comment, break it into multiple smaller comments - this helps to line the comments with where the code is actually used. Also, if possible, comment throughout the entire event, instead of doing it at the last second. In the last few minutes, it is very easy to forget small details such as comments, especially if there is still something left to debug.

Code Organization

Always, always, always use clean up (right-click in the workspace and click clean up). This feature is built into Scratch, and automatically makes all your code neat ensuring the No overlapping of code and all code must be individually visible points. Name the sprites and costumes as soon as they are made with meaningful names - graders should be able to tell what the sprite's role is just by the name. Also, as for the efficiency of code (2/6 points in the code organization column), make sure code does not get unnecessarily repeated: for example, in a collection game, you should use clones instead of duplicating the same sprite for the items the UC sprite is collecting. Lastly, an efficient way to allow users to replay the game over and over again is to create a game in progress variable set to true/false (or 0/1), and have the game repeat until the game in progress is equal to zero. The button to replay the game should broadcast a "start game" message and all sprites should receive this broadcast and repeat their respective actions until the game in progress variable is false.

Game Play

Science of Theme

This is by far the most important and hardest section to properly implement. Not only must there be scientific concepts included, but they must relate to theme and also be explained. In total, 12/100 points come from this section. To maximize points, 4 scientific topics must be present, related to the theme, and explained. Make the scientific topics different from each other - for example, if the theme was weather, having evaporation and condensation as two separate scientific topics would not work in most cases, and instead be counted as one scientific thought. Explaining the science is best done along with the instructions, or having its own page that can be accessed from the introduction screen. Be as elaborate as possible - even if the concept isn't implemented properly in the game, explaining how it relates to the game and theme can still earn a few points.

Graphics

Graphics also account for 12/100 points: 4 for UC sprite, 4 for autonomous sprites, and 4 for backgrounds. The UC and autonomous sprites are graded similarly - if a stock sprite is used, the max amount of points possible to earn is 2/4, and even then that requires changing at least one thing to the sprite. Using a custom sprite, no matter how simple or ugly, will always guarantee at least as many if not more points than a stock sprite. 2 points are given for creating a custom sprite, and 2 more for the quality of the custom sprite. Drawing is hard in Scratch, and completing a well-drawn sprite is a long and difficult task. Don't spend too much time trying to make it as detailed as possible (make a square with eyes if you must). The quality of custom sprite points are extremely subjective anyways, and would probably take a few minutes of work to successfully earn both points - that time could be used in numerous other areas that in total earn significantly more. If you do wish to go for these points, learn how to use Scratch's vector editor efficiently (especially the reshape tool) and only if you know you will have time to complete the game itself. Creating complex backgrounds is also relatively time-consuming, so either uses simple shapes and colors or choose a background that fits the game theme/gameplay and modify it minimally.

Sounds

Sounds seem like a very minor detail, but can help a lot in earning overall game impression points, and can tip the scale in competition. Add background music for the introduction, gameplay, and debriefing sections, and change it up for the "variation of sounds" points on the rubric. If there's a few extra minutes, recording a custom sound effect is a great way to earn the quality/complexity of sounds points, so before the event time even begins, try to make sure that the microphone and speakers work, although it is suggested to bring your own microphone to the competition. Look through the sound library before the competition and find a few sounds that could work for certain themes. There won't be any time to browse through the library during the competition to find a certain sound. Sounds, specifically the background music, are best implemented in the backdrop workspace since the sounds will most likely change when the backdrops change. Sometimes the "stop all sounds" block doesn't work properly, so add the "stop all other scripts" block to ensure that the sounds will stop when they need to. If you're really low on time, find a sound under the Loops category and stick it in a forever loop through the 'play [sound] until done block'.

Play Balance

Play balance also accounts for 12/100 points of the rubric, and includes a large number of areas. First and foremost, make sure to include some sort of level function. In order to make the game more smooth, adding an intermission phase in-between "Level 1" and "Level 2" is a good idea and can help make it obvious when the level is changed. You might also choose to have a "level announcer" sprite that simply just changes costume and displays itself at the top of the screen, telling the user what level it is. From each level change, increase/decrease the speed of the UC and autonomous sprites, or change other movement variables. This is another section that is easier to implement when the autonomous sprites are being avoided, because making them faster/making the UC sprite slower is easy to earn these points, but make sure not to overdo it: the movements must still be appropriate for the gameplay in order to earn the rest of the points for this section.

Overall Game

And as if Game On wasn't subjective enough, 8/100 points come from the grader's interpretation of the game - 4 points for overall impression of the game and 4 for the originality of the game. While adding all these small details to the game to maximize points is important, remember that in the end its a game. Make it enjoyable and fun for the graders. In large scale tournaments, many games end up being relatively similar, because most teams will go with the first thing that comes to mind. Spend some time thinking of more unique games that can separate it from the rest of the games. That being said, still, be efficient. Don't spend half the time thinking - you won't have time left to code!

For more specifics on the game creation, take a look at Chaguy2457's guide below.

Additional Resources

Game On/Scratch Blocks

User Carrot's Guide, from SSSS 2019.

User Chaguy2457's Guide, from SSSS 2017.

External Links

2017-18 Rubric

Explanation of Rubric

The Scratch Wiki