If you’re reading this, there probably aren’t very many posts yet. But don’t worry, you can be the first! Either create a new post or just reply to this one to say ‘hi’.
@ben loved the way you place importance on the No List. I have had way to many bad experiences in development without it. Making people stop and think about what they cant have always seems to place the focus in the right spot on the things that they need.
There are a couple of benefits to performing that exercise:
- You define what you wont do and not spend time on thinking about.
- You know what to do and plan.
All skills of an Agile Samurai. I tend to use mind mapping software to layout rough ideas and then work into lists etc from there.
Now chant “Act in haste and repent at leisure: Code too soon and debug forever”
3 Likes
Here’s the simple GDD I wrote for Bulls and Cows. I liked thinking of the requirements as a breakdown of the “problems solved.”
Goal
The goal of Cows and Bulls is to give the player a simple word puzzle. A word will be represented with underscores (representing letters), and spaces (for multiple words). The player will enter a guess, and the game will respond with cows and bulls.
Problems Solved
I want the player to be challenged with a word puzzle as a callback to childhood games.
Requirements
Console display will reveal a blank word puzzle represented with underscores (representing letters), spaces (for multiple words), and special grammar such as hyphens and apostrophes.
Input mode will be plain text in the console.
Input must match the number of characters and spaces as indicated by the puzzle.
Input must be only alphabetical, or characters (spaces, hyphens, etc.) to match the puzzle. No numbers will be accepted.
Any special characters (space, apostrophe, hyphen, etc.) will be provided by the puzzle. Those same characters must be present in the input answer.
Output will be plain text printed in the console.
If the guess is invalid, print out reason.
- “Guess is too short!”
- “Guess is too long!”
- “Don’t use numbers!”
- “Spaces don’t match!”
- “Hyphens don’t match!”
- “Apostrophes don’t match!”
If no cows or bulls, print “Miss!”
If any cows or any bulls, print out the number of each. Ex: “Cows x3” and “Bulls x1”
If the guess is correct, randomly choose to print out “BULLSEYE!” or “COWABUNGA!”.
When the game is over, print out the number of guesses that were used, and prompt the player if they want to play again.
NO List
Game will not save the score.
Game will not allow user to create their own puzzle.
1 Like
Thanks for the feedback
Well, this is a little bullet I did based in the requirement part
- Input: Keyboard
- Output: System console
- Check the key pressed
- Check if is a bull or a cow
- Show the result of the last one
I’m in the middle of Section 2 Lesson 11 and had to say, “whoa, heavy-duty stuff” on the planning bits.
It’s odd to have this, coding standards, Code Complete, and such in a place where C++ is being offered for beginners.
I have two conflicting responses. First, I think it is a very good idea to have the importance of this introduced, and how to accomplish this without leaving people completely behind is intriguing. We are addressing design, engineering and system-level aspects here and some awareness is great to develop. There has to be a connection with learning by doing and maybe this is the way.
My second response is that having this come after the suggestion that experienced developers skip to the next Section is perhaps not quite properly placed. It will lead to some dissonance later, if not already. Something else to think about.
I should explain that I always go through the optional bits of this kind. I want to know what is taught and what can be counted on that we all have as a foundation for understanding in later work. (When I was a project lead, I always took the in-company methodology courses provided by consultants.)
It is also a good way to keep my beginner’s mind sharp 
.
Hi Keyshooter.
It has been some time since your post so you’ve probably moved on.
I may be missing the context and I have a question.
I am wondering how much requirements focus on “what” is desired but not on “how” it is to be accomplished. Perhaps it is not possible to separate the two completely. Or perhaps there are constraints along with the “what” such as keyboard input and console display.
Do you have any thoughts about that as you have developed your GDD?
Update 2016-12-18T18:14Z: I raised this question without having got to the place where the Requirements are described. I misunderstood, using a sense of Requirements that I was already accustomed to. I think this remains an useful question. I must recalibrate my own understanding about different sorts of requirements in honoring the GDD assignment.
1 Like
Wow, David.
I missed your post in my earlier look at this Community topic.
Right now I am at the pause where we are expected to take a try at requirements.
I am thinking of a much simpler one-word version that sticks to the definition of “isogram” in which no letters are repeated. So I am going to make it a one-word deal. At least in a first effort.
I am also wondering about the limitation of the number of guesses and its relationship, if any, to word size.
Having never seen this game played, I don’t quite know how well the BULL and COW output should be qualified, if at all, and how that can be used by the player to narrow the search for a solution. I like the MISS! output, which is the most informative of all, in my view.
Having said that, I think I would show the progress a different way. For
example, with a row of “*” of the length of the word. For a bull, I would show it in correct place in the word. For a cow, I would show a ? in the place of the cow in the input.
That might not be so challenging but I think I want the game to be encouraging and also playable by youngsters. So I will feed that back
into the (higher-level) requirements.
One last thought, while you have me thinking about it. This console game looks like one we could have the computer play against, sort of like one program playing another. It would be interesting to see what a winning strategy would be. I think the human advantage would be our recognition of known words and patterns, so long as the game always uses correct words. Hmm, so the language of the words needs to be specified in our requirements/constraints as well. That’s way beyond extra-credit, but it might give us some ideas about what the limit on the number of tries could be.
Thanks for all of your thought-provoking ideas.
One more thought and I will get on with the GDD work.
On “The Problem” I had to stop and think. Even about the word “problem” but I will let that go to the end.
I started with “I want a mental challenge” and I think we mean that from the player’s perspective, not the developer’s. Though it could be both, aye ?
Then I thought then, OK, the purpose for developing the game is “Provide a mental challenge for the player.”
That is from the game developer/producer perspective and raises the question, how do we know we have accomplished that?
So then some qualification might be provided. How do we know that the player’s itch for a mental challenge (and success, enjoyment) has been satisfied by the itch we satisfy in providing that?
I suppose that is why play-testing is important in the game world. Or, these days, throw a first-version app into the store and see who likes it.
Something I want to think about as we go forward.
About Problems Versus Opportunities
A few years ago I began to think that thinking of programs as solving problems is a mistake. It is certainly a problem-solving operation for the programmer. But what I think programs mostly do is satisfy/provide/serve opportunities. Think about the number of very innovative programs/devices that created opportunities that were not seen as missing until the innovation occurred. (The computer spreadsheet is perhaps the most outstanding example, and now we wouldn’t know how to work without them. There are many more examples.)
Users may have problems that they hope some computer software can help alleviate. I have come to think of the computer program as an instrument for the user, not as the solution. Maybe this is just another way of looking at the same thing. It might have one appraise requirements and assessment of suitability of the software in a more powerful way, though. Think about fitness-for-purpose in providing an opportunity in the world of the (intended) user.
PS: I did some research to see how problem-solving got into our language in the way it seems to be applied to computer programs and their programming. I think it goes back to mathematical instruction and the setting of problems. I found a 1950s paper Grace Hopper sent me (for a different reason) where she used the expression in describing how digital computers function (at a high level).
1 Like
Hi guys - found an interesting site for the book Code Complete. May be helpful for those who want to supplement the book and the course.
I love Code Complete 
1 Like
I know your post was some time ago, but I felt very compelled to reply. Thank you for your clearly stated post. While I am interested in making video games for fun, my real intention is to use my knowledge from the this course to create games/applications/tools for academia. Not just tools that my colleagues can use to work more efficiently around the office, but tools that they can use to teach more effectively. I think the re-framing you did with the concept is very helpful.