Cheat Engine

[tony2108]

Step one: Assessing your skills

1.Know at least one programming language. So far, C++ is the most popular choice among game developers due to efficiency and performance advantages. Visual Basic, Java or C# might do the job as well.
2. Become familiar with a graphic library. Popular choices are SDL, OpenGL, or DX/D3D.
3.Choose the network library to utilize. You can chose between WinSock, SDL_net, or DirectPlay.
4. Have general experience in game programming. For example, the events loop, multithreading, GUI design, etc.
1. Client/Server communication and architecture.
2.Multiplatform programming. You might want to design your MMORPG, and especially the server such that it can run on multiple OSs. For this purpose, I recommend using SDL, OpenGL and SDL_net.
3. Web development. This will be needed if you want to enable people to view player statistics, server information, and other information on a website.
4. Security & Administration. You don't want someone to hack your server, and mess around!
5.Team skills. You will need a team that you can successfully lead and manage.

Step Two: Making a preliminary design


I have noticed many people posting in various forums looking for teams to make MMORPGs. Most of them start with something like this: "We are a starting company/game studio and we need 3 artists, 2 programmers, 1 musician, etc. for an innovative, never seen before MMORPG where you will have total freedom to do whatever you want and reshape the world, etc. We will pay you when it's done and we make some money." Unfortunately, with the current technology and limited bandwidth, you cannot have a dynamic world. Aiming at something impossible leads to failure. Rather, try to come up with a small, functional, expandable design and architecture.
First, try to focus on making a simple client/server model, where you will be able to:

1. Create a new character
2. Save that character (server side)
3. Log in with the character
4. Be able to chat with others
5. Be able to navigate around in 3D

Saving characters might seem simple, but in fact, it isn't. For example, there are two ways of saving the characters: using a database server or using files. There are advantages and disadvantages for both:

Databases Files
Advantages

* You can easily add new fields, or modify existing fields.
* Updating player statistics (from outside the game) is much easier.
* You can instantly and efficiently retrieve various statistics, via SQL queries.
*There is no need to perform file I/O operations yourself, the database server will do that for you.
* Easy to update/restore.
* Very fast access (read/write).
* Easy to implement.
* No additional libraries needed.
*No dependence on a database server. Therefore, you don't have to worry about getting database updates or security issues.


Disadvantages

* Easy to make mistakes. For example, doing an update query where you omit the 'where' clause. It can have disastrous effects, especially if you have old (or no) backups.
* Databases may be slower than actually opening/writing a player file. You might lose a few milliseconds when retrieving some data, especially if a lot of players log in/out at the same time.
* Additional code is required to convert your data to/from the database.
* Database and SQL experience is required. In addition, you will need a library to interface between your program and the database.
* If for some reason the database file becomes corrupt, you are out of luck; you can lose all the players (especially if no recent backups).
* It can be very difficult to add new fields, unless you carefully design the file format/structure from the beginning.
* Inability to do player-wide queries (this can be circumvented by having a program that adds every night the important fields in a database server).
*Needs special coding if you want to update/check player stats.
* A little bit harder to update/restore.

Now that you decided which way to go about saving your characters, you'll need to chose what network protocol to use for the client/server communication: TCP or UDP? TCP is known to be slower but more accurate, and require additional bandwidth. In practice, I didn't notice any problem using TCP. Provided that you have enough bandwidth available, TCP is a good choice, at least for the beginning. UDP can be really annoying, especially for beginners. Keep in mind that the preliminary tests of the engine or game will be done in your local network, so all the packets will arrive to the destination in the same order. This can't be guaranteed over the Internet. While the packets will usually arrive in the same order, some packets can be lost, and this is usually a problem. Of course, you can design your protocols in way so that the client/server will be able to recover from lost packets. But this is a painful process which is not recommended for beginner.

Step Three: Choosing an internal protocol for data transmission
It might seem simple, but, again, it isn't. You can't just send strings, '\0' terminated. This is because you will need a consistent protocol, which will be able to send both strings and binary data. It is unwise to use 0 (or any other sequence) as a terminator, because that terminator can be part of the data stream you want to send. Furthermore, if you send 20 bytes, and then another 20 bytes, most likely the server will not receive a 20 bytes packet, then another 20 bytes packet. Instead, it will receive 40 bytes at once, to avoid wasting the bandwidth with unnecessary headers. Alternatively, you can send a 1KB packet, but the server will receive it in 2 smaller packets. So you will need to be able to know where a packet starts, and where it ends. In Eternal Lands, we use the following method:

* Offset 0: 1 byte denoting the command transmitted.
* Offset 1: 2 bytes, the length of the data transmitted.
* Offset 3: variable length, the body of the message.

This method has the advantage of consistency: all the data transmitted follows the same standard. The disadvantage is that some commands have a fixed, known length, so some bandwidth is wasted. We will eventually switch to a hybrid approach, at a later date.

The next thing to decide is the server model: "Non-blocking sockets, non threaded", or "blocking sockets, threaded". Both methods (threaded vs. unthreaded) have their advantages and disadvantages.

Threaded:

1. Somewhat smoother response from the server, since if a player needs a lot of time (such as reading data from the database) this is done on it's own threaded, not affecting others.
2. Very hard to debug, and implement properly: You will need a lot of synchronization, and small oversights can have disastrous effects (server crashing, item duplication, etc.)
3. Makes use of multiprocessors systems.

Non-threaded:

1. Much easier to implement and debug.
2. Slower response time.

In my company, we went for the non threaded way, because I just don't have the resources and disposition to cope with the threaded.
Step Four: The Client
Do you plan to make a 2D or 3D game? Some would argue that it's easier to make a 2D game. I've done both, and I tend to believe that 3D is easier. Allow me to explain.

In 2D, you usually have a frame buffer, which is a big array of pixels. The format of those pixels can differ, from video card to video card. Some have RGB modes, other have BGR modes, etc. The number of bits for each color can differ as well. This happens only for 16bpp video modes. 8-bit and 24-bit video modes are easier, but with their problems (8-bits gives you few colors (256), while 24-bit modes are slower). Also, you will need to make your sprite routines, and you have to sort your objects yourself, so they will be drawn in the right order. Of course, you can use OpenGL or D3D for 2D games, but it's usually not worth it. Not everyone has a 3D accelerated video card, so using a 3D library for a 2D game usually gives you the disadvantages of both worlds: Not everyone will be able to play it, and you won't be able to rotate the camera, have nice shadows, and various other eye candies specific to the 3D applications.

The 3D way is, like I said, easier, but requires some basic math (especially trigonometry) knowledge. Today's graphic libraries are very powerful, and will offer you the basic operations for free (you won't need to sort your objects back to front, changing the colors and/or texture of an object is very easy, the objects will be lit according to the light and their position (as long as you calculate the normal vectors for them), and more. Furthermore, 3D gives you much more freedom of creation and movement. The disadvantages are that not everyone will be able to play your game (you might be surprised how many people don't have 3D capable cards), and pre-rendered graphics will always look better than the real-time rendered equivalent.
End of part 1

[tony2108]

I can't read your comment for some reason...

[Flyte]

Stolen from: http://www.devmaster.net/articles/building-mmorpg/

[tony2108]

rofl xD
Flyte stop that xD
I give credits all the time whenever these discoveries aren't mine O,o
you don't have to remind me they haven't been discovered by me T_T

[NINTENDO]

what other way would there be to save a character then with a database...

Most parts of the guide are good, even tho it's leeched, others are just bullshit