Restoration of old games

Hi Habra! This article is the first of a series of articles about the game engine StalinGrad. I will start the story about him from afar, having considered the prerequisites for its creation. The article will discuss how to make games, convert JS -> APK, and other difficulties and problems.

An example before and after restoration (and also for Android `a ):


I love games and work as a web developer. Therefore, due to the specifics of his work, he made games on JavaScript. At some point I thought about the fact that probably there are already a lot of JavaScript games and corresponding communities on the Internet, but as it turned out there are none.

All the games that I could find were divided into two categories:
')

• The first were done by fan in the 90s and either did not work or were buggy
• The latter were created on the wave of fashionable HTML5 by different companies and were not widely used on the Internet.

This is rather strange, because the Internet is full of old games, and all new ones are written as if only to write an article about them on some sort of habr.

I liked the first version, and I decided to start with the restoration of the old games.

They all have a few typical mistakes:

• Bad appearance
• Non-rubber interface
• Use of old, inoperative structures

I will start with the HTML layout - I always took Bulletproof HTML as the basis, then I looked for pictures on some iconfinder. If the subject was wide, I took games written in other languages ​​and borrowed graphics from there. The main field of the game - preferably should be a square to perfectly fit into any shape. If you couldn’t mix up with tires, I finished off changing styles from JavaScript.



Next, it was necessary to always overwrite the redundant elements (all sorts of textarea with a history of moves, etc.). And the necessary ones (for example, buttons) are designed in the form of pictures and shoved in the corners of the screen. Special attention deserved alert `s and confirm` s, which I replaced the layout.

Since I constantly had to perform the same set of actions - I began to optimize the code. This is how the modules appeared that did not depend on each other and solved one specific problem (show a beautiful message, add a menu, fasten animation).



The next step was localization. Looking at the old Japanese game of 1996 about an airplane, I realized 100% that I need to write less, and preferably in English. Unknown people from what country and how many years will look at your work - it is necessary that he understood. Yes, and bugs with a coding of 100% will not. So that the eggs do not fly into me, I will immediately make a reservation that this text is not about commercially successful games, but about how to make JavaScript work more or less clearly in any conditions and under any circumstances.

Step by step, the experience grew, the number of ready-made modules increased, and the recovery of old games turned out better and better.

Next came the question of porting. Since I am writing in JavaScript, and now it is fashionable - it means the game should be everywhere where there is a browser. But the browser is not there unless, only on refrigerators.

Since I did not know in advance where the game would work - it should not have any external dependencies, and use the simplest constructs that worked, worked, and would definitely work (here HTML5 goes through the forest).

A very interesting incident happened when I met my friend and showed him one of my games that I was writing at that moment. There the guy ran and beat the deer with a baseball bat. And at that moment, my friend was just delivered an e-reader from Amazon, and this reader could go online. I suggested running the game on the reader. No sooner said than done. And the most amazing thing is that the game worked. Of course, she slowed down, in some places the layout was removed, and she didn’t look very good on a black-and-white display, but she worked!

This fact (and even the experience of writing backgammon on JavaScript for TV), prompted me to abandon Drag and Drop, the buttons - to turn into links, and in the layout not disdain tables. Many people throw eggs at me in this place, but the fact remains that efficiency, durability and dependability exceeds the limit.



The first thing I took into circulation - extensions to browsers. It so happened to create a couple of templates for Crome and Opera. Having extension templates, I just had to insert the game files into them and put them into the markets. Then my eyes fell on mobile platforms. As it turned out, in any SDK there is a WebView element - it can be stretched to full screen and make us download our game from the folder. That's all. The only thing that stopped was too lazy to understand different SDKs. Therefore, while there is a template only for Android `s. And it turned out that Samsung is preparing to release a new Tizen operating system, and there is still more fun - you add a manifest file, zip'you, and then change the extension to wgt - that's your phone application.

In general, the majority of web applications on different platforms, as it turned out, are a zip archive with a modified extension (wgt, oex, etc.).

Many, probably, in this place will remember about fashionable PhoneGap. I used it in two projects and was extremely dissatisfied (but this is my personal opinion, since I did not see any real help from it). To use it or not - decide for yourself, but remember - on any device you can usually bridge between JavaScript and native language. If you have a developer in your native language at your side, you can implement almost everything. They threw him a bridge, and then let him write all you need in your native language.

Degeneration of new games

Once a year ago, just for the new year, Studio38 released the New Year Snake ( http://studio38.ru/portfolio/snake ) and published an article on Habré. The snake turned out good, beautiful, but it was worth compressing the browser screen, as it became clear that the snake could not live long ( http://2013 . Studio38.ru/ ). The snake was non-rubber, and a scroll appeared.



I decided to rebuild it, and at the same time pull out the graphics and restore another game (forgive me Studio38, I hope not to sue). Found another snake. She was old and with a table layout, but rather trouble-free. I corrected the styles, added modules (for example, replaced alerts), corrected a couple of jambs - and the game was ready. It did not have links to vk and facebook, did not drag the list of players from the server and there was no trendy HTML5, but it was ready for export.

I collected several browser builds, paid the student 50 rubles for a video review and began to scatter it on the Internet. And nothing, shake slowly.



Since there is still a package of graphics in stock - I reassembled the old game about balls (there are a lot of variations of it, but the essence is the same - to collapse the balls by color) and I already received two New Year games on JavaScript.



By the way, about the graphics. Looking through a huge number of old games on JavaScript, you can see that all of them were made by fan programmers who had problems with graphics and design. Therefore, if you also have problems (and most likely they are), get used to looking for graphics and borrow beautiful elements. If you managed to find a good solution, remember it and reuse it. This is much better than poking, wherever possible and impossible all sorts of Twitter Bootstrap `s.



Another point that I would like to note is the CSS frameworks. We had one half-year project at work that didn’t end with anything. We tried to assemble an online toy and, by decision of the management, were daubed with all the modern technologies (Boostrap, CoffeeScript, Jade, HAML, NodeJS, etc.) So, advice - if your toy is not Twitter, do not even think about Bootstrap ( Vadim Makeev speaks about it very well here ). Technology should not be chosen because of fashion. Collecting another game - think about what you get besides the game (it could be graphics, from which you will collect a couple of games, or an engine, or several independent modules of the rating system, which will then help you to fasten the rating wherever you go).

Cross Platform Development

JavaScript has a huge advantage over other languages ​​- it is cross-platform by default. If you have written a web application, then it will work wherever there is an adequate browser. And since in recent times the number of devices with a built-in browser and the ability to access the Internet is increasing, your application has great prospects. Therefore, it is immediately worth thinking about, and preparing for the publication of the application on various platforms and in various locations.

In cross-platform development, several nuances should be considered:

We do not know the size of the browser window that will be given to us, so the entire layout is rubber.

• For example, it can be a desktop application and a 1024x740 screen, or an extension for a browser of 400x300, or a small phone, with a screen of 320x240.

We do not know anything about what will or will not work, so we do everything as simple as possible.

• We refer to the page elements strictly by ID
• The code is modular and all calls are wrapped in try catch.
• You need to be prepared for the fact that we will have a piece of code or layout removed. Anything else that does not fall under the deletion should continue to work and not lead to system failure.
• We do not know the user's touch or not touch screen.
• We do not know if he has a keyboard or a mouse (he can sit from a tablet or terminal in the underpass)
• We do not know whether it has support for cookies or localStorage (therefore, we need to check these properties and be prepared for the fact that they will not turn out)

We do not know anything about the power of the computer.

This may be an eight-core home computer or a weak mobile phone. It is necessary to optimize the algorithms of work.

We do not know anything about user access to the Internet.

You need to be prepared for the fact that he will not have access to the Internet

• Lushe develop offline applications, or think about the possibility of offline work

We know nothing about the coding, language of the user and his intellect.

• We write less, replace all with pints, make the interface minimalistic
• If you have to write, we write strictly in English, and the shorter the better.
• Sentences should be simple, so that any translator can translate them with a minimum of errors.

Resource generation

Since the application will be published in various markets, we need to prepare a set of resources for such a publication. Consider what we need:

Application logo and advertising banners, preferably in PNG format of the following sizes:

Logos: 512x512, 160x160, 128x128, 128x128 (96x96), 114x114, 96x96, 72x72, 64x64, 57x57, 48x48, 36x36, 32x32, 18x18, 16x16

Banners: 1400x560, 1024x500, 920x680, 440x280, 180x120

A strange line of 128x128 (96x96) means that you need a 128x128 logo with transparent edges, that is, the image itself occupies the central square of 96x96 px. Such a logo is needed for the Chrome store and it is easy to make it from the 96x96 logo by adding transparent edges to it.



JPG screenshots

Three screenshots from the phone (854x480 for example)

Three screenshots from a PC (can be cut from previous screenshots by making them 800x400)

Three screenshots for each browser (they should show the application, in the form of extensions to the browser)

• Chrome 1280x800
• Opera 1366x768

Application Description

Prepare a description of the application in the form: a title (1-3 words), a brief description (one sentence with a call to action), a full description (up to 250 characters). The description is desirable to do in Russian and English.

Video (review or “lets play”).

In order not to waste time on preparing the video, try to find on the Internet any high school student, with a clear diction, which is 50-100 rubles. will remove and mount the video.

Next, register a bunch of accounts in all stores and professional forums and proceed to the publication of your application.



How to generate a bunch of logos?

Many options, the best & mdash; scripts. To create logos for my games, I use three original images: large, medium, small. Next, the script makes several copies of each of them. This is necessary in order to preserve the quality of pictures while decreasing. For example, a large 128x128 picture may look bad if it is compressed to 24x24, and vice versa. Therefore, from a small image & mdash; we will receive small logos (32x32, 24x24, 18x18, 16x16), from the middle & mdash; medium ones (96x96, 72x72, 64x64, 57x57, 48x48), and from the big one & mdash; large ones (512x512, 240x240, 128x128, 114x114). Download a set of scripts here . Consider the tools for our purposes:

• CreateOriginal.bat creates one big.png image from one, two more: small.png, midle.png. But in fact, this is not the best option, because the whole essence of the separation of the first three pictures by quality is lost.
• http://testico.net/ use this site to create curvaceous and pleasing look for the three source images (getting iPhone-style icons)
• http://pixlr.com/express/ and this site will help add filters to banners like on Instagram (in case you decide to cut banners from wallpapers to your desktop that are the same)
• CreateCopy.bat creates a bunch of copies of the original three images, signing files by size. Then you should run over the logo and manually compress them to the desired size. You probably have a question, why didn’t I compress the pictures with scripts? He did, but the quality was bad. If you can optimize this stage - skinte scripts.
• iPhone_Android.bat copies to a separate folder and renames the logos that will be needed for apple devices and for building an application on Android
• Logos for Apple should be added to the folder with the site (if you use the standard template, then the meta tags already have the addresses for the pictures)
• Logos for Android should be added to the folder with the application project (or rather, replace the standard project logos with them)

Assembly

Application and extension templates:

• Android
• Chrome . The template will fit all browsers based on it (for example, a new opera or Yandex Browser)
• Opera (old, before switching to webkit)
• Tizen

How to build a build for Android

• Install Android SDK, Eclips and all you need to build APK files
• Run Eclips
• File / New / Android Application
• Fill in all the items and create the Hello World app! (all stages of creating the first application can be found on the Internet)
• Compare the AndroidManifest.xml file in your template. There will be a couple of differences, for example, in the template there is such code: android:configChanges="keyboardHidden | orientation | screenSize" >
• Next, copy the package in the gen folder through Eclipse (or the entire folder in general) from the template into your project
• Expand the src folder. Package name does not match. Therefore, right-click on the copied package in gen and select Refactor / Rename. Rename the copied package in the same way as the package name in the src folder.
• Go to the src folder and open the MainActivity file. Copy the code from the template there. Attention! Keep track of the package name in the code! Rename all discrepancies (for example, in the first line) to your name.
• Next you need to correct the appearance. Go to res / layout / activity_main.xml and replace the code with a pattern from the template: <?xml version="1.0" encoding="utf-8"?>

<WebView xmlns:android="http://schemas.android.com/apk/res/android"

android:id="@+id/webview"

android:layout_width="fill_parent"

android:layout_height="fill_parent"

android:scrollbars="none" /> <?xml version="1.0" encoding="utf-8"?>

<WebView xmlns:android="http://schemas.android.com/apk/res/android"

android:id="@+id/webview"

android:layout_width="fill_parent"

android:layout_height="fill_parent"

android:scrollbars="none" />
• In the file res / values ​​/ strings.xml, you can correct the name of the application
• There are icons in res / drawable-hdpi and similar folders. Replace them with your similar sizes.
• Copy your application to HTML in the assets / game folder

What you need to know about Android:

• There is a file with manifests (AndroidManifest.xml), it describes what the application can and what not (for example, rotate the screen)
• You cannot build a build if you have xml open. When building, just in case, close all files and open src / your_name_name / MainActivity.java
• A virtual device must be running.
• Sometimes the Clear button helps (top menu, Project / Clean ...)
• To put the APK on Google you will need to sign it. To do this, right-click on the project / Android Tools / Export

If you have something to boot up and fail to assemble (and most likely it will boot up), look in Google, or ask familiar Java developers to see what is wrong in the project. Be prepared for suffering, because without glitches the first time the project is unlikely to be collected.

How to assemble an extension to old opere

• In the template folder, replace custom_icon_18.png and custom_icon_64.png with your logos
• In the config.xml file, fill in the fields name, description, author
• Delete everything from the game folder and copy your application there.
• Compress in ZIP the entire folder of the template and change the extension from ZIP to OEX

How to build an extension to Chrome

• In the template folder, replace custom_icon_16.png, custom_icon_48.png and custom_icon_128.png with your logos
• In the file manifest.json fill the fields default_title, description, name. In the column sandbox just in case you can add a list of files
• Delete everything from the game folder and copy your application there.
• Open Chrome / Tools / Extensions.
  
  
• At the top, put a tick Developer Mode
• Click the button Packaging extensions ...

You can test it first by clicking the adjacent Download unpacked extension button ... and specifying the folder with the template

How to assemble an extension to Tizen

• In the template folder, replace custom_icon_160.png with your logo
• In the config.xml file, fill in the name field
• Replace index.html, js, images, css with our files.
• Compress in ZIP the entire template folder and change the extension from ZIP to WGT

Build the desktop version

On Habré slowly appear articles about the release of HTML5 on the desktop. More and more corporations are starting to make products with support for HTML5, like a native language. But ... not everyone knows that the "evil corporation" wrote down the HTML Application in the form of HTA files at the dawn of 2000. So since the days of Ishak 5.0, JavaScript can be on the desktop, and if you try using VBScript and JS, you can even organize a registry entry in the background.

But usually in practice they use other options for accessing the desktop:

• Convert JS to EXE. This is the coolest way. The bottom line is that you get a single page browser. Tools are already there (you can find in Habré), but they are still raw. My assembly in EXE weighed 60 mb. and so much weight made it unsuitable for production.
• Use intermediaries. There are a lot of applications and extensions that are inherently Stems (for example, Pokki). But as a matter of fact, this is not access to the desktop, but access to a new platform for distribution. Besides, the user will need to install this platform.
  
  
• Convert JS to CHM. Horror, but the files are almost the same in weight and this is the only real way to go to the desktop. CHM - works on any Windows OS and does not require installation of any other software. The only negative - the application will be processed by the built-in browser. And what is the built-in browser for Windows? Right! Ass! And here you can catch a lot of bugs, if you have an unstable application.

If you even make a "knight's move" through the HTA, then you should take a number of measures, to hide your "non-kosher web of the past" - change the html extension to HTA, other files (JPG, PNG, JS) - rename to DLL and put in one folder . Ideally, this is index.cha and the build folder with a bunch of incomprehensible files. At first glance, the strategy is quite upset, but if the moderator of the portal software is not attentive, you can publish the game as a desktop application. The main disadvantage is again work through the built-in browser.



When uploading to software portals, you should not write the words JavaScript and HTML5. Moderators may be suspicious. Behave like a typical user and concentrate on how to attract players.

I hope the above tips and templates will help you to distribute your JavaScript applications at different sites and in different formats.

When I started writing this article, I didn’t even know how much to write and finish. At some point it seemed that there would be no end, so I published it as it is. Sorry if sometimes logical inconsistencies or demo does not work. If the article is interested, then you can learn more.