Fall 2001 Feedback on Milestone 2 & Milestone 3

Hotspots: Admin Pages | Turn-in Site |
Current Links: Case Final Project Summer 2007

Fall 2001 Feedback on Milestone 2 & Milestone 3

The TAs and I are finding issues about Milestone 2 that we wanted everyone to hear about. That's what this page is for.

Mark Guzdial

If you only created AGObject, AGCharacter, AGWorld, AGRoom, and Player, you're going to lose 10-15 points. I said on the CoWeb and in class that those ARE NOT the only classes in this problem! Where's the parser? How does input get handled? How are Verbs represented? What object represents a VerbHandler? No, the Parser is not part of the UI classes – it's core to processing adventure game input! Remember, "You can never have too many classes." Mark Guzdial

Design for this project

Design your classes to be as general as possible. If you have a tokenizer, it should be easily reusable for a task which you may think up for it sometime in the future. Same goes for a parser. If you have a class (or system of classes) that will define a set of rooms and doorways, think that you are designing a graph. The rooms are nodes and the doorways are edges (directed in this project). Ideally the system of classes that constitute your rooms and doorways will score the highest marks for design if they are reusable as general graph entities (because thats what they are).Sami Deen|

With all respect... I TOTALLY disagree. The parser is COMPLETELY part of the user interface. If we EVER switch from a text based to a graphical based user interface, then the parser becomes completely obsolete. (The comands will be built into the buttons, menus, etc.)
Chris Lawrence

Actually, I think the parser could be easily modified to parse these new types of inputs. Why not? Of course, at this point you might consider having 2 parsers, one eating text tokens and one eating mouse/pointer tokens. Splitting up the responsibilities of the parser into a lexer and parser seems pretty logical to me, and then in the above situation, your lexer could easily hand tokens over to the appropriate parser. Of course, keeping the lexer and dumping both parsers in exchange for each object knowing how to parse messages would also be doable, but then some of the abstraction goes right out the window....but at the same time, a different scenario emerges, also worth considering. I've gone on long enough, and am making progessively less sense, so I'll stop. Shaggz

Mark is right. If you look at the bigger picture, what if you want to use your UI for something other than this project? Do you then go in and rip out your parser? If so, your design needs some work. Sami Deen

You say that " one can never have too many classes" , however if we end up making a lot of classes there might be a case where you have classes which don't have much practicality as in you can easily incorporate their functions in your main classes ... so why go for TOO MUCH abstraction ?
Mohammad S Khan

You make a good point in that having a design that's so abstract that you can no longer understand what the big picture is all about is probably not very useful, and somewhat defeats one of the purposes of abstraction. It's up to you to decide where you think you have enough abstraction going on, suited to your (or in this case, the group's) particular design goals. I think the main point that was being made initially was that cramming everything that's going on into just a few classes (particular those given to you) doesn't make much sense sometimes (ding ding!). Shaggz

If you think of the classes you build as simply a framework that you can add to later, there is no such thing as too much abstraction. Even if you find your classes are becoming very small, never have one class doing two different things Sami Deen.

so correct me if i am wrong , lets say i am designing something and i can do more abstraction my adding a class that ONLY has services and for some reason on attributes ... then it is justifiable to have that class as long as it is doing something that can be said as a different thing ... but it would not be feasible to make a new class that only does attributes and no services ...right
Mohammad S Khan

You should never have a class with just attributes. If the class has attributes, manipulation of those attributes is a responsbility of that class. But think carefully about "responsibility." A single class should have all responsibilities, it should have only a coherent set of responsibilities. If you need to have more responsibilities covered, create more classes. You do sometimes have classes with only services – that's often true with abstract classes. Mark Guzdial

You can certainly start building your design with classes that only have attributes that group logically as long as you add methods later. You often find that there are all kinds of things you would like to to with attributes in a class. Such as compare them attribute by attribute to another instance of the same class. Take a look at the Graphic-Primatives->Point class in Squeak. Here is a class which logically groups 2 attributes: x and y (thats all the attributes it has). This was a nice way of grouping the values required to place a pixel on a screen. No need to pass your x and y values around separately every time you need to move the data. After this was done, the writters of the class found over 50 ways (methods) to manipulate the data. After you group your attributes you will almost immediatly find at least 1 way, and often many ways of facilitating the use of the data that is encapsulated in your class through services (methods).Sami Deen

This is up to you - if the difference between attributes is salient enough and each time you come across it in coding you have to think "what exactly do I want here" - then yeah, another class will be an assistance - but if it is something ridiculous then just dont' sweat the tedious details Webb

Make sure you have some kind of hierarchy in your design. This project allows for at least something like:

Class:WorldEntity
Subclass of WorldEntity: Character
Subclass of WorldEntity: Object

Sami Deen

I am pretty shocked that some groups I've seen did not make use of WordMatcher from Fall 2001 Milestone 1. I would say if no one in your group has a decent one then go beg friends from other groups for theirs. No big deal; you aren't going to make everything from scratch in here.

http://www.deanofstudents.gatech.edu/Honor/ Article II, section 3. Maybe you shouldn't be doing this after all. Shaggz

I agree with Shaggz, Webb – students can't beg off their friends' WordMatcher. Mark Guzdial

Mark, can you re-read this and clarrify? Shaggz seemed to say that you can't copy so if you agree with him then students shouldn't be able to "beg off of their friends' WordMatcher" Lushi

I suspect that a typo or an "external fix" – yes, I agree with Shaggz. Students cannot use another groups' WordMatcher. Period. Mark Guzdial

ah - I see the light - wasn't thinking about official rules and such. It just seems like the WordMatcher is pretty trivial piece of the project once the real design problems come down the line. But maybe a real flexible team can work around a shabby parser and create a really nice system around it and make up for it with other great ideas. This would be less interesting if everyone could default to the same generic "working" parser. hmmm - Webb

I have a question myself - it seems that rooms are only being connected one-way. Has this policy been made? I just think its unnatural to step from the kitchen into the living room and then suddenly be surrounded by 4 walls with no exit! hehehe.
Someone please let me know if so.

CRC analysis: generally is not happening. It is unusual to have the same exact name appear as a CRC class and a class in your OOD class diagram. In fact it most likely indicates that your OOA is bad. Any CRC card with AG~ should be burned.
"World" is something that's popular to think about; its easy to abstract over programming language details, but it is not appropriate for the initial brainstorming OOA. You are imagining real tangible things that are ill-defined. The consequence is that you are already really thinking about how the rest of the pieces will be situated in this "world". The "world" appears in the OOD stage after you have established the (I may be muddling my vocabulary here-) actors.
more to come... Webb
But the requirements for the project specifically required that we have certain classes with certain names. It seems that at the analysis phase, since it has already been decreed that we need to have an AGWorld class that recognizes certain commands, it's good to say "We'll need to build that class that is required" Brandon Yarbrough

Yes – I did make the announcement that doors were one-way-only, and you'd have to explicitly connect both ways. Mark Guzdial

I scanned in my answer key for the Midterm: FYI – F01-MidtermExam-Key.pdf Mark Guzdial

Link to this Page

Fall 2001 Project Milestones last edited on 17 October 2001 at 1:59 pm by guzdial2.cc.gatech.edu