Menu Search
Jump to the content X X
Smashing Conf New York

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf New York, dedicated to smart front-end techniques and design patterns.

Rebuilding An HTML5 Game In Unity

When our HTML5 game Numolition was nearly done, we decided to throw it all away and rebuild it in Unity. That turned out to be an exciting and valuable experience, and one that I thought would be worth sharing with other Web developers. Come in, the water’s warm!

Last year, we released a mobile game named Quento1. It was written entirely in HTML5, wrapped in our proprietary PhoneGap alternative and launched in many app stores with mild success.

Further Reading on SmashingMag: Link2

The game caused me to jot down a few spinoff ideas. One that I particularly liked was a game with a stack of numbered tiles in which the player has to clear a level by combining numbers and tapping groups to make them disappear. I created a prototype in HTML5, Quento Towers, so that I could run it by a few coworkers in the office by simply handing them a mobile phone with the game running in a browser.

A first HTML5 prototype7
Move 1 to the right to land on 4. Merge 1 and 4 and merge 2 and 3. Then, tap the 5s to clear the level. (Large version8)

Those who played the prototype really liked the idea, so I spent quite a few evenings and weekends designing levels and experimenting with new features. The gameplay was coming along nicely, and I even added a built-in level editor using localStorage to save levels, which was very helpful during commutes. Yes, Web technology was definitely of great value during this phase.

Fun note: You can play the prototype in a browser9 (tested on Safari and Chrome). It even has the level-editor functionality.

The Art-Direction Pivot Link

I was pretty happy with the minimalist style, which was similar to Quento’s. It would keep development time down and enable us to release quickly, allowing Quento to become our brand of math games — something I seem to have an affinity for, and the reason the team calls me He-who-makes-grid-with-numbers-games.

Meanwhile, our artist, Richard, had secretly prepared a pitch on art direction that he thought would make the game stand out. One morning, he showed this:

Possible title screen for Quento Towers
Possible title screen for Quento Towers.

Fancy explosions
Fancy explosions.

Merging effects
Merging effects.

Wacky characters
Wacky characters.

It was spot on. I saw that the effects and cutesy characters, combined with the unique gameplay, could really set this game apart. It wasn’t long before Richard was producing more artwork and we had a suitable soundtrack. Benjamin, one of our iOS engineers, was working on our own PhoneGap alternative because we had had some performance issues with PhoneGap. And I was putting it all together for an internal demo prior to our annual company trip.

The game even had a new name: Numbers. Demolition. Get it? Oh, and the word had zero hits on Google at the time.

A new name for the game.
A new name for the game.

The Internal Launch Link

On the day of our internal launch, the game looked like this:

Three screenshots of the HTML5 version of Numolition.10
Three screenshots of the HTML5 version of Numolition. (Large version11)

It ran on iOS and Android, its resolution was fixed to 640 by 960 pixels, and it had been tested only on WebKit browsers. This approach had worked before, and we wanted to streamline the gameplay before making it more responsive or tweaking it for other resolutions and devices.

Note: Our approach was to support just a few resolutions, like 3:4 and 2:3, and then scale up using CSS and fill the remaining space with white to match the comic panels.

In hindsight, setting an internal launch date was a logical next step after prototyping, because the game now had an audience and was an actual release.

The play test that followed during this trip was very informative. Everyone still loved the game, and not only did they enjoy the normal levels, but people seemed to prefer the special tower modes that we added. And we learned that all 50 nerds were comparing their high scores with one another, which made us decide to add a leaderboard of some sort.

However, we also saw a lot of problems from the Web-based DOM and CSS nature of our game. You see, with so many Android devices at hand, we noticed that some devices showed permanent movement artifacts, rendering glitches, problems with Web fonts, missing elements and many other issues that weren’t simple “bugs” that could be fixed.

One Android device was missing tiles.
One Android device was missing tiles.

Rather, these issues were caused by how a particular device’s browser component handled the rendering and offloaded parts to the GPU. We couldn’t fix the problems with code alone. We would only be able to work around them using obscure CSS tricks, which often have side effects.

Trying Out Unity Link

Back at our company, Q42, we evaluated the current state of Numolition. The core gameplay was good enough be released, which felt really good. What didn’t feel good were the rendering glitches and performance on some devices. Even though most people at Q42 had pretty new Android models and we weren’t doing anything crazy in the code, we wanted the game to run a bit more smoothly than it was.

Note: Our Web version of the game was built using the DOM and CSS, not canvas. Had we used canvas, we wouldn’t have had many of the rendering differences between platform. However, cross-platform performance, especially on old devices, was not likely something that canvas (hardware-accelerated or not) could solve out of the box.

Moving forward and releasing the game as is was one option. Rebuilding with canvas was another. A third suggestion, given by Benjamin, was to give Unity12 a try, for the following reasons:

  1. Although Unity was built for 3-D games, its developer was working on a promising native 2-D engine, which has since been released.
  2. Its free license13 seems to allow for development and distribution of mobile apps at no charge, requiring only a splash screen and missing some Pro features that we felt we could live without.
  3. Cross-platform comes out of the box: desktop, iOS, Android, Windows Phone, Windows 8, BlackBerry.
  4. It allows for development in C# or UnityScript14 (often referred to as JavaScript, even though it is more akin to Microsoft’s JScript.NET). Both languages are familiar to the team.
  5. Using it would be a great learning experience.
  6. It would offer us valuable comparative insights.

And, hey, how hard could it be? We decided to give it a try for two weeks and see how far we could get.

Not very far, it turned out. Still, the results were interesting.

Unity From An HTML5 Developer’s Perspective Link

We chose to go with C#, instead of UnityScript, because of its class-based nature and friendly and familiar syntax. We started by literally porting existing methods that dealt with the computational engine, instead of the visuals. For instance, a fragment of the JavaScript that detects which tiles are affected by a given tap was converted from this…

// returns an array of [$tile, $tile, $tile] that match the value of the given tile
// optionally (depending on GameOptions) bombs will explode surrounding tiles,
// and if those tiles are sets of numbers, they will chain a larger explosion

this.getMatchingTiles = function(x, y) {
	// create an array of tiles to check and put the current one in there
	var tilesToCheck = [],
		had = {},
		added = {},
		valueToMatch = that.getCurrentTileValue(x, y),
		matchingTiles = [];

	_lastMatchingBombCount = 0;

	// helper function to add new tiles to the checking queue
	function addTileToQueue(x,y, fromDirectMatch, value) {
		var id = 'tile-' + x + '-' + y + '-' + value;

		// if x and y are within the frid and this tile hasn't been checked yet
		if (x >= 0 && y >= 0 && x < that.tilesX && y < that.tilesY && !had[id]) {
			had[id] = true;
			if (that.existsTile(x, y)) tilesToCheck.push([x, y, fromDirectMatch, value]);

	addTileToQueue(x, y, true, valueToMatch);

… to this in C#:

public List<Tile> GetMatchingTiles(Tile tile) {

	// stack of tiles to check
	Stack<CheckTileSetting> tilesToCheck = new Stack<CheckTileSetting> ();

	// hash of positions (and their value) that were already checked
	HashSet<string> had = new HashSet<string> ();
	List<string> added = new List<string> ();
	List<Tile> matchingTiles = new List<Tile> ();
	lastMatchingBombCount = 0;
	lastMatchingStarCount = 0;

	// adds a title to the stack to check, only if the tile exists
	// and not already checked (for this value)
	addTileToQueue addToQueue = delegate(CheckTileSetting cts) {
		string hadId = "Tile-" + cts.col + "-" + cts.row + "-" + cts.valToCheck;
		if (!had.Contains(hadId)) {
			Tile tileToCheck != null) {

	// add the initial tile to the stack
	addToQueue (new CheckTileSetting { col = tile.col, row = tile.row, valToCheck = tile.val, fromDirectMatch = true });

In the first few weeks of working with Unity, I had quite a few head-scratching newbie moments. I had to forget things like pixels and relative positioning and get used to cameras, scaling, GameObjects, meshes, renderers and shaders.

A Short Overview of How Unity Works Link

Projects in Unity start with an empty scene that can be used for a menu, for a single level or even for an entire game. It’s a 3-D container, and a camera is positioned towards its center: 0,0,0 (yes, three axis: x, y and z). You can then add GameObjects from within the editor or hook up scripts that do this by code. A GameObject only has a position within the scene, and it can be a void container acting as a relative position to its children, or it can be a flat pane, or it can be any mesh (shape) ranging from a simple cube to a castle. This is all component-based: A mesh is a component, but a script is, too, and you can add them to any GameObject. Then, you add materials (the textures), which is when it starts to look like a game.

Any object may be moved or animated — relatively or absolutely — and you can control the camera, too. So, for Numolition’s menu system, we drew the comic panels only once and then pan the camera from left to right to navigate between them.

All objects that you instantiate and place in a scene may be viewed in the hierarchy panel that shows the entire tree, which is Unity’s equivalent of the DOM. While the game is running, you have real-time access to this hierarchy to inspect items, but you can also freely move through the 3-D space that represents your current game. This free view is different from the actual game view and allows you to see what’s going on from multiple perspectives. This came in handy for us on several occasions when we noticed that items were invisible because of their 3-D position in space (due to being placed behind other objects).

The Unity IDE with Numolition running.15
The Unity IDE with Numolition running. (Large version16)

Overall, the Unity IDE offers scene and property inspectors that are solid, visual and real-time, and in some cases the 3-D approach works better than a flat Web view, but I also found myself missing Chrome’s WebKit inspector from time to time, including its flexibility and especially the script console.

But what I felt was lacking the most was a mechanic like CSS: a language to declaratively describe the look and feel of objects that have a certain name, ancestor path, context or behavioral class. Sure, Unity provides a theming mechanism for its GUI layer17, but it’s not the same and hardly as flexible as CSS, one of the pillars of the Web.

This was, however, all part of the learning experience. The upside after the first few weeks was that the basics of the game had been reconstructed quite rapidly, and it wasn’t long before we had a playable version.

Managing Images For Cross-Platform Usage Link

A nice aspect of our way of working was that Unity allows visual artists to easily contribute. Richard didn’t simply provide us with new artwork — he built and tweaked explosion sprite sheets and added particle effects. All we had to do was hook them up to the corresponding event in the game.

Another fine aspect of working with Unity is the fine-grained control you get to manage your assets. We didn’t have to prefabricate all of the different images that we were going to use for each platform. Instead, this happens compile-time, based on the raw originals that you have included in your project. You can control default compression, override it for particular platforms, apply it to multiple images or per image, set maximum resolutions, compress results by a factor of 2 for memory optimization, etc.

Image management in Unity.18
Image management in Unity. (Large version19)

This truly removes a big hurdle that is still present in the Web space today, with the responsive image format still being worked on over multiple iterations. Sure, it’s all coming with HTML5, and you can accomplish it today if you know the ins and outs, but with Unity it’s just there, today, designed with mobile games in mind.

Evaluating Our Unity Game Link

Because the game had reached the point of being better and more feature-complete than where we left the HTML5 version, we decided to take a moment to evaluate the process and results so far.

We were surprised. The game ran smoothly on any high-end device that we tested it on, and older devices running the likes of Android 2.3 did really well. Sure, the frame rate wasn’t the same, but here’s the big difference: With our HTML5 (i.e. DOM and CSS) version of the game, the differences between devices and resolutions were mainly rendering glitches, device-specific hiccups or bugs. With our Unity version, the only differences were frame rate and memory usage on low-end devices.

We hadn’t written any code to optimize how the game would run. If the device was running Android 2.3 or iOS 6 or higher, it just worked. At the same time, we decided to submit a test build to the Amazon Kindle Store — despite not having an actual Kindle to test on or even having tried to run the game in a Kindle emulator. That’s how confident the results made us.

Note: Because the game wasn’t completely finished, we didn’t publish it to the Kindle yet. Since then, we’ve been able to pick up a Kindle Fire at a local store. And guess what? The game runs brilliantly!

Numolition running on a Kindle Fire.20
Numolition running on a Kindle Fire. (Large version21)

A huge disappointment in the realm of Unity, however, is the Asset Store22. Nothing is wrong with charging for add-ons, such as vector drawing and tweening libraries, but it sets the standard for others to charge for their code and is the complete opposite of the realm of the open Web, which everybody is trying to push forward.

Instead of using social coding to make things better, the Unity forums are full of developers presenting their one-off packages to solve specific problems, requests from other users for features, and bug submissions, with each individual developer hopefully fixing them. And because there is no trial for these add-ons, we ended up purchasing about eight of them and throwing away five or six because they simply weren’t very good.

Windows Phone Trial Mode Link

Towards the end of our development process, we learned of trial mode for Windows Phone23. This allows players to download the game for free and purchase it later, but it differs from an in-app purchase because it doesn’t require the developer to specify a purchasable item for each particular app store and then handle each purchase in-game. When a user purchases an app that is on trial, they go through a regular round-trip purchase, as if they had bought the game in the store directly, and then are taken back into the game.

Unity offers support for this through a simple API:


We learned that users almost expect trial mode for Windows Phone games, so Unity offering such a feature out of the box is a real treat. Implementing it took us less than a day, and it might have contributed to Microsoft’s choice to feature our game on the front page of its app store in several countries, as well as the positive reviews24.

A downside is that Unity does not offer a similar basic API for performing in-app purchases. To do this, developers still need either to build it themselves or to go with one of the third-party plugins available in the Asset Store.

Why It Took Us So Long Link

We started rewriting the game around September 2013, and the game was released in March 2014. The reasons why it took us this long are threefold, and not specifically related to either Unity or Web technology.

First of all, we decided to go with a comic book design, and so our panels needed to stretch.

Responsive comic book panels in Unity.
Responsive comic book panels in Unity.

Because we were rebuilding the game in Unity, we thought we’d tackle the responsive side of the menu system, which consists of comic book pages with panels. The idea was to draw these panels proportionally to the screen in order not to stretch any lines, which would have looked awkward.

This took us multiple attempts to get right. It involved creating the panels in code through meshes (i.e. shapes) generated on the fly, loading and scaling materials and doing a whole lot of math.

Secondly, we wanted to integrate Facebook leaderboards. This wasn’t difficult, but it just took time. We needed to sort out how to properly support both users who have installed the Facebook app and those who haven’t. And because the Facebook SDK for Unity25 is still in development, we struggled here and there. But we feel that the result justifies the time spent on this.

Facebook leaderboards26
Facebook leaderboards. (Large version27)

Thirdly, fragmented planning. We simply had many other projects and cool stuff going on, so sometimes we couldn’t touch a line of Numolition code for a few weeks — although we still had weekends and evenings.

Conclusion Link

So, does Unity beat HTML5? No, nor is this post intended to answer that question. The purpose of this retrospective is to provide insight into what it’s like for an HTML5 developer who strongly sides with the DOM and CSS to get into Unity game development.

You see, I still feel that HTML5 is… well, friggin’ awesome! Without it, we wouldn’t have been able to build a website such as Rijksmuseum28’s, one of the projects we are very proud of. HTML5 is getting better every day, and we will be using both HTML5 and Unity again for future projects. For mobile games, we think that the Web and its lineup of third-party tools, wrapping technologies and hardware-accelerated canvas solutions still have a way to go, whereas Unity offers quite an interesting alternative right out of the box.

Simply put, we are really happy with the current state of our game, and giving Unity a try provided a valuable lesson. Unity’s great performance, fine-grained control over asset management and the ability to deploy to multiple platforms so easily are big advantages of Unity over vanilla HTML5.

Having stepped into the world of Unity as a Web developer, I think it’s safe to say that a lot is to be learned from Unity’s approach. On the other hand, Unity could benefit from the way the Web works — for example, the openness and the separation of the declarative rendering mechanism from the logic. Both Unity and the Web could learn and benefit from each other.

The Numolition launch trailer. (Watch on Youtube29)

A Comparison Link

I sat down with the Numolition team to draw a list of the pros and cons of developing a mobile game with Unity and with HTML5 (although focused on the DOM and CSS with the latter). The list is as subjective as can be, but it might be helpful if you’re thinking about developing your next game in Unity.

Unity, The Good Link

  • Performance is great.
  • Publishing is cross-platform and highly reliable.
  • Management and control of assets is easy.
  • Artists can easily contribute.
  • C# syntax is still very friendly.
  • Camera positioning is easy (compared to left/top, DOM reflowing, etc.).
  • It’s proven for professional games.
  • Behaviors are built in (gravity, collision, etc.).
  • Scene and level editors come out of the box.

Unity, The Bad Link

  • 2-D is still 3-D. It relies heavily on meshes, renderers and all of the other 3-D stuff. (It would be like using WebGL and Three.js30 to make a 2-D game.).
  • Unity’s equivalent of the DOM is a hierarchy. A mechanism such as CSS to style items generated through code would be welcome.
  • Doing things like coding my own alpha grayscale shader still gives me nightmares.
  • The commercial Asset Store loses to the open Web and Git for being trial and error and for not pushing technology or usability forward.
  • There are small annoyances. For example, touching code and saving while the game is running makes the game crash, which seems avoidable.
  • In case you need all of the Pro features, the commercial license is expensive: $4500 per developer to support iOS and Android31.
  • MonoDevelop is the default code editor, and it does the job, but it’s not fantastic. (You may use any other editor, of course, such as Visual Studio on Windows, but for code completion on a Mac, you’ll find yourself sticking with MonoDevelop for some time.)

HTML5, The Good Link

  • It’s made for 2-D (with the DOM, CSS and canvas).
  • CSS is extremely powerful — you’ll miss it.
  • The WebKit inspector!
  • Having no compilation step during development is a true win.
  • Just use your favorite text editor and start partying — no IDE or software required.
  • It’s ideal for prototyping.
  • Web fonts are flexible (shadows, outlines, etc.).
  • Visual styles and behaviors can be declared separately and applied at runtime.
  • The Web is open and moving forward, thanks in large part to the community.

HTML5, The Bad Link

  • The performance of mobile games when using the DOM and CSS isn’t on par with Unity.
  • Performance from canvas is much better with third-party hardware-accelerated solutions, but you’ll lose support for quite a few old devices, and the available solutions are flakier than just having this one tool do the job for you.
  • The visual results are unreliable and differ a lot between devices when relying on a browser component wrapped in native code.
  • A native wrapper is required to publish a mobile app.
  • Using Web fonts for a mobile game falls under “redistribution” in some cases and would have incurred hefty licensing fees in our situation.

Now that you’ve read all about how our game came to be, you might be interested in experiencing it for yourself. Technical details aside, it is a challenging puzzle game. You can drop by Numolition32 for more information—but you don’t have to, of course.

(al, ml, il)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32

↑ Back to top Tweet itShare on Facebook

Martin Kool is a creative shotgun with sawed-off barrel and partner at Q42. When he's wearing his 13th bulletproof Game Designer suit he comes up with things such as Carrrds, Quento, Numolition or Flippy Bit And The Attack Of The Hexadecimals Of Base 16. He can also be held responsible for the retro adventure game portal and co-founding HTML prototyping service Handcraft. He lives in the Netherlands with his wife and four kids and has been spotted eating pindarotsjes.

  1. 1

    Fantastic post!
    Thanks for sharing your experience.

  2. 2

    Douglas Bonneville

    April 24, 2014 7:18 pm

    I’ve had annoying problems working with artwork, where Unity “adds” noise and garbage around the edges of some transparent artwork. The workaround for fixing it was creating custom alpha channels and doing very pain the neck things like expanding a copy of the artwork under itself so Unity has data to work with, etc. when blending transparent edges into the scene. Most of the artwork we did (for v1 of the game in Lua on another platform) had to be redone after refactoring everything into Unity3D.

    What was your experience with artwork, in general, in regards to transparency and sprite sheets?

    • 3

      You can disable compression to prevent artifacts but that comes with a performance penalty. It doesn’t have much to do with Unity to be honest, hardware/gpu compression in general is fairly rudimentary when compared to file compression (e.g. png, jpg etc).

      Transparency bleed is another issue that will crop up with hardware blending, you will indeed have to set the correct colors for the transparent pixels, as transparent pixels will still have a color which will be “seen” if you’re zooming out and the renderer samples multiple pixels, or when building mipmaps.

      Hardware-based rendering such as employed by Unity is made to have very very high performance, that approach unfortunately brings some quirks with it.

  3. 4

    (Hi Martin)

    Very interesting article, very informative, but coming from the non-html5 side of games I feel the need to defend some of your bad points about Unity…

    “2-D is still 3-D.”, I’m not sure if the 2d build was out when you made Numolition, but that basically removes most of the (visible) working with mesheh and “3D stuff”. But even then, loads and loads of 2d games use 3d tech, i.e. textured planes, as sprites which has some quirks but also some huge advantages such as free parallax scrolling, fog and hardware accelerated drawing.

    “a mechanism such as CSS”, you’re free to build something like CSS if you’d want to but since Unity is a generic solution for games it makes no sense to implement such a thing on a GameObject/Transform level. Sure, the blocks in Numolition lend themselves pretty well for CSS like styling, but CSS makes less sense for when one enemy is a Goomba and the other a Bullet Bill. Generally, game entities use different meshes, textures, effects etc, and less cascading styling. The unity GUI styling is terrible though, no denying that ;)

    “coding my own shader”, is it really fair to critique something because you’re not used to working with it? The shader system in Unity is actually quite amazing and flexible. I guess if you’re used to having a grayscale effect being available out-of-the-box and it not being available in Unity is frustrating, but that does not mean the shader system is a bad thing.

    “The commercial Asset Store”, I am of two minds on this: yes the open community drives tech forward and helps the community as a whole, but then there’s a huge amount of companies and creators obfuscating their code which indicates some sort of need for “closedness”. The asset store can be a great help if you’re in need of assets you don’t have time to create, but the implementation is still a bit lacking. Also, there are some good Unity communities and resources (such as Unity Answers, the Unity Live Training videos and

    “In case you need all of the Pro features”, it is expensive, but you yourself have proven that you don’t need those features to create an awesome game ;)

    “MonoDevelop”, it is true that MonoDevelop isn’t the best editor out there and especially the one shipped with Unity has some weird bugs, but it does have semantic highlighting, inline code checking, refactoring, debugging etc. And on windows you can use Visual Studio which is pretty close to the perfect C# editor.

    So, there, I felt I needed to say that :)

  4. 5

    @Douglas, I recognize what you say. We used Sprite Packer to create our sprite sheets and we saw similar effects around the edges of only some buttons – and only on some devices. We then played with overriding the compression algorithm per platform per sheet which solved our issues. All of them. So in the end our experience with art and transparency was pretty smooth.

  5. 6

    Hi @Hessel

    Thanks for your point of view! I may owe you my insights on some of your statements, so here goes:

    “2-D is still 3-D.”, there are indeed many advantages of having a 3d world represented as 2d, just the requirements to render a simple flat panel seemed a lot compared to the web.

    “a mechanism such as CSS”
    All I’m saying is that Unity could learn and benefit from it. Even if it could only set positions based on cascaded rules and not even try to touch textures or effects it would be very helpful I’d say.

    “coding my own shader”
    I expected an alpha grayscale shader to be available out-of-the-box and when coding it, my personal experience was that the shader syntax is, well, not for the faint of heart :) (compared to JScript, Javascript and C#)



  6. 7

    It is an advertorial, isn’t it? Replacing an open, well supported technology with a closed, proprietary one is like going back to the old days with Flash, ActiveX and Java applets, Nonsense.

  7. 8

    A nice sharing for your experience when port HTML5 games into Unity… i will give HTML5 a try for game development soon, cheers!

  8. 9

    طراحی سایت سنندج

    April 25, 2014 9:59 am

    Thanks for sharing, this is a fantastic article. Keep writing.

  9. 10

    Nice comparision. But I think Unity is heavy for this kind of game.
    Another alternative for multiplatform and 2d you can try Corona SDK or Gideros Mobile.

  10. 11

    Another solid option is Adobe AIR. A pretty solid performer for cross device publishing of games. Have you guys ever considered using AIR when you thought of moving away from strict HTML5?

  11. 14

    just to mention that Unity said that they are working on releasing a capability to compile to html5 based games with help of asm.js. This surely will boost the performance and cross-platform support. looking forward to see asm.js into Unity

  12. 15

    HTML is only option available option someone is giving name Adobe AIR how about more options….. free-trial.aspx

  13. 16

    Emile Jobity

    April 29, 2014 2:37 pm

    Great article.

  14. 17

    Arul Selvan

    May 3, 2014 5:14 pm

    Did you consider the free

  15. 18

    First I have to say that your game is great, really cool!

    I need to add that the new UI system (4.6) is AWESOME!

    About your review,cons/pros:

    There is an “Alpha from Grayscale” Option in the advanced texture options, so, you didn’t have to write the shader for that.

    About the money, yes, it is expensive, but I think it worths.

    “There are small annoyances. For example, touching code and saving while the game is running makes the game crash, which seems avoidable.” Well, the Unity Editor has to recompile the code, if it happens while playing the game, well, what could you expect from a compiled-based program? it is not interpreted as html5, it is a compiled software. If you mean that seems avoidable because it should not let you compile while the Editor is playing the game, well, you’re right, but it is more annoying to stop the player, save again, wait compilation, play again than just stop and play.


↑ Back to top