2017-12-11 Lab + Final Project

posted Dec 11, 2017, 5:52 AM by Konstantinovich Samuel   [ updated Dec 11, 2017, 7:39 AM ]
1. Jan 22nd: Final Exam.
2. Regarding vacations: If you plan on taking an extended vacation you MUST inform me.
   IF YOU HAVE A PARTNER (discussed later): your partner as well. 

Goals: Lists, Undo, Final Project

1. READ the notes on lists, and experiment with them in netlogo. 

Complete list commands: (optional if you are interested)

Subset of list commands with some tweaks:

Look up in the netlogo dictionary:
1. list 
    - create a list out of 2 elements ( To create with more than 2, or fewer than 2 elements requires parenthesis: See dictionary!)
2. lput / fput  
    - creates a copy of the list with an extra element at the last/first position
3. item 
    - gives you the element at the index specified. 

Constant lists

You can make a list by simply putting the values you want in the list between brackets, like this: set mylist [2 4 6 8]. Note that the individual values are separated by spaces. You can make lists that contain numbers and strings this way, as well as lists within lists, for example [[2 4] [3 5]].

The empty list is written by putting nothing between the brackets, like this: [].

Building lists on the fly

If you want to make a list in which the values are determined by reporters, as opposed to being a series of constants, use the list reporter. The list reporter accepts two other reporters, runs them, and reports the results as a list.

If I wanted a list to contain two random values, I might use the following code:

set x list (random 10) (random 20)

This will assign to the variable   a list with two different random integers each time it runs.

To make longer or shorter lists, you can use the list reporter with fewer or more than two inputs, but in order to do so, you must enclose the entire call in parentheses, e.g.:

(list random 10)
(list random 10 random 20 random 30)

CHANGING LISTS:  (read the examples of lput/fput in the dictionary)

Lists cannot be changed, but you can make a new list, and assign that to the same variable if you like. 

think: if x is 5
set x x + 1  ;this does not change the number 5, it changes which number is stored inside of x.

To add an item, say 5, to the end of a list, use the lput reporter. (fput adds an item to the beginning of a list.)
let stuff [1 2 3 4]
set stuff2 lput stuff 5   ; this does not change the list stored in stuff, it makes a new list and puts that list in stuff
show stuff                ; shows [1 2 3 4]
show stuff2               ; shows [1 2 3 4 5]


The of primitive lets you construct a list from an agentset. It reports a list containing each agent's value for the given reporter. (The reporter could be a simple variable name, or a more complex expression -- even a call to a procedure defined using to-report.
 [size] of turtles  ;reports a list like [1 1 1 1 2 3 1]
 [count turtles in-radius 2] of turtles  ;reports a list like [1 3 1 1 1 1 3 3]

Using the commands:
Will result in a copy of the list without the first or last element included (see dictionary)

2. Try to make a model: (lab move-and-undo)
turtles own [ move-list ]

setup button 
    -creates one turtle, make move-list an empty list.
    -set the shape to person    
    -Change the patch color of the origin to white.

up/down/left/right buttons:
    -When pressed, they cause the turtle to move in a direction
    -Add the word "up" "down" "left" or "right" to your list (based on which button was pressed)
    -Change the patch color of the new position to white.
undo button
    -Should 'undo' the last move, and remove it from the list. You need the but-first or but-last command.
    -This resets the patch color AND the position of the turtle. 
    -Should do nothing when there are no more moves left. 

1. You click setup, up, up, right, up.
You now have 5 white patches, and the Turtle has move-list of: ["up","up","right","up"]
The world looks like:
 W <-turtle is here
W <- origin here

2. You press undo for the first time:
You now have 4 white patches, and the Turtle has move-list of: ["up","up","right"]
The world looks like:
WW <-turtle is on the right W
W <- origin here

3. You pres undo a second time:
You now have 3 white patches, and the Turtle has move-list of: ["up","up"]
The world looks like:

W <-turtle is here
W <- origin here

Final Project Guidelines:

You have two options:

Netlogo Model Extension:  
    SOLO Project
    Max Grade 94
    You will extend 1-2 models. (2 is just in case one model runs out of reasonable things for you to do)
    You will document exactly what code you added/changed.

Project from Scratch: 
    PAIR Project
    Max Grade 102, but will only average in a 100
    This is the full CS experience! - If you have high grades you SHOULD be doing the full project from scratch. 
    Prototype is part of the grade

Both cases:
    Documentation is critical
    Same Number of submissions

Rationalle For the 94 cap:
- If everyone did a full project, some of you would spend a ton of time on it, struggle a lot, and not succeed. These projects would get low grades and are difficult to grade because they don't work and I cannot just grade on effort. 
- This gives the option for an easier but still substantial project.
- You cannot get 100 on it because if you have difficulty in the class and want to opt for this you would not have gotten 100 on the full project either! 
- If you are lazy, you can avoid doing as much work in a "legit" way. 

General Final Project Logistical Guidelines:
1. You will be required to submit 4 versions of your project over time. Regardless of what kind of project you make. 
2. You are expected to do work in class AND at home.
3. Your grade will depend on several factors beyond the actual project:
 a - Your prototype/documentation/submissions
 b - Consistent work throughout the 2 weeks. (The procrastination penalty)

Full project:
1. You should try to get the minimum requirements done early, and play with how your project looks as a last 
2. It is ok if someone goes above and beyond, as long as the other partner contributes a substantial amount. It is NOT ok if one partner does most of the work, and the other does very little.

Final Project Dates:

Dec 18th: You must have chosen what kind of project you want to make. If you are doing a full project, you need a partner + discussed with partner ideas / goals. 

Dec 20th: Project Proposal. (a concise description of the project you want to make)

Jan 4th:  Prototypes required in class while you work. This should be an elaborate explanation of your goals, and picture of how you want things to work. Details to follow.

Jan X: HW server Project slot 1 due.    (I have to pick some dates)
Jan X: HW server Project slot 2 due. 
Jan X: HW server Project slot 3 due. 

Jan 16th: HW server Project slot 4 (final version) due by end of school day. 

Jan 16-19: Demos!

Regarding games: As a game enthusiast, it pains me to STRONGLY suggest you avoid games. I have found that students tend to focus on the wrong things when making games, or just implement them poorly.  
-Original games tend not to have a good goal for you to reach. Mashup games like pacman+spaceinvaders is an exception to this. 
-Clones of existing games often need modified controls to better suit the mouse+widgets mode of NetLogo. You cannot expect a game that requires keyboard input to work the way you want it to without a great deal of effort. 
-If you want to do a game, you ABSOLUTELY must have at least one alternative project idea.