Uphill

[via Digitalmars-d]

On Monday, 1 June 2015 at 10:37:31 UTC, ketmar wrote:
> even PC games tend to migrate to Unity. mobile games will stop 
> using home-
> made engines very soon, as porting it to each platform is 
> simply wasting
> of time. so there will be old codebases which nobody will 
> convert anyway,
> and new codebases that using Unity, Cocos or something like it.

I don't know, it is hard to stand out if you build on Unity or 
Cocos unmodified.

But I think web browsers are slowly moving towards a situation 
where you soon can make sensible games in webgl + asm.js using 
home-made engines using "native javascript" (basically javascript 
targetting LLVM IR) or pnacl (LLVM IR).  So the distinction 
between native and non-native is getting blurred.

Just take a look at shadertoy and see what people can do in GL 
shaders that work on the web. And shaders are written to the 
current hardware if they are to perform well (so "native").

Realtime javascript programming + WebGL quality is going to 
become more important than native binaries for games if the 
payment model issues find a solution.

I'd say the payment model that the app-stores provide are more 
important than distributing native code.

A web-based game has a distinct significant marketing advantage. 
Click on a web ad and instantly find yourself in a game world 
(free trial). Anything that takes installation is at a 
disadvantage. Unfortunately, anything that requires entering 
credit card info is at a disadvantage too...

> so "generating native code for mobile platforms" target can be 
> ignored,
> it's investement that will take alot of time and efforts with 
> very little
> benefit.

I think the focus will shift from "generating native code for 
specific hardware" to "generating code that effectively 
translates to native code for specific hardware". Which roughly 
is the same deal.

(Most games are scripty, yes, "paper doll", "cartoony 2D" etc…)