I've been dabbling with quick wireframes to explain the design of Tree Story. There are two common ways you can look at a spec.
- One is that of the blueprint, a plan that will be rigorously followed by production workers in order to achieve the end result. In this model, the team members are followers who are expected to implement a list of fixed details, not innovate.
- The other is that of a communication tool. As a communication tool, you are trying to seed key concepts in your team so that they can take ownership and run with the idea during implementation. In this model, the team members are ultimate owners of the final design and the 'designer' is more of a facilitator of the process. Any spec exists only to spark conversation so that the team can build up a shared understanding of the feature's goals.
I've found that text is rather horrible as a communication tool, especially with small teams. It takes too long to iterate on and starts bogging down as soon as there is more than one person editing the document. Even worse, text fails horribly when describing anything visual or tactile.
Instead, I'm a big believer in using storyboards augmented by multiple discussions around a whiteboard, especially for early discussions. The story boards / paper prototypes can be quite concrete, but they are still visual and tactile enough for two or three people to stand around and comment on.
The iteration process is straight forward:
- Whip up a quick storyboard. Limit yourself to spending 30 minutes to an hour on it. Make it very rough.
- Print your latest 'official' wireframe on the biggest paper you can lay your hands on,
- Tape it to a whiteboard and nab the first person you spot on your list of influencers.
- Brainstorm around the idea. The taped version acts as a starting point for the conversation and an anchor if the conversation gets lost.
- Immediately update the wireframe with the new thoughts.
- Rehang it on the wall. Ideally look for a spot with a lot of traffic.
- Rinse and repeat.
- Is easily understood in a glance.
- Is understood by multiple team members. The story board acts as quick reference to your indepth conversations.
- Is up-to-date.
- Is a conversation starter for the rest of the team. I've had the best results when my desk is positioned near where the drawings are hung and I can leap out and chat with people wandering by.
Here's a stab at some wireframes for Tree story. Sorry that we don't have a good white board built into this blog. Someone needs to fix that. :-)
The basics of communication
In Tree Story there are NPCs you can chat with. Here is how.
Picking up objects
You can also pick up objects and drop them where you desire.
Planting seeds
A special type of object is a seed. It lets you grow new platforms in the world.
Each seed creates a different type of tree. Use different sized
trees to reach different areas or grow interesting fruit.
trees to reach different areas or grow interesting fruit.
These were done in a vector drawing tool because I find wireframes use a lot of objects that are the same. I personally prefer to copy and paste instead of spending time redrawing. However, they could just as easily been done by hand. They are likely a bit more detailed than necessary, but I'm compensating for the rather low bandwidth nature of a blog.
take care
Danc.
Weather system
PS: Here are some additional wireframes that describe how a sunlight and weather system might work. This could be used with Clint's idea for the weather trees and machines.
I really like how thoroughly you are thinking through the user experience for Tree Story. Thanks for sharing your thoughts.
ReplyDeleteOne thing I imagine might be a problem is the "Need room!" part. It would probably be useful to mention what action will be enabled once the condition is met. But overall, that's a cool idea.
Now I really hope someone actually makes this!
You might also want to add a "Tree Story" tag to your original Tree Story post.
Could you focus a bit on the difference you would make between experience in Casual vs Indie and Handheld vs Console approach? Do you think there should be difference? Do you have any practical examples in mind why there should be a difference and how that would affect perception?
ReplyDeleteToo many questions, not enough answers :)
First, I love the blog, and the glimpses into the process. Thanks for letting us in.
ReplyDeleteI've wondered if there isn't a way for the game-design process to, itself, be like playing a game. We carefully prepare one type of experience for the player and rely on an entirely different sort when we sit down to do design work.
Is there a way to use games to make games? A way to "play" them into existence?
Hey Danc, great stuff!
ReplyDeleteI'm personally of the opinion that it's hard to have *too* many GUI sketchups like this, especially when doing distributed development. The detail that you gave in these pictures is fantastic, and does a really excellent job of communicating what you're thinking -- well done!
I'm a bit curious as to how the train is going to work. It looks really cool, but what happens if you get separated from your inventory? (for instance, if you make a last-second jump onto a moving branch as it's growing away, and you barely get onto it before it gets out of jump range) If your inventory tries to make the same jump, they'll miss and fall. How are you picturing that case being handled?
Or are you thinking of a different mechanic for the inventory movement?
I really like the stacked queue approach to inventory -- it's quite clever and cute. :)
In addition to my questions regarding handling the physics of the train-of-items, I'm wondering how well it would scale to have a large number of items. I'm generally a packrat in games (Nethack totally feeds this in me), and I can imagine my train of seeds filling up a good portion of the board as I hoard rare seeds and try to do most everything through common ones, etc. I also am not sure that it would be very convenient to manage once the inventory got above 6-12 items -- it just seems like the interface could quickly go from "cute" to "annoying".
However, maybe we want to force things small. Just keep the inventory with a max of 3 or 4 items, and don't let them go higher than that. I could see that being a potential fix to this situation.
I think what I had imagined was quite different -- sadly it's more of a traditional model, and doesn't have the outside-the-box ingenuity that yours does. I was imagining that there was only a very limited number of object types in the world, and you would pick them up and hold them in your inventory. You could scroll through your inventory items, and have an available "active" seed that would be used when you pressed your "plant" button.
Something like this picture.
One advantage that yours has over mine is that it would then be possible to move NPCs around the board, as well as have greater flexibility with moving items of other types (such as a localized rain machine, or a portable sun lamp, or whatever).
So yeah, not sure how we'd want to do this. Either way, your sketches are invaluable for discussing things like this. :)
Thanks! This is a really good exercise. :)
--clint
I really like the idea of putting the spec up there for everyone to break down. This technique would allow you to run through several iterations of the design fairly rapidly. I think you'd also burn through a lot of paper.
ReplyDeleteAlthough I don't know how well it would work, I think it would be an interesting experiment to do as you say, only using a vector based flowchart tool (e.g. Visio) to illustrate the flow. If you had a collaborative data store, you could send out notifications when the file was updated, and allow people to mark up the file directly. Hyperlinks would allow you to cycle through pages so that you wouldn't have to encompass the entire design at once.
As I say, it would depend on the team as to whether this would work or not, and it would be less physical, but need not be less tactile.
Thoughts?
Clint:
ReplyDeleteGood comments! Love your picture. I was originally thinking of something similar but wondered if I could come up with a system that used fewer buttons. I love eradicating buttons from a design. :-)
Limited inventory
The inventory would need to be limited. I'm actually thinking that might be a good design choice since it causes the player to constantly wander around their tree picking items up and moving them to desired locations.
If items that you planted are constantly growing and fruit is appearing and people are giving you gifts and new quests, we can make the journeys back and forth across your little land quite interesting.
Train mechanics:
Oh, there are lots of ways of doing this! :-) You can split them up into
- AI-based 'get close to the user'
- Recording the user movements.
The simplest will be a recording method since there aren't a lot of AI routines that are used in this game for the most part.
- Record the actions (such as movement and jumping) that the player makes along with a timestamp.
- Apply those same actions to the seeds delayed by some time offset.
- Always ensure that later followers are X time units of actions behind the leaders.
- Stop the clock if the player stops.
The nice thing about this model is that if the player makes the jump, the followers will make the jump.
If you do an 'action' based model than you get nice results where characters won't get hung up in mid-air if the player stops when they are leaping. :-)
take care
Danc.
Hey Danc!
ReplyDeleteThat's a good point about the fewer buttons -- ideally, it seems like your interface could be controlled entirely through an NES controller. I really do like that. :)
As far as the train mechanics -- I was trying to communicate that I think that the "Recording the user movements" is certainly the easiest, but particularly because we have the potential for growing/moving platforms, that it can break down.
For reference, check out this picture that I whipped up to illustrate one potential missed case.
Basically, if the player (blue) is jumping onto a platform that's moving away (green), then something that lags behind him by a second isn't necessarily going to make the jump, particularly if it can only be made within a narrow time window.
However, maybe we should just do a similar thing to Sonic & Tails in this regard -- IIRC, if Tails ever missed a jump that Sonic made, then the game would detect that Tails got too far away, and it would just have him reappear above Sonic and drop down onto whatever Sonic was standing on.
How did all of this work in Donkey Kong Country with Diddy and Donkey? Could they ever get separated? I'm trying to remember...
This is a very interesting approach to design documentation. Has anyone used this method on a published project, and if so, what were the results?
ReplyDeleteIf oft-cited "Rapid Prototyping" is the merger of design and programming to make playable "design docs", then I see Storyboarding as the merger of design and art to make viewable docs. One wonders if the two could be combined.
The only caveat I see here is that you do need someone with artistic skills. Not that the panels have to be highly detailed, but they should be expressive -- and drawing expressively (even if only in stick figures in MS Paint) is a skill that not all of us designers have mastered :)
@HanClinto; even without moving platforms it could happen that the "objects" following the player will fall down. For example the player jumps on to a higher platform and then does nothing. Because the following object is not standing on the same position as the player, the object will propably make a jump too but won't get onto the platform and therefor be stuck on the lower platform.
ReplyDeleteIIRC diddy kong get's never seperated from Donkey Kong, because he will make "double" jump if he falls down to come back. So in basic it's the same idea as Sonic... it's also the best way I think if you don't want your characters not hanging somewhere in mid-air :)
I really hope that this ends up getting made as it looks fantastic. As a solution for the seeds missing jumps and such, perhaps have them "ride" on the players back. This way, not only do they travel with you, they also would 'stack' allowing for visual evolution of the player as well. I'm also thinking that after a while, navigating all of the tree-platforms could get bothersome, so perhaps a quicker form of transportation could be used, i.e. some kind of teleporter you could set up, or a bee you could ride or something. I dunno, these are just my two cents.
ReplyDelete-REZ
Just thought I'd let you know I like your concept for Tree Story and I've implemented a prototype at http://nebupookins.net/programs/TreeStory.php. After some play testing, some people were a bit uncomfortable with the "jump straight out of the normal, but gravity points down" controls, so I'll need to think of a way to make these controls more intuitive.
ReplyDelete