Altabel Group's Blog

Archive for April 2015

633f9fa73cbd70a588025148eb216a92

Since the “flash crisis” (starting from the summer of 2013) a lot of game developers have collided with an issue of being crammed with outdated flash games with copyrights sold to various sponsors and game portals.

For the majority of the developers porting their old games to the new platforms could be an ideal option.

That is why I decided to write an article on how they could re-monetize old games with no great effort.

I suggest using HTML5 as this particular game platform allows making the porting without huge investments.

The article reveals the following questions:

  • What games are suitable for the porting to the HTML5?
  • How to make the porting qualitatively?
  • How to sell the renewed game wisely?

Briefly about HTML5:

Firstly a few words, why I suggest using HTML5 for porting flash games: HTML5 is a widely known technology that has such syntactic features as , and elements, as well as the integration of scalable vector graphics (SVG) content (replacing generic tags), and MathML for mathematical formulas. These features allow to make it easy to include and handle multimedia and graphical content on the web without having to resort to proprietary plugins and APIs.

I guess it does not require a lot introduction, still for more information feel free to visit: http://en.wikipedia.org/wiki/HTML5

Below I would like to point out the main benefits and some shortcomings of using HTML5 for porting a flash game.

Pluses:

  1. Cross-platform (the ability to launch a game on any platform);
  2. The development of HTML5 apps takes relatively little time;
  3. Saves resources (writing of the universal code for all platforms is less costly in comparison with developing native apps for each platform);
  4. Easy bug-fixing.

Minuses:

  1. Security;
  2. Possible productions issues;
  3. Some limitations of the mobile devices;
  4. Lack of the common standard for the browsers and devices (bug-fix could be quite time-consuming).

So, if you are concerned in porting you game to the web we could proceed to the first question:

What games are suitable for being ported to HTML5?

Not any game is suitable for being ported to HTML5. There are a few limitations that should be taken into account, for instance:

  • While porting your game under mobile HTML5 the attention should be paid to the control. If the control is managed through the keyboard it means that apparently you will have to port the control as well in order to gain the desired game experience. It is possible to develop tab sensor, still it is not often useful because the player’s fingers hedge the majority of the display what leads to the gameplay/ levels reconstruction or even to rejecting the idea of porting the game.
  • 3D games are not suitable for porting under the mobile web (WebGL technology is not supported by the majority of the mobile browsers).

The porting process is greatly depends on the HTML5 app building approach.

How to make the porting qualitatively?

While speaking about the games with Canvas rendering there would be a three- step approach:

  • Porting the graphics

Art is almost the only thing that we would take from the old game, as the code will be written from a scratch. Porting of the graphics is a complex procedure. Its complexity depends on the initial game format. In the end we should get the raster version of every element of the game starting from the background up to effect animation.

  • Porting the logics on JavaScript

This is the most significant and time-consuming process. It could take from 2 weeks to а couple of months depending on the particular game. Normally a game is developed with using a framework. The choice of the frame is not a simple question and deserves a separate article.

  • Testing and bug-fixing

Worth mentioning that to make the testing of the mobile- web app as effective as possible you should use a number of mobile devices, at least the most popular. Otherwise it is possible to refer to the company that provides QA and testing services.

When the testing is finished the question regarding the distribution arises as well as regarding licensing and it’s specific.

Despite the fact that lately the positive tendency of the HTML5 games is observed, for many developers the monetizing issue is on the agenda. Still in case of applying the wise business model your HTML5 game could become quite beneficial.

How to monetize your game?

  • Selling of the exclusive license

Basically the portal SpilGames bought the exclusive licenses and was a price leader for the developers. Still, recently a number of changes have been noticed in the company and it is quite unclear yet whether they will continue purchasing the content. In other cases, in order to sale an exclusive license you will have to make a good scouting.

  • Selling the site-locks

It is one of the most prevalent ways to monetize the game. In average you could get the profit of about 200-600 USD per game. Just find active customers. Actually there are plenty of portals. First of all this is in interest to the flash games portals owners to keep the constant user base. Generally the users get their mobile devices and returning to the favorite flash game portals and are not able to launch any flash game. The owner of the portal whether loses this user or suggests the alternative- a game that could be launched on the mobile device browser. Another variant is to sell the unexclusive license through auction-portals like FGL.

  • Revenue share scheme

In this case you give your game to be placed in a portal or a portal network and get a part of the revenue form the commercials that were shown in the game. The revenue is mostly depends on the customer, still do not expect huge profit. When it is about a good traffic and the customer is convinced in the profitability of the game, he usually will buy the site-locks.

  • Self-promotion and commercials revenue

The developer integrates the commercials right in the game and gives it free on the partner-site. The revenue is counted on the basis of the commercials shown directly in the game. Thought in comparison with the flash market prime-time, nowadays there are no automated channels of distribution in HTM5 game dev. So it is manual work so far.

It is also worth mentioning that the Google AdWords (the most effective advertisement) will not suit for distribution of such game as Google requires direct linking to the domains where the game will be shown. 

Some useful advice:

  • Obfuscate you HTML 5 games in order to secure them from piracy. Sure, it won’t provide a perfect security, still will become an obstacle to steal the game and will filter out a number of pirates.
  • Sell the game for a particular platform/ market. Reserve the title rights. HTM5 is a universal technology so you are able to convert your game to any platform market (HTML5, web, iOS, Android- these are three different licenses.)
  • While selling the site-locks assure that the name of the portal as well as its mirrors are stated in the contract.
  • Using the revenue share scheme request the access to the statistics.

Hope this tips would be useful. Also if you have any suggestions and better solutions, feel free to share in the comments!

 

Tatyana Ogneva

Business Development Manager

 

altabel

Altabel Group

Professional Software Development

E-mail: contact@altabel.com
www.altabel.com

In the history of computing first Java appeared, then close on its heels came JavaScript. The names made them seem like conjoined twins newly detached, but they couldn’t be more different. One of them compiled and statically typed; the other interpreted and dynamically typed. That’s only the beginning of the technical differences between these two wildly distinct languages that have since shifted onto a collision course of sorts, thanks to Node.js.

If you’re old enough to have been around back then, you might remember Java’s early, epic peak. It left the labs, and its hype meter pinned. Everyone saw it as a revolution that would stop at nothing less than a total takeover of computing. That prediction ended up being only partially correct. Today, Java dominates Android phones, enterprise computing, and some embedded worlds like Blu-ray disks.

For all its success, though, Java never established much traction on the desktop or in the browser. People touted the power of applets and Java-based tools, but gunk always glitches up these combinations. Servers became Java’s sweet spot.

Meanwhile, what programmers initially mistook as the dumb twin has come into its own. Sure, JavaScript tagged along for a few years as HTML and the Web pulled a Borg on the world. But that changed with AJAX. Suddenly, the dumb twin had power.

Then Node.js was spawned, turning developers’ heads with its speed. Not only was JavaScript faster on the server than anyone had expected, but it was often faster than Java and other options. Its steady diet of small, quick, endless requests for data have since made Node.js more common, as Web pages have grown more dynamic.

While it may have been unthinkable 20 years ago, the quasi-twins are now locked in a battle for control of the programming world. On one side are the deep foundations of solid engineering and architecture. On the other side are simplicity and ubiquity. Will the old-school compiler-driven world of Java hold its ground, or will the speed and flexibility of Node.js help JavaScript continue to gobble up everything in its path?

Where Java wins:

1. Rock-solid foundation

I can hear the developers laughing. Some may even be dying of heart failure. Yes, Java has glitches and bugs, but relatively speaking, it’s the Rock of Gibraltar. The same faith in Node.js is many years off. In fact, it may be decades before the JavaScript crew writes nearly as many regression tests as Sun/Oracle developed to test the Java Virtual Machine. When you boot up a JVM, you get 20 years of experience from a solid curator determined to dominate the enterprise server. When you start up JavaScript, you get the work of an often cantankerous coalition that sometimes wants to collaborate and sometimes wants to use the JavaScript standard to launch passive-aggressive attacks.

2. Better IDEs

Java developers have Eclipse, NetBeans, or IntelliJ, three top-notch tools that are well-integrated with debuggers, decompilers, and servers. Each has years of development, dedicated users, and solid ecosystems filled with plug-ins.

Meanwhile, most Node.js developers type words into the command line and code into their favorite text editor. Some use Eclipse or Visual Studio, both of which support Node.js. Of course, the surge of interest in Node.js means new tools are arriving, some of which, offer intriguing approaches, but they’re still a long way from being as complete as Eclipse.

Of course, if you’re looking for an IDE that edits and juggles tools, the new tools that support Node.js are good enough. But if you ask your IDE to let you edit while you operate on the running source code like a heart surgeon slices open a chest, well, Java tools are much more powerful. It’s all there, and it’s all local.

3. Remote debugging

Java boasts incredible tools for monitoring clusters of machines. There are deep hooks into the JVM and elaborate profiling tools to help identify bottlenecks and failures. The Java enterprise stack runs some of the most sophisticated servers on the planet, and the companies that use those servers have demanded the very best in telemetry. All of these monitoring and debugging tools are quite mature and ready for you to deploy.

4. Libraries

There is a huge collection of libraries available in Java, and they offer some of the most serious work around. Text indexing tools like Lucene and computer vision toolkits like OpenCV are two examples of great open source projects that are ready to be the foundation of a serious project. There are plenty of libraries written in JavaScript and some of them are amazing, but the depth and quality of the Java code base is superior.

5. Threads

Fast code is great, but it’s usually more important that it be correct. Here is where Java’s extra features make sense.

Java’s Web servers are multithreaded. Creating multiple threads may take time and memory, but it pays off. If one thread deadlocks, the others continue. If one thread requires longer computation, the other threads aren’t starved for attention (usually).

If one Node.js request runs too slowly, everything slows down. There’s only one thread in Node.js, and it will get to your event when it’s good and ready. It may look superfast, but underneath it uses the same architecture as a one-window post office in the week before Christmas.

There have been decades of work devoted to building smart operating systems that can juggle many different processes at the same time. Why go back in time to the ’60s when computers could handle only one thread?

Where Node wins:

1. Ubiquity

Thanks to Node.js, JavaScript finds a home on the server and in the browser. Code you write for one will more than likely run the same way on both. Nothing is guaranteed in life, but this is as close as it gets in the computer business. It’s much easier to stick with JavaScript for both sides of the client/server divide than it is to write something once in Java and again in JavaScript, which you would likely need to do if you decided to move business logic you wrote in Java for the server to the browser. Or maybe the boss will insist that the logic you built for the browser be moved to the server. In either direction, Node.js and JavaScript make it much easier to migrate code.

2. Build process simplified by using same language

Complicated build tools like Ant and Maven have revolutionized Java programming. But there’s only one issue. You write the specification in XML, a data format that wasn’t designed to support programming logic. Sure, it’s relatively easy to express branching with nested tags, but there’s still something annoying about switching gears from Java to XML merely to build something.

3. Database queries

Queries for some of the newer databases, like CouchDB, are written in JavaScript. Mixing Node.js and CouchDB requires no gear-shifting, let alone any need to remember syntax differences.
Meanwhile, many Java developers use SQL. Even when they use the Java DB (formerly Derby), a database written in Java for Java developers, they write their queries in SQL. You would think they would simply call Java methods, but you’d be wrong. You have to write your database code in SQL, then let Derby parse the SQL. It’s a nice language, but it’s completely different and many development teams need different people to write SQL and Java.

4. JSON

When databases spit out answers, Java goes to elaborate lengths to turn the results into Java objects. Developers will argue for hours about POJO mappings, Hibernate, and other tools. Configuring them can take hours or even days. Eventually, the Java code gets Java objects after all of the conversion.
Many Web services and databases return data in JSON, a natural part of JavaScript. The format is now so common and useful that many Java developers use the JSON formats, so a number of good JSON parsers are available as Java libraries as well. But JSON is part of the foundation of JavaScript. You don’t need libraries. It’s all there and ready to go.

5. Speed

People love to praise the speed of Node.js. The data comes in and the answers come out like lightning. Node.js doesn’t mess around with setting up separate threads with all of the locking headaches. There’s no overhead to slow down anything. You write simple code and Node.js takes the right step as quickly as possible.

This praise comes with a caveat. Your Node.js code better be simple and it better work correctly. If it deadlocks, the entire server could lock up. Operating system developers have pulled their hair out creating safety nets that can withstand programming mistakes, but Node.js throws away these nets.

Where both win: Cross-compiling from one to the other

The debate whether to use Java or Node.js on your servers can and will go on for years. As opposed to most debates, however, we can have it both ways. Java can be cross-compiled into JavaScript. Google does this frequently with Google Web Toolkit, and some of its most popular websites have Java code running in them — Java that was translated into JavaScript.

What is your opinion on what to choose Java or Node.js?

Polina Mikhan

Polina Mikhan
Polina.Mikhan@altabel.com 
Skype ID: poly1020
Business Development Manager (LI page)
Altabel Group – Professional Software Development


%d bloggers like this: