Originally Posted by frieza

sounds like a good idea, the best idea would be to use baby steps
here's what i would suggest
1) flesh out what you have already
2) separate out the storage of data into a database
3) separate the logic of the game from the user interface using an api (local function calls)
4) create a network based interface using the api you created in step 3
5) design a basic network based client using the existing interface, re-worked to work with the network based interface.

after that, then you can wory about what kind of graphical interface another consideration later on down the road will also be user authentication for network based games, that way rule breakers can be banned from using the server.

good luck

Originally Posted by frieza

one more thought
as for client interface, a terminal interface using ncurses would probably be the easiest from a coding stand point, but least appealing to the masses these days

Originally Posted by frieza

sounds like a good idea, the best idea would be to use baby steps
here's what i would suggest
1) flesh out what you have already
2) separate out the storage of data into a database
3) separate the logic of the game from the user interface using an api (local function calls)
4) create a network based interface using the api you created in step 3
5) design a basic network based client using the existing interface, re-worked to work with the network based interface.

after that, then you can wory about what kind of graphical interface another consideration later on down the road will also be user authentication for network based games, that way rule breakers can be banned from using the server.

good luck

Originally Posted by frieza

as for graphical you will have a choice, either 2d graphics or 3d graphics, 2d will probably be easier in some ways, it all depends on what you intend, and whether you ether know how to make 3d models and skin them or not, or how good you are with 2d graphic maniuplation tools such as the GIMP

Originally Posted by SigTerm

IMO, that's overkill/not a good advice. I'd advise to keep things simple as long as possible, and add features only when they're required and program cannot be improved without adding them. If OP follows your advice, it might easily take 11 years to finish the program, as it happened with ADOM. I already saw several projects destroyed by this kind of thinking - "let's add feature X! OOOH, let's also add feature Y!!! Let's make it 3d and revolutionary!!! Let add shaders" (and a year later development team still doesn't have a single playable demo. Pathetic...).

The best advice I could give is to code as little as possible, but make sure that your code is human-readable, easy to maintain, and implements all features you need. Minimum amount of code with maximum functionality. Once you start worrying about "client-server" architechture and "multiplayer functionality" at early stages of development, you'll wander off into magical fantasy land and will spend next 50 years in total bliss writing unnecessarry obscure features that will not improve your program in any way, but will eat your development time and increase program resource usage. See YAGNI for more info. Even if you THINK you'll need something later, don't implement it now, since it is very likely that this feature will not be necesary or there will be different way to implement it. Always concentrate on current task and nothing else. Your main goal is to complete program and fix bugs. Everything else is secondary.


2D and 3D requires artists. If you don't have artists (or money to hire one), you should forget about it.

Originally Posted by SigTerm

IMO, that's overkill/not a good advice. I'd advise to keep things simple as long as possible, and add features only when they're required and program cannot be improved without adding them. If OP follows your advice, it might easily take 11 years to finish the program, as it happened with ADOM. I already saw several projects destroyed by this kind of thinking - "let's add feature X! OOOH, let's also add feature Y!!! Let's make it 3d and revolutionary!!! Let add shaders" (and a year later development team still doesn't have a single playable demo. Pathetic...).

The best advice I could give is to code as little as possible, but make sure that your code is human-readable, easy to maintain, and implements all features you need. Minimum amount of code with maximum functionality. Once you start worrying about "client-server" architechture and "multiplayer functionality" at early stages of development, you'll wander off into magical fantasy land and will spend next 50 years in total bliss writing unnecessarry obscure features that will not improve your program in any way, but will eat your development time and increase program resource usage. See YAGNI for more info. Even if you THINK you'll need something later, don't implement it now, since it is very likely that this feature will not be necesary or there will be different way to implement it. Always concentrate on current task and nothing else. Your main goal is to complete program and fix bugs. Everything else is secondary.

Originally Posted by SigTerm

2D and 3D requires artists. If you don't have artists (or money to hire one), you should forget about it.

Originally Posted by frieza

um I think you missed my point
each bullet point I listed is supposed to be a separate major release version, and yes I realise it would take years
I was simply suggesting a logical order of how things should be built onto each other as the game evolves so the op DOESN'T end up biting off more then they could proverbially chew
perhaps step 1 should have been 'have a clearly defined set of goals before starting', i've seen projects end up in development hell myself, having been involved in such a project
I said baby steps after all, not follow all my steps in one go.


well yeah, but that's why i suggested a minimal interface first, then see if the op can't get some artists, or learn some art.

Originally Posted by frieza

exactly, i was simply suggesting an order of operations where one step would build upon the previous, not a timetable or versioning scheme of any sorts

Originally Posted by frieza

very nice, i look forward to seeing what you have put together