Quantcast
Community Discussion: Blog by SchildConstruct | SchildConstruct's ProfileDestructoid
SchildConstruct's Profile - Destructoid




Game database:   #ABCDEFGHIJKLMNOPQRSTUVWXYZ         ALL     Xbox One     PS4     360     PS3     WiiU     Wii     PC     3DS     DS     PS Vita     PSP     iOS     Android




click to hide banner header
About
C=64, PC, XBox 360, P&P
RPG, FPS, RTS, Adventure

I'm playing games since I'm 6. I'm gaming for 6 years now.
What makes playing games different from gaming? The first one is about playing, nothing more. The latter is the meta-level of playing: It is thinking and enjoying the act of playing a game, not just enjoying the game itself. In my opinion, anyway.
Badges
Following  


Every story needs a setting,a place it happens in. The nitty gritty of world building would go far beyond the scope of this post, and would warrant its own series of articles.

However, we can take a look at what I did, and why I did it, for Lakeview in Ravens in the Sky (which'll get a website soon-ish, just in case you are wondering when you can read more about it):

Scope and Setting

While the plot is turning out to be of even more epic proportions than I thought (involving pagan gods and mythology will do that to you), the game's actual setting is fairly small. It's a small town. That limits the size of the game's map, making things easier for me, and on the player, since there's a lot less stuff to remember.

The choice of scope also influences what we can introduce. For Lakeview, I decided that the town would be tourist-y, which means it has several things another town wouldn't have: A more-than-usually-active night-life, a museum or two, and of course something worth visiting.

Of course, I want to bring in Norse mythology. That means that Lakeview is built on, or close, to Viking archaeological remains, which gives me another setpiece, almost for free: a museum of what has been found. To simplify things, the caverns and museum are linked: It makes sense that settlers who lived ~900 AD would use a cavern system as a natural stronghold (Think Helm's Deep).

These remains also give me an excuse to introduce a library which can provide infodumps for players who haven't read about Norse mythology, so that they aren't completely lost, either.


Location, Location, Location

Scope and setting inform what locations I can use, and the locations I want to use influence what I need for a setting.

To keep things simple and straight forward, at least for me as author, I restrict myself to a handful of locations:

The hotel the player starts at. That gives something obvious to explore, and allows me to hand out useful things to the player, like clues to the plot, and items where it doesn't make sense that the player character starts with, but that would be sensible to have and to find.

A library to provide information, and to provide a landmark the player would logically want to visit to gather information, allowing me to deal with plot issues that need to be taken care of first.

A hospital to contrast human values and technology with the supernatural events that are taking place in Lakeview.

And last but not least, the cavern system, which provides me with my end point in the game, is a nice setting for a final showdown with the antagonist of the game, and that allows me to tie up loose ends, and to either confirm or invalidate player speculation (thanks to the museum).


Up next: Getting players where we want them to be.








It is tautological that a game is meant to be played, or every game would be like FFX. Thus, it is quite important to have a means for the player to interact with the game (It's called "interactive fiction", after all). It follows that a means of creating a game is required. Which means writing code.

I can't give you any real advice of what to pick if you want to create a game: There are far too many choices that you can make, even in a niche as small as Interactive Fiction. Personally, I use TADS 3, since I like its library and syntax. Though if you don't like C-style languages, TADS will not be your cup of tea, and if you aren't a practised coder, the code will look like gibberish to you, anyway (in that case, take a look at Inform 7).

But before you write (too much) code, you have to do your legwork: You have to know your audience, and you have to know what the story will require of you.

Knowing your audience is the easiest part: Set up a survey to find out what games your audience has played, and what they did (not) like about these games. This isn't the gospel, of course, but it gives you an idea what the player expects, and considers fun.

The difficult part is what the story demands of you.

Map out as much of the plot as you can beforehand. That gives you characters and locations to work with, and gives an idea of how much coding will be required. Don't be afraid of leaving gaps: those will fill themselves pretty quickly as your story and code develops.

Pretty much every story can be broken down into three acts: The first sets the stage and introduces the characters, the second established the conflict, and the third act resolves the conflict. That's obviously just a rough guide, but the principle holds true: Introduce one thing after the other, and then provide resolution.

Ravens in the Sky follows this structure relatively closely. Which also means that not a lot is happening at the beginning: the player explores the setting, gets a couple of clues as to what has or might be happening, until the player sets off a major event, changing what she thinks she knows about the player character in the game. But exposition is boring, so I make exposition optional, by providing items to the player that she can choose to interact with (which is most likely to happen on the first play through), while limiting the amount of infodumping, so that every thing stays digestible. I stole one of BioWare's ideas, and created something Codex like. Of course, this technique is used to build atmosphere, too.

However, you should not hide important information in exposition! Exposition is supposed to bring the player up to speed on the game's world and the story so far, and nothing else.

And while the plot influences the amount of code you have to write, the opposite is true, as well:

I wanted Ravens in the Sky set in a town, but I didn't want to code up the tens of NPCs that would have required. But towns aren't barren, so there has to be a reason the town is depopulated. This saves on work, and helps create atmosphere.

Neither do I want to do too much work outside of the town, so player movement has to be limited. Keep in mind that the reason for the limits you set doesn't necessarily have to be apparent to the player in an instant: The reason can, and should, be revealed slowly, so that it can be used to build atmosphere, and drive the plot, too. The most famous example of using limits to great effect are probably the first three Silent Hill games, where the town of Silent Hill is covered in fog, which limits the burden on the console, while creating a claustrophobic atmosphere. In Ravens in the Sky, the fog appears like a sentient being, or at least as an agent of one, confining the player to the places I want her to be in, while providing (hopefully) a good reason to stay where she is.

Next time: Worldbuilding and building worlds.








Every creative person will tell you either that ideas are worthless, or a dime a dozen. They are right. Any idea can be traced to something that has been done already, either in mythology, or ballads, maybe even stone age cave paintings.

But that doesn't matter. Rehashing an idea doesn't mean that you are retreading the same paths that Dante, Homer, Tolkien, or Gibson took. What gives an idea worth is what you do with it, and what the story is that you tell.

My head is full of ideas (Horses are unicorns in hiding, waiting for the Second Coming to reveal their true nature). Some are better than others, and those I follow up.

I'm starting a series of blog posts today, taking you on the path I am now: Creating a game from scratch.

I'll talk about ideas, research, writing, coding, testing, and coding best practices. However, don't expect any gripping screen shots. The image on top of this c-blog shows all there is to the exciting graphics there are.

Yes, I'm writing an Interactive Fiction game.

Wikipedia defines "Interactive Fiction" as

"software simulating environments in which players use text commands to control characters and influence the environment. Works in this form can be understood as literary narratives and as video games."

(From: interactive fiction)

I started with the idea of writing a Lovecraftian horror game with survival elements, where the player has to find out why they are where they are, what is going, and how to stop what's going on. Accidentally, I looked at Norse mythology, and did a bit of research. Turns out the Norse mythology will fit very well in my story.

A clichÚd piece of advice to writers is "Write what you know." However, nowadays that means "Get to know what you write about."

Turns out that Norse mythological is all kinds of weird (not reality shattering weird like the Mythos, but still weird). The high points are:

- The world was created in three "layers" (Asgard, Midgard [that's our world], and Niefelheim [the Norse underworld, of sorts] are parts of these layers)
- The Ăsir (Odin, Thor, that lot) are in a war with the j÷tunn since, well, forever.
- We are in the end times of the Norse mythology, and Midgard is stuck in the middle of all that's about to go down.

The Mythos postulates that we humans have a very limited, and fragile, conception of what reality is. Encountering the reality behind "our" reality drives humans to madness, or worse. Magic exists--Every sufficiently advanced technology is indistinguishable from magic!--and drives the user mad, since reality gets bent around the edges.

Neither idea is particularly new, and it has been done dozens of times.

But it's an excellent starting point.