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 / I hate bullets more than collisions

Author
Message
culmor30
17
Years of Service
User Offline
Joined: 16th Jun 2007
Location: In my head.
Posted: 4th Aug 2007 21:27
Yes. It is true.

Because I used sparky's to solve all my problems with collisions, and they work great now. Nice and slidey. On to my (hopefully) final problem. (I only say that because I think I can take care of the rest myself.)

Bullets. I HATE them. Well, they're ok. But I don't like making them.

Here's my game script so far:



The media's attached. (14kb zip'd) Put it all in the same dir obviously.

So, what is it that I need to do to get this bullet thing to work? Obviously if you read it, you saw that I have a for/next loop for 200 objects (100-300) that will be my bullet objects. 200 max on screen. I've been messing with stuff but can't seem to get it quite right.

My idea is, I want to have a max 200 bullets, which will be cubes, that, when mouseclick()=1, get repositioned to the camera's orientation (because they start offscreen) and go in a straight line from there until they collide with anything.

How would I go about doing this? (And I can use the dbpro commands, sparky's, and darkphysics if you can help using those.)

And I want my bullet objects visible, but is there some way I could use that along with raycasting in sparky's?

I have no idea. Thanks in advance for help

Attachments

Login to view attachments
Jane Doe
17
Years of Service
User Offline
Joined: 29th Jun 2007
Location:
Posted: 4th Aug 2007 23:19 Edited at: 4th Aug 2007 23:22
I'm not a big fan of visible bullets, but...

What you're going to have to do is when the bullet is fired, position it at the camera position or whatever start point you're going to use. Point the bullet in the direction of flight. You're going to have to figure out how far this bullet is going to fly this program cycle and where the bullet is going to be if it flies that far without hitting anything (we'll call this point X). You then use Sparkey's raycasting command to see if there is anything between the bullet's current location and point X. If it doesn't hit anything, position the bullet at point X. If it does hit something, then do whatever you're going to do for bullet impact.

The next program cycle (assuming the bullet didn't hit anything on the first) do the same thing you did before. Calculate how far the bullet will travel this program cycle and where it will be if it travels that far (point Y). Do your collision checks and move the bullet to point Y if it doesn't hit anything.

Keep doing this until the bullet hits something or goes out of sight or reaches maximum range or whatever.

Anticipating your next question: How do I determine how far the bullet will travel this program cycle?

This is something your going to have deal with quite a bit. You want your program to run at the same speed on any computer. Take, for example, your movement:

if keystate(17)=1 then move object 1,1

This causes movement at a certain speed on your computer. Were I to run your program on my computer, the speed would probably be different because my computer is probably either faster or slower than yours. (Bear in mind that even if you don't care at what speed your program runs on my computer, you'll probably get a new one at some point. You'll want your game to run at the right speed.)

The situation is the same with the bullet. You need to decide how fast you want your bullet to travel, say in metres per second. Let's say that you decide that you want your bullet to travel 200 metres per second. (This is way too slow for a bullet, but might be fun in a game. Besides, if you use realistic bullet speeds, you won't see them, and you say that you want to. That's why I'm not a big fan of visible bullets.)

Let's say that your game scale is one unit of measurement equals one metre. That means that your bullet will travel 200 units of measurement per second. But what is this per program cycle? You're going to have to determine how much time has elapsed since the last program cycle. Place the following at the beginning of your program loop:

PreviousCycleTime = CycleTime
CycleTime = timer()
ElapsedTime = CycleTime - PreviousCycleTime

ElapsedTime is in thousandths of a second. Let's say your program is running at 60 cycles per second, each cycle will be about 16.666 thousandths of a second long. If your bullet is supposed to travel 200 units of measurement per second, it will travel 12 units of measurement per cycle (200 / 16.666).

An important thing to bear in mind: Your program speed will fluctuate. If you display your frame rate on the screen, you will see it go up and down. Using this method will ensure smooth and consistent speeds for movement, bullets, etc.

I hope this helps. If you have any questions, just ask.

- Jane
culmor30
17
Years of Service
User Offline
Joined: 16th Jun 2007
Location: In my head.
Posted: 5th Aug 2007 00:01
Thanks much

I'm gonna go out and eat some dinner then I'll be back and start coding this. I'll probly post what I have if there are any problems. And even if there aren't, I'll post what I did.

And I'll clock my cycle speed... that's a good idea.

Lol, just can't get off my mind I have to do my in-car driving test on Monday... ugh. I've never driven anything before. Soo nervous... eh, it'll be alright. I hope.

Well, thanks again. */me is nervous*
culmor30
17
Years of Service
User Offline
Joined: 16th Jun 2007
Location: In my head.
Posted: 5th Aug 2007 02:24
Okay, started on this, but how do I make multiple bullet objects work? I mean, I can create them with a for/next loop, but how do I make it so that when I click left mouse, it starts at bullet 100, goes all the way through 300, and past that, starts deleting them one by one?
culmor30
17
Years of Service
User Offline
Joined: 16th Jun 2007
Location: In my head.
Posted: 5th Aug 2007 05:01
Sorry for triplepost, but here's what I have so far:



Now this will handle 10 bullets, I'll add a reload system later.

But I can't SEE the bullets. I even want and said show object in the for/next loop, and oversized them a lot, but still can't see them. Anyone know what's wrong? (Wanna get past this step more quickly because I want to start on AI.)
Jane Doe
17
Years of Service
User Offline
Joined: 29th Jun 2007
Location:
Posted: 5th Aug 2007 06:45
I worked on your code. It still needs work, but you have a working system to start with. It's pretty well commented, so you should be able to follow it.



You need to get in the habit of indenting between FOR/NEXT, DO/LOOP, IF/ENDIF, etc. It will make your code A LOT easier to read.

Good luck on Monday.

- Jane
culmor30
17
Years of Service
User Offline
Joined: 16th Jun 2007
Location: In my head.
Posted: 5th Aug 2007 07:09 Edited at: 5th Aug 2007 08:32
Thanks, I'll try that now.

=-Edited-=

EDIT: Ah, but, if I were to only hide the b object, it would still return collisions. I can hide it, but I'm still gonna position them under my level.

EDIT 2:
==--IMPORTANT--==

Ok, so, the script works, except for one thing.

Say you click once and bullet one is flying. Ok. But while it is still flying, you shoot again. Now, bullet one stops in the air to let bullet two fly. Why's that?
Jane Doe
17
Years of Service
User Offline
Joined: 29th Jun 2007
Location:
Posted: 5th Aug 2007 08:17 Edited at: 5th Aug 2007 08:37
I may be way off base here, but I’m going to take a chance and say that I think you’re a kid. Don’t take offence. To me, anyone under the age of thirty is a kid (and I think you‘re way under thirty Mr. “I‘m taking my driving test on Monday and I‘ve never driven anything before“).

My point is: The time for you to develop good habits is NOW. Do you know what kids with bad coding habits become? Adults with bad coding habits.

So stand up straight, eat your veggies, study hard, floss your teeth and indent your code!

- Jane
culmor30
17
Years of Service
User Offline
Joined: 16th Jun 2007
Location: In my head.
Posted: 5th Aug 2007 08:35 Edited at: 13th Aug 2007 04:43
Anyone under 30 is a kid? Harsh...

Mmkay then. Yeh, I'm [AGE REMOVED BY MOD]. Guess I'm... an infant?

EDIT: Age removed by mod? Wow, this place is like, security tight.

But you probably (and hopefully) know, people have their preferences. I prefer not to spend my time editing my code for readability, but you might. I have a separator line or two to organize things, sure, but I just don't like TOO much extra work. I'll tell you what, when this gets over 500 lines, I'll indent and organize everything. I just don't feel there's a need right now.

Well, back to the main point of this thread, which was bullets. And the problem I had in edit 2 of my last post. If you can fix that, I will love you forever.
Jane Doe
17
Years of Service
User Offline
Joined: 29th Jun 2007
Location:
Posted: 5th Aug 2007 08:58 Edited at: 5th Aug 2007 10:19
I’m just trying to provide you with a little guidance, that’s all. Of course, everyone has their own preferences, but most people prefer to be able to make sense of their code. I know kids your age don’t like “old” people telling them what to do, but when you get older, you’ll understand. Do yourself a favor and save this web page and look at when you’re forty. You’ll think it’s hilarious. I’m not making fun of you. Even at the tender age of fifteen, you must realise that you’ll be a very different person at forty and you'll see things from a whole different perspective.

By the way, that 500 lines that you feel you need to organise your code is going to come at you FAST. You’ll probably have 1000 lines before you know it.

With regard to your question, that’s not what’s happening. The program is reusing the first bullet very quickly, but isn’t interrupting it’s flight to reuse it. Go into a corner and aim at the far corner. Hold the left mouse button down to achieve an automatic weapons fire effect and watch the array data on the screen. You’ll see that bullets two, three and four are being used if bullet one hasn’t finished it’s flight one way or another.

Notice that the array is checked “from the top down” so to speak to find a bullet that isn’t in flight. This is done to make determining which bullet to use faster. Also bear in mind the confined space of your level. If your level was outdoors, the bullet would be allowed to go much farther before dying out and so the time of flight would be much longer and so you would be using more bullets. In fact, even in your confined level, the only reason I had the bullets die out so quickly was to illustrate what to do in the event of a miss.

Do what I said, and if it still seems to you that the bullet’s flight is being interrupted, let me know.

- Jane
culmor30
17
Years of Service
User Offline
Joined: 16th Jun 2007
Location: In my head.
Posted: 5th Aug 2007 19:58 Edited at: 5th Aug 2007 20:06
Okay, did that. Bullet 2, 3, and 4 are being used, but bullet one will stop anyway. Take a look at this screenie (attached). In the screen I fired at the opposite corner and went over there to check, and it looked like this.

EDIT: Oh yes, and I spaced my code out nice and spacey just for you.

Attachments

Login to view attachments
Jane Doe
17
Years of Service
User Offline
Joined: 29th Jun 2007
Location:
Posted: 5th Aug 2007 20:13
The bullets in your screen shot look like they're suspended in mid air. Is that the case? They should look like they're stuck to the wall.

I moved the bullets back a bit from the point of impact so that you could see them better, but that shouldn't cause that to happen.

Have you changed the code at all? I just copied the code from my previous post and ran it to make sure that I haven't changed it since I posted it and it was fine.

- Jane
culmor30
17
Years of Service
User Offline
Joined: 16th Jun 2007
Location: In my head.
Posted: 5th Aug 2007 20:24 Edited at: 5th Aug 2007 20:38
Yep, they're just sitting there.

All I did was rem out the part you said to delete, and increased the radius of the collision sphere of the bullet to 1.5. But the same thing happened before I did that.

I'll double check the code and see if there are any complications.

EDIT: Aha, I found the problem (for once). I had forgotten this line in the bullet subroutine: bulletobject=bullets(b,0)

I had only put it in firebullet. That fixed it.

So onto the next thing that shouldn't be too hard:

How would I delete a bullet object on collision and on the wall it hit, paste a transparent sprite or image of a bullethole? (And maybe with a limit of 50, but that can come later)
Jane Doe
17
Years of Service
User Offline
Joined: 29th Jun 2007
Location:
Posted: 5th Aug 2007 20:47
I just realised that I need to make an important change to what I did before. I’ll get back to you.

- Jane
culmor30
17
Years of Service
User Offline
Joined: 16th Jun 2007
Location: In my head.
Posted: 5th Aug 2007 21:31
Aight. For now I guess I'll implement ammo.
Jane Doe
17
Years of Service
User Offline
Joined: 29th Jun 2007
Location:
Posted: 5th Aug 2007 22:02
I thought that I had made an error in determining bullet burnout based on the number of program cycles that the bullet has been in flight, rather than distance that it has flown. Since the distance traveled per cycle is fixed, the number of cycles the bullet has been in flight will determine the distance it has flown. So it's alright.

When you incorporate a timer into your program to check the length of the cycles as described above, you (or we) are going to have to change that. Since we won't be dealing with uniform lengths of time, bullet burnout is going to have to be determined based on distance, not time. (It actually would be possible to use time, but distance will be more intuitive and it‘s still going to have to be changed).

Until the timer is introduced, we need to do it just the way it is.

As for the bullet holes, I know Sparkey's has something for that. I'll read up on it and get back to you.

Sorry for the delay.

- Jane
culmor30
17
Years of Service
User Offline
Joined: 16th Jun 2007
Location: In my head.
Posted: 5th Aug 2007 22:14 Edited at: 5th Aug 2007 22:24
Delay? I'm getting so much attention I feel like I'm in private school.

Thanks much again for helping me. I can look at the sparky's ref too, but I have to go eat lunch first. Hunger...

Oh, before I go, here's so far:



I added ammo myself without any problems. That makes me happy.
Jane Doe
17
Years of Service
User Offline
Joined: 29th Jun 2007
Location:
Posted: 6th Aug 2007 00:07
I worked on your code some more. Here are the changes I made. I'm writing this while reading the code from beginning to end, so the order may seem strange.



1. Added a system for assigning numbers for objects, images, sprites, etc. That way you don't have to keep track of those numbers and your code will be a lot easier to read. MOVE OBJECT EnemyObject, 12.0 is going to be a lot easier to understand than MOVE OBJECT 346, 12.0. Note that you can't use this with everything. Things like lights and file numbers have to be within a certain number range. Object limbs have to be added in order: 1, 2, 3, etc. But for the bulk of your media, this is the way to go.

2. Introduced a user-defined type (UDT). If you know what that means, skip this section. When you make an array with a DIM command, all of the elements of the array are of the same data type. But what if you need an array with different data types? That's what UDTs are for. You use a TYPE/ENDTYPE command to define the different data types that you want in your array. Since you have a full example to look at, I'm not going to go into great detail. Just notice the way the bullet array looks and is used. If you have any questions about it, just let me know. By the way, you can e-mail me if you want. We don't have to go through the forums all the time, but we can if you want. It's up to you.

3. Added the bullet holes. The graphic that I made is attached. It isn't any big deal. Note, however, that the black in the center of the picture isn't completely black. The black around the edge is. That's the reason the black around the edge doesn't show, but the black in the middle does. I'm partial to PNG files, but I find that when I have to differentiate between real black and faux-black, I need to go with a 24 bit BMP image.

4. Added the cycle timer and applied it to the bullet flight (more on that later) and the player movement speed. Now speeds should be consistent on different machines or if your program speed fluctuates (which it‘s more likely to do the bigger your program becomes).

5. Added a variable to keep track of the number of bullets in flight. That way, if there aren't any, the bullet procedure won't be called. I also added this number to the on-screen info. It's the number under the bullet array data.

6. Converted the raycast to the Sparkey's command. Everything that Sparkey's should be used for is now using it.

7. Changed the bullet burnout from being number-of-cycles-based to distance-flown-based, as discussed above.

I didn’t have your ammo code, so it’s not in there. I’m sure you’ll be able to integrate it.

Well, that's about it. Chew on this for a while and if you have any questions or problems, let me know.

- Jane

Attachments

Login to view attachments
culmor30
17
Years of Service
User Offline
Joined: 16th Jun 2007
Location: In my head.
Posted: 6th Aug 2007 00:10 Edited at: 6th Aug 2007 01:22
Wow. Awesome. Thanks lots

I'll read through the code and use it. After that... I can probably start modeling myself a gun, then AI.

EDIT: I'm also gonna do some particle effects for when the bullets hit the environment object, but that requires darkphysics, do you have it?
Jane Doe
17
Years of Service
User Offline
Joined: 29th Jun 2007
Location:
Posted: 6th Aug 2007 06:33
No, I don't have DarkPhysics, but there are plenty of good particle commands in DBPro. There's an entire category of particle commands in the help.

- Jane
culmor30
17
Years of Service
User Offline
Joined: 16th Jun 2007
Location: In my head.
Posted: 6th Aug 2007 23:50
Yes, but they don't have self and environment collisions

Don't need to do that now though. I can put it in later.
vorconan
17
Years of Service
User Offline
Joined: 4th Nov 2006
Location: Wales
Posted: 7th Aug 2007 00:37
Get ZParticles, it's in the Program Announcements Board. It looks like your making progress, Jane is a really good help isn't she.



culmor30
17
Years of Service
User Offline
Joined: 16th Jun 2007
Location: In my head.
Posted: 9th Aug 2007 06:32 Edited at: 9th Aug 2007 06:52
She is. Thanks much, and I'll look at ZParticles now vorconan. Thanks much, and thanks much again Jane.

(Lol, it's pretty funny that I just opened this thread to ask about particles and you had already posted. You foresee the future...)

EDIT: Okay, that;s pretty much the same thing as darkphysics does though... I wanted to know, is there some way I can change the shape of the particles from squares? It's annoying me...

Here's my objective:

I want to create particles, that are spheres, at the position/angle of my bullet hole object. They need to at least have gravity and collision with the terrain. These commands aren't hard to understand and they don't differ much from the native dbpro commands, and the ones that do are self-explanatory. Here's my code:



That's in my loop. It's just, they are cubes, and they last forever. They have to be spheres, and disappear. It also seems like there's some weird wind or something always pushing them... but that's not as important now. If you can help it'd be awesome.

Oh, and look at Jane's code above if you care what NextIDNumber() and NewBulletHole are.
culmor30
17
Years of Service
User Offline
Joined: 16th Jun 2007
Location: In my head.
Posted: 12th Aug 2007 02:26
Sorry for doublepost, but I did want to bump and say something else:

Instead of particles, maybe I will use bitmaps. Like, if you've played halo, when you shoot the ground, some transparent dust or something flies up and falls down. This is composed of two bitmaps (or something like that), both transparent, one in front of the other. The one closer to you it a little shorter. They also move at slightly different speeds, for a more realistic effect.

So instead of screwing with the particle stuff, I want to just do that. Can someone just show me an example of an efficient way to do this?

Thanks in advance for help.
culmor30
17
Years of Service
User Offline
Joined: 16th Jun 2007
Location: In my head.
Posted: 14th Aug 2007 05:24
Sorry for bumping this... but I really need some help... can't figure it out.
vorconan
17
Years of Service
User Offline
Joined: 4th Nov 2006
Location: Wales
Posted: 14th Aug 2007 15:23
Try particles to start with, it's a lot easier and better in my opinion. Just spawn particles at the raycast's end location, using SC_GetCollisionX/Y/Z().



culmor30
17
Years of Service
User Offline
Joined: 16th Jun 2007
Location: In my head.
Posted: 15th Aug 2007 01:25 Edited at: 15th Aug 2007 02:48
Alright. I figured out how to position my dust object correctly when needed, but to get it to fade out and fall slowly would be very tedious. So I'll stick with particles for now.

EDIT:

Ok, I got myself some particles. Sorry I used darkphysics, but the commands are identical, just rem out the physics and take out the phys, along with anything to do with emitter collision and gravity.



Okay. Now what I want is to have particles like sparks shoot up from the collision point. That much is achieved. First they should just shoot up for about 50 milliseconds, then gravity will enable and they will fall and fade out. I added a timer to the cycle, sparkdeltimer#, which increases every cycle. I'm not quite sure how to go about it, but when the timer reaches 100, all current particle emitters should be deleted, and the timer should reset to zero.

Thanks for all the help

Login to post a reply

Server time is: 2024-09-27 02:30:54
Your offset time is: 2024-09-27 02:30:54