Worldbuilding before game design before programming, or the other way around?

Started by
7 comments, last by LorenzoGatti 3 years, 7 months ago

Salutation all!

I started an umpteenth game project and with the experience I got from the years of trying and failure it is going smoothly in term of development and the 3D artist I'm working with is also progressing.

In short, this game is a somewhat comptemplative 2d side-scroller city builder with an emphasis on the villagers. The main gameplay loop being: villager skills unlock new building to build, new building allow villagers to learn new skills, that will unlock new building, etc…


We have a well defined scope of feature for a prototype, and I'm managing so far to do pretty modular stuff so it's easier to add content later. We are probably halfway to a functional prototype, but with barely any art and sound.

But I'm now wondering when should I start thinking about world building. Of course I have a vague idea and concept for the 3D artist to be able to start working on some model, and we did some reference research. But, since we want to go with something other than the classic fantasy (dwarves, human, elves, etc..) I though of starting as soon as possible on designing the entire world. It could help us figure out the design of the characters and building and also help us design the game experience as a whole.

I was curious to know how other approach this subject. Do you start with worldbuilding? Implement mechanics then worldbuild around? Use placeholder then adapt your mechanics?

Thanks for reading!

Advertisement

For a small project and team like yours , I'd design a small level and try all the mechanics in it (and this could become your game demo). Then once satisfied with the result I would then build the rest of world levels and test the mechanics in them and fix/amend/adapt where appropriate.

That's it…all the best ?

Thanks for the answer!

I should have been more precise with my wording, sorry. When I speak about worldbuilding it would be more in the narrative way. The history of the world, is there human or not, if not what other races, the past conflict, the technology level, is it a world with a lot of rain, frequent disaster, is there normal animal, or not, in short all about the context of the game.

If I'm asking this question, it is because deciding of, for example, the level of technology will greatly impact the mechanics. But if we chose to be set in medieval era, then we have to think what is the life in this world, what tool do they use, what are the practice, and so on.

In parrallel I can still continue developing, but having a better idea of the world of the game could help us orient the mechanics to implement.

But thanks again for your input!

Since these aspects (lore, mechanics, design, art) are all entangled, you need to answer a question:

What are your pressing, strong ideas that definitely should be included?

So for example, you have the prioritized idea of including cloud cities in the game. Build the world around the question why they are there, do the mechanics (rendering etc.), the design (eg. tech path to first unlocked cloud city) and the needed sound and graphics.

Or, starting from the other end, you want air strikes and anti-air measures in the (late) game. Then make your lore fit to this design element.

The point is, pick some things you want to see in the game and consider them as seeds, or starting points, or anchors. Build the rest around it. It can be really hard to come up with a background story or a plot out of the blue. Some constraints ("must fit to my anchors") are really helpful. Writers call this “fear of the blank sheet” and tricks to solve a writers block often revolve around creating some artificial constraints (or seeds). But since writing is just one aspect of your game, you can use other elements as anchors.

For what you're trying to do, think of the races and settings mechanically before nailing them down narratively. Do you want a tribe that eats more but moves more quickly? Do you want a tribe that flies? … one that burrows? How would natural disasters affect the gameplay? How would constant rain affect it? How would a large predator population affect hunting and scouting? How much of the combat do you want to be ranged? How in-depth does the combat even need to be?

Once you have the desired mechanics laid out, the resulting parameters will narrow down which settings/eras/races work for your game.
As for non-Tolkien races, an easy way to avoid those is ask, “what if [this non-monkey animal] became sentient,” and compare how that animal normally acts with what you need it to do in the game.

Is currently working on a rpg/roguelike
Dungeons Under Gannar
Devblog

I generally go in this direction: world building → plot → game design → prototype → final implementation. This isn't an absolute order, where one aspect needs to be completely finished before tackling the next, but each step logically builds on the previous step, and each new element I introduce into the game should go through all the steps.

For example, let's say that during the prototype stage I suddenly get the idea that the player should have the ability to transform into a wolf. Well, this has all kinds of implications. It affects the game design because I now need to rebalance the game and figure out how this ability works. It affects the plot because it means that the player has another tool in his toolbox to resolve plot conflicts, so previous subplots may no longer make sense. But most of all it affects the world-building, because it means that transforming into a wolf is now a thing in my world. Who else has this ability? Where does the ability come from? How does it affect society? How do people who do not have this ability defend themselves from those who do? All of these answers will then feed back into the plot and the game design. The further along the development process I am, the more difficult it becomes to deal with these changes, so it's always best to get the big ideas as early as possible.

Thanks for the answers! The difficulty I often found is that all of them are kind of interlocked, plus I often prioritize the creation of the prototype first, as if playing the game is no fun/interesting, then no matter the quality of the world building, it still won't be fun.

But as I design the game, I have some idea of world building that give me more idea to implement, but then for those world building ideas to be complete I would need to spend time on it. But why spending time on world building that will maybe not fit with the prototype, or what if the prototype is no fun?

But in the end I guess you need a little bit of everything ?

For that issue, High Concept is your friend. If you can describe the core of your game in 10 words or less, you have a metric by which you can ask, “how will this feature directly help [the core of the game]?” If the feature doesn't help that core, put it in a scrapbook for later.

Is currently working on a rpg/roguelike
Dungeons Under Gannar
Devblog

Navezof said:

If I'm asking this question, it is because deciding of, for example, the level of technology will greatly impact the mechanics.

It's the opposite: for the mechanics that are good in your city-building game and that you choose to adopt, you need to find a background (not limited to technology) that makes them plausible and coherent.

For example, suppose you want creatures that can destroy walls at close range and creatures that can make nearby trees and plants grow instantly.

You could opt for fantastic creatures and make them, respectively, rock-eating elementals and dryads, or you could opt for cute and silly gadgets and make them people bearing oversized drills or beakers of growth stimulants.

The former would be good if you, for example, have already decided on dragon attacks and other rampaging monsters as one of the main catastrophe types; the latter if the R&D aspect is very developed, making mad scientists and gadgeteers a solid starting point.

Omae Wa Mou Shindeiru

This topic is closed to new replies.

Advertisement