Hi Blake, Welcome to the list. Before telling you what I would do I have two things to say.
First when I'm teaching people Smalltalk (and by the way I'm not a teacher, the only people that I've taught is coworkers or people that worked for me) I give a them a lot of latitude to make mistakes. I give a lot of credit to someone for making something that works. Only after they succeeded in doing something on their own do I go back and explain methods and techniques that would improve their programming, usually on a different project. So keeping that in mind it may be better to let your son solve the problem on his own and then go back and build something else using some new techniques that you can show him. Second there are a lot of possible designs for this problem. The implementation of the design should be kept separate from the design itself. Whether or not you use a text file or how you store the data is a detail. The details come easy once you have a good design. So focus on design first. That aside this is a fun question. (Although I really don't like the actual flow chart, killing and kids don't mix well in my mind. I know there are lots of killing video games but not that I let my child play) The real problem is that it is difficult to gather the requirements so since this is just a conversation I thought I'd just make them up. First I want my game to be able to add things. It should be easy to do. The things should be able to answer questions based on properties of the things. Next I want the thing to be able to follow multiple question flows. It should be easy to add properties, questions and flows to the design. I would personally like to be able to ask random questions so that I can follow random flows. OK so this is Smalltalk so let's figure out what objects we have. We have: Thing, Property, Question, Message, Tree. The Thing has properties. The Property has a question. The Question has an answer of yes or no. The System gives user Messages. And we build the flow with a Tree. The Tree routes by Questions. If the Tree does not have a question then it routes automatically to the next Tree. If the Tree does not have another Tree then we are done. Ok so first thing we need to do is build properties. Each property has a question so build a property by giving it a question. We could also add a name. Property instanceVariableNames: 'propertyName question' In your example there are only properties that have yes answers but there could be a property that applies on a no answer. For example: Property -------- question -> Question -------- Question -> Is it round? answer -> no propertyName -> non round thingy So now have your system add properties by asking you to name the property and then type in a question and its answer. For example: System: Enter Property Name: You: Scary System: Enter Question for Property Scary: You: Is it Scary? System: Answer to question Is it Scary?: You: yes Now that we have properties we can build thingys What we do is have you provide the things name and then ask you all the questions from all the properties that you added. If you answer the question with the same answer that is stored on the property question then the property is added to the thingy. Now you have thingys with properties. We need to build a flow. A tree has a question or a message. Tree instanceVariableNames: 'questionOrMessage yesOrDefaultTree noTree' So now you build your tree by having the system ask you for a question from the list of questions added by properties or you can optionally type in a message. If you add a message like: Boring find another thing. Then you can either add a default tree to the message or nothing indicating that you are done. So for every question added, the system should ask you for the next question or message allowing you to specify the yes or no tree to add too. And it should verify each branch on the tree has a yes and no tree or ends in a message. Notice there is no branching code any more. To follow a flow you start from the root tree. Tree >> processFlow "move along the tree branches until there are no more trees, displaying the question or message and following the path based on answers" anAnswer := nil. self dispayQuestionOrMessage self treeHasQuestion ifTrue: [ "do not allow anAnswer to be set to nil" anAnswer := self getAnswer. ]. (anAnswer isNil or: [anAnswer isYes]) ifTrue: [ self yesOrDefaultTree isNil ifTrue: ["we are done" ^self] ifFalse: [^self yesOrDefaultTree processFlow] ]. ^self noTree processFlow Ok so why did we build thingys? Well because things can now answer questions for themselves and we can build costumes on thingies and get them to run around on screen. Now we don't have to ask the user questions we can just send messages. (Like KILL! Ugh). So to summarize my suggestion: you use a tree construct to represent branching instead of using hard coded flows. (It is not really a linked list) You build objects that represent properties that have questions and answers. You can then build things that have these properties. Hope that helps and wasn't too complicated. Ron Teitelbaum President / Principal Software Engineer US Medical Record Specialists www.usmedrec.com > From: Blake > Sent: Saturday, February 17, 2007 7:11 PM > > I'm half thinking-out-loud here and soliciting thoughts on a programming > lesson. If this sort of thing bugs you, feel free to ignore. > --- > My son is coding this flow-chart as a Q&A type application: > > http://media.www.gamespy.com/articles/633/633817/img_2913464.html > > So, it says, "You found something!" then asks "Is it alive?" and then > branches out accordingly. I'm letting him muddle through with the idea of > using his code as a platform to teaching him a better approach (or > approaches). > > Looking at the chart, it looks like spaghetti code, and reminds me of some > of the stuff I did in BASIC. And that's sort of what he's doing within > Smalltalk. I'm actually tempted to show him how it would look in BASIC > using GOTOs and line numbers. It would have the advantage of being easy to > see all in one glance. > > But I want to, of course, show him a better approach and explain why it's > better. My first thought was to make a state machine, but I don't think > that'd be much better, in fact. > > Then I thought of what I would do, professionally, in a similar context: > The problem with the spaghetti code and even a state machine is that it's > static, and adding bits and pieces tends to require everything to be > massaged around the new parts. In the real world, I know that the chart's > not going to be static. > > I'd probably end up create a linked list of one-exit nodes and two-exit > nodes. > > So, that's what I'll probably show him. > > The other thing I'd do, though, is put this all in an editable text file, > like: > > 1,foundsomething,"You found something",alive > 2,alive,"Is it alive?",friend,smash > 2,friend,"Is it a friend?",lately,scary > 1,smash,"Smash it with a stick!",shiny > > But I'm wondering if this last wouldn't be too much. > > Thoughts? > _______________________________________________ > Beginners mailing list > Beginners@lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/beginners _______________________________________________ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners