Wrong order of doing things.

Just curious.

The traditional workflow for gamedev is to prototype with moving cubes, polish the gameplay, then improve visuals.

Would you consider doing things in opposite way?

I.e. start with a detailed visual scene, then start adding gameplay mechanics to it.

 

Possibly. I remember watching one of the Bethesda talks at GDC and one of the things they mentioned about their workflow was that they don't prototype their dungeons in the sense most people think of. Instead they draw out a basic flowchart representing the choices you can make in it and then just start building it.

If I were making an open world game with that approach I could see myself starting to build the world before I get too far with the gameplay simply because the games are iterative over their past games rather than built from the ground up with each new title.

 

Absolutely I would, especially if the mechanics are fairly generic in nature.

For example if you're creating the ever-popular survival/crafting game, all of the basics mechanics are going to be relatively common - inventory manipulation, crafting recipes, hunger and thirst management, etc... These things don't differ that much from game to game and in many cases would be relatively trivial to code (though there would be lots of tweaking and tuning later.)

So really what sets that type of game apart from others in the genre is the setting/atmosphere.

For example, one of my favorite games is The Long Dark. What sets it apart from any other similar "walking simulator with survival" is the "feeling" of it, and the atmosphere, the setting, the way the world is.

Similarly another one of my favorite games is Stranded Deep and in many ways you can almost see how certain things feel almost "copied" from a generic prototype of the genre. In fact sometimes I've found myself thinking of it as "The Long Dark, but on the beach" (and I mean that as a compliment.)

So in my opinion if the visual "feel" of the world is important to making it fun, and the mechanics are basically run-of-the-mill game mechanics, then it makes sense to get the world right first. Make a world/setting that makes the player want to see what's in the world and what they can do with it.

 

I would too. I once prototyped a game with cubes, and the player movement felt 'wrong' when converted to a detailed Sprite. There was something about the scale of the world visually that impacted how the player felt. This was a physics based character, so how it moved/bounced was a main part of the game.

 

The larger environment might be very important. It also might not be a hard problem. Ie it's a lot of time but it's quantifiable and lower risk. Gameplay is always a hard problem.

You solve your unknowns/hard problems first. Big studios can afford to move forward on multiple fronts. Indies not so much.

As gameplay evolves it will force development of other stuff naturally and fairly quickly. Because it's a total experience and often largely based on feel. Combat you really need good animations/effects to know if you nailed it, for example.

So letting gameplay drive development is the best overall approach anyone has come up with.

 

I've done this, and think it works fine. Though I find it more satisfying when adding detailed visuals to immediately see them in action instead of a cool looking static scene.

 

Yeah, I've done this a few times. Works well enough if you have a solid idea of where you're going with it. One of the other things to note is that because art and content performs a role (ie: it isn't just aesthetic) you can test your mechanics, choices, player reactions, etc. in a more accurate context. Of course, having that context often comes at a high cost, so it's really about picking your battles.

 

Subnautica was like this, it was basically a visual tech demo of the underwater environment, if I remember correctly, that spawned the idea of having something almost purely based on atmosphere.

 

Being the artsy, visual person that I am, I do like to have a good visual idea of what's going on. White boxes and capsule characters just wouldn't cut it to me. Though that's not to say I want to do all the art first, then all the mechanics last.

Straddling the line seems to be a good place for small or solo developers. As in, work out the visual feel as you implement your mechanics, albeit roughly. I don't quite have most of the central mechanics of my current project implemented, but I do have a roughly modelled, rigged, and animated player character, because I'd much rather see the star of my game plodding about my test environments.

Depending on the art style, it's probably not hard to knock together some basic assets. A good 3d artist should be able to extrude a cube into something with the feeling of what it represents within a few minutes. Said models can then be refined should they be kept.

And I agree with what @angrypenguin noted as well, if you have a solid idea I imagine it's probably a better idea to see how your art style, mechanics, world, etc, all play together earlier on.

 

If you know what you're doing is right and works, so you don't intend to invent new mechanics for the thing I don't see why it wouldn't work. Probably will take a little bit of more time and maybe more expensive because you will inevitably drop some things along the way, but it's absolutely not impossible.