I'm Johan Lajili

Jin’s Bouncing wilds, available through multiple ventures worldwide, is a game played by millions of users monthly. It features very nice graphics, relying heavily on spine animations and particles to seem as lively as possible. We developed it using the engine me and a coworker made, which uses REDUX for the state management and PIXI for the rendering, using a virtual DOM implementation similar to React. Thanks to the way it is implement, making different game becomes a breeze instead of the nightmare of maintenance that other teams might face.
It works on a variety of device, from a Samsung S3 mini to the latest MacBook pro.

I took part in the creation of the PlugnCast CMS, for INNES. In particular, I worked in the Calendar part of the application, refactoring a 5000 (!!) lines file into manageable and single responsibility modules. I also pushed throughout the application to use KnockoutJS (a Data-Binding library, similar to Angular 1, but as a library instead of a framework) properly. In particular, the use of pure function when possible, and custom bindings made the whole application not only more readable but also more performant. 

Spine is a software made by EsotericSoftware, that allows designers to export complex animations based on translation, rotation, mesh deformation etc. Essentially it allows bringing Flash-like animations in HTML5 and Unity games. 

But the software has a major flaw: There is a big difference between the animation as seen in the editor and the animation as seen in the browser. Sometimes, animation that seems to work in the editor, didn’t work in game because X feature of Spine is not supported by the JavaScript runtime. Or it would work in WebGL but not Canvas. Or it would work but have bugs on animation switch, because of missing keyframes. 

This use to be a big waste of time. Designers would export animation, and in between the first export and the final one, there would be a dozen of back and forth. That’s why in my spare time, I developed the Spine Toolkit. Essentially, it reads the exported spine animation and displays it using the same technology as it would in-game. It is packed with a number of features that allows the designer to identify the potential problem with their animation before they even have to talk to a developer.

Since it has been used, the only back and forth were for creative reasons (oh I need that fire bigger actually) and not for the differences between the game and the editor.

The application is made using React, PhotonKit (to make it look native), Electron (to package it as a binary application, making it easier to use for designers) and a node backend for the auto-update server. I have done it in its entirety.

 Those are four examples of Slot games made with our custom game engine, using Redux and PIXI at its core, and working similarly to React. Thanks to a detailed analysis of what is different between each game, and grouping games by family, we were able to put the big majority of the code in the engine. The games only contain json5 files describing how they look and placing components. This means that whenever a new feature is requested, instead of updating 5 games  (or worse, updating only one and ending up with different level of legacy code), we just update the engine. All the games support:

Local play (no need for a backend to develop the front end)
Automation (QA now write automation scripts using a simple proprietary scripting language)
Live Reload (as soon as you save your file, the game is updated. If your change is cosmetic, the game doesn’t even reload, the change appears immediately. If you are changing code (including in the engine), the page refreshes on its own.
Unit testing: All our components are written using TDD with mocha. 

This is a series of games made for Cinime (see the work experience section). Without going into details, users would open the games in the cinema as the same time as specific advertisements. Audio watermarking technology would sync up the game with the big screen, and users would have to