Should I develop my game idea in text mode first? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 10 years ago.

I recently came up with an idea for a simulation/strategy game. I've been sketching out a lot of my ideas on paper about the game mechanics as well as have a few of the basic classes and objects working. (I'm writing this in C# using XNA).

One thing that is painfully obvious to me though is that I am not a g开发者_运维问答raphic artist and trying to get anything graphical programmed right now is frustrating me. One thought that came to mind was trying to make the entire game work off the text console first. I remember spending hundreds of hours playing Zork and Hack as a kid and the majority of my game element ideas don't require real time sprite animations to work.

So my question to the community here is should I try to maintain my enthusiasm for concept by focusing on getting it to simply work in a text base mode first and then regroup on giving it a pretty graphical interface?

OR

Tackle the graphical interface hill at the same time I'm trying to flush out my idea?

During the course of writing this question I think I answered it for myself, but I would love to hear thoughts from people.

---

I think you have the right idea based on your description of the game. If you separate your concerns then you can implement a lot of the business logic first. Think of it like an MVC application. You can leave your view to be implemented later; just provide a layer that interfaces with your business logic, that your view can use.

This way it doesn't matter what your view is (text-based or graphics). You can just pass metadata up to the view, and the view will decide how to render it.

So I would say that your idea is good. Start off with the business logic and a text-based view. That way you can get your concepts and ideas fleshed out and also decide what kind of data to pass up to the view. Remember one thing though - you have to be extremely careful at this stage to not let assumptions about the view leak into your business layer. So you should code your business layer and associated interface to the view, as if you have no idea what the view is going to be. What I mean is, since you are starting with a text-based interface, don't make coding decisions that tie you to that particular implementation.

Once you have everything fleshed out, you can start learning graphics and slowly start your graphics layer.

Of course, this approach (MVC) may not work in all situations, especially when your view is time critical. For more information, take a look at these Stackoverflow questions:

• Is the MVC design pattern used in commercial computer games.
• Best practices when Designing iPhone Game with MVC
• Game framework architecture - view components or MVC

I just want to be clear that I'm not advocating an MVC pattern for your game -- I just want to emphasize separation of concern so that it is easy for you to swap your view without doing significant refactoring.

---

A game is a complicated project which can be divided into many compartments. These may be actual module (e.g., a GUI renderer or a communications manager), or they may be more theoretical or logical, such as the "game design".

While all of these parts work together - preferably in harmony - to bring out the actual game, each of them also stands by itself. As such, it is always a good direction to divide & conquer. If you are confident about your idea, then by all means go ahead and implement it in the simplest form possible, which would probably be a console application.

However, you do need to keep in mind that while you can start by developing each module separately, eventually you will need to take into account how these parts will work together. This will inherently impact your modules design. For example, you may find out that your game logic is working beautifully, but you have no way of letting the user actually doing a certain step in terms of UI. Playability is one of the most important features of a game, and your UI may even dictate some game logic. This concept contradicts the golden rule of separating the UI from the logic - but like I stated, games are complicated, and for the final product you often find yourself bending some rules. Games are different than other projects - scalability is not an issue. Maintainability is important but will be sacrificed if you need that extra CPU juice... and so on.

---

Make an UI. Keep the graphics simple (Paint) and focus on usability. Then release your game as open source and someone else will create nice graphics and a cool UI.

---

My advice: almost no software nowadays can be done single-handed.

Try to sketch out your ideas, post somewhere, find more people interested, assemble a group, and get your hands dirty.

If your idea is truly good, you'll find more team members that can fill your lack of expertise on the other areas needed.

You can try to find people on the web, starting something like an open-source project, or you can try finding an investor, that can inject money on your business and you'll be able to hire specialized people.

---

If I were you, I would create a text-based command line interface first. Then, if you decide to make an actual GUI, you can just have the GUI automate the command line game, so you don't have to write the game logic twice. Many tools will use this approach. Someone will create, for example, a command line defragmentation tool and then someone will create a GUI "wrapper" for the tool. Sort of like what Nethack did.