Exercise 36: Day 3 (Adjusted): Designing and Debugging: Learn Ruby the Hard Way: Practicum

For those who saw my "mea culpa" post yesterday, "Guilty as Charged", that would actually be "Day 2" of this project. In truth, it would be "Day 11 - 9 Days of Procrastination and Putting it of Until I Couldn't Take it Anymore", but that's nowhere near as catchy a title ;).

As a reminder, here's the original "assignment" that Zed set up for us to help us practice and get into the habit of getting these techniques under our skin.

Homework


Write a similar game to the one that I created in the last exercise (Exercise 35). It can be any kind of game you want in the same flavor. Spend a week on it making it as interesting as possible. For extra credit, use arrays, functions, and modules (remember those from Ex. 13?) as much as possible, and find as many new pieces of Ruby as you can to make the game work.


There is one catch though, write up your idea for the game first. Before you start coding you must write up a map for your game. Create the rooms, monsters, and traps that the player must go through on paper before you code.

Once you have your map, try to code it up. If you find problems with the map then adjust it and make the code match.


Again, I admit I failed at this, in the sense that I got all hung up on how I was going to map it all out and find a tool to draw it all up, etc. In short, I got lost in the thick of thin things for this, when I should have been focused on doing a little at a time. Yesterday I committed to getting the first story points into code, and demonstrated a proof of the ideas. For today, to make things a little easier to manage, I've split the individual functions into separate files (well, most of them). The main file has four functions that I'm keeping there for now. Those are the prompt, the die function, the "take a break" function (really just a place that I can direct the user to say "the ghosts are figuring out what to do with you now, and end gracefully), and the start function. So here's what it looks like right now:

And this is an example of the game output as of right now:

Personally, I find this approach to be pretty effective. Having each function that would be longer than a screen in its own file is a good way to go and see what I am doing without having to constantly scroll through a single listing and then jump back. This way, if I want to change one module, it's easy to see what changes I want to make and isolate those changes to that one location. it also helps me see patterns and makes the idea of refactoring easier to focus on. If I notice that I am repeating code in a number of places, I can determine if it would be easier to pop those repetitions out and make s single module that encapsulates those items and make a single function out of them. Case in point. I have a part of my story where, if the user does something, the character dies. Additionally, there are places in the game where the automatic action finds them falling into the basement, which is filled with water, and they drown. Mention it once, that's fine, mention it twice, well, that's an alert. Mention it three times... maybe it's better to pull the process of falling into the basement into a single function. That way, if I decide to change the behavior of what happens in the basement, I can rework one file rather than have to open a bunch of files and rework the falling into the basement process and what it actually means.

For tomorrow, I am now venturing into the house, and its' time for some new "stories". The kitchen will have a puzzle that will include a simple guessing game to continue, and then its time to explore the rest of the house and, dare I say it, more possibilities of falling into the basement, but I should find other ways to have the protagonist meet their grisly fate, too. The basement will become a boring way to die, otherwise :).