Right click on the your event, and you should see "add --> add else"

+1 for Minecraft.

But this means, we will have to keep track of the backward/forward in the events ourselves.

Ahh... so if that's really the true intention of the developer, for the feature to be coded that way, then it won't be a bug.

It is impossible to create a very big game in a short amount of time, and players play games very fast, which could make your game obsolete in hours if not days. Therefore, some game designers turn to grinding.

The point of grinding, is simple: to make player play the game longer and make the player keep on doing repetitive things over and over. Because let's face it, we can't produce a new Call of Duty every week.

Many games these days, some players have been caught in the psychological trap, where their ultimate goal is simply to reach the highest point in game possible. But up to this point, if you have played a few MMO or other games that require you to grind, have you ever feel "what have you been doing?" And then, you start thinking, "so if I reach Lv. 99, or got all collectibles, then what's next?".

What can we do to prevent this? How can we make grinding fun?

I am looking for some game design that makes the player wants more and enjoys the grinding. (or if possible, something beside grinding that is different to players almost every time, and not repetitive)

Am I looking for something that is impossible from the beginning? Because from what I've seen around from casual games to hardcore games, grinding becomes a chore that zombifies the players. Or am I missing something?

Link to .capx file (required!):

mediafire.com

Steps to reproduce:

The capx only has one sprite, called S1, which has 8 frames and has 8direction behavior, setting only to be able to move left and right.

In the event sheet, I simply have:

• Every tick: S1: set animation speed of this sprite to S1.8diection.Speed/30.

S1 has two animations: Default and pingpong. Both are identical, except having Ping Pong feature on or off.

Observed result:

Setting animation speed seems to cause ping pong feature to reset its state to "non-reversal". This will cause the animation sprite to stuck in the last few frames, instead of going back and forth. (run the .capx, try move left and right until you see frame 6-7 and you will see what I mean)

Expected result:

Setting animation speed should not interrupt ping pong feature.

Browsers affected:

Chrome: yes

Firefox: yes

Internet Explorer: yes

Operating system & service pack:

Win7 64 bits

Construct 2 version:

r152 64 bits

Lerp function! OK, rojohound's solution is what I am looking for. I can extend from it. Thanks LittleStain !

LittleStain Read this part from the link carefully:

low Hardware

Slow hardware can sometimes cause certain delays at some points, where the game gets ?heavy?. This can definitely occur with a 3D game, where at a certain time too many polygons get shown. This drop in frame rate will affect the input response time, and therefore also the player?s reaction time. The updating of the game will also feel the delay and the game state will be updated in big time-chunks. As a result the reaction time of the player, and also that of the AI, will slow down and can make a simple maneuver fail, or even impossible. For example, an obstacle that could be avoided with a normal FPS, can become impossible to avoid with a slow FPS. A more serious problem with slow hardware is that when using physics, your simulation can even explode

!

Fast Hardware

You are probably wondering how the above game loop can go wrong on fast hardware. Unfortunately, it can, and to show you, let me first explain something about math on a computer. The memory space of a float or double value is limited, so some values cannot be represented. For example, 0.1 cannot be represented binary, and therefore is rounded when stored in a double. Let me show you using python:

>>> 0.1

0.10000000000000001

This itself is not dramatic, but the consequences are. Let?s say you have a race-car that has a speed of 0.001 units per millisecond. After 10 seconds your race-car will have traveled a distance of 10.0. If you split this calculation up like a game would do, you have the following function using frames per second as input:

>>> def get_distance( fps ):

...     skip_ticks = 1000 / fps

...     total_ticks = 0

...     distance = 0.0

...     speed_per_tick = 0.001

...     while total_ticks < 10000:

...             distance += speed_per_tick * skip_ticks

...             total_ticks += skip_ticks

...     return distance

Now we can calculate the distance at 40 frames per second:

>>> get_distance( 40 )

10.000000000000075

Wait a minute? this is not 10.0??? What happened? Well, because we split up the calculation in 400 additions, a rounding error got big. I wonder what will happen at 100 frames per second?

>>> get_distance( 100 )

9.9999999999998312

What??? The error is even bigger!! Well, because we have more additions at 100 fps, the rounding error has more chance to get big. So the game will differ when running at 40 or 100 frames per second:

>>> get_distance( 40 ) - get_distance( 100 )

2.4336088699783431e-13

You might think that this difference is too small to be seen in the game itself. But the real problem will start when you use this incorrect value to do some more calculations. This way a small error can become big, and <img src="smileys/smiley35.gif" border="0"> up your game at high frame rates. Chances of that happening? Big enough to consider it! I have seen a game that used this kind of game loop, and which indeed gave trouble at high frame rates. After the programmer found out that the problem was hiding in the core of the game, only a lot of code rewriting could fix it.

Anyone else?

LittleStain check out koonsolo.com/news/dewitters-gameloop and you will know what I meant.

C2 decided to go with the "Game Speed dependent on Variable FPS". So to tackle this problem, we need some ways that make the values identical in every run.

LittleStain It would be a problem.

Imagine you are running around with 60 fps for now, then suddenly, the game drops to 20 fps for whatever reason. So here, your inputs are logged from 60 times a second and 20 times a second respectively.

If you feed your doppleganger's input that is 60 times a second in a 20 fps situation. The position of the doppleganger will be off.

See the problem?

Recall one of the final stages in Rayman, where there is this doppleganger following you and mimicking your every move?

I used to make something like that in other game engine that has fixed framerate, so I simply record all of player's moves, and then "inject" all these movements to the doppleganger x seconds later.

But in C2, with event running every tick and variable framerate, the method above is not possible. So in variable framerate game, ...how?

Google "Extra Credits". Those folks know stuff. They got 7 seasons right now.