October 1, 2017 at 18:34Classic 2D quest or how our two years of development went. Part 3
Hello again everyone, in this third part there will be a story about how the Swordbreaker The Game was programmed, why this or that framework was chosen, details under the cut.
The continuation of the history of the development of our first game, the beginning here:
So, before moving on to the final part and telling what was done after the release of the game, let's dwell on the main part of the development, namely, programming.
As described earlier, the project has experienced the following developmental milestones:
To begin with, it’s worth saying that if you, the reader, as we did not have experience in programming game projects, then most likely you should decide on the main thing, namely, free time that you will be ready to spend on developing your project. It is especially important for a software developer to take this factor into account, as mastering a new language, understanding the basics of the adopted framework, trying to write test code on it - it all takes quite 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 bother you - it’s at least another 8 hours, 8 more remain sort of like projects, but life often develops so that of these 8 it will be possible to allocate 4 hours to the project at best. And in these short periods of time you will have to study a lot and practically "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 now, looking back, I understand that working in this mode is hellish work, and if the project was more complex in mechanics or larger in volume, we probably would not have reached the final, or it would have taken even more time (and we did the game for about two years).
The lyrical digression is completed, I think about the monetary side of this issue 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 is dying, what to do, but let's switch to html5, but it’s somehow raw ...”, androids flashed famously on the horizon all new versions of the system, of course I wanted to cover everything at once, but for a start two platforms were defined - Android and Windows (in the form of Steam Greenlight, if we go of course), respectively, we needed a cross-platform engine. At that time, there were the following candidates for whom I tried to implement a basic level - Construct2, Libgdx, Unity3d, ImpactJS, Cocos2d, some other pair of Flash engines, AndEngine, CoronaSDK. Of the whole heap, only two were more or less adequate in terms of compatibility, documentation and ease of development - these were LibGDX and CoronaSDK,
How to choose an 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 can master at least a couple of weeks and start already writing something on it is suitable. LibGDX in this regard had a good wiki-documentation, an excellent forum, with a lively community, and its authors Mario Zechner even wrote two books on game programming using LibGDX (look at packtpub) all this helped a lot at the initial stage, because experience I didn’t have programming games. The situation with CoronaSDK is approximately the same - simple and accessible documentation, a relatively rich set of APIs for 2d, the Lua programming language is easy to learn, but with a lot of nuances.
The first demo, with test buttons, assembled on CoronaSDK, test font, buttons, too.
At first I generally thought of writing on CoronaSDK, but constant work with the collector on the server side, compilation, then loading on Android (all this is not fast), and quite “ the liquid ”structure of the lua language, which is somewhat reminiscent of javascript, forced to continue the development of the LibGDX engine.
LibGDX itself was good for everyone. Firstly, there was a good tutorial that made it possible to understand the main game cycle, there were demos (about 100 pieces) with various API functions that you could run and see, the whole thing was collected on Windows and did it very quickly, plus when compiling on Android the project looked 100% as well (Corona had glitches on the emulator like that, but on the phone in a different way). In addition, it was Java - the mainstream OOP programming language, I must say it is very convenient for implementing 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 (the creators of Resharper and heaps of other tools), which was also an extremely convenient IDE for development.
Actually, what conclusions have I drawn from all of this - if you are just a beginner in game development, take the engine that is most acceptable to you in terms of ease of development, yes, I understand that if I chose Unity3d, I would have mastered a more powerful tool, but in general, for the game, as for a software product, it is important - the gameplay component itself, on what it will be implemented - is secondary, all engines work approximately the same with 2D and 3D, so choose what suits you (maybe from the experience of maybe for convenience), the only the criterion at this stage is the prototype development speed.
Find AdMob in the photo
It probably makes no sense to describe the programming process for the game itself, for LibGDX everything is available in the Wiki, although the project has lagged a bit lately, but I think for beginners I would recommend it for a “pen test”.
So, we reached LibGDX before the demo version was released; here the engine played an important role:
The rest is especially nothing to tell, if you went through the prototyping stage and even the release of the demo version, then, most likely, you have already chosen an engine that meets your requirements. If at the moment (September 28, 2017), I would choose the engine for the implementation of the game, I would probably first of all step towards Unity3d, which has evolved very much over all this time.
Gradually correcting the last bugs, we approached the Steam release, it was decided to postpone the launch of the Android version, because there were a couple of technical issues and we still couldn’t decide whether to make it free with advertising or paid-app. Preparation for launching on Steam also took its time, it was necessary to fill in a lot of information - personal data, achievements, prepare materials (as it turned out, you need pictures for achievements, icons, emoticons for chat, wallpapers for user profiles), as well as test the API in the game . Steam in general in this regard is a very convenient platform, a lot of documentation that is available after registration (and which is not subject to disclosure by o_O), I make the process quite simple, in addition, as I said, there were ready-made libraries for LibGDX. In general, a couple of times we were rejected by moderation due to mismatch of materials, but still we went and started! : D
Here the process flowed from the “development” state to the “support” state, and the first long-awaited “bugs” fell in - some didn’t work properly with FitViewport, some lost their save, others were not given a achivement, in general, it hurts someone. Some of the bugs were promptly fixed, and some ... alas, but I have not been able to deal with some until now.
Typical debugging
However, for most players the game was stable, the first statistics, screenshots, reviews, and some kind of moral satisfaction from the work done appeared. Hooray we became developers! : D
Why did I actually mention about 4 hours at the beginning of the article ... The last time before the release, I wanted to do everything qualitatively, check everything I needed, and release a normal working version, in general it was a lot of stress. Coding, painstaking work of pushing symbols on the map, editing dialogs, testing, everyone who knows what crunch is, those in the know)
Castle map, prototype, in the beginning we wanted to connect all this with arrows and when passing so that certain areas of the castle become bright
Map of the whole games
In general, these were busy days of pre-polishing an almost finished product. After some time, the Android version was created, and launched as a paid-app, the transformation due to the LibGDX functionality was pretty painless, all the functions for the if-else interface settings were there, so the control part was adjusted to the finger touch and everything turned and spun. .
There was one more unfinished business - this is the version for Mac, namely for iOS, in general, Android for the paid application proved to be quite good, there was a hope that the iOS version would be at least no worse.
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 like there were some nuances in compatibility. A Mac was also purchased in order to register on the portal and for testing on a virtual machine.
Quickly enough, although not without problems with Lua, the game was rewritten and started on the emulator quite well, some differences in components affected, I had to optimize something, remake something, but in general the engine coped with the task assigned to it, plus CoronaSDK It has a good and nimble emulator. The place Android Studio replaced Sublime Text under which CoronaSDK has a plug-in, it turned out something like an IDE, which was also quite convenient. In general, CoronaSDK has a plus and minus language - it is a scripting Lua with dynamic typing, which you don’t get used to right away and sometimes get confused in the scope, definition of variables, etc., you get used to it gradually, everything becomes a table into which you can push everything - starting from data and ending with functions, in general, there is its own logic, but debugging all this hell isn’t very cool. The crown also has a rich API in which there is much to create 2D games, it is very easy to learn, it contains many examples in the documentation itself, plus there are plugins for embedding monetization, and other services (some are paid). To create simple toys for phones - the very thing, for something larger, I would probably get confused in this whole booth, in the absence of a normal IDE.
Three thousand devils (actually three hundred mechelomes) and one small scene!
The launch of the iOS version was stable, having written and tested everything under Windows on the emulator, it remains to fill in the registration information, make a build and run the build on iOS. Profit! : D
On this, in principle, everything, I’ve kind of told the main points, in the next part Sanya will talk about the support of the game after the release, what PR actions were carried out, and what it all gave, plus we’ll talk about monetization.
The continuation of the history of the development of our first game, the beginning here:
So, before moving on to the final part and telling what was done after the release of the game, let's dwell on the main part of the development, namely, programming.
As described earlier, the project has experienced the following developmental milestones:
- A prototype was created on paper in the form of a dzdok, platforms were determined, and approximate gameplay
- Prototypes were created on various game engines in order to determine which one is best for implementing ideas
- A demo was created for a preliminary assessment of the game by the community
- The game was implemented for major 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, as we did not have experience in programming game projects, then most likely you should decide on the main thing, namely, free time that you will be ready to spend on developing your project. It is especially important for a software developer to take this factor into account, as mastering a new language, understanding the basics of the adopted framework, trying to write test code on it - it all takes quite 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 bother you - it’s at least another 8 hours, 8 more remain sort of like projects, but life often develops so that of these 8 it will be possible to allocate 4 hours to the project at best. And in these short periods of time you will have to study a lot and practically "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 now, looking back, I understand that working in this mode is hellish work, and if the project was more complex in mechanics or larger in volume, we probably would not have reached the final, or it would have taken even more time (and we did the game for about two years).
The lyrical digression is completed, I think about the monetary side of this issue 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 is dying, what to do, but let's switch to html5, but it’s somehow raw ...”, androids flashed famously on the horizon all new versions of the system, of course I wanted to cover everything at once, but for a start two platforms were defined - Android and Windows (in the form of Steam Greenlight, if we go of course), respectively, we needed a cross-platform engine. At that time, there were the following candidates for whom I tried to implement a basic level - Construct2, Libgdx, Unity3d, ImpactJS, Cocos2d, some other pair of Flash engines, AndEngine, CoronaSDK. Of the whole heap, only two were more or less adequate in terms of compatibility, documentation and ease of development - these were LibGDX and CoronaSDK,
How to choose an 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 can master at least a couple of weeks and start already writing something on it is suitable. LibGDX in this regard had a good wiki-documentation, an excellent forum, with a lively community, and its authors Mario Zechner even wrote two books on game programming using LibGDX (look at packtpub) all this helped a lot at the initial stage, because experience I didn’t have programming games. The situation with CoronaSDK is approximately the same - simple and accessible documentation, a relatively rich set of APIs for 2d, the Lua programming language is easy to learn, but with a lot of nuances.
The first demo, with test buttons, assembled on CoronaSDK, test font, buttons, too.
At first I generally thought of writing on CoronaSDK, but constant work with the collector on the server side, compilation, then loading on Android (all this is not fast), and quite “ the liquid ”structure of the lua language, which is somewhat reminiscent of javascript, forced to continue the development of the LibGDX engine.
LibGDX itself was good for everyone. Firstly, there was a good tutorial that made it possible to understand the main game cycle, there were demos (about 100 pieces) with various API functions that you could run and see, the whole thing was collected on Windows and did it very quickly, plus when compiling on Android the project looked 100% as well (Corona had glitches on the emulator like that, but on the phone in a different way). In addition, it was Java - the mainstream OOP programming language, I must say it is very convenient for implementing 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 (the creators of Resharper and heaps of other tools), which was also an extremely convenient IDE for development.
Actually, what conclusions have I drawn from all of this - if you are just a beginner in game development, take the engine that is most acceptable to you in terms of ease of development, yes, I understand that if I chose Unity3d, I would have mastered a more powerful tool, but in general, for the game, as for a software product, it is important - the gameplay component itself, on what it will be implemented - is secondary, all engines work approximately the same with 2D and 3D, so choose what suits you (maybe from the experience of maybe for convenience), the only the criterion at this stage is the prototype development speed.
Find AdMob in the photo
It probably makes no sense to describe the programming process for the game itself, for LibGDX everything is available in the Wiki, although the project has lagged a bit lately, but I think for beginners I would recommend it for a “pen test”.
So, we reached LibGDX before the demo version was released; here the engine played an important role:
- 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 to Android - Java
- Actually, the launch of the demo went virtually without any technical problems, there were a couple of questions for some reason the display was crookedly formed, but in general - everything is fine.
- Then the marathon began before the release of the main version of the game.
- Throughout this long journey, the following things have been very helpful:
- Android Studio - which is a very convenient thing with all the features of refactoring, 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.
- Project structure in LibGDX - it so happened that this framework was perfectly designed for creating 2d games, almost all APIs had either Demo or Wiki articles, so there were few technical problems, localization also had its own API. At the final stage of integration on Steam, it also turned out that there were free components for implementing the Steam API in the game, the same was with google play services. In general, LibGDX was a kind of framework similar to the standard .NET library with a bunch of ready-made classes from which you can sculpt everything you need, there is almost everything (within OpenGL ES, probably =])
- Sanina’s moral support, especially when we rewrote dialogs and tested all these things for bugs. =]
The rest is especially nothing to tell, if you went through the prototyping stage and even the release of the demo version, then, most likely, you have already chosen an engine that meets your requirements. If at the moment (September 28, 2017), I would choose the engine for the implementation of the game, I would probably first of all step towards Unity3d, which has evolved very much over all this time.
Gradually correcting the last bugs, we approached the Steam release, it was decided to postpone the launch of the Android version, because there were a couple of technical issues and we still couldn’t decide whether to make it free with advertising or paid-app. Preparation for launching on Steam also took its time, it was necessary to fill in a lot of information - personal data, achievements, prepare materials (as it turned out, you need pictures for achievements, icons, emoticons for chat, wallpapers for user profiles), as well as test the API in the game . Steam in general in this regard is a very convenient platform, a lot of documentation that is available after registration (and which is not subject to disclosure by o_O), I make the process quite simple, in addition, as I said, there were ready-made libraries for LibGDX. In general, a couple of times we were rejected by moderation due to mismatch of materials, but still we went and started! : D
Here the process flowed from the “development” state to the “support” state, and the first long-awaited “bugs” fell in - some didn’t work properly with FitViewport, some lost their save, others were not given a achivement, in general, it hurts someone. Some of the bugs were promptly fixed, and some ... alas, but I have not been able to deal with some until now.
Typical debugging
However, for most players the game was stable, the first statistics, screenshots, reviews, and some kind of moral satisfaction from the work done appeared. Hooray we became developers! : D
Why did I actually mention about 4 hours at the beginning of the article ... The last time before the release, I wanted to do everything qualitatively, check everything I needed, and release a normal working version, in general it was a lot of stress. Coding, painstaking work of pushing symbols on the map, editing dialogs, testing, everyone who knows what crunch is, those in the know)
Castle map, prototype, in the beginning we wanted to connect all this with arrows and when passing so that certain areas of the castle become bright
Map of the whole games
In general, these were busy days of pre-polishing an almost finished product. After some time, the Android version was created, and launched as a paid-app, the transformation due to the LibGDX functionality was pretty painless, all the functions for the if-else interface settings were there, so the control part was adjusted to the finger touch and everything turned and spun. .
There was one more unfinished business - this is the version for Mac, namely for iOS, in general, Android for the paid application proved to be quite good, there was a hope that the iOS version would be at least no worse.
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 like there were some nuances in compatibility. A Mac was also purchased in order to register on the portal and for testing on a virtual machine.
Quickly enough, although not without problems with Lua, the game was rewritten and started on the emulator quite well, some differences in components affected, I had to optimize something, remake something, but in general the engine coped with the task assigned to it, plus CoronaSDK It has a good and nimble emulator. The place Android Studio replaced Sublime Text under which CoronaSDK has a plug-in, it turned out something like an IDE, which was also quite convenient. In general, CoronaSDK has a plus and minus language - it is a scripting Lua with dynamic typing, which you don’t get used to right away and sometimes get confused in the scope, definition of variables, etc., you get used to it gradually, everything becomes a table into which you can push everything - starting from data and ending with functions, in general, there is its own logic, but debugging all this hell isn’t very cool. The crown also has a rich API in which there is much to create 2D games, it is very easy to learn, it contains many examples in the documentation itself, plus there are plugins for embedding monetization, and other services (some are paid). To create simple toys for phones - the very thing, for something larger, I would probably get confused in this whole booth, in the absence of a normal IDE.
Three thousand devils (actually three hundred mechelomes) and one small scene!
The launch of the iOS version was stable, having written and tested everything under Windows on the emulator, it remains to fill in the registration information, make a build and run the build on iOS. Profit! : D
On this, in principle, everything, I’ve kind of told the main points, in the next part Sanya will talk about the support of the game after the release, what PR actions were carried out, and what it all gave, plus we’ll talk about monetization.