Rocketjumping platform engine example.

Hai. Any Quake Live or Quake 3 fans here? Well, I've made a pretty good platform engine featuring rocketjumping. I wanted to make my own game using this, but realised I can't draw nice graphics.

Uhh, tell me what you think of it?

'Kay. Cya.

Edit: Well, I should mention it works in 360�, and uses the inverse square law. Doesn't that sound impressive? 'Kay. Cya for real this time.

Nice engine, but you're wasting a lot of events (wasting CPU power) by making it custom. This could be done much better with the built in platform movement, and it would allow for much more control. I'm also mentioning it would run many times faster than your example.

Well, I should mention it works in 360�

Ahh. Quotes like these bring me back to the shitty clickteam days where 360 degree anything was something impressive.. In Construct, Mentioning that something works in 360� is like saying that water is wet.

Welcome to the forums, and enjoy Constructs power.

360� movements are still more frustrating to implement in MMF2 than they need to be. Working with Construct on this engine was awesome fun. Hmm, I'll look at the default movement and update it if I think it's better. How much faster, anyway? It's not like I'm rotating and recolouring a thousand semi-transparent objects, here

Actually a custom engine doesn't give you more control at all. Just get acquainted which the all the abilities of the platform and custom movement behaviors, they are a lot faster than events(not saying events are slow either..), and will save you headaches. How much faster are they than using events? quite a bit if you have many objects.

Nice example, and it works great

[quote:j8d64kv3]Actually a custom engine doesn't give you more control at all.

Sure it can, if you make it that way. It all depends on what you're going for. Anyway, there's nothing wrong with making a custom platforming engine, and yeah one of the benefits is you can add as much control as you need, or don't need. But unless you're doing something non-standard with your engine, you might just be wasting time.

For basic things like gravity and collision you might as well use the built-in platform movement, because it already does it for you. You can apply the fancy inverse-square math to the platform movement's speed, thus enhancing the basic platform movement. It's just something to keep you from reinventing the wheel every time you want to make a game.

Generally speaking, the platform behavior will cover all the basics (and then some) for what you need it to do, and unlike the MMF platform behavior it's very well put together and flexible (it better be, David's been tweaking it for like two years ).

The only time you'd really need to make a custom platform movement is if you need special logic/drawing separation like kayin for his IWTBTG engine, or if you're making something like Sonic or Flashback that has non-standard platforming functionality. For everything else you can pretty much start with the built-in behavior and just add the features that you need to it (like swimming or ladders or double-jumping or whatever).

The main advantage of the platform behavior is its perfect ^^ Or at least I'm aiming for it to be, and if there is a bug Deadeye will be sure to find it and I will be sure to fix it! By using the platform movement, you dont have to waste your time trying to programming difficult things like slopes and platforms and moving platforms...they are all done for you. By manually overwriting the horizontal and vertical speed you can simply make an object that wont go through obstacles, and will automatically slide up and down slopes when they are approached horizontally.

The choice is yours of course, we're just letting u know that the behaviours are designed to be useful rather than quick alternatives for people who cant use events. btw, is the platform movement in mmf2 anymore decent? last I heard if you ran into a wall or fell on a corner you got stuck in the wall until you jumped

Nice engine, but you're wasting a lot of events (wasting CPU power) by making it custom

This is a classic case of armchair optimisation. You can't say statements like this without measured FPS differences between comparison .caps. I'd put money that there's no detectable difference, due to the parallel working between the CPU and GPU (the CPU will spend lots of time simply twiddling its thumbs waiting for the GPU, which does the serious work with rendering, to finish). So I say if it works for you and doesn't dent your FPS, go for it.

Don't feel bad though - it's common for supposedly experienced low-level programmers to make incorrect statements about optimisation - given the mind boggling complexity of modern CPU caches, pipelining and branch prediction, its virtually impossible to look at two bits of code and say for certain one is faster than the other.

If optimisation crosses your mind, the key is measure, measure, measure. Otherwise you don't know.

(in this case it's unlikely the built in behavior would ever be slower, that's not the point, if it's not measurable it's irrelevant)

The main advantage of the platform behavior is its perfect

Brave words from a man who's behavior accounts for over 5% of the total bugs submitted to Construct, ever!

theres no point in this being custom is all, in fact its just a waste of YOUR time. this can be 100% done with the platform behavior, and it would only take one event to add the rocket jumping funcionality, you wouldn't even need all these fancy detectors.

Thanks for the tips Ash, I know you're into getting the whole CPU/GPU parallelism thing to people, but I frequently work at 320x240 resolutions, which means the CPU is my main bottleneck. I hit the CPU bottleneck hard in my main large scale project (not bit fortress btw), and it's mainly due to a lot of offset collision checking and movement events. I'm all for making every little optimization, and in markys case, using all those collision checks and loops would lay hell to the cpu if many objects (100+) used his custom event code. Maybe i was a bit jumpy on the optimization gun, just trying to point out to a new user that behaviors are faster than using events in large-number-of-instance scenarios.

Maybe i was a bit jumpy on the optimization gun, just trying to point out to a new user that behaviors are faster than using events in large-number-of-instance scenarios.

Even that's a tricky statement - if the collision checks are bottlenecking your game (by the way, the collision checker is very highly optimised, so you must be absolutely HAMMERING the collision checker) then the overhead of the event engine is small compared to the collision checks. The overhead of the platform behavior is smaller - but the actual collision check is the heavy lifting here and both would do that - so again, would switching between one or the other really change the efficiency of collision checks?

> The main advantage of the platform behavior is its perfect

>

Brave words from a man who's behavior accounts for over 5% of the total bugs submitted to Construct, ever!

He's trying very hard

I think David deserves a cookie

Hahahah I lol'd IRL

Also, I compiled the thingy in 7 parses... >.>

~Sol

Hahahah I lol'd IRL

Also, I compiled the thingy in 7 parses... >.>

~Sol

Then post it, why let a perfectly good .cap go to waste?

>

> > The main advantage of the platform behavior is its perfect

> >

> Brave words from a man who's behavior accounts for over 5% of the total bugs submitted to Construct, ever!

>

He's trying very hard

I think David deserves a cookie

Notice how nearly all of them are closed

isnt platform most popular behavior