2
\$\begingroup\$

I've created a playable oblique-styled adventure game in HTML5, using Tiled for tilemapping. I have a storyline set up, and am ready to make my final draft map.

The game world will be loosely based on areas of East Asia.

The issue is, my game is more dependent on player interacting with NPCs than on locations. How do you go about designing a map? Should I throw down the loose representation of a city, and then fit my game into it?

I guess I'm not sure how you'd go about creating a meaningful map for an adventure game or of any special considerations.

While I'm looking for an objective answer, opinions can help a lot too.

\$\endgroup\$
3
  • 1
    \$\begingroup\$ Whatever suits your game? \$\endgroup\$ – JPtheK9 Jun 30 '15 at 4:46
  • 1
    \$\begingroup\$ Short ways, closely packed maps. No need to stretch anything. \$\endgroup\$ – aggsol Jun 30 '15 at 7:45
  • \$\begingroup\$ One of aspects that should be considered is time needed for character to reach each of the points of interest. Especially if you have no fast travel option or equivalent. In my opinion time spent by player should be carefully estimated and then tested with a stop-clock. \$\endgroup\$ – rostok Jun 30 '15 at 16:13
2
\$\begingroup\$

There is a reason the Thriving Ghost Town - villages represented by about 3 buildings and huge metropoles represented by about 20 - is such a common trope in games. Even a small town of realistic size would be far too large for most story-focused game concepts. You simply don't have the resources to add content to make all of it interesting, and even if you would, it would just end up distracting from your main plot. So exploring and navigating it will inevitably become tedious and boring for the player.

So you usually tightly pack all story- and gameplay-relevant locations of your game into small, densely-packed maps. Avoid adding any locations which are irrelevant to the player, except when it's for aesthetics. When you feel that such unrealistically small cities break immersion too much (usually they don't - players are quite used to this), you can hand-wave it by implying that the parts of a city the player can explore is just a very small part of it and the city is actually much larger. An interesting way to do this is by having an overview map the player can navigate on which highlights "areas of interest" the player can explore but also implies that there is quite a lot of "uninteresting" city between them they wouldn't want to explore anyway when they could, like in this example from Baldur's Gate: enter image description here

\$\endgroup\$
1
  • \$\begingroup\$ Excellent answer Phillip. This is exactly what I was looking for :) Not accepting just yet as I'd like to hear opinions of others. \$\endgroup\$ – Growler Jun 30 '15 at 13:36
0
\$\begingroup\$

There is a concept in writing called "economy". You often encounter it as part of the phrase "economy of character" or "economy of plot".

Readers have to become immersed in the story. They have to get to know each character to be able to build a relationship, to care about them to the level that you need for your story to have impact. That means you have to tell stories involving each character that show off their personality, their motivations etc.

The more characters or locations you have, the more such background you need to provide, and the longer it takes until you can start telling the actual story. This is why writers are encouraged to be economical about characters, to reduce the number of characters in the story. One way to do this is to "merge" several characters into one (which is why so many unvelievable things happen to the same person in long-running TV shows).

The same applies to your game's story, the setting, the characters. Try to have your game take place in the smallest number of locations you can. Avoid long "empty spaces" between the locations with nothing to do for the player, just because they would exist in the real world. They are just an annoyance that the player has to click past when moving back and forth between two of the important locations.

Instead, plan your few locations so they optimize gameplay. Place related locations (e.g. locations that are part of the same puzzle) near each other, or provide some kind of fast travel between them (maybe a door that unlocks only from one side), so that once they've encountered all the parts of the puzzle and can be expected to know what they have to do, they can just pop back and forth and finish the puzzle.

Also, don't be afraid to "close down" "suburbs" that are done. Many games put you in one suburb, then once you've solved all the puzzles there, open the path to the next suburb (which they make the player's goal from the start), and give them no way back. This means that each suburb is self-contained, and you don't have to worry that a player leaving an item behind in suburb A might make it impossible to solve the puzzle in suburb B, because items in one suburb do not affect those in another one.

This way, not only does it become easier for you to avoid game-breaking bugs, but it is also clear to players that they don't have to rummage through the previous suburb's locations when they can't find a solution in the current suburb.

(Which of course doesn't mean there should be only one suburb open at a time -- one of my favorite aspects of adventures is that if I am stuck in one suburb, I can go to another one and solve the puzzles there, and then go back with a fresh mind and probably solve the puzzle)

And finally, it makes it more likely that you will actually manage to finish building the game before your budget runs out. And you can always go back and add side quests once the core game is done. Build your "minimum viable product", then go back and flesh out the game with more locations if you think they add something and don't slow down the core of the game.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.