0
\$\begingroup\$

I'm a solo dev working on prototyping my game's movement system. My character is intended to be agile and lightweight, with quick movement options and a knack for climbing.

As we know, the key to prototyping any game mechanic is efficiency. Get the minimum viable product together ASAP so you can test, iterate, and retest until you get it right. As such, producing quality art assets in the prototyping phase is generally a big no-no.

But here's the problem: A huge part making a movement system fun comes from elements that we would sooner classify as polish. In my case, this predominantly comes from acrobatic and fluid character animations. Empirically, it would be safe to say that other polish elements like particle effects, sound, and so on would also contribute to the intrinsic fun of moving through the world.

So now, I'm caught between a rock and a hard place: I can ignore animation and focus solely on how the character feels, but lose out on "finding the fun," or I could develop animation alongside my movement system but hamper my iteration time.

Have other developers run into this problem? If so, what are some ways that you have gone about addressing it?

\$\endgroup\$

1 Answer 1

1
\$\begingroup\$

Motivation as a Resource

As a solo dev one of your single most precious resources is motivation. If adding polish to certain aspects of the game is going to increase your joy of working on the project, then I wouldn't be surprised if the personally rewarding route actually ends up simultaneously being the most efficient one.

On The Philosophy of Grey Boxing

In terms of iteration on the game design, I think it's hard to cleanly detangle the game's system design from the aesthetics of the game's theme, art and any mechanical juice or QoL you add. This de-tanglement might be easier in certain genres: say turn-based abstract strategy board games (chess?), or perhaps strategy card games (hearthstone). Nevertheless, I think in a lot of cases, especially with real-time games, grey boxing is a fundamentally flawed approach to development.

As a general philosophy I think it's impossible to iterate on design completely separately from it's aesthetics. Design and Aesthetics are in conversation with each other and this should be reflected in your dev process. This is of course if your primary concern is the experience of the player and not systems design in the abstract as a more academic endeavor (which is totally valid but is just different).

In large companies where various displines might only ever talk to eachother through leads or producers you have to cut down on two-way dependencies and construct a clear pipeline where system design, level design, art, movement physics etc. are neatly arranged. This is what must be done for the realities of production. But as a solo dev you're responsible for all of these aspects of the game anyways so this isn't an issue.

Conclusion

I would say if the movement system is core to your game and is novel, you probably should try to polish it to properly verify that it can work and feel as intended. If it's a movement system that is found in a ton of other games that you enjoy, then it's already verified that it can work and you can polish it later. In that case invest resources into unknown aspects of the prototype.

\$\endgroup\$
1
  • \$\begingroup\$ This is a very insightful answer. I never would have thought to consider the differences between between solo developing and developing in a team in this context, either. Thanks! \$\endgroup\$ Dec 25, 2021 at 0:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .