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