How a converter from Flash to HTML5 called IceStone was created and why it was decided to launch a full—fledged multiplatform publishing house on its basis, – said Igor Chavychalov, who holds the post of executive producer of the company.
The article is an adapted version of Igor Chavychalov’s report “Converting Flash to HTML5 with IceStone. Resurrection of the product without costs and with a full cycle of publishing“, read at the HTML5 games development meeting in the office Mail.ru March 13.
Igor Chavychalov
How did it all start?
We had our own game engine in C++. Games were created on it, which were compiled into Flash for display on the web.
A few years ago, the situation changed. Flash started blocking browsers, everyone started talking about the need to switch to HTML5.
We also started looking for a solution that would allow us to move to the “new rails”. So we came to the Emscripten compiler, which allowed us to convert our C++ code into the desired HTML5.
It would seem to be a victory, but not all projects from our portfolio were written in C++. There were enough games developed initially on Flash.
What to do with them was not entirely clear, because we immediately dismissed the porting option. At the same time, it was a pity to abandon projects that still have sales.
Why didn’t we take up porting?
Those who are porting with Flash today usually have two paths — Unity and HTML5.
Unity
Rewriting the game on Unity in order to then launch it on the web is a strange solution, but it is periodically resorted to. Including — to then launch in mobile as a native application already.
However, it is expensive to rewrite the game on Unity, because this requires a new team that understands the engine. Often such things are entrusted to outsourcers. It doesn’t always end well.
Such a process can take up to two years in time, if we are talking about a large project. It is clear that it is better to spend this money and time on a new game, rather than on a ported version that will not even work on the mobile web, which is still not supported by Unity.
The latter is especially critical, given that more than 80% of all web traffic comes from mobile.
Porting also increases the likelihood of a number of poorly predicted errors. If a programmer, analyst or game designer had something poorly documented, then rewriting a product from scratch can break the code, monetization, balance. The error can be anything. The larger the project, the older it is, the higher the probability of error.
HTML5
HTML5 has many of the same problems as porting to Unity. That is, first of all, you will need a new team and a lot of time, which today the owners of Flash projects do not have.
Let me remind you that in December 2020, Adobe will officially stop supporting the technology and close Flash Player. Google will completely disable support for the technology in Chrome throughout next year. Some browsers, such as Mozilla Firefox, have already disabled Flash Player support.
Porting itself is also expensive. Some budgets reach $300-500 thousand. King can afford it, most developers of projects on ActionScript 3 — definitely not.
And we are not talking about big projects in the spirit of Clash of Clans right now. It’s generally easier to hang yourself here than trying to translate the game to HTML5.
Again, as in the case of Unity, there is a high probability of an error. Something was overlooked somewhere — and as a result, we did not get a profitable HTML5 project, but a broken product.
What were the alternatives to full-fledged porting?
The most obvious thing then seemed to us to find a tool that can rebuild the Flash project in HTML5. We were not ready to write something of our own on our own at that time. Plus, it seemed to us that someone certainly had to come up with something.
As a result, we found only four solutions that could theoretically meet our needs. And none of them suited us, and that’s why:
Shumway
Mozilla’s open source solution converts everything directly during playback in a computing environment (runtime). This has a disastrous effect on performance. At best, we had 2-3 frames per second for the most primitive games on desktop devices. Plus Mozilla itself stopped supporting the media player in 2016.
Apache Royale
Previously called FlexJS. Allows you to write applications for HTML5 in MXML and ActionScript. The problem with this open source solution is the lack of a full implementation of the Flash API. It is sharpened for MXML and Flex components, not for Flash games. The Flash API has insufficient implementation and is not executed identically to the original. Simply put, you can’t convert Flash games using Apache Royale.
OpenFL
There are two main problems here. First. It is assumed that OpenFL should fully reflect the Flash API, and SWFs created in Adobe Flash can work in OpenFL. But in fact, part of the API in ActionScript 3 does not work the way it works in Flash. The second problem: multiplatformity is provided exclusively through Haxe.
A bundle of Adobe Animate and CreateJS
Suitable exclusively for transferring animation. The code does not support this toolset.
Having figured out that there were no adequate solutions, we rolled up our sleeves and ourselves took up the implementation of a solution that would allow us to transfer projects from Flash to HTML5 with a minimum of effort.
That’s how IceStone was born.
How was the development of IceStone going?
We started making IceStone in 2016. The first version of the product took us two years.
We had to make all the tools from scratch ourselves. For example, we have created our own Flash Player in JavaScript, as well as a predictive compiler for browser standards, rendering batching and much more. All together, this allowed us to achieve three times better performance relative to the original on AS3.
Today, our solution supports the Flash API 100% and thanks to this, it allows you to transfer code to HTML5 format relatively painlessly, where it reproduces well using WebGL hardware acceleration.
We work with all types of sources: FLA files, Adobe Flash Builder, FlashDevelop, IntelliJ IDEA and even SWF.
Even at the beta stage, we connected the first partner. He provided us with quite a lot of games, about 20. They were all written within the same architecture. Everyone had a very nice clean code.
In July, when the first 20 products were ready, we started to connect more partners. That’s when the “zoo” began. We began to regularly encounter projects that have poorly documented code, huge vector images, a love of XML and a million more features in each product.
Therefore, all last year we not only polished IceStone, but also adapted its functionality to completely different projects, of which there are already more than 170.
For example, we are faced with the fact that many Flash games do not provide for resizing the active window (frame resize). They could only be reproduced within a given resolution and with only one possible aspect ratio.
And that was the problem. The fact is that many Flash projects were created exclusively for desktops with an aspect ratio of 4 to 3. For desktop systems, the product’s widescreen is not critical. Quite another thing is mobile devices, the market of which should not be missed.
Another problem that had to be solved was management. A number of Flash games involve keyboard control. Fundamentally changing the management even within the framework of one game is a serious task that can affect the design, not to mention the code. Doing this “on the stream” is an impossible task.
The most obvious solution here is to create a virtual stick and a pair of keys, which we implemented.
What have we achieved?
To date, we have already converted 170 projects. There are no performance problems on either desktop or mobile devices (in fact, we are talking about increasing productivity by 2-3 times, depending on the specifics of the project.). Moreover, we are talking here not only about physical puzzles, which include, for example, Cover Orange, but also about strategies, farms and other social projects.
Our conversion usually lasts no more than six weeks for a newly received loaded project. At the same time, a scenario is possible when the developer’s team continues to make a Flash game after conversion, makes updates, which we, accordingly, translate into HTML5 and pour out into production (such a cycle usually takes us no more than a couple of days).
And now what?
Even during development, we realized that we were not making a solution for ourselves, but for the market as a whole. There are no analogues, and the demand is huge both from developers and from platforms.
Today, a lot of games on Facebook, VK, OK, Armor Games, Kongregate, Poga Games and other sites remain on Flash. However, the developers themselves are not ready to transfer them to the new technology.
As we have already found out, there was no simple and efficient converter before, and as for porting, this is a conversation about big money and time.
So we come to a situation where next year the sites will face the loss of 80% of all their content, and many developers will lose their income.
Therefore, we at IceStone have come to a business model that is not the most standard for a service solution. You can’t buy the service, you can’t subscribe to it. You can use it only if the team is ready to publish with our help.
How do we work with developers?
We have a full cycle of publishing.
The first stage
A flash developer comes to us and offers a game for publication. For projects with advertising monetization, a link is usually enough. For free-duplex projects whose monetization is based on IAP, we ask you to provide business metrics.
We are considering new games, but first of all we are now focused on projects that have been running for a long time. There is a requirement for the latter: at least 10 million sessions. For us, this is an indicator that investments in the game will pay off.
In addition, the game is evaluated by our marketing and QA departments. Only after that we answer whether the project is interesting to us.
The second stage
A contract is being signed.
The third stage
Project conversion. We carry it out ourselves with the help of the tools described above.
This usually takes, as I noted just above, up to six weeks for loaded projects.
The fourth stage
Distribution.
We try to cover the maximum number of sites, including those that are not the most standard for HTML5 projects:
- gaming portals (more than 150 sites, including SpilGames and Miniclip);
- social networks (VKontakte, Odnoklassniki, Facebook and so on);
- messengers (KakaoTalk, Telegram and so on);
- mobile stores (App Store, Google Play, and so on);
- desktop stores (Steam, Epic Games Store, Gameroom, and so on);
- game zones (The New York Times and USA Today and so on).
Here are the main advantages of working with us:
- we are porting the game to HTML5 ourselves;
- we publish the game on the maximum number of sites;
- from these sites, the developer receives more than if he left alone, since we can dictate conditions to the same game portals (we come to them with a large
- a package of projects that are guaranteed to generate gaming sessions);
- we are planning a large grid of projects. By the end of the year, we will have 600 projects that will exchange traffic among themselves.
We work on the revenue share model. Half of the income received is paid to the developer, half goes to the publisher.
***
Such a story. If you have any questions, be sure to ask.