Development of indie games for Starling, or the second life of Flash
From the point of view of graphics, most indie games gain their popularity not by the number of polygons in the frame or super-quality textures, but by an unusual approach to art and attention to trifles, most using only 2D graphics. In my opinion, Flash is great for projects in this style. The flash in this case should be understood not only the browser plugin, which gradually gives up its position and gives way to HTML5, but the “eco-system” itself, which allows you to use the features and “ideology” of the flash to develop for desktop and mobile platforms. It will focus on Adobe AIR (cross-platform environment for running applications) and the Starling framework used in the development of indie games.
Under the cut - examples of practical solutions and animation effects.
The project is an advanced port of the once popular flash game for Steam, of course, in an expanded form (for example, the number of levels increased from 30 to 200+), and many of the “pitfalls” had to be revisited, on a different platform.
In the original flash game, content rasterization was used when the application was started (more precisely, when you first go from the main menu to the level selection screen). Each frame from each MovieClip was stored in a separate BitmapData object. Of course, the decision was very “clumsy”, but it was a good fit for a simple flash game.
')
In the version of the game for Steam (and later, perhaps, for mobile platforms), this option is not suitable for two reasons:
1. A large amount of memory occupied after rasterization. The data in MovieClip in Starling is transmitted through an array of textures. A texture can not only be loaded from a file, but created using data from BitmapData. However, in this case it is worth remembering that Starling (more precisely, the stage3D on which it is built) uses textures of the height and width of equal degree two. Those. a 130x160 pixel image will have a “size” in memory of 256x256.
2. Another disadvantage is a large number of draw calls. Fortunately, Starling has automatic image batching (outputting several sprites in one call to the graphics API) if they are inside the same texture.
The solution to the problem: the use of texture atlases.
Originally it was planned to generate atlases “on the fly” using DynamicTextureAtlas , and the entire game schedule would be stored in vector format.
After the test run, it turned out that flash-game resources (in the form of swc — closed source code class libraries) should have a well-defined structure, which was not suitable for existing developments. It also turned out that converting a vector to a raster (in fact, rendering each object frame by frame, and using Flash itself) takes quite a lot of time, and, the larger the object’s size in the game, the more rasterization took (it’s clear that pixels for 800x480 and 1920x1080 screens will be different at times).
In fact, it killed all the advantages of using vector graphics, namely, scalability without loss of quality. There was only one way out, the classic one - using pre-created texture atlases.
After saving all the graphics in the form of png files and creating atlases, it turned out that about 70% of the space was taken by frames of various effects, often quite simple. The solution to the problem was obvious - the replacement of three-dimensional animations (converted from a vector) in animations created from components. This provides significant space savings, because, say, a star burst effect (shown below), saved frame-by-frame and placed in an atlas, would occupy a texture of 1024x1024 pixels in size that would take 4 MB in memory, while the components of the animation total occupy no more than 128x128 pixels.
An example of a part of a texture atlas with individual animation frames:
And component parts of the effects:
Initially, I planned to use the base extension for Starling (Particle System), but after collecting a test project, a number of things came to light:
1. Even the richest selection of settings does not give what can be changed in the code yourself. For example, the formula for changing the speed of flight of a particle.
2. The editor is “sharpened” primarily on a realistic display of permanent sources of particles. An example is the flame of a burning candle. In our game, however, most of the effects are explosions.
An example of an effect from the Particle System editor:
As a result, it was decided to use samopisny effects editor.
Pros - the ability to connect not only the particle system, but also add sprites with a variable scale, rotation speed and alpha, and a set of parameters created based on the desires of the designer. Each of the effects consisted of several layers. 3 bottom layers - for individual sprites that change their scale, rotation angle and transparency. The top 3 - for the particle, as a rule - scattering from one point.
Effects examples
Comparison of effects from the flash version and made in the editor:
1. Animation explosion (on the left - flash version):
2. Animation of taking object (star), on the left - flash:
A separate advantage of the particle version is a tunable element of chance - each explosion / effect (of the same type) looks different, because the number of particles, their size and speed varied within certain limits set in the editor.
Another advantage of working with Starling is the available “out of the box” image processing effects. These effects in the game are used in several places, for example, after winning and the appearance of the results menu, the level background itself (and the objects remaining on it) gradually change.
Initially, we, as well as in the flash version, wanted to make an effect when the level picture is gradually “lit”, rotating clockwise (all this goes “background”, under the level results menu). But in the Starling version, the use of this effect very sharply reduced fps, even in the PC version of the game (from 50-60 to 2-3 frames per second).
Instead, it was decided to use the “fading” effect (going “snake” from left to right and from top to bottom through the elements), changing the transparency of the object and the data of the matrix of the ColorMatrixFilter filter, which made it possible to make a quite spectacular effect without fps drawdown.
In conclusion, I can say that the entire Flash eco-system allows the designer and programmer to “communicate in one language” when creating and polishing graphics, which allows paying more attention to the little things that create the atmosphere of the game, and performance problems arising from “clumsy” solutions, forced to look for workarounds and sometimes change some of the concepts that often benefit the final product.
Under the cut - examples of practical solutions and animation effects.
From vector to raster
The project is an advanced port of the once popular flash game for Steam, of course, in an expanded form (for example, the number of levels increased from 30 to 200+), and many of the “pitfalls” had to be revisited, on a different platform.
In the original flash game, content rasterization was used when the application was started (more precisely, when you first go from the main menu to the level selection screen). Each frame from each MovieClip was stored in a separate BitmapData object. Of course, the decision was very “clumsy”, but it was a good fit for a simple flash game.
')
In the version of the game for Steam (and later, perhaps, for mobile platforms), this option is not suitable for two reasons:
1. A large amount of memory occupied after rasterization. The data in MovieClip in Starling is transmitted through an array of textures. A texture can not only be loaded from a file, but created using data from BitmapData. However, in this case it is worth remembering that Starling (more precisely, the stage3D on which it is built) uses textures of the height and width of equal degree two. Those. a 130x160 pixel image will have a “size” in memory of 256x256.
2. Another disadvantage is a large number of draw calls. Fortunately, Starling has automatic image batching (outputting several sprites in one call to the graphics API) if they are inside the same texture.
The solution to the problem: the use of texture atlases.
Originally it was planned to generate atlases “on the fly” using DynamicTextureAtlas , and the entire game schedule would be stored in vector format.
After the test run, it turned out that flash-game resources (in the form of swc — closed source code class libraries) should have a well-defined structure, which was not suitable for existing developments. It also turned out that converting a vector to a raster (in fact, rendering each object frame by frame, and using Flash itself) takes quite a lot of time, and, the larger the object’s size in the game, the more rasterization took (it’s clear that pixels for 800x480 and 1920x1080 screens will be different at times).
In fact, it killed all the advantages of using vector graphics, namely, scalability without loss of quality. There was only one way out, the classic one - using pre-created texture atlases.
From animation to particles
After saving all the graphics in the form of png files and creating atlases, it turned out that about 70% of the space was taken by frames of various effects, often quite simple. The solution to the problem was obvious - the replacement of three-dimensional animations (converted from a vector) in animations created from components. This provides significant space savings, because, say, a star burst effect (shown below), saved frame-by-frame and placed in an atlas, would occupy a texture of 1024x1024 pixels in size that would take 4 MB in memory, while the components of the animation total occupy no more than 128x128 pixels.
An example of a part of a texture atlas with individual animation frames:
And component parts of the effects:
Creating a particle editor
Initially, I planned to use the base extension for Starling (Particle System), but after collecting a test project, a number of things came to light:
1. Even the richest selection of settings does not give what can be changed in the code yourself. For example, the formula for changing the speed of flight of a particle.
2. The editor is “sharpened” primarily on a realistic display of permanent sources of particles. An example is the flame of a burning candle. In our game, however, most of the effects are explosions.
An example of an effect from the Particle System editor:
As a result, it was decided to use samopisny effects editor.
Pros - the ability to connect not only the particle system, but also add sprites with a variable scale, rotation speed and alpha, and a set of parameters created based on the desires of the designer. Each of the effects consisted of several layers. 3 bottom layers - for individual sprites that change their scale, rotation angle and transparency. The top 3 - for the particle, as a rule - scattering from one point.
Effects examples
Comparison of effects from the flash version and made in the editor:
1. Animation explosion (on the left - flash version):
2. Animation of taking object (star), on the left - flash:
A separate advantage of the particle version is a tunable element of chance - each explosion / effect (of the same type) looks different, because the number of particles, their size and speed varied within certain limits set in the editor.
Effects of image processing
Another advantage of working with Starling is the available “out of the box” image processing effects. These effects in the game are used in several places, for example, after winning and the appearance of the results menu, the level background itself (and the objects remaining on it) gradually change.
Initially, we, as well as in the flash version, wanted to make an effect when the level picture is gradually “lit”, rotating clockwise (all this goes “background”, under the level results menu). But in the Starling version, the use of this effect very sharply reduced fps, even in the PC version of the game (from 50-60 to 2-3 frames per second).
Instead, it was decided to use the “fading” effect (going “snake” from left to right and from top to bottom through the elements), changing the transparency of the object and the data of the matrix of the ColorMatrixFilter filter, which made it possible to make a quite spectacular effect without fps drawdown.
findings
In conclusion, I can say that the entire Flash eco-system allows the designer and programmer to “communicate in one language” when creating and polishing graphics, which allows paying more attention to the little things that create the atmosphere of the game, and performance problems arising from “clumsy” solutions, forced to look for workarounds and sometimes change some of the concepts that often benefit the final product.
Source: https://habr.com/ru/post/274157/
All Articles