Writing an adventure game : scientific method

[Monsieur OUXX]

I'm currently analyzing in-depth what makes Fate of Atlantis so thrilling to play.
It relies on a few things that most wouldn't notice unless they pinned them down meticulously, but are essential.

Spoiler

Non-exhaustive list of technical tricks :
- Immediately starts with exciting credits ("Indiana Jones" written in large letters, fanfare music, Indy enters screen swinging from his whip)
- Immediately starts with a small, dumbed-down adventure (simply left-click on random stuff during intro). It's action-packed because Indy keeps falling (physical, non-point'n'click action) --> after that you can make the game as much of a walking simulator as you want, the player stays under the impression that the character can do offroad physical stuff.
- Immediate mystery (mysterious small statue)
- Physical threat (Kerner points gun + fistfight)
- CHARACTERS GET INTRODUCED : you see a close-up of Indy, Sophia, and Kerner's faces in the first 5 minutes ,and later on you see Ubermann's face)

And that's only the extended intro.
Later on, more stuff is packed in the first 20 minutes :
- Supernatural threat : Sophia's neckclace shines and shows ghost
- Feeling of exploring: Sophia sets the McGuffin for you and sets several places in the world to be explored (even though they're just one-room or two-rooms locations)

[close]

Additionally to that, the "parallel" puzzles are not as parralel as they seem, and yet the player feels like he/she can travel around. The backgrounds or the 3 paths (wits path, fists path and team path) are mostly recycling the same backgrounds very cleverly.

All of that to say : I'm struggling to pack that amount of information and thrill in the first 5 minutes of our game, while keeping it to only a handful of backgrounds, and I'm having trouble "breaking" our current script to make it possible for the player to come and go between places, instead of being stuck in 100% linear "corridors" (they go in, but they can only go out when you're finished with that set of rooms).

I need advice on all that. I'm worried that this community (AGS community) might not have the expertise on these story-development questions in full-length games; there are a few geniuses or pros in the forums who are able to produce such elements by following their intuition/guts/experience, but they're busy with their own games.
Alternatively, I'm sure that some writers or screenwriters forum would be packed with people who understand the issue, but then they would not understand the point-n-click side of it.

Would you have a community to recommend where there would be people focusing primarily on the story writing, but who can understand the point-n-click aspects (parallel puzzles and such)?
I've considered joining communities of text-based adventures (e.g. the community of "Quest" -- the editor for text-based adventure).
Any advice?

[Mandle]

So, you're not so much asking our advice as you are asking where to get better advice?

[CaptainD]

It took me a while to properly learn about game flow, and much of what I learned came through the tutelage of TheBitPriest as we were developing Captain Disaster.  I consider myself a good writer, but a poor planner - this is why with my fiction I always seems to stall at getting a full novel out, but have written plenty of short stories.

From my own experience I would say that your best friend is the flow chart.  It's absolutely the best way for you to map out what puzzles relate to which locations and which puzzles are interdependent (one of the best ways of keeping the game open for exploration is to have a puzzle solution in one location lead to a clue, or an inventory item, that solves a puzzle in another location).  Of course pointing is especially important as your game gets bigger.  Flow charting also enables you to effectively plan when to open or close off (temporarily or permanently) locations so that the player is still exploring, but prevented from spending too much time in locations that are no longer relevant.

A flow chart generator I've personally found very easy to use is https://www.draw.io/.

I'm not sure how much I'm really answering your question here, but if you're not using flow charts I suspect you will find it very difficult to map out and keep track of your game flow.

[Monsieur OUXX]

EDIT : This reply was written at the same time as CaptainD's. Great tool suggestion, thanks.

I realize that I phrased my question poorly, and I made it sound like that indeed.
While writing it I drifted away from what I originally wanted to ask:

What's your take on a methodic approach to writing a game? Tools? Rules? Anything you have, apart from "I usually go for a stroll and ideas come by themselves".

[Danvzare]

I'm having trouble "breaking" our current script to make it possible for the player to come and go between places, instead of being stuck in 100% linear "corridors" (they go in, but they can only go out when you're finished with that set of rooms).

How exactly are you having trouble with that?
Just give the player multiple goals to complete, a set of locations attached to each goal, and let them wander between all of the locations.

If your script implies that things are happening in a set time schedule, such as one part of the game taking place in a castle at night when there's a full moon, while another part of the game takes place in a pyramid where someone is about to be sacrificed, just write out the full moon and have the sacrifice be indefinitely postponed. Then give the player an unlimited supply of airplane tickets.

[Snarky]

It relies on a few things that you don't notice but are essential.

Don't we?

To add to Danvzare's point, one of the neat tricks FoA uses both in the opening and later on is allowing stuff to have happened off-screen. We start in medias res, and when we get back to the office with Marcus and Kerner we find that we're continuing a meeting and conversation that took place before the game began. Later on we often find ourselves on the scene after something has happened, or just before something happens: the most obvious case being the guy frozen in the cave on Iceland.

I think this approach can be used to free the narrative from very linear chains of events. If the Iceland sequence had you trapped in the cave with Dr. Heimdall, who has to freeze to death before you can get out, you couldn't very well pop off to the Yucatan in the middle and come back later to finish up the storyline. But by putting in a break and even omitting parts, you enable non-linearity (storywise, if not puzzle-wise).

[Monsieur OUXX]

allowing stuff to have happened off-screen.

Excellent point.

@Danvzare : the reason why it's hard is because in FoA the "parallel" areas can sometimes be tiny (Azores = only one screen!!!) while feeling large.

It's hard to draw a room:

• where stuff happens, (unlike the first Iceland room that's only meant to show the landscape)
• where that stuff is at the same time non-final enough that you can leave any time (Costa: "bring me an Atlantean artifact and I'll reveal stuff) but later so crucial that it marks the literal end of a chapter (Indy: "Costa just revealed that the Lost Dialog is in Barnett! Off we go for that new McGuffin!")
• that is "complete" (gives the player an idea of the landscape set (moutains+sea+town), how the character arrived (plane in the distance), what vehicle he used (plane then car), and also depicts the set where he'll interact with the NPC (Costa's front door and small yard)) --> The Azores background shows all of that in one room and it doesn't even look artificial.

[Monsieur OUXX]

I think that I'll proceed as follows :

• do a flow chart for the very general storyline. Only to have an indicator of the number of places and the story arcs where stuff happens in parallel or sequentially. Have this flowchart validated by the project's core team. There has always been a flowchart, but it was too detailed. It should be so abstract that the names of the places don't even matter.
• Implement every room with just a black background (zero drawing) and the objects it contains (default blue cup sprite)
• Create some basic console gui where the room is described as a very short text (temporarily skips the need for descriptive hotspots too) and you can interact with the objects through command line ("pick up key"). I'll implement the basic response to the actions, using the same script as the final game (if(...) { player.GiveItem(iKey); } ). This way the scripting can actually start. This interface also tells you the exits and you can take them.
• This way you can play the entire game textually and have testers play it, while graphic designers do their thing in parallel. That allows you to measure how much time the players spent on each section, how much of the story they understand (or don't actually need to understand), etc.

Ultimately, the goal is to see if the game is well balanced.
But specifically, substituting the graphics with text, you can :
- See if the player is confused by too many locations or characters
- Predict and prototype a lot of things : number of inventory items, etc.
- Prototype different paths very quickly (fists, wit, team) and see if you have inconsistencies and softlocks. You have a better view of the many global variables needed to control the state machine of the game.
- (important for our project) NO BOTTLENECK :
   # the scripters are not blocked waiting for any piece of graphics AND same thing for the dialogs, which might be another big thing that might require a ton of rework separately.
   # graphic designers can start sketching the backgrounds roughly

[ManicMatt]

Implement every room with just a black background (zero drawing) and the objects it contains (default blue cup sprite)

That sounds like a nightmare, having everything look the same, I'd be getting confused myself. Additionally you can't predict where Indy will walk etc. In my semi inexperienced opinion, I strongly suggest you have at least makeshift objects, characters and backgrounds.

I had simple shapes or lines to have a rough room. I had unanimated silhouettes with name tags on each character. And the objects are crude drawings.

The advantages to this extend to the final art. I realised a room I designed just wouldn't work in its current planned perspective, and if I had drawn the whole room (which takes me like, a week), I'd have wasted my time.

[Danvzare]

Implement every room with just a black background (zero drawing) and the objects it contains (default blue cup sprite)

That sounds like a nightmare, having everything look the same, I'd be getting confused myself. Additionally you can't predict where Indy will walk etc. In my semi inexperienced opinion, I strongly suggest you have at least makeshift objects, characters and backgrounds.

I had simple shapes or lines to have a rough room. I had unanimated silhouettes with name tags on each character. And the objects are crude drawings.

The advantages to this extend to the final art. I realised a room I designed just wouldn't work in its current planned perspective, and if I had drawn the whole room (which takes me like, a week), I'd have wasted my time.

ManicMatt's got a point.

What you need to do is make some rough concept art and use that instead. Make a wireframe. It requires a bit more effort, but it should be easy enough for a non-artist to do. Plus it should save you some work later on, and give the artists a bit more to work with, while at the same time giving you more control over your artistic vision for the game.
Plus, it's what everyone else does. And I figure everyone else is doing that for a reason.

[ManicMatt]

Yeah, I used a free program called SketchBook. Here is one such image I created, if it helps to see what I/we mean. This image is before I made some changes, after finding I didn't like some of it when I put my character in the environment.

Now this may look like I'm really good at doing 2 point perspectives, but the program did most of the hard work, that's what makes it so damn useful!

[Monsieur OUXX]

That sounds like a nightmare

I insist on the fact that with that strategy there will be a little bit of text description. You don't even see the main character walking around. You play the game as a text adventure. the descriptive text will be very short, but stimulate your imagination so that you (temporarily) don't need a drawing.

What you need to do is make some rough concept art and use that instead.
That's what everyone does.

That's step 2. We're not "skipping" that bit, and ultimately we do "like everyone else". But we push the industrial process further, by creating an extra step : the preliminary sketch of the preliminary sketch.
I cannot stress enough that even a simple black and white wireframe is still a bottleneck. 100 wireframes take days of work. Plus it requires the "puzzle designer", "storywriter" and "director" to be the same person because the information is too raw to be shared efficiently at that point.
If you do sketches, it kind of settles your mind on the room's size and camera angle. Then it's harder to let go of what you've done (well-known cognitive issue). Plus, they distract you from the main task (story writing).  Not to mention, that's assuming that your GUI system works. We have a complex one (two available GUI systems + tap interface for mobiles) which makes it constantly broken.

Bottlenecks are our big problem. There's always a task waiting on another task, blocking contributors. We want to go industrial and push fast prototyping to the extreme.
The fact that we are a project based on contributors causes two unforeseen issues : 1) Free contributors don't wait. They have this sudden rush of creative energy, and if you wait too long they give up in the middle of the task. 2) Contributors hate to work on something if they're not sure it will be kept in the game. That's the ego kicking in, I don't blame them. As soon as they sense an hesitation on your end, they just step back 3) It's very hard to bring a new contributor up to speed, because the mass of information about the game (plot, puzzles, concepts, tools) is HUGE to absorb, and scattered all over the internal team forums. So, the less they need to start toying around, the better for them (and for their "trainer").

That said, the Sketchbook suggestion is welcomed open-heartedly. I usually use Paint.Net myself (set of black straight lines on top of a white background) + Sketchup when the scene's perspective is too risky.

[ManicMatt]

Yeah true enough, I am giving advice as a lot us would, as individual developers, not teams and some without contributers.

I'm doing everything myself, and I'm dying to compose the music but I decided to focus on each asset at a time (backgrounds, sprites, objects, music and sound.) Something a team cannot do.

Trying to do bits of everything wasn't working!

[HanaIndiana]

More on charts.... I love them. They are indispensable.
I found this article particularly good, by Ron Gilbert of Monkey Island/Maniac Mansion. Pretty sure I got this from someone else on the forums.
https://grumpygamer.com/puzzle_dependency_charts