Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers DBPro Corner / [LOCKED] The Newcomers Guide To Creating First Person Shooters

Author
Message
RUCCUS
19
Years of Service
User Offline
Joined: 11th Dec 2004
Location: Canada
Posted: 6th Jul 2005 11:44 Edited at: 9th Jul 2007 16:02
Link
Work on the new FPS Tut has begun, for updates and progress reports of how the tut is coming along, along with other code resources and help, visit www.freewebs.com/ruccus.


-- Dont read this tutorial. The concepts can be overcome better with new plugins, the structure is wrong, and some of the methods dont make sense. I recommend looking up Tutorial City and finding other tutorials from there --







RUCCUS.net is currently down for construction and has not yet been decided on when it will be back up and running again. For the time being you can locate a zip file of the tutorial in the download in this message (scroll to the bottom of the post and click the red "Download" button).

Sorry for the inconvenience,
- RUC'

Quote: "
One of the most popular game genres around the world are FPS’s, or First Person Shooters. Not many people can avoid the urge to go online and blow someone’s head off, however sick that fact may be. So, since FPS’s are very popular (Halo, Half Life, Counter Strike, Battle Field, Republic Commando; just to name a few of the recent popular ones), a lot of kids (and sometimes adults) get the idea that they can make their own awesome FPS, the next CS:S or maybe Halo 3. They get so caught up in the idea of doing the game; planning it out to the last detail, and then when they reach the programming step they find it’s very hard to accomplish such a ground breaking task and give up their dreams. The forum guru’s always try to warn them about not going into such a hard task so soon but nonetheless there are very few that listen.

So, since it’s inevitable that newcomers will rush into creating an FPS, here’s a detailed walkthrough/tutorial on how to create your first FPS. By the end you’ll have:

= Completed | = Working On | = Incomplete



Shooting/Reloading
Killing Enemies
Running Around
Ammo Crates
Mouse Look
Target Reticule
Jumping
Polygonal Sliding Collision (Using Intersect Object)
Gravity
Dynamic Maps w/ Texture
Multiple Weapons
Basic A.I
Health Crates
Mission Objectives (Kill All Enemies...Kill Boss...Obtain Secret Object...etc. Simple)
FPS Engine (Map Editor) <-- Hopefully
"



Attachments

Login to view attachments
Back to top
Profile PM Email Website
RUCCUS
19
Years of Service
User Offline
Joined: 11th Dec 2004
Location: Canada
Posted: 6th Jul 2005 11:45 Edited at: 27th Jul 2005 01:52
Link
Chapter 1: Getting Prepared

Before we can start we’ll need to open up our apps, and type a few lines at the beginning. So, follow these steps:

- Open up DBP
- Create a new blank project if one hasn’t been created for you by default (File/New Project)
- Click in the empty code area
- Type the following, pressing enter each time a new line begins:



Be sure to replace the <> with your name and the date.
The ` symbol in DBP specifies a comment, whenever you use the ` whatever you type after that on that line will be skipped by the compiler, as if it weren’t there, so you can type comments to help you remember what each line does.

In addition, the rem commands can do the same. Rem can’t be used at the end of a line with code however. Use remstart and remend to define a multi-line remark so you don’t have to keep typing rem. Here’s an example of using the rem commands, don’t type this into DBP, this is just to show you what they can do:

REM This is a comment
REMSTART This is the first line of a remstart
This is a second line, this won’t be checked by the compiler since REMSTART is used
REMEND This text WILL be checked by the compiler since it’s out of the REM cycle.


Back to top
Profile PM Email Website
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 6th Jul 2005 11:46 Edited at: 6th Jul 2005 11:47
Link
<nevermind!>


"Lets migrate like bricks" - Me
Back to top
Profile PM Email
RUCCUS
19
Years of Service
User Offline
Joined: 11th Dec 2004
Location: Canada
Posted: 6th Jul 2005 11:48 Edited at: 27th Jul 2005 08:15
Link
Chapter 2: The Setup

Alright to begin we’re going to need to setup our game, this will include:
- Setting the client options
- Creating all of the needed objects for our game to start and position them accordingly
- Adding some controls to move around
- Commenting on what we’ve done throughout the process


Part I: Setting Client Options

Alright, we’re going to set things the user usually doesn’t notice while playing, things like hiding the mouse, changing the sync rate, and setting some other options.

Enter down a few times from the last line you typed, and type the following:



The SYNC command tells the screen to refresh. SYNC ON takes control of how many times the screen will refresh, allowing you to customize the speed of your game. The more SYNC’s per second, the faster the game is running.

The SYNC RATE 0 line overwrites the set amount of times the screen refreshes. You can now specify the amount of times you want the screen to refresh by changing the SYNC RATE number, setting it to 60 for example will refresh the screen 60 times per second. This is alright but some computers cant handle 60 refreshes/second, so they will lag, which is bad. So, setting SYNC RATE to 0 as we have above tells the computer to refresh as much as the computer will allow, eliminating a large amount of lag.

Finally, the HIDE MOUSE command will do exactly what it says, hide the mouse. You don’t often see the mouse while playing FPS’s, it just gets in the way and makes the game look unprofessional, so we’re hiding it.

Part II: Creating the Objects

Now that we have our system/client options set, we can start creating the object’s we’ll be using in the game. Since this game is just a basic FPS, we won’t be using any complex models, instead we’ll be using spheres for characters, boxes for static (non moving objects), and rectangular prisms for weapons.

First we’ll create our main character. Enter down a few lines and type the following:



The first line creates or MAKES a SPHERE that is of the type OBJECT. Each object must have a specific number that only that object may have, there can never be two object’s of the same number so we can distinguish what’s what.
MAKE tells the compiler we’re making something.
OBJECT tells the compiler it’s going to be an object, instead of maybe a camera, light, or other entity
SPHERE tells the compiler what object will be made, in this case a sphere or ball.
1 specifies the object number
50 specifies the diameter of the sphere

From that info the compiler will create a sphere of the specified size and number and position it at X,Y,Z coordinates 0,0,0. (X, Y, and Z are the main axis in the game. X specifies how far left or right something is, Y specifies how high or low something is, and Z specifies how close or far something is)

The second line adds more info to the object. We’re colouring it so we can distinguish it from other objects.

COLOR OBJECT tells the compiler we’re colouring...an object, duh
1 tells the compiler we’re colouring object 1, which we just made. If we had changed 1 to 2 we would get an error since object 2 doesn’t exist.
RGB(000,255,000) is a command used to easily colour things, R stands for RED, G for Green, and B for Blue. Each colour has a scale from 0 to 255. We’ve given the Green value it’s maximum amount, and the Red and Blue to their minimum, this way the object will show up being Green.

Alright, we’ve created our player. Now we’re going to create another object for an enemy, and a large box for a wall. Enter down some more and type this:



This code is pretty much the same as the code we used to make the first object. The only difference is we’re colouring it red, the object number is now 2, and we’re using the POSITION OBJECT command to position it at the given X, Y, Z coordinates. This will position it slightly to the right from the main character. Now for the wall:



We’ve now created a box instead of a sphere, boxes require more dimensions, the width, height and length. We’ve set the box to be quite wide and tall, but not very thick. And then using the POSITION OBJECT command once again we’ve positioned the box in front of us. Onto Part III

Part IV: Preparing Our Game for Testing

We want to test the game from what we’ve done so far so we’re going to add a little more code and then see what we have – and if there’s any errors.

Add the following code:



The first two lines position and point our camera to the given x, y, z coordinates. Not much else to be said here other than we didn’t specify a camera number since the default camera number is 0, so no number is needed.

The DO command is one of the most important commands in a program. This command starts the program loop, a program loop is a loop that performs a series of checks and commands every time the computer refreshes, or syncs. Every DO must end with a LOOP. The LOOP command tells the program to go back to the DO loop and run through the procedures again. Before we use the LOOP command we put the SYNC command to tell the screen to refresh, without the SYNC command in place we wouldn’t see anything happening. You should always put SYNC right before the LOOP command for maximum performance.

Inside the DO LOOP we have put some basic movement controls. Think of programming as a series of yes or no questions. We ask the computer a question with an IF statement, and if the statement is true one answer is returned, if it’s false a different one is returned.

The first movement command runs through like this:

IF the UPKEY() is pressed (making it equal 1), THEN MOVE the OBJECT numbered 1 at a rate of .5 units in the direction it’s facing.
DBP has built-in names for the main keys used for computers, things like the Arrow Keys, Spacekeys, Esc, etc. But for keys like the letters or numbers, you can use KEYSTATE() or INKEY$(), we’ll get into that later.

Remember that for each IF statement, you must either use a THEN command if you’re going to give a response on the same line, or an ENDIF command if you’re going to have a series of lines giving the response. Here’s an example of how you’d use the ENDIF command to do the same as what we’ve done above, but in more lines. Don’t type this into DBP, this is just an example:



Using this method takes more lines but can be more efficient when you have a lot of things to be done when the if statement is true, giving more organization.

The other IF statements are pretty much the same, except moving the object backwards for the DOWNKEY(), turning it right for the RIGHTKEY(), and vise versa for the LEFTKEY().

While we’re on the topic of organization, now’s a good time to introduce the colon. The colon ":" we can put multiple lines together, shortening our code greatly. It doesn’t change how the code is run through, but its good when you’re trying to keep the amount of lines smaller.

Here’s everything we have written down in DBP at the current time:



And here’s the code compressed into much less lines using the colon operator:



We can compress the code even more but it’s a good idea to keep each line to doing one task for one object.

Some extra notes to remember about using the colon:

Colons cannot be used to compress IF statements, in other words you can have two if statements on the same line. Also, the SYNC command must be on it’s own line.

Part IIII: Testing the Game

Alright, now that we’ve got a pretty good base for our game, let’s test it. Click the small button near the top of DBP that looks like a green arrow pointing to the right, with the word EXE above it. This will compile the source file we’ve just created and turn it into a machine executable or exe, so we can view it as it would run on other people’s computers.

You should be a green sphere, able to move around with the arrow keys, with a red sphere to the right and a large wall in front.

When you’re done having the time of your life moving your little green ball around, press the esc. button to exit the program and return to DBP. You shouldn’t have gotten any errors. Now that we have a very basic engine down, we can start working on the cool parts like shooting and killing other enemies.


Back to top
Profile PM Email Website
RUCCUS
19
Years of Service
User Offline
Joined: 11th Dec 2004
Location: Canada
Posted: 6th Jul 2005 11:54 Edited at: 27th Jul 2005 08:15
Link
Chapter 3: Shooting

It’s time to add the part that basically defines an FPS, without it it’s just an FP, we need that S damnit! So, we’re going to add shooting, here’s what will be covered in this Chapter:

- Clicking the mouse to shoot
- Reducing ammo as we shoot
- Forcing us to reload when the clip has run out
- Disallowing us to shoot/reload when we’ve run out of clips
- Obtaining ammo to increase the amount of clips we have
- Changing weapons
- Killing an enemy after shooting them a given amount of times
- Adding mouse looking for the First Person part of FPS
- Adding a reticule to the screen to show where we’re aiming
- Showing how much ammo and clips we have left on screen as well

Part I: Adding a Limb

Its time to add shooting. So, since bullets (at least now-a-days) go so fast you can barely see them, there’s no need to be creating bullet objects. Instead, we’re going to use the Intersect Object command (DBP only). This command checks to see if two vertexes cross each other in the program. What we’re going to do is position a limb far away from the object, and cast an intersection ray from that limb to the object (our character) and check if anything is in between the two points. If so and the user is clicking the mouse, we’ll handle appropriately.

So, go way back to the beginning of the code, just before we positioned/pointed the camera. Click the blank line above the camera code and enter down a few times. Now type this code:



This code will add a limb numbered 1 to our character object and position it far away from the character (500 units away). The sphere number is 9999 because we don’t want to create an object that already exists, so we’re starting this one at 9999. Just to be safe. Before we go any further I should explain what a limb is first.

Every complex object is built up from limbs. Say you had a skeleton model for your game, and the skeleton had all the usual components (arms, legs, backs, feet, hands, head, torso). The parent object would be the body or torso, this would be the object you move around in a game. In our case, object 1. Then, we would add limbs to the parent object to create arms and legs and the other ligaments.

Limbs take on the exact position, rotation, and movement of any object. So if we were to add a limb to object 1, it would follow and turn wherever they went, kind of like an arm. We can then manipulate limbs to be offset from the center position of the user.

Limbs need to have a mesh number so they know what they’ll look like, so we obtain a mesh number by making a mesh from the previously created sphere. Once we have the mesh, we can delete the sphere for less lag. Now that we have the mesh object, we can add a limb. The ADD LIMB syntax requires an object number, a limb number and a mesh number, in that order respectively. We’ve added the limb to object number 1, given the limb number 1, and created the limb from our mesh number 1.

Now that we have a limb, we can delete the mesh for even less lag. Add this code:



Now, run the game again and you’ll notice that the sphere will be positioned far in front of you, and rotate as you turn. Try moving in all directions, it will stay with you all the time. When you’re done, come back here!!!

Alright, now its time to reduce some lag. In our case we aren’t using the limbs as parts to be shown like arms, but instead a position to shoot a ray back towards us to detect when there’s an object in front of us. Thus, since the limb won’t need to be seen, we will make it as small as possible and as simple as possible and then hide it to reduce lag. Plains are the simplest objects since they only have one side, so change the object creation code from making a sphere to this:



And then, add this code to the end of the section of limb code:



Now run the code again and you’ll notice that the limb doesn’t appear, this is because we’ve hidden it.

Delete the HIDE LIMB code for now, we’re going to want to see the limb for the next while, we’ll hide it later on once we have a target reticule in place.


Part II: Clicking the Mouse to Shoot

So, we have a limb in place, now we’re going to implement shooting at a very basic level, and then slowly make it better. Currently, we’re going to just delete the object when we shoot with the mouse, instead of reducing health, and the user will have unlimited ammo.

Scroll yourself to the DO/LOOP section, and start typing right after the movement commands. Enter down some more times to separate this from the movement code so we don’t get confused.

Add this code:



There’s that intersect object command. Intersect Object can be quite confusing, here’s the syntax of how we call it:

Return Float=INTERSECT OBJECT(Object Number, X, Y, Z, ToX, ToY, ToZ)

We replace the object number with the object we want to check for intersection with, in this case it being the enemy or red sphere, so object 2. The x, y, and z specify where the intersection ray will start, and the ToX, ToY, and ToZ specify where the intersection ray will travel to to detect intersection between.

Where it says Return Float will be the number the compiler will return when an intersection occurs. This number equals the distance from the intersection to the beginning X, Y, and Z positions.

In our case, we’re sending the ray from our limb to the user’s object. So by using the LIMB POSITION commands DBP has, we can find the X, Y and Z position of our limbs by specifying the object number and limb number in the brackets. Then we use the OBJECT POSITION commands to give the destination point by putting a 1 in the brackets.

So, now that you understand the intersection command (I think), we can move on. If you’re still having troubles with the command just use the Index in DBP to find the intersection command and get a more detailed explanation of it, or just ask in this forum.

The rest of the code is pretty simple, basically IF the INTERSECTION distance is >0 (> means greater), we delete the object. The other command at the top, IF OBJECT EXIST(2)=1 checks to see if Object 2 exists, if it does then it will go through with the rest of the code, if not it will skip the checking. This is handy because it reduces lag and will stop the computer from freezing when it tries to delete an object that doesn’t exist.

Now you can run the game again. You’ll notice that when you face the red sphere, it will be deleted. Once again, when you’re done, get yer’ ass back here.

If you’ve returned...
FPS’s usually don’t just delete objects when you face them, this is a very basic form of deletion. Now, we’re going to customize the process even more and require the user to click the left mouse button and be facing the object in order to delete it.
Add this code before the IF OBJECT EXIST(2)=1 part:
IF MOUSECLICK()=1
...and then add another ENDIF below the 2 ENDIFS you currently have.

Run the code once again, and face the red object. Then, press the left mouse button to delete the object.

The code is pretty self explanatory, it checks IF the MOUSE is CLICK()ed then follow through with the rest of the code. Now it’s time to add some ammo and reloading.


Part III: Ammo and Reloading

Ok, we want even more realism to this game, so we’re going to add limitations to how much ammo the user has and a reloading capability to stop the user from shooting all their bullets at once, and give the enemy some health. Plus we’ll show some onscreen information.

Go back to the camera positioning, and click below it. Enter down a few times. We’re going to define some variables, but before that Ill explain what variables are.

You can think of variables like cards. Each card has a distinct name and a piece of information along with it. There are several types of variables: Strings, Integers, and Real Numbers. You distinguish variables by the symbol at the end of the variable name. Strings have a $ at the end of their name, Integers have a # sign at the end of them, and Real Numbers have no symbol. We won’t be using Real Numbers.

Here’s an example of an Integer variable called IntegerVariable, along with how we would define it.



This code tells the compiler that there’s a variable named IntegerVariable, and that it is of the type Integer, and that it equals 200. We can further define variables by stating if they’re global, but that’s another subject. Here’s an example of a String Variable:



String Variables can contain text and must be defined in the quotes. Integer variables can’t have any text in them. This code tells the compiler that there is now a String variable named StringVariable$ that equals “This is a string variable”.

Now then, with your typing mark below the camera positioning junk, type the following:



Now, go back to the shooting code with the intersection command and delete all of the code that had to do with shooting in the loop, we’re going to neaten it up and add more.
Replace with this:



Here’s an explanation of what’s going on now:

If the user clicks the mouse and the enemy object exists and the user’s AMMO# variable is greater than 0 (which means the user can then shoot) and there’s an object intersecting between the user and the limb (thus something is in front of the user) and the object is the enemy object, decrease the EnemyHP# variable by 1 (DEC stands for decrease, same as INC stands for increase), and decrease the user’s AMMO# variable by 1. Then end all of the if statements to wrap up.

Like said above, DEC decreases a variable by the amount given, the syntax is DEC variable, amount. Above we’re checking if the Ammo# variable is greater than 0 which means the user has ammo left, so they can shoot, and we always decrease the Ammo# variable by 1 even if the user isn’t facing an enemy, as long as the mouse is being clicked.

Now, below this code, add this:



This code checks if the EnemyHP# variable equals 0, if it does the enemy must be dead so we delete the object.

Finally, we’re going to display some onscreen information. Enter the following:



This now introduces the TEXT command. Using the TEXT command we can specify the X and Y coordinate of where we want to display text, and then specify what text we want to show. The coordinates of a screen are much different than the coordinates of the 3D world. For example:

The X, Y and Z coordinates in the 3D world start at 0,0,0, but on the screen the X and Y coordinates start in the upper left, and there’s no Z since the screen has no depth.

The TEXT command comes with a lot of customizable commands for it, things like BOLD, ITALIC, UNDERLINE, or what we’re using, CENTER. Using the CENTER TEXT command we find the middle point of the text string and position it accordingly.

So, what we’re doing above is checking if the enemy object exists (because if it isn’t we cant display text over it), then if it does, using the TEXT command to display “Enemy Health: “and then the variable EnemyHP#. Since EnemyHP# is an Integer and not a String, we need to convert it to a String. That’s what the +str$() command does.

Now, the final part of the code to explain is the OBJECT SCREEN X() and OBJECT SCREEN Y(). Like I said above, the screen coordinates are not the same as the world coordinates, the SCREEN X and SCREEN Y commands take over the task of converting world coordinates to screen coordinates. We specify what object in the brackets. The reason we’re subtracting 70 so the text will be above the object, not right in it’s position.

Ok ok I know I didn’t explain this bunch of code too well so if you have any questions feel free to post.

Finally, we’re going to display the user’s Ammo# variable on the screen as well, but this won’t be following our character, instead it will be in the bottom left. Type the following below the last bunch of code you typed:



Once again using the TEXT command we place the cursor position at the far left, and to the bottom. The SCREEN HEIGHT() command returns the screen’s height for the current screen being used, then we subtract 50 so it’s not displayed right at the bottom. Using the screen height command we can now position the text in the same place no matter what the screen resolution. The rest is the same as the EnemyHP# bit, but instead with Ammo#

Ok, if you want you can test it, basically you’ll be able to shoot the enemy until your ammo equals 0. So, we need to code in a reload button. Here’s how will do it. Just above the text display code, type the following:



That little bit of code checks if the user is pressing the R button and if the Ammo# variable equals 0, if so it automatically reload the Ammo# to the MaxAmmo# amount.

Like I said way back in the beginning, only the main keys are given actual names. But keys like letters aren’t, instead they’re given scan codes. Each key has a distinct scan code, and R just happens to have 19 as it’s scan code. Using the keystate command we can check if a key is being pressed with the scan code 19.

Before we go any further, here’s what we have so far:



But there’s an awful lot of ENDIF statements in there that aren’t needed. Remember the colon? Meet its brother: AND. Using AND we can combine IF statements, like this:



Alright, run the code and see what happens. When you reach 0 ammo, you can reload with R. If you look at the enemy for the entire time you shoot then it should take 5 reloads. Next up on the list, adding clip limitation and making it harder for the user to reload by adding a delay between reloads.

I’m off to watch a movie, Ill get back to work on this tomorrow. For now, try:
- Changing the speed the player moves and turns at
- Increasing/Decreasing the amount of ammo the user has
- Changing the program to killing the wall and not the red sphere


Back to top
Profile PM Email Website
RUCCUS
19
Years of Service
User Offline
Joined: 11th Dec 2004
Location: Canada
Posted: 6th Jul 2005 23:11 Edited at: 28th Jul 2005 09:07
Link
Chapter 3: Shooting (Continued)

Part IV: Obtaining Ammo, Clips

One thing that’s wrong here is that you don’t have infinite amounts of clips in real life. So, we’re going to add a limit of 3 clips.

Go back to the variables we defined, just under the last variable write this:



Pretty self explanatory. Now, go to the reload code and change it to this:



Finally, so we can see the amount of clips we have left, enter this below the TEXT command we used before:



Now run the code again and you’ll see that you can’t kill the enemy because you don’t have enough clips. So, we’ll add some ammo on the ground that we can pick up. Go back to the section where we used MAKE OBJECT, way back at the beginning, just under the last object we made. Type this:



Now we have our ammo object in place, but that’s obviously not enough. We’re going to need to check if the player is above the ammo, and if so then increase their ammo and delete the object. To do that, we'll check for intersection below the user every loop, by using the INTERSECT OBJECT command.

Note: In the old version we were using a limb for this, if you're still doing that I realized it's not the best way of accomplishing things so change it to what we;re about to add

Ok, now enter this code below the reload code. So find that and enter down a few. Here it is:



Lets look at what we’re doing here. First, we check to see if there’s anything beneath the user using the intersection command. If there is, we INCrease the Clips and Ammo by the Max of their variable subtract the current variable. Using that formula allows us to fill up the user’s Ammo and Clips to the max no matter how many they have. You my be wondering, why didn’t we just make the Clips#=MaxClips# and Ammo#=MaxAmmo#. Well, mainly because I didn’t think of that until just now because I’m a moron so, its up to you if you want to change it to that now or just keep it as is. It won’t make much of a difference either way. Ok, then in the end we delete the ammo box since if we didn’t that’d allow infinite ammo.

We have to add one last IF statement to the code above. Change the IF INTERSECT OBJECT blah blah blah to this:



Then add an ENDIF at the bottom, underneath the first ENDIF. Without using what we added we would have two problems. 1. We could get a runtime error saying the object doesn’t exist to be checked for intersection with since it would be deleted after we ran over it, and 2. Even if we had full ammo and clips we would have still deleted the ammo crate, now it checks to see if the ammo is less than maxammo and if so it continues.

Ok, test the game and see what it’s like. Try running over the box before you shoot and then after you have shot a lot of bullets, enough to reload once. You’ll see it fills up both variables.

We’re going to add one last piece to finish off this section, we’re going to display text above the ammo crate so we know what it is while we’re in the game. So, go back to the last text display, put this code ABOVE the text we’re displaying about ammo and clips.




Back to top
Profile PM Email Website
RUCCUS
19
Years of Service
User Offline
Joined: 11th Dec 2004
Location: Canada
Posted: 7th Jul 2005 03:03 Edited at: 27th Jul 2005 08:16
Link
Part V: Adding Delay to Shooting and Reloading

Right now the user can basically hold down the R button as they shoot and it will seem like they have infinite ammo. So we’re going to add some restrictions to reloading and a delay to shooting/reloading.

We’ll start with adding the restrictions by disallowing the user to shoot if they’re pressing the R button. Change the first line of the shooting code to this:



Now the user can’t fire whilst pressing the R button. One other thing to add that I just realized is the part where it says IF Ammo#=0 in the reloading code, change the =0 part to <MaxAmmo#, since in reality you can reload even if you have ammo.

So, now the entire reloading code should look like this:



No we’re going to add some delay to the reloading process. Delete all of the reloading code and replace it with this:


This code checks if the mouse isn’t being clicked and R is and if the Ammo is less than the MaxAmmo variable AND if they have clips in stock. If they do then it sets the Reload# variable to 1. The next line checks if Reload# equals 1, if so it INCreases the Time# variable by .001. The last line checks if Time# is greater than OR EQUAL TO 1, if so then fill up the Ammo# variable to its Max, Decrease the Clips, and reset the Time# and Reload# variables for the next reload. We check if Time# is greater than or equal to one because sometimes the system jumps and will skip a number.

The reason we’re setting Reload# to one instead of just increasing the time if the user presses R is because if we did that the user would have to hold down the R button, which would be a hassle. One last part to add, to give a better affect:



That piece of code will show that we’re reloading since we don’t have any animations to show it. This will show the text “Reloading...” on the screen until the user is finished reloading. Ok, run/test it if you want but it should be working. Before we start the next part we’re going to comment everything so we know what’s what. Remember; use the ` symbol to comment.



That’s all of the code we have so far, commented out. On to Part...IIIII...Ack can’t even remember what part,

Gona take a break, ill get back to work on this in an hour or so.


Back to top
Profile PM Email Website
Ace Of Spades
19
Years of Service
User Offline
Joined: 6th Mar 2005
Location: Across the ocean
Posted: 7th Jul 2005 12:28
Link
A Lesson On Roman Numerals


1 = I
2 = II
3 = III
4 = IV
5 = V
6 = VI
7 = VII
8 = VIII
9 = IX
10 = X
20 = XX
30 = XXX
40 = XL
50 = L
60 = LX
70 = LXX
80 = LXXX
90 = XC
100 = C
200 = CC
300 = CCC
400 = CD
500 = D
600 = DC
700 = DCC
800 = DCCC
900 = CM
1000 = M

Thus wrapping up our lesson on how to correctly display roman numerals.

tip: "IIIIIIIIII" does not equal "10"

Back to top
Profile PM Email Website
MikeS
Retired Moderator
21
Years of Service
User Offline
Joined: 2nd Dec 2002
Location: United States
Posted: 7th Jul 2005 12:37
Link
Nice work, you can never have too many tutorials like this. I'm sure this will help many.



A book? I hate book. Book is stupid.
(Formerly Yellow)
Back to top
Profile PM Email
RUCCUS
19
Years of Service
User Offline
Joined: 11th Dec 2004
Location: Canada
Posted: 7th Jul 2005 21:34 Edited at: 27th Jul 2005 08:16
Link
Lol thanks Leys, I was going to google it when I finished but I guess Ill fix it now.

Thanks Mike, next part will be up soon.

<Edit> Ok, done with teh numerals. Thanks again Leys.


Back to top
Profile PM Email Website
glyvin101
19
Years of Service
User Offline
Joined: 27th Jan 2005
Location:
Posted: 9th Jul 2005 10:44
Link
I copy and pasted the tut to see what the final thing i was making would be and i got error at line 24 unrecognized peramiter
Back to top
Profile PM
RUCCUS
19
Years of Service
User Offline
Joined: 11th Dec 2004
Location: Canada
Posted: 9th Jul 2005 10:56 Edited at: 27th Jul 2005 08:16
Link
Are you using DBC or DBP?

DBC doesn't recognize the INTERSECT OBJECT command so your compiler may be getting confused and just giving you that line (since it doesnt make sense that it'd tell you the line that defines the variables is unkown).

P.S: This tut isn't done so that current code is only where we're at NOW, as soon as I finish my puzzle comp entry Ill get back to work on it.


Back to top
Profile PM Email Website
Antidote
19
Years of Service
User Offline
Joined: 18th Mar 2005
Location: San Francisco, CA
Posted: 9th Jul 2005 12:45
Link
I just want to point out that you stated that integers were created with # signs after them and reals were created with nothing after them. This is actually wrong since an integer can only be a whole number <, =, or > than 0 and reals define all numbers.

I have know idea what sflm stands for
Back to top
Profile PM
RUCCUS
19
Years of Service
User Offline
Joined: 11th Dec 2004
Location: Canada
Posted: 9th Jul 2005 13:38 Edited at: 27th Jul 2005 08:17
Link
Ahh Ill fix it first thing tomorow thanks for the tip.


Back to top
Profile PM Email Website
SimSmall
19
Years of Service
User Offline
Joined: 7th Aug 2004
Location: United Kingdom
Posted: 11th Jul 2005 02:18
Link
can someone do one of these in DBC?

my first attempt at an FPS is a disaster

...maybe one day I'll finish a project
Back to top
Profile PM Email
RUCCUS
19
Years of Service
User Offline
Joined: 11th Dec 2004
Location: Canada
Posted: 11th Jul 2005 03:29 Edited at: 27th Jul 2005 08:18
Link
The only reason (that I can think of) why you wouldn't be able to use this in DBC is because Intersect Object isn't included in DBC. This can be substitued though by just adding a long stretched out limb and checking for collision with that limb. I'll make a DBC version after the pro version is complete but by then someone else may have.


Back to top
Profile PM Email Website
Neotech
18
Years of Service
User Offline
Joined: 10th Jul 2005
Location:
Posted: 11th Jul 2005 04:14
Link
ruccus in i was testing some things in your code and what ive done was position camera where objct 1 is and use movement commands

so where the camera went the object would go also if camera turns 5 then object 1 will turn 5 and works like a charm so it is now in first person but how do i add limb to object and place it in front lower right hand of screen so i can glue gun object to it?
would really like the help on this
Back to top
Profile PM
RUCCUS
19
Years of Service
User Offline
Joined: 11th Dec 2004
Location: Canada
Posted: 11th Jul 2005 04:45 Edited at: 27th Jul 2005 08:18
Link
Well I'm covering this pretty soon but I just answered this question in another post, it should help until I add it to the tut:

http://forum.thegamecreators.com/?m=forum_view&t=56924&b=7


Back to top
Profile PM Email Website
Undercover Steve
18
Years of Service
User Offline
Joined: 6th Jun 2005
Location: Vancouver, Little Canada(Washington)
Posted: 11th Jul 2005 19:31
Link
ermm..when I start it, it is not first person:o
Back to top
Profile PM
RUCCUS
19
Years of Service
User Offline
Joined: 11th Dec 2004
Location: Canada
Posted: 12th Jul 2005 00:54 Edited at: 27th Jul 2005 08:17
Link
I know the first person aspect is added in the next chapter. Like I said this tut isnt complete but is good enough to get you started.


Back to top
Profile PM Email Website
Neotech
18
Years of Service
User Offline
Joined: 10th Jul 2005
Location:
Posted: 12th Jul 2005 01:00
Link
Yes, The Tut. is great and it has helped out alot Im doing alot of test with your code. getting the skeleton of the engine down at first seem difficult but after reading you code it just starts to make more sence and easier to understand code.. Thanks alot, you'll defenitly be credited when i post my code .
Thanks again Ruccus
Back to top
Profile PM
Killonyas Slayer
19
Years of Service
User Offline
Joined: 13th Apr 2005
Location: Mozerok,Eartreg
Posted: 15th Jul 2005 14:55
Link
great tutorial, hope to see more soon

-"I'm over twice as strong as I was when we last met"-
-"Good, Twice the fall, double the glory"-
Back to top
Profile PM
Mr Duck
18
Years of Service
User Offline
Joined: 14th Jul 2005
Location: \&quot;quaack... \&quot;
Posted: 16th Jul 2005 01:22
Link
nd how would someone using dbc make this "long stretched out limb and checking for collision with that limb"??(that someone being me)

QUAAAAAAACK!!!!
Back to top
Profile PM
The admiral
21
Years of Service
User Offline
Joined: 29th Aug 2002
Location:
Posted: 16th Jul 2005 18:08
Link
Although this is simple I think it should be stickied.It has some useful advice and good step by step guide to help the newbies out.

The admiral
Back to top
Profile PM Email Website
MMO lover
18
Years of Service
User Offline
Joined: 15th Jul 2005
Location:
Posted: 16th Jul 2005 21:54
Link
Ruccus Thanks alot for taking the time out of your day to write up a Tutorial. Although I don't have DBP yet, I am amazed at how willing you are to help us newbies (im below newb status) write a starter FPS Program. Thanks a ton for going out of your way!!
Back to top
Profile PM
Mattman
20
Years of Service
User Offline
Joined: 5th Jun 2003
Location: East Lansing
Posted: 18th Jul 2005 13:01
Link
Now where did I put that bottle of glue...

Good job Ruccus, can't wait to see it finished.

Word.
Back to top
Profile PM Email Website
RUCCUS
19
Years of Service
User Offline
Joined: 11th Dec 2004
Location: Canada
Posted: 20th Jul 2005 05:18 Edited at: 27th Jul 2005 08:17
Link
Wow a lot of excellent comments thanks all.

Well after trying very hard to get my submission into the contest....I didn't . I had to leave for Alberta (damn those Rockies are amazing)



and ran out of time, just got back today . I might still finish it but before I do that Ill continue work on this tut. Look for a new part or chapter tonight (hopefully, you never know what might happen) .

Thanks again for all the great comments im glad it helped some people out even when it isn't finished

P.S: Oh about the collision with a limb, well until the DBC version of this tut is out all I can really say since I dont have DBC is:

Add a long plain or cylindrical limb or whatever shape you want and offset it infront of the user. As for checking for collision with the limb you could use the built in collision commands since it's just a basic .dbo object, Im not fluent with the built-in collision commands for dbc but Im pretty sure theyre fairly standard.

If dbc doesnt support checking collision for limbs, simply glue a long cylindder or plain to the limb position and check for collision with that object instead of the limb.

Hope it helps until I get more work done.


Back to top
Profile PM Email Website
Antidote
19
Years of Service
User Offline
Joined: 18th Mar 2005
Location: San Francisco, CA
Posted: 20th Jul 2005 08:48
Link
I would just like to say that this isn't just for newcomers as more advanced users can use it for a really nice engine for FPS's.

Now if you'll excuse me the solo to stairway to heaven has just started.

Formerly known as SFLM.
Back to top
Profile PM
RUCCUS
19
Years of Service
User Offline
Joined: 11th Dec 2004
Location: Canada
Posted: 20th Jul 2005 10:02 Edited at: 27th Jul 2005 08:18
Link
Part VI: Switching to First Person View

Ok next thing up is making the camera go into first person view, and then adding a little more to the HUD.

First off, delete that one line at the top that has to do with the camera positioning and pointing. Then, click right below the DO command and type the following:



Now the camera will be positioned inside the character in the First Person View people are used to. Next go to the movement controls section, we’re going to add strafing since we’re changing the mouse to rotating the object instead of the arrow keys. So, delete the two lines that use the TURN command. Replace them with this:



Ok, that handles strafing. Now we’re going to make the mouse control the camera to give that feeling of looking around.

Below the movement code, type this:



Time to explain. Ok, first we are defining two variables, CAMX# and CAMY#. We are making these variables equal the integers the MOUSEMOVEX() and MOUSEMOVEY() commands return. These two MOUSEMOVE commands return the difference between the current and last position of the mouse, allowing us to determine if it’s moving left, right, up or down. We then multiply that value by .1 since the speed would be too great if we didn’t. Next, we check if the CAMX values are greater than 90 or 270 and less than 135 or 225. These IF statements restrict the player from fully rotating the camera all the way around, to add some realism. Finally, we rotate the camera and object on the appropriate axis by the variables.

Ok, the last thing we’re going to add as far as movement goes for now is changing the movement buttons. See currently to reload we have to reach way over to the left to press R, so we’re going to switch the movement from arrow keys to the classic WSDA style.

Change the four movement controls to this:



We simply changed the keys to the letters WSDA. Now W moves you forward, S moves you backward, A strafes left and D strafes right. Test the game and see how everything is working. Then try looking up and moving forward, you’ll notice something.

See what happened? You can fly! The reason for that is that when we move forward we are moving in the direction we face, so we have to solve this by keeping the object on the ground. How? GRAVITY! Before we do that though, we’re going to do one more thing, we’re going to make a target reticule on the screen and hide our limbs.

So, add this code right under the last TEXT command we used (we can put it anywhere but it’s good to keep like commands in the same area)



That will draw a circle to the center of the screen with a radius of 5. We obtain the center of the screen by dividing it’s width and height by two. Fairly simple.

Now we need to hide the limbs, add this code after OFFSET LIMB for the first limb:



And this code after OFFSET LIMB for the second limb:



We’re basically specifying the object number first, then the limb number.

Ok, run the program again and you’ll have a circle. Now then, onto gravity!

Current code:




Back to top
Profile PM Email Website
Antidote
19
Years of Service
User Offline
Joined: 18th Mar 2005
Location: San Francisco, CA
Posted: 23rd Jul 2005 08:52
Link
Wow its been three days since Ruccus' last post. I wonder if he is going to continue with the tut.

Formerly known as SFLM.
Back to top
Profile PM
RUCCUS
19
Years of Service
User Offline
Joined: 11th Dec 2004
Location: Canada
Posted: 23rd Jul 2005 09:49 Edited at: 27th Jul 2005 08:19
Link
Yes master.


Back to top
Profile PM Email Website
RUCCUS
19
Years of Service
User Offline
Joined: 11th Dec 2004
Location: Canada
Posted: 23rd Jul 2005 13:15 Edited at: 27th Jul 2005 04:21
Link
Part VII: Implementing Jumping (Updated Version)

We’ll start off with adding in jumping. Here’s the basic idea of what we’re going to program next:

- If the user presses the space key
- Get the user’s current y position
- Get the maximum jump height by adding on a number to the user’s current y position
- Store these two values in variables for later use.
- Move the user up until they reach the maximum height
- Once reached, move them down until they reach the ground level

So, to get started, enter down a few times below our movement code and enter this:



This line detects if the space key is being pressed. If so it sets the JUMP# variable to 1, pretty simple. The reason we don’t just do the jumping routine right when the space key is pressed is because we’d then have to hold in the space key to jump. Instead, when we set the jump variable to 1 we can then check if that variable equals 1, and jump, even if the space key isn’t being pressed. Keep this process in mind since there are a lot of cases where you need to detect a key press only once.

Next enter down again and add these lines:



See if you can understand what’s going on here before it’s explained.

If you do understand then great, but still read this part for more info. Basically we check if JUMP# is equal to 1, if so then the user must have pressed the space key since we told the compiler to set JUMP# to 1 when that occurs. Then we set some variables:

GROUND#: This variable is defined as the user’s y position, basically where they are right before we do the jump.

JUMP_SPEED#: This variable specifies two things really. Firstly it specifies how fast the user will move up, but in doing so it also specifies how high the user will jump. You’ll see why later.

JUMPING#=1: Then we set this new JUMPING# variable to 1. The reason we’re using this variable is to check if the user is jumping, if so then we can disallow them to jump while they’re jumping. If we didn’t do this they could just hold the space key down and fly upwards.

JUMP#=0: Finally, since we only want to define these variables once, we now reset the JUMP# variable to 0 again. This way the system won’t keep making GROUND and JUMP_SPEED# equal different values canceling out the jumping process.

So, since we’re checking if the user is jumping. Go back to the space key checking code and edit it to this:



Alright, now it’s time to actually make the user jump since our main needed variables have been defines. Enter down a few times from that ENDIF and type this:



That’s basically all of the jumping code we’re going to need. Here’s what it’s doing.

First it checks if the JUMPING# variable equals 1, if so then the user must have pressed the space key. Then , if JUMPING# does equal 1, it starts decreasing the JUMP_SPEED# variable at a rate of .001. Next, it positions the user at their current x and z position but then increases the y position by the current JUMP_SPEED# variable.

The reason we’re using the POSITION OBJECT command instead of the very handy MOVE OBJECT UP command and MOVE OBJECT DOWN command is because those two commands are relevant to the user’s current rotation. We don’t want this because then if we were to look down and jump, we would move forward instead of up since the command is moving the user up according to how they’re turned. Keep this in mind since it’s a common problem with many aspect’s in movement.

Finally, we check if the user’s Y position is less than or equal to the GROUND# variable we set earlier. Remember GROUND# equals the user’s original y position, before they moved up. This if they are below GROUND#, then we should stop their jumping process and let them jump again.

IMPORTANT: Ok, the JUMP_SPEED# variable is important here. In the beginning we set it to 1, setting it to 1 specifies the starting amount to add to the user’s y position. Then we slowly decrease it as the user moves up to add a realistic feel, making the user go up fast in the beginning, slow as they reach the top, then speed up again as they move down.

Now then, why does the object move down when we’re always adding JUMP_SPEED#? Because since we’re decreasing the variable by a given amount (.001 in this case), eventually it goes into the negatives, in which case we’re really subtracting from the user’s Y position. Hope this makes sense it can get complicated.

Try experimenting with the JUMP_SPEED# variable until you understand this process. Here’s some tips:

To make the user jump faster, increase the amount that is decreased from JUMP_SPEED (the part that says .001). For example, to jump at double the speed change .001 to .002. To move at half the speed change .001 to .0005.

To make the user jump higher, increase the starting JUMP_SPEED# setting. Currently we set it to 1, if we set it to 2, then it will take the user double the time to start going into the negatives. If we set it to .5, it’ll be half the time.

If you are having trouble understanding this feel free to ask and I’ll get on to answering it as soon as possible.

Alright, test the game, jump around, and customize the jumping settings to your needs until you like the way it’s handling. Onto gravity!

Here’s the current code you should have now:




Back to top
Profile PM Email Website
Antidote
19
Years of Service
User Offline
Joined: 18th Mar 2005
Location: San Francisco, CA
Posted: 24th Jul 2005 02:05
Link
I want to add this to my favorites but where is the add button

Formerly known as SFLM.
Back to top
Profile PM
RUCCUS
19
Years of Service
User Offline
Joined: 11th Dec 2004
Location: Canada
Posted: 24th Jul 2005 02:33 Edited at: 27th Jul 2005 08:17
Link
I never could understand where that button was

Just manually add it to your IE favourites by going to Favourites/Add.


Back to top
Profile PM Email Website
Yamman
18
Years of Service
User Offline
Joined: 11th Jun 2005
Location:
Posted: 25th Jul 2005 00:41
Link
thx for this tut, its realy helped me understand db more
Back to top
Profile PM Email
RUCCUS
19
Years of Service
User Offline
Joined: 11th Dec 2004
Location: Canada
Posted: 27th Jul 2005 04:23
Link
The new jumping code is in, it's much better than the old way and includes a jumping physics system for a better feel of jumping (Slowing as you reach the top of the jump, speeding up as you fall down). There's less variables to worry about than the old code and is easily customizable.

Im putting this in a new post so the thread will go to the top to let people know that the new code is in. Ok onto gravity.


Back to top
Profile PM Email Website
Supremacy
20
Years of Service
User Offline
Joined: 30th Dec 2003
Location:
Posted: 27th Jul 2005 08:15
Link
to had something to your favorities, the botton disappears after u have added 10 things, u must go to the control panel and erase some of your favorities so that the button comes back

Your signature has been erased by a mod

Thank u modddddd..........
Back to top
Profile PM Email
RUCCUS
19
Years of Service
User Offline
Joined: 11th Dec 2004
Location: Canada
Posted: 27th Jul 2005 10:30 Edited at: 28th Jul 2005 10:27
Link
To inform anyone waiting, gravity will be in as of tomorow if all goes as planned. It's coming along well and I already have a working demo, just fixing the kinks, making sure the tut is fairly well explained, spell checking, etc. Look to see it sometime tomorrow evening.

<EDIT> Well things aren't going as planned, mainly because Ive been drawn into playing and beating The Legend of Zelda (n64) by tonight. I know, N64, wow, but my X-Box broke and I never really beat the game so Ive decided to, im hooked . Still might be up tonight but don't wait up for it.


Back to top
Profile PM Email Website
Resident Evil 4 fanboy
19
Years of Service
User Offline
Joined: 2nd Feb 2005
Location: Where evil doers are!Oh wait, my room!
Posted: 30th Jul 2005 02:20
Link
you are my savior! maybe you can do other codes like rts,rpg, etc

Don't mess with spiderman!
Back to top
Profile PM
Resident Evil 4 fanboy
19
Years of Service
User Offline
Joined: 2nd Feb 2005
Location: Where evil doers are!Oh wait, my room!
Posted: 30th Jul 2005 16:43
Link
hold it! theres something wrong with your reload code! when I use all my ammo, and press r it won't work!

Don't mess with spiderman!
Back to top
Profile PM
Antidote
19
Years of Service
User Offline
Joined: 18th Mar 2005
Location: San Francisco, CA
Posted: 30th Jul 2005 18:42
Link
works fine on mine.

Are you sure you have any clips left?

Formerly known as SFLM.
Back to top
Profile PM
RUCCUS
19
Years of Service
User Offline
Joined: 11th Dec 2004
Location: Canada
Posted: 30th Jul 2005 20:55 Edited at: 31st Jul 2005 06:30
Link
Spidy like Antidote said make sure you have clips left.

To all of you very patient programmers: Sorry for not updating the tut for a while. I've had quite a few delays (Playing Zelda, Not being able to use the computer, and well forgetting about the tut ), but I'm back to work now. I'm leaving for a week to go to a camp but when I return Ill be back to work.

I've still got to pack my things and do some chores around the house today but I should be able to FINALLY finish the gravity section.

- REMEMBER - If you implemented the old version of checking for the ammo crate intersection, go back to that part and redo it, it's been updated with better code. Now there's no need for a second limb, much more efficient.


<EDIT>

Sigh...I hate to do this but it's getting late and for some reason the system that I thought was fine is having a minor problem, and I don't want to post something in a rush and get people confused so I'm not going to be able to finish by tonight. I know I've been putting it off sorry for not finishing on the dates I said I might be done on but no more promisses Ill finish it when I can that's all I'll say.

Until I get back have a go at making your own gravity system, here's some pointers:

- Make a big ground object for the user to walk on
- Check if the user is standing on the ground object with the intersect object command
- If the user isn't standing on the object, move them down as we did in the jumping code and disallow them to jump during falling.

That should be a fairly simple system have a crack at it, creating things yourself is always a good way of learning.

Again sorry for all the unkept promisses but Ill get back to work when I return, a week from now.

Goodluck,
RUCCUS.


Back to top
Profile PM Email Website
UnderLord
20
Years of Service
User Offline
Joined: 2nd Aug 2003
Location:
Posted: 31st Jul 2005 21:40
Link
Can you put this in a document so i can download it? hehe

When we talk to god, we're praying. When god talks to us, we're schizophrenic.
Back to top
Profile PM
Resident Evil 4 fanboy
19
Years of Service
User Offline
Joined: 2nd Feb 2005
Location: Where evil doers are!Oh wait, my room!
Posted: 4th Aug 2005 02:22
Link
hey guys! I figured out what was wrong with my reload code
Back to top
Profile PM
Resident Evil 4 fanboy
19
Years of Service
User Offline
Joined: 2nd Feb 2005
Location: Where evil doers are!Oh wait, my room!
Posted: 4th Aug 2005 02:52
Link
sorry! I have another one! I can kill the enemy!
Back to top
Profile PM
RUCCUS
19
Years of Service
User Offline
Joined: 11th Dec 2004
Location: Canada
Posted: 7th Aug 2005 18:53
Link
@Spidy you're supposed to be able to kill the enemy, reading the tut would have explained that instead of just copying and pasting the code.

@Underlord when the tut is finished a complete word document spell checked and polished will be put into a download along with an .exe of the final game, a help file, useful links, other notes, basic theories for advanced things, a list of challenges, and other small things like special thanks and what not.

On that note, I'm back


Back to top
Profile PM Email Website
Resident Evil 4 fanboy
19
Years of Service
User Offline
Joined: 2nd Feb 2005
Location: Where evil doers are!Oh wait, my room!
Posted: 9th Aug 2005 03:37
Link
thanks, than maybe your able to help me with collision, you see, when I don't want to change the subject so suddenly but, when I wrote this code

it suppose to display hit! Can you help me?

I'll be waiting for you on halo 2 with a magnum and shotgun in hand!
http://media.teamxbox.com/wallpapers/halo2_1029_800.jpg
Back to top
Profile PM
Resident Evil 4 fanboy
19
Years of Service
User Offline
Joined: 2nd Feb 2005
Location: Where evil doers are!Oh wait, my room!
Posted: 11th Aug 2005 00:59
Link
never mind

I'll be waiting for you on halo 2 with a magnum and shotgun in hand!
http://media.teamxbox.com/wallpapers/halo2_1029_800.jpg
Back to top
Profile PM
Aoneweb
21
Years of Service
User Offline
Joined: 9th Sep 2002
Location: Tucson, Arizona
Posted: 11th Aug 2005 02:32
Link
good work.

Toshiba,3.2Ghz,ATI Radeon 9000 IGP 128mb,1.2gig of Ram,Windows XP Home. www.aoneweb.com

Back to top
Profile PM Email Website
Kim Possible
18
Years of Service
User Offline
Joined: 13th Aug 2005
Location: Where ever there\'s trouble.
Posted: 14th Aug 2005 07:47
Link
I might have missed this - and if so, I apologize. I haven't been exposing all the code, just following along and writing it in my head as I'd do it. I only expose code when I want to see how you've done it.

Also - I'm a rank newb to DarkBasic. (twenty something years in 3D programming, though. Dating back to Phigs and Ramtek) I just downloaded DarkBasicPro Trial last night, ordered it this afternoon. Did a multiplayer fps skeleton with a few player models in a few hours to get the feel for it... Awesome for rapid proto! So with my newb-ness in mind...

A small point/question:

For first-person camera, you write - >POSITION CAMERA OBJECT POSITION X(1),OBJECT POSITION Y(1),OBJECT POSITION Z(1)

Now, wouldn't you want to Position Y + some offset? If you don't, wouldn't the camera be then the equivalent of having eyes on your feet? Mine usually reside five feet and change above the x plane.

Just a thought!

Thanks for the tutorial - I've had fun following along! You have a very approachable writing style!
Back to top
Profile PM Email
Back to top

Login to post a reply

Server time is: 2024-04-20 02:59:40
Your offset time is: 2024-04-20 02:59:40