How to storyboard your panoramic adventure

I started this thread because as a process-motivated artist, I have spent all my time working on difficult landscapes and exquisite renders and in the process have lost my vision for what the point of the whole exercise was about…making a game!
I decided to get back to the story-boarding and put all my current modeling projects on hold as a way to refocus on my vision and excitement about the game process.
Are you stuck in the same way?

Making your own adventure game is a huge task. Movie and game studios (ie professionals) have long recognized the need to break the project into smaller steps required to reach the end goal, a finished game!

Many of us indie developers prefer one mode of development, whether it’s modeling, story creation, or fancy coding. But that can lead to spending a lot of time in your favorite creative activity and not moving forward. Games, just like movies, are a visual product, and the jump from a story/render/screenplay to a game/film is a huge one.

Story-boarding is an effective intermediate step to move from concept to final product.

-It allows you to quickly visualize and experiment with what your final experience should be.

-It prevents you from spending too much effort developing assets that don’t work well in the final product. This is probably the BIGGEST difference the goal-oriented game maker and the process-oriented artist.

-It quickly gets you into the ‘game’ experience and out of your favorite creative process. By getting to that game experience you energize what your real goals are and keep your focus on the big picture, so to speak.

Modern studios like Pixar have created even more steps that could be lumped into the story-boarding stage. Once they have sketched out the flow using traditional series of storyboard images, they then do a quicky version of the movie using animatics, or quick and dirty animation to move closer to pre-visualizing the active dynamic elements of the movie. Again, this allows them to carve out the final experience before spending literally millions of render CPU-hours.

Story-boarding for games vs movies:

-Movies are static in that the final product is a passive experience. The creator has complete control of what the audience sees. The flow from start to finish is a straight-forward linear experience, which is the easiest way to think.

-Games however are non-linear, at least to some degree, because they are interactive. The player’s choices, at the very least, effect where they are, what direction they are looking, etc. This make the process of story-boarding your game less clear. You need to not only provide the visuals but include some way to interact with them in a way similar to the game experience. Because the pace of the game is driven by the player, there needs to be a way to pre-experience the interaction as well as pre-visualize the visuals.

Story-boarding for Dagon:
-Dagon is a panoramic engine and that determines both how the game interacts and how the visuals will be displayed. Like a first-person shooter, any direction can be visualized. Unlike a first-person shooter, the display is not in real-time. A first person shooter can start with primitive models and voila, instant interactions to test out.
Panoramic games are different though. They are pre-rendered. Rendering can take hours to days per location.

Without actually writing code, it’s difficult to storyboard the interactive nature of the game. What CAN be done easily is a complete walkthrough, with simple clicks within each scene to move to the other scenes. Tie in some mood music and you now have a pretty good indicator of the ‘feel’ of your game.

Anyway, my approach to story-boarding is to go back to the first stages: story-> then some artistic sketches to play the role of artistic director for my scenes -> then a map of locations -> then quickly mock up the intended scenery using very primitive objects. The objects themselves might be ultra simple but attention to lighting and color are very useful to create the mood of the scene. (this is where I get trapped. It’s easy to keep embellishing those scenes endlessly…)
I can render them out super quick and line them up in a series of folders. After that I find a panoramic viewer to look at them. QuickTime VR is popular for virtual tours, which means I can line up all my locations and tie them together with simple clicks to create an entire walkthrough of my game. Other panoramic-capable engines (Pipmak is relatively easy to use) will also work for this but require more effort to include the interactions necessary to move from one location to another.

Dagon is still in early stages but once it is out of beta with basic functionality it is the obvious choice for previewing. The storyboard doesn’t need to be migrated from another application and work is not duplicated. It might even be possible (and very handy for a starting point) for someone to release a vanilla script with generic scripting that makes it easy to expand by cut and paste an entire walkthrough. But in the meantime…

The thread subject was a deliberate troll to invite discussion about how to storyboard a panoramic game such as Dagon. I don’t have the answers but I do have some ideas and approaches. I invite others to share their methods and tools to wrestle with this step in the development process.

shadowphile, you should really put this on the wiki. :slight_smile:

It was supposed to generate a discussion, but not one reply. :frowning: Weird.

I know. I personally did no storyboarding, but I still think what you wrote could be beneficial to someone else. I started with a text outline and just started laying out the scenes in Vue, then would alternate between fleshing out the story in the text document and refining the visuals in Vue.

I think the unique issue with adventure making is that it’s both a design process and a creative process. By that I describe ‘design’ as a more structured process with an end-product more clearly in mind, ie how the story play’s out, pacing and walkthrough, puzzles, clues, etc. whereas the creative process if usually more about the Muse and discovery, ie a writer’s characters “coming to life” as some point and seemly growing on their own.
Storyboarding as I described may be more appropriate for the designer, which makes sense because the script is usually worked out first.
But I can identify with the inspiration that comes from playing around with the modeling and graphics, often stumbling across something as a seed that I would never have thought up on my own. I’m not a ‘goal-driven’ type so I play around a lot, let things work out at their own pace.
Guess ‘storyboarding’ is more appropriate for those who are hard-focused on getting things finished. Seems to work for the movie industry.

You’re right, shadowphile, and I think your information and suggestions would have been beneficial to me when I was starting out and knew nothing about game creation. So stick this in the wiki. :stuck_out_tongue:

Imari, I respectfully reject your suggestion :disgust: (what a perfect emoticon!)
I think the wiki should be left to documenting the engine itself and ways to use it. My comments are more blog-like and seem to change as I evolve and talk to others. If the topic becomes hot and and seems to be converging on ‘common knowledge’, then I’ve seen other forums decide to condense it and post it in a FAQ somewhere.

This general forum (Adventure Development) is more about adventure game creation in general (hopefully without degenerating into technical discussions about Unity engine or other irrelevancies) and there is no one recommended approach to outlining a project. I want to see a discussion! :nod:

I like the way that you outlined the conventions of other media and then turned the view toward game development, shadowphile. It strikes me as a great way to present the topic for discussion and I’m surprised that more conversation didn’t arise from this.

For Prominence, we did pre-vis for a year. We created weekly builds that grew to include more and more of the game content, along with fixes/updates for the stuff that needed improvement from previous weeks.

The art in those pre-vis builds was low-poly, with simple lighting and surfacing to keep render times low. Puzzle graphics were pretty simple, too. (Sometimes hilariously so.) Audio was simple (if it was included at all) and usually came from a library.

The fact that they were weekly builds helped minimize over-investment on modeling/texturing/lighting/etc. When everything has to be in the asset folders by 4PM on Thursday, it gets a lot easier to say, “I’ll put the details in next week!”

We used those pre-vis builds to test navigation, gameplay/puzzle design, and story. Navigation and gameplay issues were generally easy to spot and revise until they felt right. Story was the hardest to “test” during pre-vis because we found it relied on a combination of things – voice, art, text, sound, atmosphere, animation, cinematics, etc. – in Prominence. I’m not sure if that would be the case for all adventures.

A lot of puzzle mechanics and feature designs came out of the pre-vis process for us, which was good. It definitely made the game better, in my opinion. But it cost us a year and we had nothing to show for it publicly because all the assets were placeholder.

MikeM: what kinds of viewers/code are you using? Custom? Dagon as it stands? Just wondering about your tools.

Kevin uses Microsoft Visual C++ 2008 Express Edition for code view. Our engine is mostly custom at this point, written in C, with roots that go back in Agustín’s direction. Since node-based, first-person adventures are generally similar in execution, I try to participate and contribute in this forum when I can even though we don’t specifically use Dagon.

Sorry for the delay in this reply!

I was a big fan of text adventures (‘IF’) back in the day and have recently been playing some again. The similarities between point and click games and IF is high: both are paced by the player, both have little or no ‘action’ sequences, both thrive on puzzles, either as in-story mini-games or as plot-driving elements. Both have node-based locations.
When Myst came out I was hooked because it felt like the first graphical game to inherit the text adventure experience.

Anyway, I was playing with a development environment called Quest,which is very graphical and requires little or no programming. You can throw together an interactive story extremely fast.

As I was quickly threading together a story it occurred to me how excellent this would be for Dagon story-boarding: fashioning the entire storyline and plot first, work out the puzzles, describe the mood and visuals and sounds. Quest in particular even allows you to add sounds and images. (and I think videos)

I think that this approach would be a good way to get the story down first. Asset creation for the Dagon engine would be more focused and prevent too much re-creation caused by changing the plot-line during development. And you’d have a text-only version of your game, if that interests you.