So, I really want to design code, but I am finding that I am not having enough requirements to actually know what I need to design. I know I want to make a puzzle, but how does one imitate the physical world? My solution has been to study it.
For the past two week I have been buying, playing with, shopping for, learning how to manufacture, drawing, talking about puzzles. For me requirements gathering is like an actor training for a new role by remaining in character for two weeks. Does it help? I think so. Foe example, I now know the following:
In the physical world
1) Amazon sells a wooden puzzle for about $10 USD. Good puzzles can be $30 USD, or more. This helps set pricing.
2) I personally like thicker, or taller puzzle pieces, instead of the ones with the nobs on them to hold/rotate.
3) Puzzles have to be tested for choking hazards, and labeled appropriately. For me that mean bigger shaped pieces would be beneficial. On my “board” it looks like I should have no more than six (6) pieces on the screen at once.
In the App market
4) Puzzles Apps range from free, to not more than $5 USD. Some of them are funded via ads, which are painful. Others are funded by in-app purchases. Some of the in-app purchases would be impossible from me to hide from my kid, others require good adult interaction to purchase. I want my puzzle to not be a pain for parents, but still fun for kids. This mean no adds, and the in-app purchasing needs to be convenient for parents, but not available easily for kids.
5) Puzzles range from complex animation to static images. Watching my daughters, it seems that you don’t have to animate everything, but static shapes bore them. I’m thinking of adding sound, and maybe a splash animating when piece is placed correctly. (I might to better animations with Spine later, but again I want to get the app up).
6) I need a way to vary the levels. They seem to like the A, B, C’s but their attention span will not get them through the alphabet. If you look at many of the kids movies, cartoons, or games, they have 3 chapters, 3 clues, and finish a story in 10 minutes.
7) Kids like to make the game their own. Nicole loves the idea of stickers and other free-form distractions in between solving the actual puzzles. I’m thinking of creating a shapes cut-and-paste area where she can free form “draw.”
From My Dev Research
I have pages, and blog posts started, for a number of items. The more research I do the more I am starting to believe that the simple iterative designs is going to produce the best results. For example, Nicole played with a circle colored with a blue crayon, but hated the circle that I used with her face on it. Iterations and play testing are an absolute must.
The basic set of screens that I can think I need are a
1) Landing/Welcome screen
2) Game Screen (the actual puzzle)
3) About Screen
4) Settings Screen
I am going to try to keep most things simple. I will make the Game Screen, “Level” based so that I can switch them our and/or try new puzzles. This will allow me to respond to new puzzle requests and/or modify exiting gameplay without adjust the overall architecture of the game.
Once the basic structures are in place, I’m going to do an iteration of refinement to move them from prototype screens to more refined in gameplay, graphics, and/or sound. Once I think I have a stable setup, I’ll be able consider publishing.
My eventual goal would be to be able to add user content and/or allow people to rate and vote for the levels that are most enjoyable. Eventually, I could publish groups of levels that contain common themes, gameplay or other traits (A,B,C’s / Numbers / Shape), etc.
Development Notes
I know this is a non-technical blog, but I think there is something to be said for maintaining a set of requirements. My plan is to create a simple requirements document that is updated and tested against as I go. This will allow me to practice an Agile-style development cycle, while maintaining code that has some traceability.
Since the requirements are generally few in number, this will also allow me to bring up basic software necessities such as a code repository and other standard development items. While it may seem like overkill to do so, I will be implementing a basic Quality Management System to go along with this. Why? In my opinion, test driven, development works best with user stories are mixed with requirements. Even if this is not completely true to test driven development, the general principle of testing as you are coding to requirements I have found greatly reduces overall testing time.
Next Stop… Requirements