Archive for the ‘html5’ Category
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.
- Cross-platform (the ability to launch a game on any platform);
- The development of HTML5 apps takes relatively little time;
- Saves resources (writing of the universal code for all platforms is less costly in comparison with developing native apps for each platform);
- Easy bug-fixing.
- Possible productions issues;
- Some limitations of the mobile devices;
- 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.
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!
The Web as we know it have been born and matured on computers, but as it turns out now, computers no longer have dominance in it. According to a recent report by analyst Mary Meeker, mobile devices running iOS and Android now account for 45 percent of browsing, compared to just 35 percent for Windows machines. Moreover, Android and iOS have essentially achieved their share in just five years and their share is getting tremendously larger.
According to some forecasts their worldwide number of mobile devices users should overtake the worldwide number of PC users next year. If forecasts come true, this shift will not only continue, but accelerate. Based on data from Morgan Stanley, Meeker estimates roughly 2.9 billion people around the world will be using smartphones and tablets by 2015.
What does it mean now that more people are accessing the Web through tablets and smartphones rather than laptops and desktops? And is it really a big deal? Anyway, Internet is intended to be accessed from anywhere and thus from any device. Well, it is quite a change at least in terms most people consider the Web and how it gradually adapts to be used on mobile devices.
As mobile devices take over, the use of today’s desktop browsers like Internet Explorer, Chrome, Firefox, and Safari will decline. Mobile browsers are already very capable and will increasingly adopt HTML5 and leading-edge Web technologies. As mobile devices naturally have less screen area, the sites need to function more like mobile apps and less like collections of links. So the sites are likely to look like apps.
Apps may rule
Native apps for smartphones and tablets almost always surpass websites designed for mobile devices because they can tap into devices’ native capabilities for a more responsive and seamless experience. This is most likely to change in the nearest future – most experts agree HTML5 is eventually the way of the future. This is already the status quo in social gaming: for example Angry Birds and Words with Friends. Some services won’t be available at all to traditional PCs — they won’t be worth developers’ time.
Less information at once
Web sites and publishers will no longer be able to display everything new for users and hoping something will catch the user’s eye. Smaller screens and lower information density means sites will need to adjust to user preferences and profiles to customize the information they present. Increasingly, the Internet will become unusable unless sites believe they know who you are. Some services will handle these tasks themselves, but the most likely contenders for supplying digital identity credentials are Facebook, Google, Amazon, Apple, Twitter, and mobile carriers.
Sharing by default
In a mobile-focused Internet, anonymity becomes rare. Virtually every mobile device can be definitively associated with a single person (or small group of people). Defaults to share information and experiences with social circles and followers will be increasingly common, along with increasing reliance on disclosure of personal information (like location, status, and activities, and social connections) to drive key functionality. As the Internet re-orients around mobile, opting out of sharing will increasingly mean opting out of the Internet.
Emphasis on destination
Internet-based sites and services will increasingly function as a combination of content and functionality reluctant to link out to other sites or drive traffic (and potential advertising revenue) elsewhere. These have long been factors in many sites’ designs but mobile devices amplify these considerations by making traditional Web navigation awkward and difficult. Still URLs are not going to die – people will still send links to their friends and Web search will remain most users primary means of finding information online.
Going light weight
As people rely on mobile, cloud, and broadband services, the necessity to do things like commute, store large volumes of records or media, or patronize physical businesses will decline. Businesses won’t need to save years of invoices, statements, and paperwork in file boxes and storage facilities – cloud storage comes as their rescue. Banks will become purely virtual institutions consumers deal with online via their phones. Distance learning and collaborative tools will let students take their coursework with them anywhere — and eliminate the need to worry about reselling enormous textbooks.
Going mobile is an obvious trend today. Experts envisage that nearly every service, business, and person who wants to use the Internet will be thinking mobile first and PC second, if they think about PCs at all. Do you agree? And what other related changes can you imagine?
Many thanks for sharing your thoughts :)
The IT world is constantly forging ahead. There already exist several dozens of programming languages and software technologies. At the same time to choose the right thing for a specific project is not an easy thing to do.
Every technology has its own advantages and disadvantages. Hence, if you want to choose a certain implementation, which will be effective for both-development and its further support, you need to consider following issues: project scalability, its tasks and timeframes.
Large-scale projects (high load systems)
For big and high load systems (more than 3000 queries per sec, beginning from 10000 database tables) it is necessary to choose the technologies very comprehensively, as it will influence the general project productivity and security.
There are 4 suitable languages for the backend: Java, NodeJS, PHP and ASP. Though it’s better to use Java, as it allows achieving effective work speed, and gives the possibility to support hyperthreading and refacoring. Moreover, Java is one of the best fit from the point of view of development speed – there are plenty of handy frameworks.
It is better to remember, that NodeJS is a bit difficult to use when it comes to complicated calculations. Nevertheless, it helps to provide an easy project scalability and processing speed.
When it comes to high load systems, one should remember about extensibility, because it is one of the problem developers face to most often. Hence, it is necessary to think over the work layout with a database in details. For big projects it is better to put away relational databases, and turn attention to non-relational models, such as MongoDB и Redis. It is possible to use CouchDB as well.
It is relational bases that place a limit on the projects and do not give an opportunity to be extended easily. Non-relational models have a completely different structure: instead of SQL-queries API are used.
While working on middle-scale projects (1000-3000 queries per sec, 2000-10000 database tables), i.e. not too load, but not home pages either, it is possible to use Java and PHP. In this case NodeJS will not give such attractive results as in high load projects.
Databases can be both relational and non-relational. Everything depends on the further project development. If it is planned to grow rapidly, it is better to use non-relational models MongoDB or Redis. If a too big scalability is not required, Oracle will perfectly fit. The point is that in spite of being relational, Oracle is used in many projects that have a potential to scalability. At the same time there no extension problem emerge, even if several servers are used.
When the question is about small projects (less than 1000 queries per sec, 2000 databases), it is essential to put away all the complicated things, that present in high load systems. Consequently, PHP, Ruby on the Rails (this framework allows fast development), Erlang are best for development here. No doubt Java can fit as well, though it would be much faster and easier to use PHP or Ruby.
Anyway, apart from the project scalability it is essential to consider its potential. The reason is that the problems start after the project growth, when developers face to inability of an adequate project transfer to other servers and workload distribution. Besides, it is important to keep in mind the project tasks. It is highly possible to turn out, that what is popular today will not be effective for a specific project.
You know that my opinion is not the ultimate truth :-) I would be glad to read about your experience of using languages, databases while working on different projects!
Mobile apps and HTML5 are two of the hottest technologies right now, and there’s plenty of overlap. Web apps run in mobile browsers and can also be re-packaged as native apps on the various mobile platforms. With the wide range of platforms to support, combined with the sheer power of mobile browsers, developers are turning to HTML5 as a “write one, run many” solution. But is it really viable? There are still compelling reasons to go native, and clearly, many developers are indeed going that route.
1. We can divide mobile functionality into two dimensions: the experience of the app itself, and the way it hooks into the device’s ecosystem, e.g. for Android, this would be features like widgets and notifications. In terms of app experience, native apps can do more.
2. It’s true that many in-app features are simply beyond reach for an HTML5 app. No matter how hot your web skills are, if your app is stuck in a sandbox with no camera API, it won’t be taking snaps anytime soon! Making a hybrid – native plus web – app is hardly an ideal solution. It adds complexity and applies only to web apps wrapped as native apps, rather than traditional websites accessed from a mobile browser. But it mightn’t be necessary for long. Web standards are evolving rapidly, and modern mobile browsers are keeping pace. Offline storage, geolocation, canvas graphics, and video/audio playback all enjoy widespread support among modern smarpthones, for example. Even camera is starting to be supported — as of Android 3.1, it’s possible to capture photos and videos using web standards. And the latest iOS browser supports WebSocket for 2-way streaming, as well as device orientation detection.
Overall, mobile is evolving. But the web is also evolving, and fast. Among desktop browsers alone, there are five major browser vendors evolving standards and adding features at lightning pace. While it’s not a trivial process to port these features to mobile, many of them have already made their way into the mobile browsers.
Native is a fast-moving target, but the web is closing the gap.
3. Native apps use robust programming languages (e.g. Java, Objective C, C++) which were designed for complex application development and have a proven track record. The APIs were designed ground-up to support the platform at hand. You can easily debug apps in desktop emulators which provide a close representation of the target device.
What makes web development particularly troublesome is the huge diversity of browsers and runtimes. When your app runs, it’s no guarantee feature X will be available. And even if it is, how will the browser implement it? Standards are open to interpretation. On the other hand Web is often easier to develop, especially if targeting multiple devices.
4. One of the defining features of any platform is its look and feel. Users come to expect controls to be presented consistently and manipulated in the same way. There are certain idioms which vary from platform to platform, e.g. what happens when the user performs a “long hold” (keep touching an element for several seconds)? Platforms have standard idioms for such things, and you can’t satisfy them all with a single HTML5 app.
Furthermore, platform look-and-feel is orchestrated by the platform’s native software library, whose widgets encapsulate the kind of look and feel users expect. You get a lot of the expected look-and-feel “for free” just by using the native toolkit.
5. App distribution mechanisms, like Android’s Market and Apple’s App Store, have been overwhelmingly popular in recent years and are a major driving force for the entire mobile industry. Any developer can submit their native app to the marketplace, where users can discover it through a combination of browsing, searching, and getting recommendations. Not only that, but if you’ve done your job right, the glowing ratings and comments will convince users to hit the all-important install button.
It would be nice to declare a winner here, but right now, there is no clear winner. Some apps are best suited for native and some are best suited for the web. The web stack arguably has more momentum, but in terms of capabilities and execution qualities, native apps are moving fast too. And unless there comes a time when web technologies are a first-class citizen on the majority of mobile OSs, native will always be an important consideration.
Seems like the world is pushed towards HTML5. Apple has been amongst those trying so hard to get Web developers out of the Flash domination, and judging by the latest news of Adobe becoming HTML5-religious Apple’s anti-Flash campaign was successful. Becoming stronger and better polished HTML5 looks to supplant not only Flash but also press back such mobile giants as Apple, Google and Windows.
Recently the popular prediction has become that HTML5 will kill mobile apps business. The logic is simple: better HTML5 => higher quality developer’s tools release => better Web apps => improved Web-browsing experience on mobile devices. All these make the native applications position pretty unsteady. So will it necessarily lead to the twilight of native mobile apps development? At first glance – all point to this supposition. Still let’s take a deeper dig.
1. All the look and feel.
Native apps are intended to look glossier and perform better than their browser-based counterparts. As they are developed separately for each mobile platform and therefore use advantage of being OS customized and smartphones’ hardware features advanced. But will native apps preserve this advantage for a long time? Sounds doubtful…due to several reasons.
First, because to the growing variety of mobile platforms and their sub/versions. Recently developers have to spend more and more efforts on versioning and support and this is indeed exhausting and expensive. So perhaps the biggest potential benefit of HTML5 is that it will enable app developers to focus on making one version of each app running smoothly in many kinds of browsers, thus freeing them to move on to bringing more and better apps to market. And that’s definitely good, especially keeping in mind that a well-designed Web app can be indistinguishable from a native application for the user, but not ideal in this terms as still HTML5 browser apps run differently from browser to browser and from device to device making it quite difficult for developers to ensure that all mobile consumers will enjoy the way an app works in their setup.
Another point of concern so far has been that, despite all HTML5 improvements, in real-life use cases native apps still run better, faster and more predictably than browser apps. It’s natural because mostly native apps run from the phone’s memory and rely less on the network. But that’s surmountable with time – with the advent of 4G networks users will be able to retrieve content from the network far faster and more reliably than in the past.
2. Visibility and promotion.
After creating a quality application your next step will be to make it visible and popular longest possible. Native apps published in an app store may receive very little notice as app stores have grown and become bloated with shoddy or useless apps and thus accessing apps has become more of a hassle. The main issue is poor organizing and categorizing that results in difficulties to find a proper app for user’s need even if it exists in the store. Still poor cataloging of apps at big app stores could be smoothed over by specialized app stores.
Browser-based mobile apps spare developers app stores addiction and lend themselves better to Web promotion via social media like Twitter and Google+. Still even if it seems easier at first glance isn’t it still a challenge in terms of making visibility better and longer but not seen for a fleeting moment? For those creating Web apps, there’s just no good way and even a good review of a Web app on a popular site has only a temporary impact.
The way to get your app in front of potential customers is to get it featured in an app store. And this is gained by building an app that highlights unique hardware capabilities, exactly the features the hardware company use to sell the product. [These will likely be features that you can’t access today or in the foreseeable future with a Web app. This isn’t because HTML5 won’t advance, but because the device and OS manufacturers will always do their best to keep their products somewhat ahead of the lower-common-denominator Web platform. It is how they sell products.] That’s business-justified. So HTML5 is good for many apps, enterprise and customer ones, but not for the core features or the main UI.
Basically relying on HTML5 to quickly get to broad compatibility across the mobile landscape could become a trap if you follow selective strategy in your product distribution and want to have the app perceived distinguishing. For instance, you might want to build apps that only work on the latest and greatest version of a phone, and intentionally not on previous models. Then fewer people will be able to use it but those with the newest toys. [The more your app makes the hot new hardware look good, the more it’ll get promoted by the hardware or OS manufacturer. That can give your app presence it could not otherwise get. Once your product is succeeding on the brand-new hardware, you can start adapting it to other platforms.] Doesn’t this strategy distributed strategy look the most attractive?
3. Distribution and revenue generating.
As you may predict here we will mostly speak of Apple and its revenue-sharing mechanisms that has been receiving so many claims. Apple takes a 30% cut of all app sales through its store – the only way for consumers to get apps. That’s much compared to an option to build a web app and putting the whole revenue in your own pocket. This is especially unfavorable for applications with subscriptions as surprisingly this 30% cut doesn’t just cover buying apps in the store, it also applies to in-app purchases including subscriptions that may remove all the profit. That’s why for instance you can already download HTML5 Financial Times :)
So many counterpoints but should there finally be an either/or decision? The truth is somewhere in between. And we believe for the majority there may be a place for both kinds of apps. Just an example – you can create a browser-based “lite” version of your app so that prospective buyers can try it out without having to visit an app store; and further if they like the game, they might decide to buy the full version as a native app.
Moreover, developers build many native apps in much the same way that they build browser apps, using the same tools, but then fit them with a native app “wrapper.” For this reason, native apps and browser apps sometimes aren’t as different as people may imagine.
And what do you think?
In your particular case what have you decided or are going to opt for?