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…)
