Teaching tools

Teaching Goal: Excited Students not finished Games
Some teachers are concerned about time. Keep in mind that the goal of the initial module is about giving students a positive experience regarding computer science. Finishing a game, e.g., finishing Frogger, is not the main goal. If you can get your students to create a simple version of Frogger with, say, cursor key controlled frogs, moving trucks, and perhaps some truck generators then you are doing great. If you have more than a week students could move on to the more complex part of frogger such as the transportation (tutorial #2). Again, if you do not get to that point do not worry. If students want to they could download AgentSheets at home and continue. If the students have uploaded the games to the Scalable Game Design arcade then they can download their games and continue working at home.

Synchronize Students
We find it to be likely to result in trouble if you allow your students to go at different speeds. Especially at the beginning there will be an enormous difference between students. Later you may be able to have them work at their own pace for instance by using the wiki tutorial online or in printed out form. Here are some ideas on how to can keep students in synch:


 * formulate clear goals:, e.g.," today we will draw four agents: Frog, road, grass and truck"
 * use count down timers (more info below) to provide students a sense on how much time they have left
 * allow for some touch up tasks. If you give students limited amount of time to make depiction, e.g., 5 minutes, then there is a good chance that some student would like to make their depictions looks better. Allow them to do these touch up tasks only if they have done everything else. For instance, if they are ahead with their programming tell them they can use the time for touching up the depictions.
 * show them what they need to do using screen lock out: to get their attention show them what they need to have, and how to get there. Lock out their screens to get their full attention.
 * Absolutely NO YOUTUBE: It is not OK to play around with other stuff such as YouTube, Facebook etc.
 * Involve students into teaching: ask them how to achieve a certain goal. How do we make our frog look like this... How do we create a new rule... You may even have a student come up to drive the game building. Make sure you tell them that you and the rest of the class will talk them through. This not only makes the class more interesting but it allows you to walk around in the class room and help students. It is as if there is one more teacher in the class.

Use Projected Stopwatch to show much time there is left to finish depiction or program
A common problem is that students get carried away with drawing their depictions. We like students to be interested in the drawing part as it deals with parts of the ISTE standard but there is a high risk for your class to get out of synch. Teach your students to draft depictions quickly. For instance, make a blob looking frog in just about 5 minutes. The students can improve their creations later. You can find count down timers online. Project them allow everybody to see how much time there is left.

Compile Error on Aurora Novell Networks
The Aurora Public Schools is using a Novell based network that introduces a problem with AgentSheets. When creating a new depiction or new agent you may see this kind of error message, e.g., "Compile Error: Unable to generate byte code for agent 'so and so' Unable to write class file for agent 'So and so' to ...so and so.class" As far as we can tell the Novell network interprets - sometimes - the compilation of resulting in the creation of .class files as unusual activity against which it will protect itself. We have not found a reliable way to reproduce this effect. It appears to happen randomly.

Work arounds


 * when getting the error message above have the students save the work, exit AgentSheets and launch AgentSheets again. No work will be lost.
 * we have had some students save their projects onto the computer desktop and then only at the end of the session copy the project into their networked account folders. This may not be very practical as students may forget to copy the project.

AgentSheets Troubleshooting
We have observed a number of issues that are common among students using AgentSheets


 * AgentSheets crashing / running out of memory: having an agent in a game that creates new things can quickly get out of hand and you can end up with thousands and thousands of agents piled on top of each other without even knowing. If this is the case, the system will eventually run out of memory and it will crash. To debug a situation like this, the first thing to do is to check Generators. Are they generating new things (e.g. a tunnel generating new cars) without checking that there is an empty street piece there? If it's not the obvious generator agents that have the problem, is there any other agent who's creating new things? Check all behaviors, looking for uses of the New action. Be cautious of how students use this action, always putting some checks so that generated things don't end up piling up. Also, for generated things, there typically has to be some kind Absorb agent to delete them. Is that happening? If there is a "leak" somewhere, the generated items will end up piling up - and it may be in positions on the worksheet that you don't see.


 * Submitting project to Scalable Game Design Arcade: when using the new feature in AgentSheets 3.0 to submit a game to the Arcade, we suggest that you use the default location it gives you for creating the Arcade zip file, which is the Desktop. Navigating to other places which the students have write privileges (e.g. their student accounts) works, but a word of caution: DO NOT select to save the arcade file in the actual project folder. This will result in a nasty recursion which will generate nested folders to the point where Windows will not be able to handle them - and you will have a hard time deleting those nested folders. It is a known bug and we are working on fixing it for the upgrade, but in the meantime please be cautious and completely avoid putting an Arcade file in the project folder.


 * Downloading and Re-Uploading Projects to the Arcade:, you should RENAME the project folder before proceeding. Failure to do this may result in the destruction of the project file when you attempt to submit it to the arcade. Here's why. When a project file is downloaded and decompressed ("un-zip'd"), the folder is named "ProjectFile-youroriginalfilename". When you begin the process to submit the project to the arcade, the first thing that AgentSheets does is to attempt to create a project folder with that name. Unfortunately, if that folder name already exists, this means it will be deleted first, thus destroying the project folder.The subsequent steps to compress the folder for uploading and the submission to the arcade appear to go successfully; however, that is true only mechanically speaking. What gets uploaded is a folder of zero-length files. You may not notice this, because in the process, AgentSheets also creates a Java applet that is uploaded to the arcade so that the project can be run in a browser. The applet is not destroyed, so that when you test the upload by running the project, it appears OK. However, if you later download the project, you will discover that the project is no longer valid. This is especially serious if the project you downloaded was your own project, which you were updating, and the only version is stored in the arcade. Until this situation is changed, the best way to avoid this is to RENAME A DOWNLOADED PROJECT FOLDER AS SOON AS YOU HAVE DOWNLOADED IT, by at least removing the "ProjectFile-" prefix.This problem exists on both Windows and Macintosh platforms.