Cyto: creating a level editor, adapting to the iPhone and other utilities
Hi, Habr! We continue to share our practical experience in developing games for iOS from scratch. In this case, there were a lot more pitfalls than we could have imagined when we began development. Disrupting the deadlines, unnatural (at first glance) requirements of publishers and Apple, crooked free engines ... This is only part of what we had to spend our time and energy on.
In the last article we talked about the choice of the engine and how we achieved high-quality pictures and the natural behavior of the elastic shell of our main character. Below, we will talk about our level editor and touch on the burning topic of how to mercilessly trim your child to an acceptable size, as well as adapt the game for a miniature iPhone screen reader. And finally, we will give a few more useful tips for which they themselves would have given the left kidney a year ago.
Carefully, under the cut a lot of pictures!
')
In this article we tell exactly the technical details of the development, so if anyone is interested to know where it came from, how the idea developed and why it is worthwhile to appreciate the advice of publishers - read our Dev Story on iphones.ru.
One of the first gameplay videos Cyto. Compare with the release version - click
When it came time to make up the levels for the game, we realized that this process takes us an unrealistic lot of time. All changes were made blindly in the level file, but in order to check what happened, it was necessary to completely recompile the project, which, by that time, had already become quite large. It took half a day to assemble one more or less imputed level. We had a choice - to spend a lot of time and energy on drawing up levels or to allocate some time to create a visual editor and forget about the problems with level design. The choice was obvious. However, the time for this eventually went away, of course, twice as much as planned. Having spent twice as long as we expected, we built our Level Editor, with blackjack and whores.
Embedding the ability to edit existing functionality turned out to be another entertainment. Whatever game you do, be sure to include the ability to edit, save and load game objects at an early stage, and the more flexible this feature is, the better. The debug console, by the way, also does not hurt, although we did not add it. How to organize work with the level editor depends on the specific project. For us, the most convenient approach was editing the levels directly on the iPad. You can play the "freshly picked" level right away, literally with one tap.
We decided to use a very simple workflow:
The database of levels is stored on the FTP server, all devices are synchronized with it and store a local copy of the database. After the work on the level is completed, it can be downloaded to the server. This makes it possible for several level designers to simultaneously participate in the process, as well as work quietly on the levels in the absence of the Internet, being, for example, in an airplane (there have been cases), and when a network appears, simply upload the results of your work to the server.
After all the levels are ready, they are already manually pulled from the server and added to the project - the approved levels in the build are always separated from the edited ones, thus eliminating the possibility of accidentally changing the finished level.
By the way, the indispensable thing was the small preview pictures of the locations, which are stitched by the editor directly into the level file. Without them, it would have been impossible to sort through several hundred Levels.
We paid a lot of attention to the convenience of creating and editing. Level Editor turned out to be more like an app from the App Store than an internal development tool. When we completed it, creating levels was as enjoyable as playing them.
One unexpected surprise was waiting for us at the end of the development. When we started working with Chillingo Publisher, they emphasized the importance of the “ keep within 50MB ” item . Not for nothing almost all the top games on the App Store are less than 50 meters. There is no exact statistics on this, but it may well be that the size of the application is much more important than the minimum supported version of iOS.
We knew about the limit for cellular networks before, but did not give it enough attention. By that time, the Cyto build was over 150MB. The size of the application had to be reduced three times! "This is unreal ... It is not worth it ...", - we thought and started optimizing the size. It turned out to be quite real, although not so easy.
After examining the size distribution for different resources in the application, it turned out that the largest places were occupied by huge atlases with animations of game objects. We wanted to make the world of each level pack unique, with its own graphic elements and colors. For each of the worlds, their cells, backgrounds, portals were painted - each pack had a completely original art.
In some places we tried to set the color to the sprites (there is such a function in cocos2d). It was terrible. Repainting objects with embedded coconut means was no good. We wanted to achieve the same effect as in Photoshop, where you can completely change the hue of the image without losing any details.
It turned out to be sufficient to apply the HSV color model, and everything fell into place. Although it was possible to perform all these color manipulations directly in the shader (by that time Cyto had already moved to cocos2d 2.0 for a long time), this would mean a constant extra load on the device. Since during the game we did not need to dynamically change the colors of the objects, it was decided to change the color of the texture immediately when it was loaded.
Googling a bit, we found some ready-made solutions for converting from RGB to HSV, for example, here . Screwing this to the test case, we realized that this is exactly what we wanted. As a result, the necessary colors were beautifully substituted for each pack and our designers were extremely pleased with the result.
Nevertheless, even using one set of basic objects for all packs, we could not keep within the required size. All the same, there were huge atlases with separate animations of objects that should be unique for each world.
The most effective approach was to replace the frame-by-frame animation of entire objects with software animation of individual elements of these objects, although it had to be done with a hard code. But as a result, we also received a bonus in the form of the dynamism and liveliness of these animations - there is practically no cycling in them, everything moves randomly within the specified limits. In addition, an object composed of several small elements looks much better when scaled than a similar object drawn by one sprite.
Something like this atlases before and after optimization
Another trick that had to go - the backgrounds in the menu and in levels. All of them, in fact, are made in a fairly small resolution and only under SD screens, no @ 2x pictures. The fact is that the textures in the coconut with an increase are filtered in such a way that it turns out quite beautiful and, most importantly, free blur. The main thing is to prepare the source code correctly so that they already have minimal blurring and no sharp lines, otherwise you will get a picture with blurred squares instead of a blur.
For some textures, we additionally added a program blur. It occurs, as well as repainting, at the stage of loading the texture. We took AWTextureFilter as a basis .
As a result, we got our own sprite, which can be repainted and blur, and working with it is limited to just one line:
There remained the last step - to optimize the already significantly “thinner” game resources. And again, it did not take long to search. We came across two free utilities that work in pairs - ImageAlpha and ImageOptim . The result of their work is simply amazing! In some cases, they can reduce the file size by 80-90%, with almost no deterioration in image quality.
After all these tricks, we were surprised to find for ourselves that the build was reduced from 150 to 30 megabytes. 5 times! There is nothing impossible and it makes no sense to reinvent the wheel - you only need to correctly apply the solutions from which we are separated only by a single search query.
Cyto - first of all, a game for iPad. On the iPhone, of course, you can play and some even like the iPhone version more, but, in our opinion, the sensations are a bit different. It's still a game that requires maximum interaction with it, and even a slightly extended iPhone 5 screen will not give half of those sensations that can be obtained by playing on the iPad.
However, the adaptation of the game for a small screen had to work hard. The first thing was added zoom camera. The player can bring the scene a little closer to more accurately aim. I had to experiment a lot with the zoom level. At first I wanted to make it possible to bring the camera to the maximum, as far as art allowed. As it turned out, this did not add anything to the player except for a heap of inconvenience, although it looked very nice ... Therefore, we decided to limit the zoom as much as possible.
You can never do and evaluate something in isolation from the overall picture, you need to look at the result in the aggregate. Even if some thing seems to be super brilliant, but spoils at least some part of the overall result, it must be safely thrown away. Especially scrupulous about this should be approached in the issue of gameplay. If any element that does not make the gameplay better worsens even a small part of it, this should by no means be left as it is.
After watching a couple of levels on a small screen, it immediately became clear that you can’t just take and reduce the levels from the iPad to the iPhone. Urgently had to adapt the levels. The levels on both platforms look the same, but if you look closely, they differ in details.
Levels on the iPhone were created in the editor on the iPad. We added the ability to display a frame corresponding to the actual size of the level on the iPhone screen. Moreover, the same level was immediately adjusted to the resolution of the iPhone 5, and for older devices.
Immediately on the iPad, you can try to play in the iPhone-new level - as seen in the screenshots, the picture on the iPad is no different from that on the iPhone. However, the biggest difficulty was not just to pack the same level in space almost one and a half times smaller. Although the pictures look identical, the gameplay on the tablet is fundamentally different from that on the phone, where the player covers with his finger almost a quarter of the location.
As a result, the iPhone version of the game turned out to be quite “playable”, although far from ideal in our understanding. By the way, the statistics of the distribution of devices on which people play Cyto were a surprise for us: the number of iPhones exceeds the iPad by 20%, although we focused mainly on the iPad platform. Apparently, it affects the fact that the application is universal, and the number of iPhones on the market significantly exceeds the iPad.
We turn to the conclusions. If we sum up all of the above, then the main thing that we have learned over the entire development period is that the main component of the project’s success is implementation, not the idea. Contrary to popular belief, it doesn’t matter what inspired the game designer when creating the project. The main thing - that he could eventually show the players. And, no matter how important and ingenious some ideas would seem, if they do not make your gameplay better - they are worth nothing. And on the other hand, if even the most banal and all-used element will help improve your gameplay - apply it in your game.
In addition, novice developers (and ourselves a year ago) would like to advise the following things:
In the last article we talked about the choice of the engine and how we achieved high-quality pictures and the natural behavior of the elastic shell of our main character. Below, we will talk about our level editor and touch on the burning topic of how to mercilessly trim your child to an acceptable size, as well as adapt the game for a miniature iPhone screen reader. And finally, we will give a few more useful tips for which they themselves would have given the left kidney a year ago.
Carefully, under the cut a lot of pictures!
')
In this article we tell exactly the technical details of the development, so if anyone is interested to know where it came from, how the idea developed and why it is worthwhile to appreciate the advice of publishers - read our Dev Story on iphones.ru.
One of the first gameplay videos Cyto. Compare with the release version - click
How to make a level design nice
When it came time to make up the levels for the game, we realized that this process takes us an unrealistic lot of time. All changes were made blindly in the level file, but in order to check what happened, it was necessary to completely recompile the project, which, by that time, had already become quite large. It took half a day to assemble one more or less imputed level. We had a choice - to spend a lot of time and energy on drawing up levels or to allocate some time to create a visual editor and forget about the problems with level design. The choice was obvious. However, the time for this eventually went away, of course, twice as much as planned. Having spent twice as long as we expected, we built our Level Editor, with blackjack and whores.
Embedding the ability to edit existing functionality turned out to be another entertainment. Whatever game you do, be sure to include the ability to edit, save and load game objects at an early stage, and the more flexible this feature is, the better. The debug console, by the way, also does not hurt, although we did not add it. How to organize work with the level editor depends on the specific project. For us, the most convenient approach was editing the levels directly on the iPad. You can play the "freshly picked" level right away, literally with one tap.
We decided to use a very simple workflow:
The database of levels is stored on the FTP server, all devices are synchronized with it and store a local copy of the database. After the work on the level is completed, it can be downloaded to the server. This makes it possible for several level designers to simultaneously participate in the process, as well as work quietly on the levels in the absence of the Internet, being, for example, in an airplane (there have been cases), and when a network appears, simply upload the results of your work to the server.
After all the levels are ready, they are already manually pulled from the server and added to the project - the approved levels in the build are always separated from the edited ones, thus eliminating the possibility of accidentally changing the finished level.
By the way, the indispensable thing was the small preview pictures of the locations, which are stitched by the editor directly into the level file. Without them, it would have been impossible to sort through several hundred Levels.
We paid a lot of attention to the convenience of creating and editing. Level Editor turned out to be more like an app from the App Store than an internal development tool. When we completed it, creating levels was as enjoyable as playing them.
Trim the game five times
One unexpected surprise was waiting for us at the end of the development. When we started working with Chillingo Publisher, they emphasized the importance of the “ keep within 50MB ” item . Not for nothing almost all the top games on the App Store are less than 50 meters. There is no exact statistics on this, but it may well be that the size of the application is much more important than the minimum supported version of iOS.
We knew about the limit for cellular networks before, but did not give it enough attention. By that time, the Cyto build was over 150MB. The size of the application had to be reduced three times! "This is unreal ... It is not worth it ...", - we thought and started optimizing the size. It turned out to be quite real, although not so easy.
After examining the size distribution for different resources in the application, it turned out that the largest places were occupied by huge atlases with animations of game objects. We wanted to make the world of each level pack unique, with its own graphic elements and colors. For each of the worlds, their cells, backgrounds, portals were painted - each pack had a completely original art.
In some places we tried to set the color to the sprites (there is such a function in cocos2d). It was terrible. Repainting objects with embedded coconut means was no good. We wanted to achieve the same effect as in Photoshop, where you can completely change the hue of the image without losing any details.
It turned out to be sufficient to apply the HSV color model, and everything fell into place. Although it was possible to perform all these color manipulations directly in the shader (by that time Cyto had already moved to cocos2d 2.0 for a long time), this would mean a constant extra load on the device. Since during the game we did not need to dynamically change the colors of the objects, it was decided to change the color of the texture immediately when it was loaded.
Googling a bit, we found some ready-made solutions for converting from RGB to HSV, for example, here . Screwing this to the test case, we realized that this is exactly what we wanted. As a result, the necessary colors were beautifully substituted for each pack and our designers were extremely pleased with the result.
Nevertheless, even using one set of basic objects for all packs, we could not keep within the required size. All the same, there were huge atlases with separate animations of objects that should be unique for each world.
The most effective approach was to replace the frame-by-frame animation of entire objects with software animation of individual elements of these objects, although it had to be done with a hard code. But as a result, we also received a bonus in the form of the dynamism and liveliness of these animations - there is practically no cycling in them, everything moves randomly within the specified limits. In addition, an object composed of several small elements looks much better when scaled than a similar object drawn by one sprite.
Something like this atlases before and after optimization
Another trick that had to go - the backgrounds in the menu and in levels. All of them, in fact, are made in a fairly small resolution and only under SD screens, no @ 2x pictures. The fact is that the textures in the coconut with an increase are filtered in such a way that it turns out quite beautiful and, most importantly, free blur. The main thing is to prepare the source code correctly so that they already have minimal blurring and no sharp lines, otherwise you will get a picture with blurred squares instead of a blur.
For some textures, we additionally added a program blur. It occurs, as well as repainting, at the stage of loading the texture. We took AWTextureFilter as a basis .
As a result, we got our own sprite, which can be repainted and blur, and working with it is limited to just one line:
CCSpriteExtended *myAwesomeSprite = [CCSpriteExtended spriteWithFile:@"image.png" hueShift:120.0 saturationMult:2.0 valueMult:1.0 blurSize:4];There remained the last step - to optimize the already significantly “thinner” game resources. And again, it did not take long to search. We came across two free utilities that work in pairs - ImageAlpha and ImageOptim . The result of their work is simply amazing! In some cases, they can reduce the file size by 80-90%, with almost no deterioration in image quality.
After all these tricks, we were surprised to find for ourselves that the build was reduced from 150 to 30 megabytes. 5 times! There is nothing impossible and it makes no sense to reinvent the wheel - you only need to correctly apply the solutions from which we are separated only by a single search query.
IPhone Screen Adaptation
Cyto - first of all, a game for iPad. On the iPhone, of course, you can play and some even like the iPhone version more, but, in our opinion, the sensations are a bit different. It's still a game that requires maximum interaction with it, and even a slightly extended iPhone 5 screen will not give half of those sensations that can be obtained by playing on the iPad.
However, the adaptation of the game for a small screen had to work hard. The first thing was added zoom camera. The player can bring the scene a little closer to more accurately aim. I had to experiment a lot with the zoom level. At first I wanted to make it possible to bring the camera to the maximum, as far as art allowed. As it turned out, this did not add anything to the player except for a heap of inconvenience, although it looked very nice ... Therefore, we decided to limit the zoom as much as possible.
You can never do and evaluate something in isolation from the overall picture, you need to look at the result in the aggregate. Even if some thing seems to be super brilliant, but spoils at least some part of the overall result, it must be safely thrown away. Especially scrupulous about this should be approached in the issue of gameplay. If any element that does not make the gameplay better worsens even a small part of it, this should by no means be left as it is.
After watching a couple of levels on a small screen, it immediately became clear that you can’t just take and reduce the levels from the iPad to the iPhone. Urgently had to adapt the levels. The levels on both platforms look the same, but if you look closely, they differ in details.
Levels on the iPhone were created in the editor on the iPad. We added the ability to display a frame corresponding to the actual size of the level on the iPhone screen. Moreover, the same level was immediately adjusted to the resolution of the iPhone 5, and for older devices.
Immediately on the iPad, you can try to play in the iPhone-new level - as seen in the screenshots, the picture on the iPad is no different from that on the iPhone. However, the biggest difficulty was not just to pack the same level in space almost one and a half times smaller. Although the pictures look identical, the gameplay on the tablet is fundamentally different from that on the phone, where the player covers with his finger almost a quarter of the location.
As a result, the iPhone version of the game turned out to be quite “playable”, although far from ideal in our understanding. By the way, the statistics of the distribution of devices on which people play Cyto were a surprise for us: the number of iPhones exceeds the iPad by 20%, although we focused mainly on the iPad platform. Apparently, it affects the fact that the application is universal, and the number of iPhones on the market significantly exceeds the iPad.
Conclusion
We turn to the conclusions. If we sum up all of the above, then the main thing that we have learned over the entire development period is that the main component of the project’s success is implementation, not the idea. Contrary to popular belief, it doesn’t matter what inspired the game designer when creating the project. The main thing - that he could eventually show the players. And, no matter how important and ingenious some ideas would seem, if they do not make your gameplay better - they are worth nothing. And on the other hand, if even the most banal and all-used element will help improve your gameplay - apply it in your game.
In addition, novice developers (and ourselves a year ago) would like to advise the following things:
- Never try to tie the gameplay to the game world, the plot, etc. Thereby, you drive yourself into tight frames and dig a hole in your game, from which it will be very difficult to get out. If it is interesting to play the prototype of squares, circles and triangles, you can move on. Come up with as many varied game mechanics as possible. Having a good gameplay, you can pull on almost any plot. On the contrary - it is very difficult. In Cyto, we went the wrong way, dotted with a rake in the form of a ready-made game world, character and plot. And it was a great lesson for us.
- Really evaluate your strength and timing. We planned to make the game in a couple of months, and spent several times more. We were lucky and we were able to complete the project. And for most startups, unfortunately, reassessing their strength is tantamount to failure. Be honest with yourself, ask yourself, can you bring it to the end?
- Design patterns are good, but they are not a panacea. And patterns for patterns is not good at all. As it turned out, in games it’s not really where to use them, the structure is too specific. Than to foster an inappropriate pattern and turn around an already complex code, it is better to try to think over the functionality in advance, try to take into account all the details, and then it will be much easier. And yes, no one canceled the code comments.
- Use tools to help you better organize your workflow. Bug tracker, wiki, task lists, agile / scrum - all this will help you to be more effective, but only if it really helps and fits. Do not use these tools just because someone advised them to you or to follow the latest trends. Try, experiment!
Source: https://habr.com/ru/post/174301/
All Articles