procedural FPS

[-HP-]

[jaboo224]

Seriously this is got to be my favorite indie project to watch and its not even marketed to me through a website. Truly inspiring. You rock peris! If you got some wicked gameplay then this could make you some serious bucks.

[Skjalg]

When you say raycast based, do you mean you actually use a raycast every time you shoot? and for the shotgun, do you use raycasts for all the "particles" ?

Raycasts are expensive... Wouldn't it be way faster for your game if you just spawned a projectile and made that move instead?

[Pericolos0]

a moving particle doing collision testing sounds more expensive than raycast to me, and also it wouldn't really be an instant hit. I'm not noticing any slowdowns with raycasts anyway, and I'm using them for a lot of things, like the enemies use raycasts too to spot the player. You just need to make sure your not doing too many every frame

How many ppl is working on this project ?

Just me! I'm mostly doing this to learn more about the other aspects of game development other than what I do at work . Maybe in the future I'll get more people in on this, who knows! Before I do that though, I want to have a solid fps engine running with all the elements I want in my game and the code being fairly flexible.

[twiz]

so when can we play it :derp:

[Pericolos0]

Hehe things are starting to line up for getting the one playable random level with most basic gameplay elements in there, but I'm actually going on a 3 week vacation now, so it'll be after that I'll probably release that .

[knj]

;(

why da fuck you need vacations ? complete OUR game

[Skjalg]

a moving particle doing collision testing sounds more expensive than raycast to me, and also it wouldn't really be an instant hit. I'm not noticing any slowdowns with raycasts anyway, and I'm using them for a lot of things, like the enemies use raycasts too to spot the player. You just need to make sure your not doing too many every frame

I suggest you buy yourself a brand new laptop and try to play your game You'll notice severe slowdowns! And a moving transform with a boxcollider attached to it is waaaaay less expensive than doing a raycast, even if its just once every time you shoot. You should really look into doing stuff without raycasts if you want to keep things optimized, because the moment you fall into the "I'm just gonna do it this once, because its so much easier", then you're on a slippery slope

I know a lot of games use ray casts for their weapons, I think the source engine does as well, but you gotta remember that you don't play source engine games in your browser.

The first thing I did when we started working on the full game for ponh, was to remove each and every raycast that is being done (except one on the camera that always checks if it can see the player, and if it cant then it must move closer.. I couldn't think of any way out of that one )

[Pericolos0]

that doesn't make sense that a moving box is cheaper lol. Lots of game engines use raycasts for various thing. Doom uses raycasts and is almost 20 years old lol. Are you sure it's the raycast and not a graphical effect that's slowing things down like effects being spawned? Raycast should be pure cpu, I can't imagine your laptop cpu is that much slower than my computer's?

[Campaignjunkie]

The Flashbang Studios people had some blog posts about how they use box collider-triggers for a lot of their game logic. For more info -- http://technology.blurst.com/unity-phys ... -examples/ -- I think they're talking Unity 2 at the time, but it's still probably true.

The #1 reason for using triggers, over this “manual” method, is that triggers will be faster. Much faster! There are ways to make this example better–check the sqrMagnitude of the distance to avoid a square root, cache your Transform, etc–but the crux of the problem remains: You have to run this code every Update, FixedUpdate, or at least with enough frequency to respond interactively.

However, the physics engine is already checking for trigger collisions. It’s doing the work for you! Let it do its super-fast optimized thing; believe me, you can’t compete with PhysX on an optimization level. Instead of polling for spawn points in our radius ourselves, let the physics engine send events only when something enters our player radius trigger...

[Pericolos0]

Oooh that's really useful info, definitely something I can use. For example right now my enemies will try to dodge projectiles fired at them. This works by the projectile checking for nearby enemies and sending them a message when it's close (so I don't have 50 enemies checking for projectiles constantly), but it's kind off an awkward way to do this. This trigger method seems way more efficient .

[Skjalg]

Yes, triggers is the way to go. Use them as often as you can instead of raycasts.

I'm not saying you should never ever use raycasts, as I said in my rant there I also use it. I just argue that you should be VERY scarce with using it, and if you ever start thinking that it doesn't cost anything you'll eventually end up with a laggy game. You said yourself its fine as long as you only ray cast a few times, and I agree, except you should never ever raycast more than once or twice for a frame.

So if you have 50 enemies that randomly shoot raycasts to check where the player is, or if they should dodge bullets, bullets which are shot with raycasts then all of a sudden if you shoot at 3 enemies that are just figuring out that you are there then you have 3 enemies * 2 (dodge and player check) + bullet raycast (i dont know how many you do) which amounts to over 7 raycasts in a simple scenario.

If you had gone with the notion of staying away from raycasts altogether you'd have to do some nifty tricks with triggers, and I know its soooooooo much simpler to use raycasts, but what I'm trying to tell you here is that once you start using it for quick and dirty stuff you will eventually get over budget.

[Pericolos0]

hehe this is an interesting discussion, I really appreciate the advice . The scenario you describe isn't actually what happens in my game, my enemies will only ever raycast to check if they can see the player if they are in attack mode, and only do it once every few seconds. First they detect if the player is within a certain distance, then they check if he's within field of view, and only then they will raycast to check if they can actually see him, after which they will switch to attack mode and raycast every few seconds to see if they can still see him. The only time in my code multiple raycasts happen in one frame is when the shotgun gets fired, but just to make you happy I put a 1 frame yield between every shot now . So the chance now that multiple raycasts will happen on the same frame in my game is very small . I'm not really noticing the game running faster on my computer though, but it probably saves me from some trouble later on .

It's really fun to learn about this stuff, makes me understand the programmers at work a lot better whenever they tell me they can't implement what seems to me like a really simple feature

[Skjalg]

hehe yeah, keeping frame rate high is always the first priority. especially at blizzard i bet since their games always runs smooth on low end hardware

[wilco]

Keep it up Peris! Looking great so far