RPG Design Flaws: Giant Maps

As a member of the verge-rpg.com community since 1997, I’ve seen over 15 years of failed RPGs, and very, very rough demos. I intend on cataloging a list of RPG antipatterns to try and build up a set of good design principles.

The most common flaw I’ve seen, by far, is to make giant areas.

Be it because they’re using defaults in map editors (I’ve seen a few use 100×100 as the standard) or because of the common mistake that bigger is better, large areas seem to be the first, and perhaps the most critical, failing of a nascent RPG.

Big Zones Are Visually Boring

One of the two big draws in an RPG for me is Exploration. In fact, it’s my favorite part. And I love the occasional large area to explore… but any single zone of exploration that is enormous quickly gets tedious to explore.

Simply put: large, empty areas are boring, and I’ve seen hundreds of amateur RPGs that have this “feature”.

When designing a game, I find a useful guide to be to think in terms of single screens. Every distinct screen of game should have something new and interesting on it. Zelda is particularly inspirational here: each screen of Zelda had something specific and interesting to discover and explore.

Big Zones are Mentally Tedious

Even if you manage to make every screen of an area unique, you can still screw it up by putting too much stuff to explore, or too repetitive of a thing to explore.

There is a certain type of player who wants to do see everything and play with everything, and if you present too much, they’ll get bored with repetition in a single area. It’s far better to present a small, tightly curated set of “extras” so as to not overload this player archetype.

Big Zones Are Too Much Work For You

Another common plight with novice RPG creators is underestimating how much time map assets will take to create. We tend to think about time to create the tile art itself, or to script the map events together, but for some reason there seems to be this passive idea that the map assembly itself is trivially quick, as if to spring fully formed from Zeus’s head.

Nothing could be further from the truth.

Even after a decade of experience, if I have the tile art already fully completed it takes me a minimum of half a day to make a small zone.

Let’s say that a screen’s worth of tiles is 20×15 tiles in size. A six-screen zone (which is a small zone) is 40×45 in size. That’s 1800 tiles you have to lay down per layer.

There are flood fills and auto-tiling tools, but it’s still a lot of area to cover for you as the map creator. My maps often have upwards of 7 layers because I’m fond of fringe effects and translucencies, so regardless of how many affordances your tool chain has, it’s still a lot of work.

Now, let’s consider the same effort with a 100×100 map. First off, that’s a 33 screen zone, which is large. For comparison, the entire enormous overworld area of Zelda 1 was 128 screens… so our single 100×100 map is over a quarter the size of this mega-area. Now, we’re talking about laying down 10000 tiles per layer of work here. And if you’re talking about my 7-layer monster-maps, there’s 70000 tiles of possibility to cover.

This… is a lot of work for asset creation. A beautifully made map this size could easily take an experienced asset creator a week. And if you were to make a game with 20 such areas this size, you’re talking 20 weeks of map creation. Which is a lot of time when you consider that many first-time RPG makers simply overlook this entire part of the process.

Go small!

Keeping your zones small keeps your workload low, keeps your player’s engagement high, and keeps your own engagement in the creation of the game high. After all, you’re going to make a complete area quicker, and you’re going to feel good about it sooner, which feeds into a desire to make more… which becomes a virtuous cycle that leads to a completed game.

So, that’s it. Go try making a map today, and keep it small! Some of my proudest creations have been game maps, and it’s really an art that’s not very well explored.

Bigger, Better, More and the RPG curse.

When I went to GDC 2012, I talked with a lot of other indie game developers. (That’s what you do as a game developer at Game Developer Conference.) And part of the introduction dance is invariably: “So, what are you working on?”

What are you working on?

So, sheepishly, I’d admit that I was on a mission to “bring RPGs back” to the indie community, since so very few indie RPGs seemed to ship.

I said this sheepishly because I had assumed that RPGs like Final Fantasy, Phantasy Star, and Lufia were kinda a bad joke in the indie game circles since nobody seemed to talk about them.

The actual response from around half of the multitude of developers I talked to that year was some variant of “Oh, I love RPGs!” or “my first game project was an RPG!”

Followed, invariably, by “they’re impossible to make, of course. They’re too big.”

RPGs are Too Big

I believe this idea that an RPG’s value is in it’s length comes from the 90′s-kid mentality where an NES or SNES cart cost $50-80 — more than a month’s salary for a paperboy — where you want to get the most bang for your buck.

It’s no longer like that however; Adults who were kids then are low on time… and kids now don’t care about money as much, both because games are generally cheaper, and because games are generally pirateable now.

Indies do smaller better

The instinct is that RPGs must be giant, sprawling epics. You need dozens of dungeons and sidequests and hundreds of monsters, because bigger and more is always better, right?

The few indie RPGs that have been relative a commercial successes have not been giant 20-dungeon epics. Zeboyd’s games have been small and quick paced; respectful of the players time. To The Moon was a tightly packed 4 hours of emotional catharsis, and completely lacked battles! Dragon Fantasy chose a small episodic model to release regular updates of content without overwhelming people at any one time.

If these teams can succeed with smaller, more detailed, less… why does everyone think you need bigger, better, and more?

RPGs are not too big; you just need to kill your children.

A principle lesson one must learn early on in making creative works is the concept of Killing Your Children: removing entire sections of your project that you’re in love with that aren’t actually working well.

It seems to me that the “large, sprawling epic” mindset of many RPG authors is the fat, lazy child we all love… and must sacrifice. If feeding this monster countless months of effort only results in a crushing sense of despair and the resolute belief that “RPGs are impossible to make,” perhaps that fat child isn’t pulling his weight.

You don’t need a long experience to make a fun game.

If you want to make an RPG, focus on smaller, more interesting. Fun.

I know I am.

The Naval gays

(If it was not a parent already this entire blog post was done via voice to text recognition .)

( except for formatting)

several years ago my friend Timothy fritz created a blog Pact: our mission to make a blog post 1 today and or die trying.

Many of us tried and failed and died in Maryland.

But this packs had mini fridge for uses including the creation of the continues to play with movement and intermittent test and I believe my previous job!

Joe Maphis won the previous bog packed because he lasted the longest.

But now around 2 has started, and the requirements are simpler you only have to make 1 post a week!

That’s 170 obligation Ill take 1,000,000 years before the wind dies!

So I rejoined blog packed: I will make 1 post a week, and it will be super crate.

I am 10 /2/ to divide my posts maybe between RPG design and JavaScript Siri.

Sincerely,
Ben Drew

PSI think voice recognition has some ways to go

XNA and RPGs

I may have stayed up until 7am with Zeromus at some point this week working on making verge games work in XNA.

Okay, that’s a thing that actually happened. There isn’t (and won’t be) scripting conversion, but you can totally run maps and chrs and such in an xbox atm. Which is interesting.

So, there’s that.

gruedorf: toys!

Very busy lately at work. Ursa work continues apace on the other members of the team, but… as for my grudorfian contribution this week, I’ve been doing some feasibility experiments with XNA.

What, you want a screenshot? Not this week, kiddo.

API updates

Today’s gruedorf update isn’t game related! It’s pingpawn.com related!

Now you can query pingpawn for the number of quotes that match a query string. You can further filter this by quotefile.

Examples for queries of quotes containing the word taco:

http://pingpawn.com/api/count/?q=taco

http://pingpawn.com/api/count/gayo/?q=taco

http://pingpawn.com/api/count/grue/?q=taco

Exciting, no?

More Ursa work, some website maintenance…

Been working on user ui and basic testing stuff for Ursa. Not much screenshot-wise.

Also of note is bringing http://beta.verge-rpg.com/ back to life. Mainly so I can shove the code into github and do some easy maintenance on it again…

gruedorf

I wanted to post this for screenshot saturday, but going to PAX and/or drinking made me forget and lose Gruedorf for a few days.

Curses.

Anyways, check this out!

How to merge trunk conflicts safely in bzr (bazaar.canonical.com/)

Sadly, the openstack community currently uses bzr instead of git. Instead of rebasing, this is the process by which I have to deal with tree conflicts “safely”?

bzr branch lp:trunk_project merge_temp_dir
cd merge_temp_dir && bzr merge ../your_original_branch
vi path_to_the_conflicted_files #and make your merges
bzr resolved
bzr commit -m "resolving commits."
bzr push --overwrite lp~myusername/path/to/my/branch

I hate this. And I’m storing it here so I can reference it in the future.

Some Ursa Screens

Ursa continues apace. I grabbed some art from the internets and made a mockup of some discovery screen stuff (It looks better animated.)

And, in general, the spikes are looking neat! Here is something that Ustor should be posting so he doesn’t lose at gruedorf, because he got this part working: