Re: [Algorithms] Complexity of new hardware

[Jon W. <jw...@gm...>]

Andrew Vidler wrote:
> Yes, I think there is.
> But I think you'd be competing with (possibly lower-level) scripting 
> languages rather than engine level C/C++. Not that that's necessarily 
> a bad thing.

Wouldn't that be a tough sell? You'd already be competing with free 
implementations of LUA, Python, JavaScript and their ilk on the low end, 
and built-in languages like UnrealScript on the high end. While 
middleware for something like mesh exporting and animation (Granny) or 
something like networking or AI make sense, because there is no good 
free library for those areas, the scripting language market seems full 
of entrenched competitors with a zero dollar price point.

>
> There definitely needs to be a change to the way most games are 
> written when considering new hardware. It's perfectly possible that a 
> new/different language might be a good way to go - however, I'd be 
> concerned that it would introduce more complexity, i.e.

Doesn't this bring us back full circle? I recall a statement from a 
month ago saying that we all need to think differently about how we put 
together massively parallel software, because the current tools don't 
really help us in the right ways... That's not just games, mind you, but 
business software is often less performance critical, and server 
software already has a reasonable parallelization strategy with data and 
service federation (and 800-way CPU boxes like those from Azul...).

Sincerely,

jw