Quote: "I do it professionally, and in any given week I don't know which language I'll be using.."
I am also a professional programmer and use several different languages on a day to day basis but I can still see the advantage of writing in
one language and using the others only to edit when necessary.
This is orthogonal programming in it's simplest form! All you need to do is:
1-Write the game once in one language, this creates one game binary that can be used across all of the supported platforms
2-Edit the interpreters when necessary. The interpreters have a simple job, they read the game binary and make it work on their intended platform
The two parts of the system have a clearly defined purpose and can be indipendently adapted to suit specific requirements.
If you are writing the original game in another language you are inheriting its quirks and making life harder for yourself.
I know that in the real world you have languages and other requirements imposed on you by your client but what AppGameKit is aiming towards is the option to create the game your own way (in basic) and then adjust it as necessary to suit specific requirements (in the interpreter). It's not really a long way from that already. The part that's missing is when there is a specific requirement that the AppGameKit command set does not cater for. That's when you would need to translate into native code and compile using the SDK, but you would still be ahead because you would already know that your game works.
The basic version of AppGameKit is incredibly quick for rapid prototyping game mechanics and ideas too. I wrote an early version of a game (for a paying client) in about 2-3 hours and had it back on their desk for an early review just yesterday. They couldn't believe how quickly I turned their idea into a working demo so fast, and they are experienced game designers.
That's the potential of AppGameKit in a real world scenario.
I assume you're joking about DX
