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.

1) 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 will help you a lot. Start small and grow over it, since you are a beginner you probably have no real idea of how complicated creating those things actually are. Also, you can easily scale to graphics, pathfinding and many other control structures you will need to build.

2) 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?

Nope, it is not rocket science, at best you will find some design patterns and work methods that will reduce the amount of work and increase its quality.

2) 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.)

Really depends on what you are really interested in focusing your knowledge. I would say stay in middle ground by using libraries, i. e.: if you need to set the properties in the code (and understand why the properties have the given values), you are likely to be fine. If it is a tool that you just call DoItForMe() or push a button and everything works, you are unlikely to learn anything from it.

3) 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?"

Both are possible, but the first one would take you 50 years, the second will probably take a few years.

I don't want to be negative about it, the most likely prediction is that you will work on it for a few months and quit. That is not bad, as long as you learn a lot from the experience.

Many years ago I gave it a try, mostly to learn, and boy, did I learn. I learned how to serve multiple clients on a network program, how to pack data (server was on C, client on python), basics of pathfinding, A LOT about multi threaded application, a little of physics and a little of shaders.

4) What's love like?

Do something over and over again, be happy doing it and never looking back.

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.

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?

I personally would skip the text part and go straight to an event based game. There is a technique that envolves designing the game as a client-server application and running the single player game in localserver host. This would save the time do adapt the single player game to work on a client-server manner.

I would start with that (create the base client, render a fixed dungeon and moving), and evolve on player actions (attack, collect item, etc).

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

I didn't really understand the question, sorry.

If you're not in a hurry to get the program finished, consider doing an "internship" in one or more open source projects for some time.

Working in an open source project is a great way to learn coding at a bigger scale, getting experience with version control systems, issue trackers, and other tools. If you look for MMO or isometric projects, you can also get a first idea on how those things can be done. Check them out,learn from them, and decide later if you like their approach.

Last but not least, usually, there are other friendly people around that can help you with problems.