Classic 2D quest or how our two years of development went. Part 3
Hello again to everyone, in this, the third part, there will be a story about how Swordbreaker The Game was programmed, why this or that framework was chosen, details under the cut.
Continuation of the history of the development of our first game, start here:
So, before moving on to the final part and tell you what was done after the release of the game, let's focus on the main part of the development, namely, programming.
')
As described earlier, the project experienced the following milestones of development:
To begin with, it’s worth saying that if you, the reader, have no experience in programming game projects, then you will most likely be determined at the initial stage with the main thing, namely, with free time that you will be willing to spend on developing your project. For a developer programmer, it is especially important to consider this factor, since mastering a new language, understanding the basics of the adopted framework, trying to write a test code on it - it all takes a lot of time.
See for yourself - you work at work - it’s 8 hours, you need to rest normally, otherwise there will be constant porridge in your head and stress will finish you off - this is at least another 8 hours, 8 more remain like projects, but life often develops so that From these 8 on the project it will turn out to allocate hours on 4 at the best. And in this short time will have to learn a lot and almost "on the fly." Therefore, before starting to do something, try to soberly assess whether you are ready to write code 12 hours a day to implement the project.
Why this retreat? And to the fact that, looking back now, I understand that working in this mode is still a hell of a work, and if the project were more complex in mechanics or more in volume, we would probably not reach the final, or it would take even more time (and we made the game about two years).
Lyrical digression completed, about the money side of this issue, I think we'll talk in the next part, and now to the code itself. =]
At that time, when it all started (early 2014), life on the Internet took place under the slogans a la “Flash dies, what to do, and let's switch to html5, but it’s however some kind of raw ...” androids were also rushing to the horizons Of course, all new versions of the system, I wanted to cover everything at once, but for the beginning two platforms were defined - Android and Windows (in the form of Steam Greenlight, if we pass of course), respectively, a cross-platform engine was needed. At that time there were the following candidates for whom I tried to implement the basic level - Construct2, Libgdx, Unity3d, ImpactJS, Cocos2d, another pair of Flash engines, AndEngine, CoronaSDK. Of the entire heap, only two were more or less adequate in terms of compatibility, documentation and ease of development - LibGDX and CoronaSDK, at Unity3d at that time work with 2D graphics was done with a set of crutches (but I wrote a couple of demos on it, but compared to those two he was not so comfortable).
How to choose the engine for the initial prototyping of the game? Note that for a prototype, namely a prototype, when you need to make a vision of a future game, any actual engine that you will be able to master at least a couple of weeks and start something to write on it is suitable. LibGDX in this regard had good wiki documentation, an excellent forum, with a live community, and its authors Mario Zechner wrote even two books on game programming, using LibGDX, (look at packtpub) all this helped quite a lot in the initial stage, because experience I didn't have programming for games. Approximately the same situation with CoronaSDK is simple and accessible documentation, relatively rich for 2d API set, Lua programming language is easy to learn, but with a lot of nuances.
The first demo, with test buttons, compiled on CoronaSDK, test font, buttons too
At first, I was thinking of writing on CoronaSDK, but constant work with the server-side collector, compiling, then loading on Android (all this is not fast), and the rather “fluid” structure of the lua language, which somehow resembles javascript, was forced to continue learning LibGDX engine .
Actually LibGDX was good for everyone. Firstly, there was a good tutorial that allowed to understand the main game cycle, there were demos (about 100 pcs.) With various API functions that could be run and see, the whole thing was going on Windows and did it very quickly, plus when compiling on Android The project looked 100% also (Corona had glitches, on the emulator this way, and on the phone in a different way). In addition, it was Java - the mainstream OOP programming language, I must say very convenient for the implementation of projects of any level, and almost the same as C #, in which I wrote (and write) at work. In addition, it was all managed by Android Studio (creators of Resharper and heaps of other tools), which was also a very convenient IDE for development.
Actually, what conclusions did I make of all this - if you are just a beginner in the development of games, take the engine that is most suitable for you in terms of ease of development, yes, I understand that by choosing Unity3d, I would master a more powerful tool, but In general, for a game as for a software product, it is important - the gameplay component itself, on which it will be implemented is a secondary matter, all engines work roughly the same with 2D and 3D, so choose what is right for you (maybe from the experience of PL, may for convenience), the only The criterion at this stage is the speed of development of the prototype.
Find AdMob in the photo
It probably makes no sense to describe the programming process for the game itself, for LibGDX everything is available on the Wiki, although the project has been a bit lately, but I think for beginners I would recommend it for “trying on a pen”.
So on LibGDX we reached the release of the demo version, the important thing was that the engine had:
Otherwise, there is nothing particularly to tell, if you have passed the prototyping stage and even the release of the demo version, then, most likely, you have already chosen the engine that meets your requirements. If at the moment (09/28/2017), I would choose the engine for the implementation of the game, I probably would first have stepped in the direction of Unity3d, which has evolved greatly in all this time.
Gradually ruling the latest bugs, we approached the release on Steam, it was decided to postpone the launch of the Android version, because there were a couple of technical issues and we still could not decide whether to make it free with ads or paid-app. Preparing to launch on Steam took its time too, it was necessary to fill in a lot of information - personal data, updates, prepare materials (as it turned out, you need pictures on icons, icons, chat emoticons, wallpapers for user profiles), and also to test the work of the API in the game . Steam in general in this regard is a very convenient platform, a sea of ​​documentation, which is available after registration (and which is not subject to disclosure o_O), makes the process quite simple, and, as I said, there were ready libraries for LibGDX. In general, a couple of times we were rejected by moderation due to inconsistency of materials, but after all, we passed and started! : D
Here the process flowed from the “development” state to the “support” state, and the first long-awaited “bugs” fell down - some of them were not working on FitViewport, some were losing their preservation, some were not given any progress, in general, who is in pain. Some of the bugs were quickly corrected, and some ... alas, but I still couldn’t deal with some of them until now.
Typical debugging
However, for most players, the game was stable, the first statistics, screenshots, reviews, and some moral satisfaction from the work done appeared. Hurray we became developers! : D
What I actually mentioned at the beginning of the article about 4 hours ... Recently, before the release, I wanted to do everything qualitatively, check everything I needed, and release a normal working version, in general it was quite a lot of stress. Coding, painstaking work on pushing characters along the map, editing dialogs, testing, everyone who knows what a crutch is, those in the know)
Map of the castle, a prototype, in the beginning we wanted to connect all this with arrows and when passing so that separate areas of the castle become light
Map of the whole game
In general, it was a busy day prefinal polishing almost finished product. After some time, a version for Android was created, and launched in the form of a paid-app, the transformation thanks to the functionality of LibGDX occurred quite painlessly, all the functions for the if-else interface settings were there, so part of the control was adjusted to the fingertip and everything started to turn. .
There was one more unfinished business - this is a version for Mac, namely for iOS, in general, Android for a paid-application showed itself quite well, there was a hope that the iOS version would be at least as good.
Now I don’t remember what exactly was the reason why I decided to write the iOS version not on LibGDX, but on CoronaSDK, but it seemed there were some nuances in compatibility. A Mac was also purchased in order to be registered on the portal and for testing on a virtual machine.
Fast enough, although not without problems with Lua, the game was rewritten and started quite nicely on the emulator, some differences in the components affected, something had to be optimized, something was redone, but on the whole the engine coped with its task, plus CoronaSDK has a good and nimble emulator. The place of Android Studio replaced Sublime Text under which CoronaSDK has a plugin, it turned out something like IDE, which was also quite convenient. In general, CoronaSDK has a plus and a minus language - it is a scripted Lua with dynamic typing, which you do not immediately get used to and sometimes get confused in areas of visibility, definition of variables, etc., you gradually get used to it, everything becomes a table to shove everything - starting from data and ending with functions, in general, there is a certain logic here, but debugging all this devilry is not very cool. The crown also has a rich API in which there is a lot to create 2D games, it is very easy to learn, contains many examples in the documentation itself, plus there are plugins for embedding monetization, and other services (some are paid). To create unpretentious toys for phones - the thing is, for something larger, I would probably be confused in all this junk, in the absence of a normal IDE.
Three thousand devils (actually three hundred mosques) and one small scene!
Running the iOS version was stable, having written and tested everything under Windows on the emulator, it remains to fill out the registration information, make the build and run the build on iOS. Profit! : D
On this principle, everything seems to be the main points, in the next part Sanya will tell about the support of the game after the release, what PR actions were carried out, and what it all gave, plus we will tell about monetization.
Continuation of the history of the development of our first game, start here:
So, before moving on to the final part and tell you what was done after the release of the game, let's focus on the main part of the development, namely, programming.
')
As described earlier, the project experienced the following milestones of development:
- A prototype was created on paper in the form of a dizdok, platforms were defined, and approximate gameplay
- Were created prototypes on various game engines in order to determine which one would be best suited for the implementation of ideas
- A demo version was created for the preliminary evaluation of the game by the community.
- The game was implemented for the main platforms (Windows, Android OS)
- The game was implemented for secondary platforms (Linux, Mac, iOS)
To begin with, it’s worth saying that if you, the reader, have no experience in programming game projects, then you will most likely be determined at the initial stage with the main thing, namely, with free time that you will be willing to spend on developing your project. For a developer programmer, it is especially important to consider this factor, since mastering a new language, understanding the basics of the adopted framework, trying to write a test code on it - it all takes a lot of time.
See for yourself - you work at work - it’s 8 hours, you need to rest normally, otherwise there will be constant porridge in your head and stress will finish you off - this is at least another 8 hours, 8 more remain like projects, but life often develops so that From these 8 on the project it will turn out to allocate hours on 4 at the best. And in this short time will have to learn a lot and almost "on the fly." Therefore, before starting to do something, try to soberly assess whether you are ready to write code 12 hours a day to implement the project.
Why this retreat? And to the fact that, looking back now, I understand that working in this mode is still a hell of a work, and if the project were more complex in mechanics or more in volume, we would probably not reach the final, or it would take even more time (and we made the game about two years).
Lyrical digression completed, about the money side of this issue, I think we'll talk in the next part, and now to the code itself. =]
At that time, when it all started (early 2014), life on the Internet took place under the slogans a la “Flash dies, what to do, and let's switch to html5, but it’s however some kind of raw ...” androids were also rushing to the horizons Of course, all new versions of the system, I wanted to cover everything at once, but for the beginning two platforms were defined - Android and Windows (in the form of Steam Greenlight, if we pass of course), respectively, a cross-platform engine was needed. At that time there were the following candidates for whom I tried to implement the basic level - Construct2, Libgdx, Unity3d, ImpactJS, Cocos2d, another pair of Flash engines, AndEngine, CoronaSDK. Of the entire heap, only two were more or less adequate in terms of compatibility, documentation and ease of development - LibGDX and CoronaSDK, at Unity3d at that time work with 2D graphics was done with a set of crutches (but I wrote a couple of demos on it, but compared to those two he was not so comfortable).
How to choose the engine for the initial prototyping of the game? Note that for a prototype, namely a prototype, when you need to make a vision of a future game, any actual engine that you will be able to master at least a couple of weeks and start something to write on it is suitable. LibGDX in this regard had good wiki documentation, an excellent forum, with a live community, and its authors Mario Zechner wrote even two books on game programming, using LibGDX, (look at packtpub) all this helped quite a lot in the initial stage, because experience I didn't have programming for games. Approximately the same situation with CoronaSDK is simple and accessible documentation, relatively rich for 2d API set, Lua programming language is easy to learn, but with a lot of nuances.
The first demo, with test buttons, compiled on CoronaSDK, test font, buttons too
At first, I was thinking of writing on CoronaSDK, but constant work with the server-side collector, compiling, then loading on Android (all this is not fast), and the rather “fluid” structure of the lua language, which somehow resembles javascript, was forced to continue learning LibGDX engine .
Actually LibGDX was good for everyone. Firstly, there was a good tutorial that allowed to understand the main game cycle, there were demos (about 100 pcs.) With various API functions that could be run and see, the whole thing was going on Windows and did it very quickly, plus when compiling on Android The project looked 100% also (Corona had glitches, on the emulator this way, and on the phone in a different way). In addition, it was Java - the mainstream OOP programming language, I must say very convenient for the implementation of projects of any level, and almost the same as C #, in which I wrote (and write) at work. In addition, it was all managed by Android Studio (creators of Resharper and heaps of other tools), which was also a very convenient IDE for development.
Actually, what conclusions did I make of all this - if you are just a beginner in the development of games, take the engine that is most suitable for you in terms of ease of development, yes, I understand that by choosing Unity3d, I would master a more powerful tool, but In general, for a game as for a software product, it is important - the gameplay component itself, on which it will be implemented is a secondary matter, all engines work roughly the same with 2D and 3D, so choose what is right for you (maybe from the experience of PL, may for convenience), the only The criterion at this stage is the speed of development of the prototype.
Find AdMob in the photo
It probably makes no sense to describe the programming process for the game itself, for LibGDX everything is available on the Wiki, although the project has been a bit lately, but I think for beginners I would recommend it for “trying on a pen”.
So on LibGDX we reached the release of the demo version, the important thing was that the engine had:
- Easy integration with the advertising API, it was possible to easily and easily integrate AdMob advertising modules into the project using ready-made APIs.
- It was actually native for Android - java
- Actually the launch of the demo went virtually without any technical problems, for some reason there was a couple of questions that the display was crookedly formed, but on the whole - everything is fine.
- Then the marathon began before the release of the main version of the game.
- On all this long journey, the following things were very helpful:
- Android Studio - which is a very handy thing with all the refactoring chips, syntax highlighting, quick transitions, debugging, etc. JetBrains - one love! All this made it possible to conveniently manage the code and quickly find errors, saving time and nerves.
- The structure of projects in LibGDX - it turned out that this framework was perfectly designed for creating 2d games, almost all the APIs were either Demo or Wiki articles, so there were few technical problems, and the localization was also pleased. At the final stage of integration in Steam, it also turned out that there are free components for implementing the Steam API in the game, it was the same with google play services. In general, LibGDX was a kind of framework like the standard .NET library with a bunch of ready-made classes from which you can sculpt everything you need, there is almost everything (within the framework of OpenGL ES, probably =])
- Sanina's moral support, especially when we rewrote the dialogues and tested all these things for bugs. =]
Otherwise, there is nothing particularly to tell, if you have passed the prototyping stage and even the release of the demo version, then, most likely, you have already chosen the engine that meets your requirements. If at the moment (09/28/2017), I would choose the engine for the implementation of the game, I probably would first have stepped in the direction of Unity3d, which has evolved greatly in all this time.
Gradually ruling the latest bugs, we approached the release on Steam, it was decided to postpone the launch of the Android version, because there were a couple of technical issues and we still could not decide whether to make it free with ads or paid-app. Preparing to launch on Steam took its time too, it was necessary to fill in a lot of information - personal data, updates, prepare materials (as it turned out, you need pictures on icons, icons, chat emoticons, wallpapers for user profiles), and also to test the work of the API in the game . Steam in general in this regard is a very convenient platform, a sea of ​​documentation, which is available after registration (and which is not subject to disclosure o_O), makes the process quite simple, and, as I said, there were ready libraries for LibGDX. In general, a couple of times we were rejected by moderation due to inconsistency of materials, but after all, we passed and started! : D
Here the process flowed from the “development” state to the “support” state, and the first long-awaited “bugs” fell down - some of them were not working on FitViewport, some were losing their preservation, some were not given any progress, in general, who is in pain. Some of the bugs were quickly corrected, and some ... alas, but I still couldn’t deal with some of them until now.
Typical debugging
However, for most players, the game was stable, the first statistics, screenshots, reviews, and some moral satisfaction from the work done appeared. Hurray we became developers! : D
What I actually mentioned at the beginning of the article about 4 hours ... Recently, before the release, I wanted to do everything qualitatively, check everything I needed, and release a normal working version, in general it was quite a lot of stress. Coding, painstaking work on pushing characters along the map, editing dialogs, testing, everyone who knows what a crutch is, those in the know)
Map of the castle, a prototype, in the beginning we wanted to connect all this with arrows and when passing so that separate areas of the castle become light
Map of the whole game
In general, it was a busy day prefinal polishing almost finished product. After some time, a version for Android was created, and launched in the form of a paid-app, the transformation thanks to the functionality of LibGDX occurred quite painlessly, all the functions for the if-else interface settings were there, so part of the control was adjusted to the fingertip and everything started to turn. .
There was one more unfinished business - this is a version for Mac, namely for iOS, in general, Android for a paid-application showed itself quite well, there was a hope that the iOS version would be at least as good.
Now I don’t remember what exactly was the reason why I decided to write the iOS version not on LibGDX, but on CoronaSDK, but it seemed there were some nuances in compatibility. A Mac was also purchased in order to be registered on the portal and for testing on a virtual machine.
Fast enough, although not without problems with Lua, the game was rewritten and started quite nicely on the emulator, some differences in the components affected, something had to be optimized, something was redone, but on the whole the engine coped with its task, plus CoronaSDK has a good and nimble emulator. The place of Android Studio replaced Sublime Text under which CoronaSDK has a plugin, it turned out something like IDE, which was also quite convenient. In general, CoronaSDK has a plus and a minus language - it is a scripted Lua with dynamic typing, which you do not immediately get used to and sometimes get confused in areas of visibility, definition of variables, etc., you gradually get used to it, everything becomes a table to shove everything - starting from data and ending with functions, in general, there is a certain logic here, but debugging all this devilry is not very cool. The crown also has a rich API in which there is a lot to create 2D games, it is very easy to learn, contains many examples in the documentation itself, plus there are plugins for embedding monetization, and other services (some are paid). To create unpretentious toys for phones - the thing is, for something larger, I would probably be confused in all this junk, in the absence of a normal IDE.
Three thousand devils (actually three hundred mosques) and one small scene!
Running the iOS version was stable, having written and tested everything under Windows on the emulator, it remains to fill out the registration information, make the build and run the build on iOS. Profit! : D
On this principle, everything seems to be the main points, in the next part Sanya will tell about the support of the game after the release, what PR actions were carried out, and what it all gave, plus we will tell about monetization.
Source: https://habr.com/ru/post/339092/
All Articles