http://code.google.com/p/nekonme – sdl binding for haxe

http://code.google.com/p/neash
The “neash” library provides a compatibility layer to allow haXe programs to target neko, c++ and flash9, giving both web browser and stand-alone support. The API follows the flash9 API very closely to allow easy porting from existing code. The neko and c++ implementations currently make use of the NME library, which in turn uses SDL.

no need to develop a new language, there are a multitude of “mature” languages which already exist, for example, lua, or python.

as for a unified language. there already is one, and you guessed it, its called c/c++.

it has a massive amount of available code, fantastic debuggers, multitudes of supported environments, excellent documentation, and a multitude of experts.

trying to keep a similar codebase between such different platforms as a phone, and a console will lead to far more trouble than its worth .

if anything, learning how to use an engine (code wise) will take far longer than learning any internal scripting language Most scripting languages tend to be very similar, and similar concepts tend to apply to most, reducing the learning curve substantially.

They all have different goals, requirements, features and users.

I find for client programming I need a native, managed and scripting language. For me, this is C++, C++/CLI (or C#), GameMonkey Script (or Lua). With those three, which work together quite well, I have the tools I need.

Game scripts serve a variety of purposes such as:
Configuration Data (eg. game entities, system config)
Testing and Debugging (eg. automation, debug console)
Limited game logic (eg. behavior, events, scriptlets)
Complete game logic (eg. entire gameplay, computation library)
Utility scripts (eg. make files, asset pipeline config)

The end user of the scripts may be an experienced programmer, and advanced level designer, or a artist / designer with no programming background.

From that list of uses and users, it is difficult, though I would not say impossible to unify. I do think we will see some maturity and consolidation of game scripting languages in the future.

The worst experience as a game programmer is being forced to use an obviously inferior system. I have seen game scripts that had syntax like assembly language, and configuration syntax mathematicians would find confusing. Why force others to use such rubbish? Well that would probably lead to a discussion of failed teams, projects and management.