I have been developing a very simple RPG which is lightweight (12KB when compiled), portable, and text based.

Recently I was thinking of a way to make it more popular, and I think that many users like GUI applications, but I wanted to keep it using a small amount of space so it could run on devices like Ben Nanonote, while still having the same speed and fun on a big gaming computer, and possible could be ported to mobile phones (It is in C to allow portability).

A reason to make it GUI based is it would allow for it to display the enemy characters specifications, like health, etc, on the side, but I am not sure if this would be such a good improvement.

So, I need opinions. What are the good points and bad points, and would it be worth getting a GUI for it? Also, I know it is a weird question to ask on a Linux forum, but if I made a GTK+ GUI or a Qt GUI, could it be run on Windows?

PS: The idea for the game is a simple command line based adventure game with about 50 enemies (3 so far) who gain power through each level of the game, and you can either play over your local area network, or against friends, or even on a main server (I will be able to host it) where it gets your level (Calculated by the average of all the variables) and pits you with people of your same level to battle through masses of enemies until you reach level 100 and you enter a big level against a single boss who can use multiple weapons. I am currently working on the single player version, but expect it to get bigger.

With a nice model-view-controller design, there's no reason you can't easily produce several ports/versions with different GUIs (both for the same platform and for differing ones, i.e text and GUI versions for Linux first).
GTK+, Qt and other widget toolkits (WxWidgets, etc) can run on Windows as well as Linux and other platforms. I believe it comes down to each toolkit as to whether you'd also need OS-specific conditions in your code to keep things nice across platforms.
You'll also need the rest of your code to be sufficiently abstracted/layered that it can easily cope with using e.g. different file access methods for different builds. Sometimes people use libraries like SDL for such abstraction.

Qt GUI. It is more flexible/powerful.

You need to define space requirements. Qt/GTK libraries take space.

Consider developing two versions - with and without gui frontend.

Qt requires C++.

It is your game, so you're the one to decide. Normally, if you're making a GUI version, people would expect to see graphical art. Do you have artists/art for you game? On other hand, there are great gui-based games that have nearly no art at all (example: Uplink). Anyway, it is your choice.

It could be compiled for windows platform.

I'd stuff it all into a library written in standard C, i.e. built as a shared library on *nix and as a DLL on Windows. I'd create an API for it (i.e. a C header) that handles all the interaction you want the user to have (via C functions); that way you can write multiple console and GUI front-ends that only handle interfacing with the user. This would also make it easy for other people to write a graphical front-end (I'm a strong believer in "if you're not going to do it, give others the means to"). To choose a GUI platform, find out where most of your users will be, i.e. Windows, KDE (=> Qt), Gnome (=> GTK+), etc. and start with that one. I've only worked with the latter 2, and of those Qt seems easier to work with; however, I also run KDE and I wouldn't install GTK+ just for a game that can be played in text mode. The opposite might be true for Gnome users.
Kevin Barry

PS Sorry about the Gnome/KDE dichotomy. It's mostly for illustrative purposes.

Thank you for your opinions, I have decided to do most things you said, as I am going to finalise the command line one and then build GUIs on top of it. Also, I am releasing the source code of each version so others can work on it. I will probably use GTK+ as SigTerm mentioned Qt only works with C++, and I think the GIMP uses GTK and that runs on KDE and Windows.

GTK+ doesn't run on KDE unless you install GTK+ separately.
Kevin Barry