Minimalistic Example: Arrow Walker

[cjcat2266]

Hi, I've just started trying out PushButton Engine and I must say it's brilliant!
This is my first attempt to create a PushButton Engine application.
I've written down my development steps. You can check it out here.

This example is definitely too simple for users familiar with the engine.
But I hope it can help others who are interested in the engine and are just about to start trying it out, like me

[lithander]

Nice blog you got there! I've had a quick glance at the particle engine of yours and noticed that unlike Flint your's supports XML serialisation. This (serialization in human readable xml) is also one of the main features of PBE's component based structure. Have you considered to integrate your particle engine into PBE by providing a set of related components?

Might even be able to sell the results in the component store!

[cjcat2266]

Have you considered to integrate your particle engine into PBE by providing a set of related components?

Yes, I've thought about doing that. But I just need some more time to get familiar with PBE
Also, I'm trying to come up with a way to best integrate it with my particle engine.

[thecreatrix]

I love your particle engine, and integration with PBE is (was?) on my roadmap. I hope you'll do something "official" with it.

[Nitrev]

Thanks for the example. As you said, for people starting with this engine (like me ) it gives a nice place to start from. Thanks to your example, I'm already working on my own variations of mover components. I have to admit that programming for games it completely new to me (I normally just do the more standard webdevelopment stuff), so things like tickrate etc are new to me. Which leads me to the following bit:

Code: Select all

//time alignment
dx *= tickRate;
dy *= tickRate;


I can read what's happening there, but I have no idea why it's necessary. Care to explain?

[lithander]

Remember the old DOS games and how unplayable fast the ran on newer PCs? This was because the game code of these days lacked lines like these! They are intended to make the game behave the same no matter of how often the simulation is updated per second - or in PBE terms: how many onTick events are fired per second. The tickRate parameter is the time in seconds since the last onTick event. More ticks per second means a smaller tickRate. so you have more ticks but change less -> after a second it comes down to the same thing no matter how many ticks you received. Thats the idea.

In PBE onTick will fire onTIck events at a fixed framerate though. The quoted code is not necessary to have framerate independency. But it doesn't hurt to have them: If nothing else they allow you to think of the dx as "horizontal movement in pixel per second" which is a pretty human understandable unit of measurement!

[bengarney]

It will also save your butt if you decide to change the tick rate halfway through your project.

Nice explanation, lithander.

[Nitrev]

*explanation about tickrate*

My apologies that I didn't reply or give thanks for the explanation, I kind of got distracted with other things so I haven't been able to play around with the engine as much as I'd like.

So if I understand correctly, if you don't utilize tickRate, it would come down to how fast your computer is able to process everything, and in doing so possibly distorting the game's speed (your example of DOS games on modern computers).

When you do utilize it, it would remain constant based on the tickRate, as long as the computer is able to keep up with the rate (as inverse to your example, playing a game made with PBE on a 486 DXII (yes I'm old) probably wouldn't be able to keep up with the tickrate).

So ideally, every piece of code dealing with animating/moving an entity would have to factor in the tickRate right?

My apologies if I keep droning on about it, but it seems like tickRate is a core concept when dealing with game engines, so I want to make sure I have a solid grasp of the concept.