Open johngtimms opened 11 years ago
He has already mentioned in class that there will be a rubric for v2.
I am working on a full and complete rubric for v2. It will be coming out soon.
:D
^_^
:っ)
:DDD
= ]
Smiling at 4:40AM is difficult
:c
@ztanner :っ(
=/
:|
D=
:baby: :baby_bottle: :cry:
:'(
T_T
ಠ_ಠ
つ ◕◕ ༽つ Give Rubric つ ◕◕ ༽つ
░░░░░░░░░░░████ ░░░░░░░░░░░█░░█ ░░░░░░░░░░█░░░█ ░░░░░░░░░█░░░░█ ██████▄▄█░░░░░███▄ ▓▓▓▓▓█░░░░░░░░░░░░█ ▓▓▓▓▓█░░░░░░░░░░░░░█ ▓▓▓▓▓█(づ。◕_◕。)づ ░░░░░█ ▓▓▓▓▓█Give Rubric ░░░░░░█ ▓▓▓▓▓█░░░░░░░░░░░░░█ ▓▓▓▓▓█░░░░░░░░░░░░█ ▓▓▓▓▓█░░░░░░░░░░░█ ▓▓▓▓▓████████████
░░░░░░░░░▄░░░░░░░░░░░░░░▄░░░░ wow so happy ░░░░░░░░▌▒█░░░░░░░░░░░▄▀▒▌░░░ ░░░░░░░░▌▒▒█░░░░░░░░▄▀▒▒▒▐░░░ much rubric ░░░░░░░▐▄▀▒▒▀▀▀▀▄▄▄▀▒▒▒▒▒▐░░░ ░░░░░▄▄▀▒░▒▒▒▒▒▒▒▒▒█▒▒▄█▒▐░░░ ░░░▄▀▒▒▒░░░▒▒▒░░░▒▒▒▀██▀▒▌░░░ ░░▐▒▒▒▄▄▒▒▒▒░░░▒▒▒▒▒▒▒▀▄▒▒▌░░ ░░▌░░▌█▀▒▒▒▒▒▄▀█▄▒▒▒▒▒▒▒█▒▐░░ ░▐░░░▒▒▒▒▒▒▒▒▌██▀▒▒░░░▒▒▒▀▄▌░ ░▌░▒▄██▄▒▒▒▒▒▒▒▒▒░░░░░░▒▒▒▒▌░ ▀▒▀▐▄█▄█▌▄░▀▒▒░░░░░░░░░░▒▒▒▐░ very 5 am ▐▒▒▐▀▐▀▒░▄▄▒▄▒▒▒▒▒▒░▒░▒░▒▒▒▒▌ ▐▒▒▒▀▀▄▄▒▒▒▄▒▒▒▒▒▒▒▒░▒░▒░▒▒▐░ ░▌▒▒▒▒▒▒▀▀▀▒▒▒▒▒▒░▒░▒░▒░▒▒▒▌░ ░▐▒▒▒▒▒▒▒▒▒▒▒▒▒▒░▒░▒░▒▒▄▒▒▐░░ ░░▀▄▒▒▒▒▒▒▒▒▒▒▒░▒░▒░▒▄▒▒▒▒▌░░ ░░░░▀▄▒▒▒▒▒▒▒▒▒▒▄▄▄▀▒▒▒▒▄▀░░░ ░░░░░░▀▄▄▄▄▄▄▀▀▀▒▒▒▒▒▄▄▀░░░░░ ░░░░░░░░░▒▒▒▒▒▒▒▒▒▒▀▀░░░░░░░░
O_OO_OO_O
^^_
(╯°□°)╯︵ ┻━┻
(ーー)!! (-.-) (--) ( 一一) (;一_一)
;A;
woohoo
¨ ¨ ¨ ¨ ¨ ¨ ¨▲.︵.▲ ¨ ¨ ¨ ¨ ¨ ¨ ¨◄ƒ░░ 0 }…..︵. ¨ ¨ ¨ ¨ ¨ ¨◄ƒ░░░░░░ o”) ¨ ¨ ¨ ¨ ¨ ◄ƒ░░░(────.·^”’ ¨ ¨ ¨ ¨ ¨ ◄ƒ░░░§ ´ )¨ ¨ ¨ ¨ ◄ƒ░░░░§ ¨ ¨ ¨✺✺✺ ) ¨ ¨ ¨◄ƒ░░░░░§¨ ¨ ¨|//✺ );; ¨ ¨ ◄ƒ░.︵.░░░§((( );;;¨ ¨◄ƒ░(░░)____// );;;;¨◄ƒ░░░░░░__// );;;;;◄ƒ░░░░░░░░§ );;;;;;;░░░░░░░░░(((
Thank you for the enthusiasm. Here is the rubric. I will leave it open for comment for a few days after which it will be put on the website. [Sorry for the way the formatting came out below. It's Git's fault.]
Team Rubric for SimCity201 v2
Each NUMBERED item below represents 2½ points of grade; partial credit is available. Your team starts out with 100 points and you lose 2½ points for each item which doesn’t comply. The idea is that:
• You can still get an A- team grade with four flaws.
• You can still get a B- team grade with eight flaws.
• etc.
Normative Scenarios – Baseline, i.e., little or no interleaving
Scenario: [Tests all the behaviors.]
I forgot the rubric for the producer-consumer waiter. Here it is:
Proper integration of producer-consumer code
Question about producer-consumer waiters: are all restaurants expected to implement this new design, or is it acceptable for some restaurants to do so while some retain the normal waiter functionality? It doesn't seem to reflect reality that within a single restaurant, some waiters talk directly to the cook while some clip their orders to a rotating shared data location.
This is an individual assignment and has nothing to do with reality. I want each student to do the refactoring required to make this behavior happen.
Is it intentional that numbered items * 2.5 does not equal 100?
"Market delivery fails because restaurant is closed." We designed our city to be open 24 hours and nothing is ever closed. Do we need to redesign to have regular open/closed cycles daily (i.e. beyond some buildings being closed on weekends) or (since this is a non-norm) can we simply set the restaurant closed at some point in the scenario?
"People make decisions to eat at particular restaurants." Does this mean that the choice of restaurant should not be random? Is "I'm closest to Restaurant X so I'll eat there." sufficiently non-random?
"Icons/images are beautiful for non-grading view." I don't want our team to be distracted from coding by finding or developing graphics for this requirement. We're learning to be programmers, not graphic designers. The intent here is obviously to show that teams have the ability to work with GUI elements beyond colored squares. Can this requirement be changed or can the professors provide a set of images suitable for use to the whole class?
1) Yes. 2) Yes, there should be opening and closing hours. But, I doubt you have to redesign anything. 3) Random is ok for v1, not v2. Closest is one of many possible decisions, but will produce only very predictable behavior. 4) Maybe "beautiful" was too strong a word. Maybe post this as a separate issue and see what the class comes up with.
@johngtimms You don't need to work too hard to find suitable art, I don't think. A quick search of Google images for "sprite sheet" will get you tons of 2D artwork that you can use. Take 10 minutes to crop out pictures using Paint or something and you should be fine. I don't think the professors wanted us to produce our own artwork for this project?
@Valakor I already saw some people doing that for v1. Hopefully it can be made clear in the rubric that producing your own artwork isn't necessary.
You do not have to produce your own artwork. I'll add that to the rubric.
Would a smaller team also need at least 50 people in their city? By "At least 2 instances of other workspaces", do you mean that instead of having one market, we could have 3 and that would satisfy this requirement? Does all functionality from previous restaurant projects need to still be in place, or can we edit it to make it work better with our cities? For example, certain things like setting a customer to "hungry" are no longer possible (right?) Will we get penalized for missing requirements from previous restaurant versions even if the restaurant fills its function adequately?
*When I asked about smaller groups perhaps not needing to implement quite so many people, that came from the fact that we will have significantly fewer jobs for them. A group of four versus a group of seven means that the former group will have three fewer restaurants than the latter, which makes up a large percentage of overall jobs
@dwilczyn - Regarding rubric point number 4 (Roads should have appropriate complexity [e.g. intersections with stop signs and/or signals]), this seems to contradictory to our entire GUI that our team designed. As John said in the first post about the flexibility of V1 requirements leading to different products, we designed our city in a different way which allowed us a more efficient movement algorithm and city layout. Having to incorporate intersections would be fine if it were a requirement from the beginning, but having to redesign our entire city, building layout, transportation mechanism, and movement algorithm at this late stage seems more difficult than intended for the assignment.
Would there be a way to substitute a more personalized road requirement (for example, we could include sidewalks, alleys, and bus lanes) which could teach us more than redoing all of our existing GUI work?
Thanks for your understanding.
The rubric will be published on the website at the end of the day today. Last chance for comments.
Will the performance/framerate of our city be taken into account in grading? Our team has not been too concerned with optimization for v1. Right now with 10-15 people and only 1 restaurant, our city has a relatively low framerate and I am concerned with how well our city will be able to run with 50+ people running simultaneously. Is this something that will have an affect on grading?
@dwilczyn I still don't understand why there are 85 requirements for v2 that are worth 2.5 points each but total points is 100? 212.5 != 100?
I haven't done the math but there are extra credit scenarios in that list of 85.
@richy0101, please read what @dwilczyn wrote a bit more carefully:
Each NUMBERED item below represents 2½ points of grade; partial credit is available. Your team starts out with 100 points and you lose 2½ points for each item which doesn’t comply.
In other words, we will not grade by adding-up the score, but with deducting points when things go wrong.
The extra-credit scenario was, obviously, a joke. It won't be in the version soon to be posted.
The problem with this grading scheme is that you could hypothetically get less than 0 points, and have to do more than 100 points worth of work in order to get 100. Why don't you just weight the requirements to add up to 100, or start with a higher score?
I agree that it doesn’t make sense that you can lose more points than you can earn.
On Dec 2, 2013, at 4:22 PM, jdg123 notifications@github.com wrote:
The problem with this grading scheme is that you could hypothetically get less than 0 points, and have to do more than 100 points worth of work in order to get 100. Why don't you just weight the requirements to add up to 100, or start with a higher score?
— Reply to this email directly or view it on GitHub.
Frame rate will not be taken, as long as the grader can tell that things are happening properly.
(34) For the bank, should we implement 2 or more instances? When discussing the design prior to v1 and during v1, my team was under the impression that having only one bank was sufficient for v2 requirements. (I can't think of the issue or comment in class specifically at the moment as to why we were under this impression, but I believe there is an issue of it on GitHub and can search for it if required). Due to this, we built our design around only having one bank (as a part of the person/bank interaction and deciding what bank to go to). Is this still the case or should we redesign our banks/people to implement multiple banks as well as multiple bank accounts?
(44) For implementing the log filter mechanism, we already have separate consoles for each building, visible when the building is open. This allows a feed much like for the restaurant. Is this acceptable instead of the log filter? It seems to accomplish the same purpose of cleaning up the log and it would seem redundant to add the log filter inside of every building as there are few messages to filter through.
(47) For agents bumping into tables, it was never posted as a requirement or guideline to have A* or any sort of collision avoidance algorithm within our personal restaurants. Does this requirement apply to our individual restaurants as well? I fear this addition to the individual portion of the grade will take team members further out of the team portion of the project (as A* would have to be tuned for each member's GUI) and would hurt the team as a whole.
(82) Also, as a personal question for my waiters, my producer-consumer waiter and regular waiter are very similar and I was able to accomplish the two with a single class and an enum for the type rather than creating two new classes. In addition, my toggle method meets requirements 83-85. I can see how larger variations between the waiters would require the extra classes, but with just a few lines of code difference as the end product, would this solution also be acceptable/efficient?
Quite a few people have been (and still are) confused about the requirements and grading for v1. Since the grading has yet to begin, I think now would be a good time to discuss the exact requirements for v2.
The professors do not desire to provide a rubric to give students experience working with nebulous requirements. However, I think it would be helpful to provide a list (if not exhaustive, then partial) of individualized team-specific requirements for v2 along with the grade reports for v1.
Because very few v1 projects will look the same (due to the flexible requirements) any general requirements published for v2 may not be relevant to all teams. I simply want to have a fair opportunity to do as well as possible. Just like in industry where programmers either get an "A" or an "F" for complete or incomplete work, I know from experience as an intern that companies also hire writers and analysts to ensure that requirements are properly specified and understood by programmers.
@crowley1958 @dwilczyn