Hey, guys. I asked this at StackExchange—but was recommended here (HELLO, I AM YOUR NEW MEMBER):

• Knowing that I'll eventually need graphics, is it ok to build a rudimentary MUD and work from that? Or is there a completely different mindset I should be taking? That is, will building a MUD first hinder me more than help me?
  
• There are a *ton* of aspects to game development (art, itemization, the logic behind every object, etc.). Is there **a)** a canonical breakdown of these things—like the scientific method of game-design? **b)** a most important one I should be working on first?
  
• While I'm open to *not* "reinventing the wheel," my being such a nublet, and the fact that I've never seen a game with the mechanics I'd like to implement, makes me hesitant to use already-existing stuff. I'd like to build what I can, then, when I'm well-versed enough, look into using something else (or improving my own!) Is this ok, or are there some things such that there's *no* reason to code myself? (I'm not looking to pump out a quick game and make cash.)
  
• I'm under the impression that "building a game from scratch using C++" means I'll be coding *everything* in C++. Is this viable—or is it more like saying "I'm going to use binary to build a program?"
  
• What's love like?

Edit: Although I'm a C++ nublet, I'm pretty proficient in Python, Java, PHP, and a few others.

Your goals and your stated level of experience don't match up. It's fine to have a longer-term goal of building an isometric action game (an "MMO" is practically-speaking unlikely, since you'll almost never have the popularity to actually achieve "massive" concurrency, even if you develop the technical acumen to build the proper infrastructure for it).

It's rather unlikely you'll be able to start by building this simple, text-based MUD, and then retroactively graft the rest of the stuff you need onto it as you increase your knowledge. Doing so even in theory requires an extremely clean, extremely high-quality separation of concerns between the appropriate subsystems of the game and you're unlikely to be able to produce that quality if you self-identify as a "C++ newb."

Instead, you should focus on making a game you believe you can make now within your skills budget, and then making successive games, increasing in complexity or adding some new aspect you've learned about. You can re-use common portions of your prior games as you build more, but don't try to make one game over this long stretch of time. It's a recipe for frustration and disaster.

Knowing that I'll eventually need graphics, is it ok to build a rudimentary MUD and work from that? Or is there a completely different mindset I should be taking? That is, will building a MUD first hinder me more than help me?

It won't hinder you; it's a good idea as it's text-based and lets you focus on other aspects of game development, making sure you have a solid grasp of those fundamentals before moving on. In fact I'd even suggest starting with something simpler that had *no* multiplayer component, especially if you haven't built such a thing before. Building even simple guess-the-number games, or Blackjack-style games, or simple old-school text adventures can teach you a lot about game development processes and a lot about your chosen language even before you add the complexity of multiplayer or graphics.

I don't think you should expect that you'll be able to bolt-on graphics after the fact.

There are a *ton* of aspects to game development (art, itemization, the logic behind every object, etc.). Is there **a)** a canonical breakdown of these things—like the scientific method of game-design? **b)** a most important one I should be working on first?

There is no "canonical method" of anything involving game design, really. You should consequently focus on the aspects of design that are most relevant to the core gameplay loop of the project you're working on (this is another reason why it's better to start out with smaller, focused projects) or the ones that interest you the most and will help hold your attention on the project when the difficult and boring aspects of the process rear their head.

While I'm open to *not* "reinventing the wheel," my being such a nublet, and the fact that I've never seen a game with the mechanics I'd like to implement, makes me hesitant to use already-existing stuff. I'd like to build what I can, then, when I'm well-versed enough, look into using something else (or improving my own!) Is this ok, or are there some things such that there's *no* reason to code myself? (I'm not looking to pump out a quick game and make cash.)

You should build the things that are critical to your game's success, and "buy" (i.e., don't build) the things that are not. Similar with your investment in your education: if you're not interesting in being a low-level graphics programmer, don't learn OpenGL or Direct3D and write your own graphics rendering framework "just because." Find an existing one and use that.

I'm under the impression that "building a game from scratch using C++" means I'll be coding *everything* in C++. Is this viable—or is it more like saying "I'm going to use binary to build a program?"

"Scratch" is a dangerous word that often doesn't end up meaning what people think it means in the context they're using it. You're always going to be relying on libraries and technology written by others, practically speaking, because that's what the language and the standard library itself is. That said, it's quite reasonable to build a game using C++ as your only programming language.

Thanks for the responses, guys. Very helpful.

I'm trying hard to separate having an end-goal, and having delusions of grandeur.

For now, I'll begin with a single-player text RPG while keeping the end-goal in mind (i.e. - There doesn't need to be 30 synonyms for "attack." Eventually, it will be a button-press.)

Another couple of questions, if you guys don't mind:

• Would it be best to go from single-player text RPG to single-player RPG w/ graphics? Or from single-player text-RPG to MUD, then to single-player graphics RPG to MO (to differentiate from MMO)? That is, at what point should I delve into the networking aspect of things?
  
• On the subject of networking, is what I learn from building a MUD transferable to an MO?

Would it be best to go from single-player text RPG to single-player RPG w/ graphics? Or from single-player text-RPG to MUD, then to single-player graphics RPG to MO (to differentiate fromMMO)? That is, at what point should I delve into the networking aspect of things?

Either option is sufficient, but I would advice the first (text to graphics) as it will introduce you to some event-based programming concepts that may help you understand real-time networking easier. Beyond that, tackle learning about networking when you feel comfortable with doing so.

On the subject of networking, is what I learn from building a MUD transferable to an MO?

Aspects of it will be, yes.