2
\$\begingroup\$

I'd like to ask what sort of "roadmap" one would follow in order to be skilled enough to create such amazing work, both for games, or for UIs in general. The thing is though, my experience on other stack exchanges has taught me that questions like that are generally poorly received, and considered to be too broad/opinionated, or if more detail is provided (e.g. "I am skilled with Python", etc.) the question ends up being too asker specific for general use.

Could you help me figure out what questions I really want/need to ask given my motivations, and which one of those would be acceptable to ask on the main gamedev stack?

\$\endgroup\$
5
\$\begingroup\$

Some questions, no matter how they're asked, will never fit into the stack exchange format. A question like "What skills do I need for X?" or "What should I learn to do X?" or "What should I know before making something like X?" are just too opinion based. There's no correct answer to those questions.

Only you can decide what your requirements are and how those requirements match up to your skills and resources. If you're absolutely not sure where to begin, you'll have to do further research on your own. That research can include asking your open ended discussion questions on another site. If you look at the bottom of this help page you'll find a few sites that are available for such questions.

\$\endgroup\$
4
\$\begingroup\$

You can ask about it in chat.

\$\endgroup\$
2
\$\begingroup\$

These questions are always just masked forms of "I don't know how to make a game. Where do I start?" Because if the user did know how to make a game, he or she would know what specific questions to ask about the particular kind of game he or she wants to make. (i.e, "How do you implement X kind of collision checking?" "How do you implement X kind of AI?" or even better "I tried making feature X, but I am confused about Y")

At the very least, the user needs to have tried to make the game, but got hung up on a specific point.

\$\endgroup\$
1
\$\begingroup\$

It pretty much comes down to ordinary project methodology, which applies to everything. That is, decomposing a problem into bite size chunks, and then attacking each piece individually. Your questions here should be driven by specific problems you run into while running that course, which is the stuff we're really interested in answering.

For example, say I want to clone Scorched Earth. From the ground up:

  1. What's the most basic premise of the game? It's an artillery game, so
  2. Piece-wise, I need a launcher, a projectile, and maybe a field.
  3. I'd write the code to display that stuff.
  4. Next, mechanics-wise, I need to control the launcher and I need some basic physics for the projectile.
  5. Then I'd write the code for that.
  6. Then comes the "whee" part, where I play around with it for a while going "whee!" and making little tweaks.
  7. Rinse, repeat.

So much depends on personal preference and background, or just doesn't matter, between here and there that there's nothing interesting to say about it.

\$\endgroup\$

You must log in to answer this question.

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