[Tutor] spam, eggs, and my text adventure

[Kent Johnson]

david wrote:

> hello :)
> i have some questions that are more about programming in general than 
> python specifically.
> suppose, for whatever reason, you had a burning desire to write a 
> simple text adventure.
> how would you start? would you just start writing some code?

Alan G and I had a brief discussion about this recently - see the thread 
that starts here:
http://mail.python.org/pipermail/tutor/2005-November/043602.html

> i knew i wanted a room structure or object and that i wanted to be 
> able to create the rooms
> from within the game. so i thought i will keep track of rooms in a 
> dictionary and use xy coordinates
> as keys and rooms as values. and rooms can keep track of their exits 
> in a dictionary too.
> then all i would have to do is write some code to create rooms and 
> move through them.
> anyway i am stuck so please find a question in there somewhere.

So actually you didn't just start writing code, you thought about the 
objects and data structures you might need to use to solve the problem 
before you started writing code. That's pretty much what I do too.

For simple scripts incremental development can work well - just write a 
little code, run it to see if it works, repeat. This works well if
- running the script provides immediate feedback so you know whether it 
is working or not (this is not true of your adventure game)
- the script is not likely to get big enough to require significant 
refactoring (reorganization) in its lifetime (this is hard to know when 
you start but generally it applies to one-off scripts and very simple 
utilities)

For any other kind of program, I find a test-driven approach works very 
well, especially  when I don't have a good understanding of the problem 
or how to solve it. I think of a small part of the problem that I 
understand, write a test for the code that will solve it, and run the 
test. Of course the test fails, I haven't written the code yet! So I 
write the code to make the test pass. Frequently reassess whether the 
code I have written is the best code I could write to solve the problem 
*as I currently understand it* as expressed in the current tests. Repeat 
until done.

James Shore recently described this process well in his blog:
http://www.jamesshore.com/Blog/Red-Green-Refactor.html
(though I think Michael Feather's guidelines are too strict)

By the way, for anyone reading who hasn't tried TDD (test-driven 
development), I really recommend you do. For me it was a profound shift 
to a way of working that is productive and satisfying.

The constant feedback of working tests is a clear indication that I have 
accomplished something. At the end of a coding session I have great 
confidence that I have created working code - I have tested every part 
of it many times. At the end of a project, when I deliver to QA, I have 
great confidence that I have created working code - I have tested every 
part of it many times! And it's fun - the constant feedback of "yes, it 
works...yes, it works" is like having someone constantly saying, "that's 
good".

Being able to refactor without fear is priceless. Until I tried TDD I 
didn't realize how much I was programming in fear of breaking something. 
Without automated tests, it is easy to break something. Whenever I 
wanted to refactor something I had to weigh the benefits of the 
refactoring against the chance of breaking something. Now I just make 
the change and run the tests to see if I broke anything, then go and fix it.

Uncle Bob Martin has a great article that describes some of the benefits:
http://www.butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd

Kent