- I''m not going to use a 3d engine. Probably will be a text based game. Maybe I''ll make a 2d version of it. I''m mainly trying to make the systems that make up the mmo like how the players interact, how the battle system works, the upgrade / modification feature... that sort of thing. If I can show a game company the system i already have made then maybe i can get them to make the 3d version. I guess i''m trying to make the core server... not the client part.
- It won''t be truly multiplayer... maybe a little but it won''t be massive. That is yet another part I''m not trying to design. It''s already been done.
- I''m going to try and make it very modular. So I can add 3d engines easily, or add other new features easily. I''m already doing that with other programs i''m making.
- Basically it''s a demo of what the game could be.
Should I think smaller?
Author
I''ve read this document that was posted here. It gave me a lot of insite as to what making a game costs, as in what you need to do not how much money. Most of the things I pretty much knew already through common sense.
My one problem is that I''m currently (oh a hobby basis) designing a MMO. It would probably be considered my second game. Should I make a few other games before trying to make this one?
Before you answer that, read this about what I''m going to do:
MUDs are very feasable, and a very good learning experience.
[ Start Here ! | How To Ask Smart Questions | Recommended C++ Books | C++ FAQ Lite | Function Ptrs | CppTips Archive ]
[ Header Files | File Format Docs | LNK2001 | C++ STL Doc | STLPort | Free C++ IDE | Boost C++ Lib | MSVC6 Lib Fixes ]
[ Start Here ! | How To Ask Smart Questions | Recommended C++ Books | C++ FAQ Lite | Function Ptrs | CppTips Archive ]
[ Header Files | File Format Docs | LNK2001 | C++ STL Doc | STLPort | Free C++ IDE | Boost C++ Lib | MSVC6 Lib Fixes ]
I am on the same goal for a MMORPG, I think it's meaningless to write a few simple games to warm you up. I prefer to go directly to the implementation of the idea. Just to layer the idea carefully then build the skeleton and add flesh and blood. I simply think that learning is much faster when stick directly to the project than to write other things for practicing.
[edited by - Hawkins8 on October 20, 2003 11:17:04 PM]
[edited by - Hawkins8 on October 20, 2003 11:17:04 PM]
I think that a MUD designed for a few players will have very little in common with a true, graphical, multi-player game, IF the multi-player game allows interaction between physical entities (i e, collisions).
If the game basically treats others as non-entities, or only does collisions locally on each client (like EverQuest) then it''s a little more similar to a MUD, but the "massive" part still is a real challenge.
Regarding networking, graphics, memory management, interface design, and pretty much everything else: I would disagree with the poster stating that sticking to a single goal is better. I find that I need to know the individual components before I can figure out how to build the overall system, and it''s easier to learn each component in isolation.
If the game basically treats others as non-entities, or only does collisions locally on each client (like EverQuest) then it''s a little more similar to a MUD, but the "massive" part still is a real challenge.
Regarding networking, graphics, memory management, interface design, and pretty much everything else: I would disagree with the poster stating that sticking to a single goal is better. I find that I need to know the individual components before I can figure out how to build the overall system, and it''s easier to learn each component in isolation.
Author
well if i design it without any collision detection or with networks in mind, i could have say a few modules handle that when the time comes. The core of the server would probably assume everything sent to it was valid and allowable. No client will have access to the core so this should be safe. There will be an outer layer that handles anything from verifying that the player was in the spot he should have been, ie. no cheating, to everything else.
quote:Original post by trapdoor
well if i design it without any collision detection or with networks in mind, i could have say a few modules handle that when the time comes. The core of the server would probably assume everything sent to it was valid and allowable. No client will have access to the core so this should be safe. There will be an outer layer that handles anything from verifying that the player was in the spot he should have been, ie. no cheating, to everything else.
To a certain extent, i totally agree with the previous poster on that you need to bear in mind all the elements required for a MMO. I myself will model a simple local client/server first, say using DirectPlay, then a simple client, say, using DirectInput. The client does nothing more than just to send commands back and forth to initiate and respond to the various server codes. Only then I will concentrate on the server core coding.
Else, u cant simulate the multi-player scene interactively.
In my own project, i've already done the localhost/client part. i am actual taking another approach than yours. I am now learning the 3D graphic coding in the client side.
While the server is doing nothing but to write the received and sent commands to the console.[edited by - Hawkins8 on October 20, 2003 12:30:56 AM]
[edited by - Hawkins8 on October 20, 2003 12:33:00 AM]
quote:
if i design it without any collision detection or with networks in mind, i could have say a few modules handle that when the time comes
My advice is that this is not true. You may of course do something else, and I hope you succeed! But, I think you''d increase your chance of success by carefully determine what you''ll build, and then build it, without thinking that you can bolt on additional core concepts on the side. You''ll be sad once you try to do that bolting-on.
You can''t design a system to feature things that it''s not doing, because the design will be entirely un-tested. You need working test cases that get excercised regularly to make sure that your design is solid, and that the implementation doesn''t break.
quote:My advice is that this is not true. You may of course do something else, and I hope you succeed! But, I think you'd increase your chance of success by carefully determine what you'll build, and then build it, without thinking that you can bolt on additional core concepts on the side. You'll be sad once you try to do that bolting-on.I totally agree. I know a lot of people find it boring, but I've been programming my entire (2D) engine, with just a console window as output. I have my manager print lists of objects, and other variables to the screen, but that's it. For complicated pieces, I build them separately, and then try to add them on after I've tested them. I find that if I try and build the program immediately, I will suffer from the "bolt on" problem the AP described, become disinterested, and stop the project. I think all products more advanced than say, Pong, should be planned out to SOME extent. The only time I show any graphics is to verify that my render functions work correctly.
You can't design a system to feature things that it's not doing, because the design will be entirely un-tested. You need working test cases that get excercised regularly to make sure that your design is solid, and that the implementation doesn't break.
[edited by - Peon on October 21, 2003 3:02:55 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
