how the code works.txt

用vb开发的RPG游戏引擎＋例子,不错,值得参考

(Turn word wrap on)


This text file will describe how the game was put together. I will put things into sections so it will be easier to understand. If you are fairly new to VB and don't understand some of this stuff by reading through it once, I suggest you read it again and again until it really soaks through. There are lots of words here I know, but if you have patients and read each sentence one by one without rushing as if your doing a book report, then I promise you will understand it. My code is fairly simple, there is minimal amounts of API, and everything was created by simple logic. The mathematics part of my code is at 2nd grade level, so don't be intimidated. I am not that smart, so my code shouldn't be complex. Also, even though I am explaining my code, if you understand how I made my "game engine", you can easily make yours by changing a few concepts of mine. So make sure you understand all this and you won't need my program even. So, just have patients.




QUESTION #1: How is the map read/drawn?
=======================================

	Before I start to explain, you need to know some basic information about the size of the tiles, how many there are, and so on. Each tile is 40x40 pixels big. There are 255 tiles per map. There are 15 tiles across and 15 tiles down. The picturebox which all this is drawn into is 600x600 pixels big, 40x15 = 600. The pictureboxes on frmTiles are ARRAYS. All the code to load the map is in the MODULE under the "newmap" section. The sprites in the game are 50x50 pixels big, but this has nothing to do with the map, but I want to clearify that. Also, the tiles are drawn with BitBlt, so if you don't understand how to work with API, then it would be a good thing to learn it before continueing with this text file.
	The maps are stored in the x#y#.map files. At the very start, the variables "mapx" and "mapy" are equal to 0. This is to load the map file "x0y0.map" on startup. As the player walks off the edge of the map, those two variables change so it will load the map that was to the side of the current map. This will be explained later on. If you open the map files up in notepad, you will notice that all it is is a bunch of numbers. There are two columns per row which looks sort of like this:

##, #
##, #
##, #
##, #
##, #
##, #
##, #
(and so on.....)

	The first set of numbers is actually the tile number that will be drawn, and this is assigned to the variable "t", and the second number, which will always be 0 or 1, contains the information if the player can walk on this tile or not, which gets assigned to the variable "w". So when the game engine reads from these files to draw the map, it reads it number by number. It will read the first number and draw the tile which equals that number. After that, it will check the next number and make the variable "walk" equal it. Remember, this is always going to be either 0 or 1, 0 meaning you can't walk on this, and 1 means you can. Then it will go down to the next row and do the same thing until all tiles have been drawn. Also, you should notice that the variable "walk" is an array from 0 to 254. This is because there are 255 tiles per map, and each "walk" will hold the information for each tile. Most of the game information is held in arrays actually. Once you understand this, most of the stuff falls into place quiet easily.
	So right now the game is drawing the tiles and storing the information on which ones you can walk on. But how does it actually now where these tiles are once they are drawn? Good question, this is where the variables "tLEFT" and "tTOP" comes into place. "tLEFT" holds the left position of the tile, sort of like picturebox.left and "tTOP" holds the top position of the tile, sort of like picturebox.top. See, it's pretty simple. Remember these variables are also ARRAYS, so there is a "tLEFT" and "tTOP" for EACH tile. You can see that this emulates an array of pictureboxes or imageboxes in a way, but it's not.
	Notice how I have so many for/next statements? Well this is for all the variables, because they are all in arrays the for/next statement will do just fine to put info into these variables.
	The variables "X" and "Y" hold the position of the TOP LEFT corner of each tile, but these are NOT arrays. "X" and "Y" will equal something else each time the for/next statement starts over. But notice this line of code:

tLEFT(land) = X
tTOP(land) = Y

	"tLEFT" and "tTOP" store the "X" and "Y" information permenantly. The "land" is the for/next statement. "X" grows by 40 each time the for/next statement rolls around. This is because each tile is 40 pixels wide, so if you enlarge "X" by 40, the next tile will be drawn exactly next to it, no space or overlaping. "Y" grows by 40 once everytime the row of tiles touch the side of the picturebox. All of this is done with these simple lines of code:

X = X + 40
If X >= 40 * 15 Then
X = 0
Y = Y + 40
End If

	See "X" grow by 40 each time the for/next statement rolls around? Well notice the next line, since there are 15 tiles across, this means I don't want "X" to be larger then 40*15. When "X" is at the position of the 15th tile, it will go back to 0, simple as that right! Yep, it sure is. Now also notice that "Y" grew by 40, this is because the tiles must be directly under the previous row. There is nothing to it once you understand this. Remember that "tLEFT" and "tTOP" are storing these numbers as things go along. Now that you know how the tiles are positioned, you should take a look at this line of code:

BitBlt(frmMain.picRefresh.hdc, X, Y, 40, 40, frmTiles.tile(t).hdc, 0, 0, SRCCOPY)

	This is what actually puts each tile in the picturebox. I'll disect this down a little to give an understanding. "frmMain.picRefresh.hdc" is the destination of where BitBlt is going to paste the tile. "X, Y" is the TOP LEFT position of the tile, so the coordinate (560, 0) is the last tile of the first row, or tile 15 of 255. "40, 40" is telling BitBlt how big the picture is, since it's 40x40 I put "40, 40", this is really simple right? Now "frmTiles.tile(t).hdc" is the source if the picture. "frmTiles" is the form which holds all the pictureboxes with the tiles in them, and I made all the pictureboxes an ARRAY. And notice that "t" is the number that was pulled from the .map files. So if "t" equaled 33, then it will go to the 33rd tile on that form and get the picture from that. "0, 0" is saying where you want to start getting the picture from? I put "0, 0" because it will start from the TOP LEFT corner, which inturn will go 40 pixels left and 40 pixels down. This is exactly the whole tile, not a part of it. "SRCCOPY" is the method of which it will paste it. In the Declarations section, you will notice there are 3 ways it can paste it, but for this method I will just plain COPY it. If you don't understand how BitBlt is working, then you should find a tutorial on it, because I didn't go into detail on how it works.
	Now the map has been drawn after the for/next statement does this steps 255 times! Things seem more complex in that procedure than it really is because I have code in there which puts enemies into place, but have nothing to do with the map actually being drawn. If the code for the enemies weren't there, the code would be half the size it is, so try to ignore that enemy code for now until you totally get how the map is created.



QUESTION #2: How does the player move?
======================================

	All the code for the player movement can be found in the picMain picturebox in the "KeyDown" section. I will be posting more code from this section, because it is a little more complex then the previous section.

If dHIT = 1 Then Exit Sub

	This is the second line of code to be found here and it is fairly simple actually. "dHIT" is the variable which contains the info if the player or AKA "Damien" (this is where the 'd' of 'dHIT' came from) gets hit. Don't worry about this for now, but all this does is stop the player from controlling when he gets hit.

If KeyCode = 32 Then
Call cast_magic_up
End If

	Ignore this code. This was when I was trying to add magic abilities to the game but I quit working on it. It was going to be a fireball that shot the direction you were looking when your pressed space. Just ignore this feature, it doesn't work.