Tuning Canabalt
An attempt was made to preserve the original spelling, jokes and punctuation. And yes, this post is a translation of the article by the creator of Canabalt, do not think that I created the game.
[This article reviews the technical features, ratios, and sizes of the Canabalt Flash version of the game. Reader, be careful, the article contains spoilers and a large number of numbers!]
')
Friends often ask me: have I thought about putting the source code of my Canabalt Flash game on the Internet for mercy and study. They think that it will be useful for people to see how physics and other things are organized in the game. But I am concerned about this idea, for which I have several reasons, for example: the source code of the game, written in 5 days, is a horrible and disgusting spaghetti code that is unlikely to help anyone. Therefore, out of pride about the first birthday of Cannabalt, I thought: “why not write an article that tells how everything is arranged inside?”
One of my goals during the development of Canabalt was to create a game that would require a quick reaction, sharp as a blade, a game from which palms sweat. Making such a game in 2D is not so easy. 3D games allow you to look into the distance, for long distances, unlike them, 2D games, as a rule, do not give the same sensations. You can move the camera back so that players can see more, but if you do this, objects will move more slowly.
The visible area of ​​the game is 480 px wide and 160 px high. Regular web-version of Canabalt is displayed in double size (960x320), and MEGA-assembly has a resolution of 3 times more. But inside the game works with a resolution of 480x160 px, it needs to be remembered to understand some of the nuances of the article, since all the sizes and speeds described, which will be discussed, will be specified in px as well.
Why 480x160? Simply, it helped us avoid problems with the speed of objects. Such dimensions allow players to look far enough ahead to be able to respond to obstacles more effectively, and also maintains a cool and compact window size, creating a sense of speed. By the way, we'll talk about speed a little later!
The visible area of ​​the game can be 480x160 px, but the Canabalt world starts at width from 0 and lasts to infinity, while maintaining a height of 320 px. I really wanted to leave a small vertical scrolling to create a parallax effect for buildings in the background. You may notice how they move up and down, and this helps create a sense of "depth." Obviously, the more vertical space there is for the player, the better, it allows you to create falling objects and facades of larger houses. Falling objects are one of the most spectacular pieces in the world of parkour / free running, so I really wanted to add them to the game.
A running man is a 24x24 px sprite, but its bounding box is smaller. All buildings, more or less, fit into a 16x16 px grid. Background scrolling is created from 3 480x320 px pictures. I used 2 pictures for the nearest background layer. It’s more efficient to make them 960 px wide, to create additional variety. For the far background, I used 1 image and slowly moved it, as this is a less noticeable background layer.
AT
Flixel (the Flash library with which Canabalt was developed) objects can be assigned a “scrolling factor” ( scrollFactor ), which affects how objects should move in comparison with other objects. This means that if objects were assigned a “scrolling factor” with a magnitude of (1.1), and their position changed by 20 px horizontally, then on the screen their position also changed to 20 px. If the “scrolling factor” is (0.5, 1), this means that with such a change in position, the objects will visually shift only by 10 px. In Canabalt, for scattered background layers, the “scrolling factor” is (0.15, 0.1), and for nearby ones (0.4, 0.2). Such “settings” allow us to create some distance between the player and the space invaders on the background; besides, we can be sure that buildings will not “fly with a whistle” past us if the player reaches “supersonic speed”.
One of my goals was to create animation in Canabalt, similar to animation in the games I grew up with ( Flashback and Prince Of Persia ). These games used realistic rotoscopic animation with a large number of frames, each game had a special style, and the animation in these games looked cool. In Canabalt, the running man has only 4 types of animation (running, sliding, jumping and falling), but despite this, the animation consists of 38 frames, about half of which are devoted to running animation.
As we learned earlier, in Canabalt, the image of a running man measures 24x24 px. For comparison, it is slightly larger in height than the size of a regular Mario in Super Mario Bros. but a bit smaller than the size of the “super” Mario, and a little wider than both. If you look at the other side, the character’s height is about 15% of the height of the visible part of the world. As you can see, the character does not use the entire space of the 24x24 rectangle, most of this space is used to animate the fall and spread the arms during the jump. The “hitbox” of the running man (the “real dimensions” of the object with which the game engine works) is much smaller, and is about 12x14 px. In the picture you can see that the “real size” is not just located in the center of the character, but shifted to its lower border and slightly to the left.
The “hitbox” setting is a very important part of creating a game, even if you are using a circle, and not rectangular objects. Tweaking hitbox helps to adjust the difficulty of the game, making it simpler or more difficult to play, depending on what you want to achieve. I wanted to make the game more simple, but you need to understand that such a setup involves more than just reducing or increasing the size.
Since more time in the game is spent jumping over rooftops and over other objects (or at least trying to do this), I tried to set up the character's hitbox so that these actions look as natural as possible. Due to the fact that the "hitbox" does not go ahead of the character, the player can go very close to the obstacles without causing a collision or stumbling. Due to the fact that the hitbox is a little to the left of the character, it is possible to “run across” the building a bit, but have time to jump at the last moment. All these nuances simplify the game a little, requiring less reaction from the players, which allowed me to add more complex obstacles without fear of upsetting the players too much.
Oh, yes, I almost forgot, the obstacles of the "hitboxes" also look funny, they are only 2 px in height! =) It also simplifies the game, and allows you to avoid the moments when players say “What ?! What the hell ... me ?! I normally jumped over this e ... obstacle! Mistress, not a single gap! ”.
As we said earlier, the screen size is 480x160 px. The biggest possible speed of a character is 800 px per second, which in game units is about 80 meters per second, or about 286 km per hour! It's very fast. But despite this, given the fact that the width of the visible area is 480 px, and the character is at its left edge, players have more than half a second (480/800) to react to any obstacles. In my opinion, this is a good window size, in my opinion, people need about 0.3 seconds to react to unexpected events. Therefore, technically, even on the greatest difficulty, people can play Canabalt.
But players do not start running at 800 px / sec. from the very beginning. At the beginning of the game, the speed is 100 px / sec. Also, the game has an acceleration curve for the character, so at a speed from 0 to 100 px / sec. acceleration is 50 px / s, at a speed of 100-250 px / s. acceleration is 30 px / s, at a speed of 250-400 px / s, acceleration is 20 px / s, and at a speed of 400-800 px / s, acceleration is 10 px / s. Simply put, the faster you move, the slower you accelerate. This means that it takes a long time to reach the highest speed, but it is possible to quickly reach the average speed after tripping. In Canabalt, obstacles (chairs, boxes, etc.) reduce the player’s speed by 30%. If the player is running at a speed of 300 px / sec. (acceleration 20 px / s), then after a collision with an obstacle, its speed will decrease to 210 px / s, and acceleration will increase to 30 px / s.
Also, Canabalt uses funny character jumping rules: the longer you hold the jump button, the higher you will jump. This is done using a timer that starts counting when the player presses the jump button, and until the timer expires or until the player releases the jump button, we set the character to a vertical speed of 300 px / sec. (To be precise, the speed is set to -300, since negative values ​​mean "top" in 2D games, but to hell with it).
But that is not all! The timer time will change depending on your speed, the slower you run, the faster the timer expires, no matter how long you press the jump button. With this, we have achieved that the faster a character runs, the longer he stays in the air. The maximum value of the timer can reach 0.35 seconds. Also, I added another small change to the rules of the jump: if the timer was created recently (if less than 0.08 sec. Has passed since the button was pressed), then the vertical speed of the character is set to 200 px / s, not 300 px / s . This allows players to not jump too much if they quickly press the jump button, but at the same time, it does not look strange if the jump button is pressed for a normal jump.
Even when the prototype of the game was still very new, I was pretty sure that the game would use roofs. This idea fits perfectly into the mechanics of the game. In the earliest prototypes of the game, large green rectangles were used with an empty space between them, and I needed quite a bit of imagination to see a running dude in place of a white rectangle, and buildings in place of a green rectangle. The dimensions of the objects fit well with this idea. With this, I completed the development of a system of roofs, walls and fills consisting of 16x16 px tiles that could be moved, repeated and combined in various ways to meet the graphic requirements of these settings.
(Note to Flixel users: I created a custom object based on the FlxTilebock class, which provided me with random tiles of interior building sections, and also allowed me to customize specific tiles for use at the edges of each block. Most of the buildings use only 2 custom objects FlxTileblocks, without taking into account roofs. Buildings with corridors, in my opinion, consist of 7 similar objects).
Like many other important Canabalt elements, buildings also have hitbox settings. Buildings are simply large rectangles, but they have a small (8 px, to be exact) space, “hanging” on the right side. This indent is added to the size of the building and forms the “real size” of the building, or, if you look at it from the other side, the size of the building that the game “sees”. This is another way to simplify the game for those who press a button only a fraction-second later than they need, they want to make this jump, but they’re late a little bit, so we “go to meet them” and simplify it a bit them play All these settings affect the "fan" derived from the game.
I hope that this article was interesting and useful for you! Also, I would like to add that Canabalt was not developed analytically, I did not measure the character’s ideal speed based on the ratio of objects when I was developing the game. I just did what we usually do: I changed a large number of parameters until I felt that everything was cool in the game. In the article I tried to tell at least some of the reasons by which I managed to achieve this. I would be very happy if I managed it.
[This article reviews the technical features, ratios, and sizes of the Canabalt Flash version of the game. Reader, be careful, the article contains spoilers and a large number of numbers!]
')
Friends often ask me: have I thought about putting the source code of my Canabalt Flash game on the Internet for mercy and study. They think that it will be useful for people to see how physics and other things are organized in the game. But I am concerned about this idea, for which I have several reasons, for example: the source code of the game, written in 5 days, is a horrible and disgusting spaghetti code that is unlikely to help anyone. Therefore, out of pride about the first birthday of Cannabalt, I thought: “why not write an article that tells how everything is arranged inside?”
Dimensions
One of my goals during the development of Canabalt was to create a game that would require a quick reaction, sharp as a blade, a game from which palms sweat. Making such a game in 2D is not so easy. 3D games allow you to look into the distance, for long distances, unlike them, 2D games, as a rule, do not give the same sensations. You can move the camera back so that players can see more, but if you do this, objects will move more slowly.
The visible area of ​​the game is 480 px wide and 160 px high. Regular web-version of Canabalt is displayed in double size (960x320), and MEGA-assembly has a resolution of 3 times more. But inside the game works with a resolution of 480x160 px, it needs to be remembered to understand some of the nuances of the article, since all the sizes and speeds described, which will be discussed, will be specified in px as well.
Why 480x160? Simply, it helped us avoid problems with the speed of objects. Such dimensions allow players to look far enough ahead to be able to respond to obstacles more effectively, and also maintains a cool and compact window size, creating a sense of speed. By the way, we'll talk about speed a little later!
The visible area of ​​the game can be 480x160 px, but the Canabalt world starts at width from 0 and lasts to infinity, while maintaining a height of 320 px. I really wanted to leave a small vertical scrolling to create a parallax effect for buildings in the background. You may notice how they move up and down, and this helps create a sense of "depth." Obviously, the more vertical space there is for the player, the better, it allows you to create falling objects and facades of larger houses. Falling objects are one of the most spectacular pieces in the world of parkour / free running, so I really wanted to add them to the game.
A running man is a 24x24 px sprite, but its bounding box is smaller. All buildings, more or less, fit into a 16x16 px grid. Background scrolling is created from 3 480x320 px pictures. I used 2 pictures for the nearest background layer. It’s more efficient to make them 960 px wide, to create additional variety. For the far background, I used 1 image and slowly moved it, as this is a less noticeable background layer.
AT
Player
One of my goals was to create animation in Canabalt, similar to animation in the games I grew up with ( Flashback and Prince Of Persia ). These games used realistic rotoscopic animation with a large number of frames, each game had a special style, and the animation in these games looked cool. In Canabalt, the running man has only 4 types of animation (running, sliding, jumping and falling), but despite this, the animation consists of 38 frames, about half of which are devoted to running animation.
As we learned earlier, in Canabalt, the image of a running man measures 24x24 px. For comparison, it is slightly larger in height than the size of a regular Mario in Super Mario Bros. but a bit smaller than the size of the “super” Mario, and a little wider than both. If you look at the other side, the character’s height is about 15% of the height of the visible part of the world. As you can see, the character does not use the entire space of the 24x24 rectangle, most of this space is used to animate the fall and spread the arms during the jump. The “hitbox” of the running man (the “real dimensions” of the object with which the game engine works) is much smaller, and is about 12x14 px. In the picture you can see that the “real size” is not just located in the center of the character, but shifted to its lower border and slightly to the left.
The “hitbox” setting is a very important part of creating a game, even if you are using a circle, and not rectangular objects. Tweaking hitbox helps to adjust the difficulty of the game, making it simpler or more difficult to play, depending on what you want to achieve. I wanted to make the game more simple, but you need to understand that such a setup involves more than just reducing or increasing the size.
Since more time in the game is spent jumping over rooftops and over other objects (or at least trying to do this), I tried to set up the character's hitbox so that these actions look as natural as possible. Due to the fact that the "hitbox" does not go ahead of the character, the player can go very close to the obstacles without causing a collision or stumbling. Due to the fact that the hitbox is a little to the left of the character, it is possible to “run across” the building a bit, but have time to jump at the last moment. All these nuances simplify the game a little, requiring less reaction from the players, which allowed me to add more complex obstacles without fear of upsetting the players too much.
Oh, yes, I almost forgot, the obstacles of the "hitboxes" also look funny, they are only 2 px in height! =) It also simplifies the game, and allows you to avoid the moments when players say “What ?! What the hell ... me ?! I normally jumped over this e ... obstacle! Mistress, not a single gap! ”.
Character movements
As we said earlier, the screen size is 480x160 px. The biggest possible speed of a character is 800 px per second, which in game units is about 80 meters per second, or about 286 km per hour! It's very fast. But despite this, given the fact that the width of the visible area is 480 px, and the character is at its left edge, players have more than half a second (480/800) to react to any obstacles. In my opinion, this is a good window size, in my opinion, people need about 0.3 seconds to react to unexpected events. Therefore, technically, even on the greatest difficulty, people can play Canabalt.
But players do not start running at 800 px / sec. from the very beginning. At the beginning of the game, the speed is 100 px / sec. Also, the game has an acceleration curve for the character, so at a speed from 0 to 100 px / sec. acceleration is 50 px / s, at a speed of 100-250 px / s. acceleration is 30 px / s, at a speed of 250-400 px / s, acceleration is 20 px / s, and at a speed of 400-800 px / s, acceleration is 10 px / s. Simply put, the faster you move, the slower you accelerate. This means that it takes a long time to reach the highest speed, but it is possible to quickly reach the average speed after tripping. In Canabalt, obstacles (chairs, boxes, etc.) reduce the player’s speed by 30%. If the player is running at a speed of 300 px / sec. (acceleration 20 px / s), then after a collision with an obstacle, its speed will decrease to 210 px / s, and acceleration will increase to 30 px / s.
Also, Canabalt uses funny character jumping rules: the longer you hold the jump button, the higher you will jump. This is done using a timer that starts counting when the player presses the jump button, and until the timer expires or until the player releases the jump button, we set the character to a vertical speed of 300 px / sec. (To be precise, the speed is set to -300, since negative values ​​mean "top" in 2D games, but to hell with it).
But that is not all! The timer time will change depending on your speed, the slower you run, the faster the timer expires, no matter how long you press the jump button. With this, we have achieved that the faster a character runs, the longer he stays in the air. The maximum value of the timer can reach 0.35 seconds. Also, I added another small change to the rules of the jump: if the timer was created recently (if less than 0.08 sec. Has passed since the button was pressed), then the vertical speed of the character is set to 200 px / s, not 300 px / s . This allows players to not jump too much if they quickly press the jump button, but at the same time, it does not look strange if the jump button is pressed for a normal jump.
Roofs
Even when the prototype of the game was still very new, I was pretty sure that the game would use roofs. This idea fits perfectly into the mechanics of the game. In the earliest prototypes of the game, large green rectangles were used with an empty space between them, and I needed quite a bit of imagination to see a running dude in place of a white rectangle, and buildings in place of a green rectangle. The dimensions of the objects fit well with this idea. With this, I completed the development of a system of roofs, walls and fills consisting of 16x16 px tiles that could be moved, repeated and combined in various ways to meet the graphic requirements of these settings.
(Note to Flixel users: I created a custom object based on the FlxTilebock class, which provided me with random tiles of interior building sections, and also allowed me to customize specific tiles for use at the edges of each block. Most of the buildings use only 2 custom objects FlxTileblocks, without taking into account roofs. Buildings with corridors, in my opinion, consist of 7 similar objects).
Like many other important Canabalt elements, buildings also have hitbox settings. Buildings are simply large rectangles, but they have a small (8 px, to be exact) space, “hanging” on the right side. This indent is added to the size of the building and forms the “real size” of the building, or, if you look at it from the other side, the size of the building that the game “sees”. This is another way to simplify the game for those who press a button only a fraction-second later than they need, they want to make this jump, but they’re late a little bit, so we “go to meet them” and simplify it a bit them play All these settings affect the "fan" derived from the game.
In custody
I hope that this article was interesting and useful for you! Also, I would like to add that Canabalt was not developed analytically, I did not measure the character’s ideal speed based on the ratio of objects when I was developing the game. I just did what we usually do: I changed a large number of parameters until I felt that everything was cool in the game. In the article I tried to tell at least some of the reasons by which I managed to achieve this. I would be very happy if I managed it.
Source: https://habr.com/ru/post/120302/
All Articles