views:

123

answers:

5

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 graphic 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.

+6  A: 

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:

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.

Vivin Paliath
I think I like this approach. Most decisions can be made in a menu/action button sort of way. All things that can be left to the design side later. At work I do a lot of SQL work, crunch numbers at the query level, let the report make it look pretty.
NA Slacker
@NA Slacker exactly. Do all the busywork and pass the data up to the view -- let the view decide what to do with it.
Vivin Paliath
Plus, if you ever want to modify to GUI, you don't need to touch the actual game executable; just write a new View or change the existing one
SimpleCoder
Honestly, I can't even begin to imagine how could the same game be played either on text-mode or on graphic-mode. We're not talking about a pc here and an handheld there, we're talking about two completely different worlds. There are so many things that can't be done in text mode, that allowing it to run there **already** gives you some constraints that are unacceptable if you plan to add some graphics later.
Lo'oris
@Lo'oris. It's easy. Think of a board-game like Monopoly. You could "draw" a simple board with ASCII characters or you could draw it with actual graphics. What is important is the state of the game being passed into the view, which should be independent of the technology used to render it (if you plan to swap the view out later).
Vivin Paliath
Sure, but as I said this places a lot of constraints on what just can't be done in ascii, and if you actually plan to do the final version using a graphic mode, you will be limited by those constraints that should no longer apply.
Lo'oris
@Lo'oris It really depends on the design of the game. If he just depends on metadata (game state) then it shouldn't be so bad. But even in this case its ok being constrained, since it's easier to add new things (when he goes to graphics) than it would be to remove things.
Vivin Paliath
A: 

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.

SimpleCoder
A: 

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.

Arian
Too optimistic to be serious.
Lo'oris
If you have any experience on that topic, please share it. I don't think it is too optimistic. If there is someone who uses a software, there is also someone who would help improving it.
Arian
A: 

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.

Fábio Batista
+1  A: 

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.

Eldad Mor
I'll keep this in mind. One benefit of doing it this way is that there will be a complete set of keyboard short-cuts defined should it ever reach a mature point with a graphical interface.
NA Slacker
Actually you don't have to necessarily do it by using keyboard shortcuts. When you make a text interface, don't try making it fancy - try making it as informative as possible, and nothing beyond that. Think about it as a debugging/test solution. It cannot really be an actual playable prototype while in text mode. Stick to the game logic, develop it, then find someone skilled with graphics programming to do the interface.
Eldad Mor