Making MMORPG, need a bit of help.

Started by
103 comments, last by jpetrie 15 years, 12 months ago
i am in the process of brainstorming ways to create my first computer game. i know i will be harshly critisized for not trying somthing less ambitious, so please only comment constructively. my game will have the classic client/server architecture, with collision detection, game mechanics directly handled by the server, and graphics, sound, object interpolation handled by the client. the collision detection will be 2d, as the players will not be able to jump. the gameplay will be much like knights of the old republic, or mass effect except without the manual aiming. i plan to have 2 kinds of game entities- the environment itself and objects. the environment will be static, while objects can be dynamic, and the players themselfs are in this catagory. the objects will have a 3d model, a texture mesh, and a script file that determines its behavior and any animation it might have. since i am new at this, i could use any advice you may have on this project- i plan on doing the engine all by myself while recruiting help when its time to work on the actual art and audio files (along with models). one particular point of confusion for me is how to handle object scripting. i want to make it so i dont have to release a patch to the game engine every time i add objects, and i want object script files to be seperate from the game .exe itself. maybe kind of like gary's mod for half life 2. i would prefer to use my own language for scripting, and be able to do it on notepad. any advice is much appreciated, thanks!
Advertisement
The best advice I can give you is to put that project to the side for now and work on something smaller first. I've been in your position before and I know you probably think "I really want to do this, I can do it!" -- but it's not that easy.

Just take the Tetris challenge... Surely, if you feel you can make a MMORPG, making a tetris clone shouldn't be too hard, right? Well... Make a tetris clone. Just try it! It's a great eye-opener.
Well have you created a 3D game before? Have you done a lot of networking and database work? I'm sure you've worked with a scripting language and have created scalable applications? You've worked with GUI API's (and physics engines if you need one) when working on your other 3D games I imagine?

If you have the experience to make an MMORPG, normally you don't ask about them. Or so that's normally what I've heard.

What language are you using and what platforms are you targeting. If you say those we can list of some choices you have to make. (For instance, C# with IOCP is fairly easy to set up a scalable server cluster with if you have the experience with threading and such).

If it's any consolation you're on the right track. I've created quick multiplayer engines with a one layer entity hierarchy based on a component system. Basically entities are created from smaller components. In my new engine I'm using that same system, but I've been creating my own byte code scripting language to handle the components. So scripting ideally takes over most of the tasks.

I recommend you look into engines. Making one from scratch will slow you down if you don't have a lot of engine programming already behind you.
if you are going for "dynamic" objects you are probably going to have to go with a 3 axis collision detection system because if its 3d objects still have height to them (y axis) so even if they can't jump there are 3d games typically imply 3 axis collision detect. This is even more important if its a shooting game because there would be no way to detect when some one gets a nice boom headshot in.
well to answer sarisian, i have no experience whatsoever for any of those things! ive made a basic ray tracer, but thats obviously not very useful when making realtime 3d applications. the reason my collision detection isnt 3d is because while the game will indeed be 3d, all player movement will occur on a 2d plane. it is therefore a much easier load on the engine if i forget 3d collision and stick with simpler and faster 2 collision detection. shooting wont be manually aimed by the player. itll be sort of like world of warcraft, where when you have a line of sight to an object, and are within range, you can interact with it.

i plan to build my own game engine and network system from scratch. while this may sound insane, its because i detest modern software bloat, and would like to have complete control over every aspect of my game. i want it fully optimised. im using an intel 10 c++ compilier for this, and i have an excellent understanding of complex things like pointers, dynamically allocated arrays, the stack and heap, ect. the reason i am skipping making a simple game like many suggest is because i have no patience and want to make my concept a reality as soon as possible. i have been thinking of making this game for a long time, and i am highly motivated, so im not worried about losing confidence or interest. i have also read up on nearly every advanced topic of game making. about the only thing im lacking in knowledge of is networking, and client-server interactions.
Quote:Original post by DescentPro
the reason i am skipping making a simple game like many suggest is because i have no patience and want to make my concept a reality as soon as possible. i have been thinking of making this game for a long time, and i am highly motivated, so im not worried about losing confidence or interest.
Yeah I know what you mean. I started programming 5 years ago to make an mmo and after three failed C++ engines I sat back and have been working on the components one at a time.

I know your fired up to make an mmo, so break it apart. Try to render some terrain and trees first. Then render some water. This is all client stuff to test things. That should keep you busy then you can necro this thread again. Once you understand that kind of stuff transferring the idea of separating terrain over multiple zone servers would be your next bet and will take a while I can imagine to get working correctly. Getting 1 player to walk across multiple zones is a critical part and will keep you motivated once you have something set up. Then you can add things to it.

Networking wise make the server 100% authoritative. Since MMO technology isn't widely understood (except by the people who reverse engineered or wrote the engines) then a good way to start out is to make a login server application. Then make a zone server application. (zones are smaller than you might imagine at first). A single zone server should be able to run multiple instances of zones. So you'll end up with these classes called zones which are instanced onto the server. If one server gets too CPU intensive (you time how long each zone takes to process) they communicate with the login in server which decides where to transfer the zone and a handshake system is set up and players connect to two servers and transfer data.

So you end up with a zone application and login application. From drawing out pictures of how I'm structuring mine I've figured out this is a solid way to handle it. (my engine is 2D).

So the key thing to remember is to break the project apart into manageable chunks. Physics, GUI, Networking. All of these kind of things should be unit tested outside of the main engine. Keeping them separate also makes your code a lot easier to maintain. The only thing you may run into is that your scripting or event system gets tied very tightly into your GUI and Entity system. I believe this is completely normal.

thanks alot for the advice sirisian, breaking up a project as immense as a game certainly makes alot of sense! on the topic of zonning, i think that one good server should be able to run the entire gameworld, as 2d collision detection is trivial calculation wise, and im sure the scripts for object and player interactions are likewise simple. for what information the client receives, i think the client should be given a list of object updates restricted to the visual distance and maybe line of sight distance, instead of discrete zones like many servers. this should be easy to implement if im only using one server, with all the players on the same computer.
Quote:
i have an excellent understanding of complex things like pointers, dynamically allocated arrays, the stack and heap, ect.


That's a good start, but do you know how to make a game? Some things -- like games -- are more than just the sum of their parts. Do you know how to structure your game to maintain loose coupling and allow for extensions in the future? What would the architecture for your game look like? Could you make a UML diagram to show this architecture?

Things like these you can only learn from experience - by making games.
Quote:
because i have no patience

You're going to fail. Patience and perseverance is even more important than knowledge and skill. Knowledge can be gained, skills can be learned, patience is a character trait and I've never seen anyone suddenly develop patience or perseverance. Without those two you'll very likely fail to fully complete any serious undertaking, not just insanely large ones.
well i have perseverance- when i say im going to do somthing i always do it- and i feel doing the simple game like tetris is unnecessary. tetris may go a long way to show the true difficulty of making a game, but it doesnt change the fact that im going to start this mmorpg, and id rather start immediately than do some little game i have no interest in.

as for how the game will be structure, there will of course be two different components- the client and the server. i have a full understanding of how the client will work- the main engine loop, the graphics rendering, network input/output, player input, sound output, and intelligent interpolation between incomming packets.
the server will receive input, run script for every game object, perform a collision detection and response, and output the environment info to each client, the information sent to each client determined by what objects are in clients range.

i also plan to implement VOIP instead of text communication; with the volumn diminnishing over distance, and a whisper function of some kind.

my goal for this game is to make possible a realistic economic system, with all goods and services, structures and research created by the players. the game will start with just the environments, and it will be up to the players to organise and build up a sort of virtual society. eventually players will be able to construct spacecrafts and settle different worlds, and build space stations. since im not including a true physics system (other than collision detection of course!) all this will be handled by script. in some ways its harder, due to huge number of potential objects. in other ways its easy, as all structures and locations will be player created! all the game designer has to do is create the framework, environments, objects, and let it run loose.

i also wish to have some sort of way to add objects into the game later without having to mess with the game engine itself. the concept of object scripting isnt very clear to me, so any tips would be appreciated.

This topic is closed to new replies.

Advertisement