FPS idea- but need help
Blitz3D Forums/Blitz3D Programming/FPS idea- but need help
| ||
I noticed a lot of 2D stuff, and a few primitive FPS material, but What about lifts, elevators, ladders, vehicles- wait--- Now consider a type array and a loadanimmesh, because I went through a whole lot of trouble just getting an export (via blitzpipeline from 3ds max 5) to be making stuff algorithmically. So here we sat, able to walk up a ramp, jump onto any static surface. Great! I chose not to parent my colliders and camera together, because- watch your head!!! And, oops, I jumped forward, and my head was pinned between the vertical fork! Uh oh! With all the spinning gears and such... I opted to child my main collider entity to whatever entity I'm standing on. Any easy samples would be most helpful since my body entity is oval. See, I've been through this all before in Visual Basic, and I'm just trying to port over what shouldn't be too hard... I'm ready to progress, advice, sample code? Update: Phone fixed. Sample code coming tomorrow! |
| ||
I'm assuming that you're all on Holliday, and that blitz doesn't fall short in this respect... I'm a big fan. |
| ||
For lifts and for elevators, you can use linepick to detect where is the ground and a distance calculation to detect if player is in range. For ladders you can use a collision check or a distance calculation to detect if player is in range. I think there is an example in Blitz3D\samples\si\fps For vehicles you can use a distance calculation or a collision check to detect if player is in range and the use of a key to decide whether player wants to climb in the vehicle or leave the vehicle. The rest is up to you, it is your game, you only can decide how it will work. Concerning the collision of a character with the environment (ground, walls, ceiling, obstacles) i repeat what i have already explained : i have found that the best combination is to use one collider sphere to detect the obstacles at front, at back, at left, at right), and a linepick at up (to detect the ceiling), an a linepick at down (to detect the ground). Another solution would be to use a physics engine like "Bullet" : http://tools.mirage-lab.com/ in which i think there is a collider capsule for characters. |
| ||
Remi, I know you're trying to help, but I have no working example- there's no ladder in si's demo. We need something more comprehensive than a tip. |
| ||
Yes there is a ladder, this is the first thing i see when i run the demo. But this is not the best way or the only way to code a "ladder". You can code it as you want. My personnal preference would be to use different states as mentioned before : OnGround OnAir OnWall OnLadder OnElevator and update the player accordingly. I am not trying to code your game for you, i am trying to make you understand what are the possibilities. |
| ||
At least try to code it for yourself or your skills will never improve. If you make a honest attempt and are still stuck post your code. Blitz guys are very helpful but won't make your game for you. |
| ||
If you have tried the ladder in the fps demo, and looked at the code, you can see that :; Climb ladders If EntityCollided(camera,type_ladders)<>0 Then TranslateEntity camera,0,1,0 ; Gravity TranslateEntity camera,0,-1,0 the gravity force is -1Y and when the collider sphere of the player is in contact with the collider mesh of the ladder, there is another force of +1Y applied to the player This is what allows the player to move up when he is in contact with the ladder. In my opinion this is not the best solution because the player is not locked on the ladder and thus if he wants to look around, he may fall. Also if the game uses one animation for each action, the player (or a bot) must be either walking or running or jumping or falling or grabbing or climbing a ladder/ledge and not doing several actions at the same time, else it will look weird. |
| ||
I made a mistake- Si's code resembles my own with regards to gravity. It had been a while since I examined his code, and it DOES look tight. BUT there are other issues that remain unresolved. I don't mean to come across as stupid. |
| ||
I've had numerous problems trying to parent moving objects to my camera/collider cluster and need elaboration of some small details- 1. There was only a mention of how you had used a couple of subroutines to create/destroy your colliders. 2. Is it simply that it doesn't matter what entityxyz reports BECAUSE of the use of number 1? I ask this since if I'm using a lift and I'm a child of it (which doesn't fix rotations on other turning objects by the way), how can I ensure my Y is going to be right? |
| ||
1. There was only a mention of how you had used a couple of subroutines to create/destroy your colliders. The idea is simple : All colliders "receiver" can be precreated before the mainloop All colliders "emitter" are destroyed at the beginning of the mainloop then Depending on the position of the entity, some colliders "emitter" are created then a first update to turn/move the entities (player, bots, projectiles) then updateworld to calculate the collisions then a second update to check for each collider emitter if a collision has happened and if yes change the state of the entity accordingly so the mainloop look like this : Repeat UpdateColliders() UpdatePlayerBC() UpdateBotsBC() UpdateProjectilesBC() Updateworld() UpdatePlayerAC() UpdateBotsAC() UpdateProjectilesAC() Renderworld() Flip() until(Keydown(1)=1) From my tests, it is necessary to have at least 1 collider emitter for player and for each bot which is the parent of all others components of player/bot (pivots, meshes, others colliders) and to never destroy it because it will prevent the player/bot to go through the environment. For projectiles it does not matter. 2. Is it simply that it doesn't matter what entityxyz reports BECAUSE of the use of number 2? I don't understand what you mean. how can I ensure my Y is going to be right? If you know the height of your lift (you can use MeshHeight() to measure it), and if you know the origine of your mesh, then you know exactly where to position the player/bot feet so that it is precisely on top of it. |
| ||
I'm not yet ready to even involve bots in this application until I can ensure that the player is going to behave correctly. Once again- order of events in the loop are shown. But what about the contents of UpdateColliders()? I think I see destroy colliders, updateworld, add colliders?? No, before collision, after collision?? By entityxyz reporting incorrect values, I mean that it DOES when your collider is pinned or snagged somehow against say an angled surface and you keep pushing into or pulling away from it. |
| ||
Because of the sometimes complex nature of my indoor maps, I am just testing a camera with 3 sphere colliders (vertical) against the basic b3d map entity (no doors or anything right now) Because of erratic collider results. I took your advise about the oval collider pivot. :) |
| ||
Forget about the UpdateColliders() function, i have coded this only to be able to destroy and recreate collider more easily when i used several colliders sphere for each complex projectile. But to have collisions between character and the environment (terrain, ground parts, wall parts, ceiling parts, obstacles), you only need to use one collider sphere for each character to prevent a character to go throught the environment and to detect the collisions at front at back at left at right, and use linepick to detect where is the ground and where is the ceiling. Also i don't know if you are aware of this but it will work better and be faster to calculate if you use a low details mesh for collision and a high details mesh for rendering. |
| ||
Simplicity is always good advise. Of course for now, I'll see what I can do. |
| ||
Testbed app posted: http://www.blitzbasic.com/Community/posts.php?topic=101898 |