PlayScript Roadmap

[Ben Cooley]

Here are some of the things we've been discussing as potential features to be added in our PlayScript Roadmap.

Please understand that our focus is first and foremost on providing a full IJW cross mobile/web solution for our own games, so some of these features may be a while in coming (or never come at all).  However we'll post them here as potential features to get a little bit of feedback.

We'll repost this roadmap on the blog (playscriptblog.com) when it finally is turned on.

PlayScript Goals

------------------------

Primary Goal:

* Provide a high performance cross web/mobile solution for building games with advanced tooling for all platforms (IDE, debugger, profiler)

Secondary Goals:

* Extend the AS3 language with advanced features found in other languages

* Provide additional language features that make common game programming tasks easier and more performant

* Deliver performance and app-size and battery usage competitive with native code

* Provide language features that facilitate integration with advanced tooling, editors, and remoting

PlayScript Roadmap

-----------------------------

Short Term

1. Improved compatibility with ActionScript

   a. Most ActionScript source code should compile with minor modifications for unsupported features.

   b. Runtime library support to cover most common runtime classes (65 core classes identified)

2. Easily installable binaries and add-ins for Xamarin Studio

    a. Installable IDE plugins for all platforms (Windows, Mac, Android, iOS)

    b. Installable compiler binaries.

3. Validation of performance and compiler/runtime coverage

    a. Test compiler/runtime on actual game code in the wild

4. Deep dive on performance

    a. Ensure that all runtime core classes (Vector, Array, etc.) are high performance

    b. Reduce use of dynamic language features, identify use of dynamic via warnings in code

    c. Introduce either unmanaged code extensions or intrinsics for optimizing hotspots

    d. Validate app size, memory usage, linker efficiency, etc.

    e. Optimize hotspots of common open source runtime libraries (Starling/Away3D) with unsafe code, direct opengl calls, etc.

Mid Term (Proposed)

1. Add SWF/SWC compile target for PlayScript to allow use of PlayScript language features on the Flash platform

2. Move both C++ target and JS target from experimental to alpha state

   a. Validate with demos of Starling/Away 3D

3. Add additional game oriented language features

   a. Add vector basic types for float2, float3, float4, double2, double3, double4, int2, int3, int4. with hardware acceleration

   b. Add matrix basic types (i.e. float4x4 and double4x4) with hardware acceleration

   c. Add extensions to support fast direct binary data serialization/caching

   d. Add "not null" extension to reference types  (i.e. MyObject! object) to identify and prevent null reference errors.

4. Add language extensions to provide advanced toolabilit/serialization support

   a. Add the [Proxyable] extension to support simplified editor/data tooling on game classes (think CoreData on OSX)

   b. Add [Serialized] extension to support simple binary caching/serialization on game classes (think Pickle in python, but with high performance binary native support)

Long Term (Proposed)

1. Add "native" support to language

  a. Packages or classes marked with 'native' keyword are compiled using C++ ABI and are not managed/garbage collected.

  b. "native" classes by default do not have bounds checks, memory zero, null checks and require explicit reference counting or memory release

  c. "native" classes are implemented using each platforms native sandbox (mobile->native code, flash->domain opcodes,  javascript->asm.js)

  d. Any "native" package or class can optionally be compiled either native or managed.

2. ASM.JS support for all "native" code

  a. Any native classes are compiled to ASM.JS and run in the native sandbox on JS environments.

  

3. Direct LLVM target

  a. An LLVM target to bypass the C++ target and go directly to LLVM native code.

4. Inline assembler support

  a. Support inline .NET IL code for .NET environment

  b. Support inline LLVM

  c. Support inline ARM code

Please feel free to comment on this roadmap and let us know what you think.

[Rick Zhou]

Is there a list of the 65 core classes?
I think it will be better to also list AS3/flashplayer features that won't be supported in playscript (in short or mid term)

[Ben Cooley]

We track those in a private google doc spreadsheet.  I can possibly move that to public.

Essentially the classes we found our games referenced.. mostly in display, utils, geom, network, and media.   There are surprisingly few "real" classes in the flash core library - most of the classes are actually enum classes.

[Ben Cooley]

I can take a stab a rough draft.   The problem has been that we have been drawing those lines in the sand, then actually breaking down and implementing the features anyway.

E4X is a good example.. we were not going to implement it, but it's now to the point where it's almost complete.

On Thursday, May 16, 2013 5:35:11 PM UTC-7, Rick Zhou wrote:

[Kevin Newman]

This all looks pretty good.

The asm.js target through a "native" keyword sounds pretty nice too. I'd imagine you'd also need to add a way to allocation and deallocate memory. This seems like a nice integrated way to expose those memory features of the various platforms.

Something unrelated - I can't seem to post to this list from my email client. Is anyone else having that problem?

Kevin N.

[alex...@digikama.com]

Forgive me for a newbie question, I'm not very familiar with .NET/Mono. 

Your Flash runtime and specifically Stage3D implementations - are they actually universal .Net libraries and can be used without Playscript, say, in a vanilla C# .NET/Mono project?

[Ben Cooley]

Yes they are.  

Let me be a bit more clear on the use of .NET and how ActionScript/PlayScript and .NET interact.

First of all, we use .NET for all of our tooling.  The IDE plugin, the compiler itself, and the debugger etc. are all based in .NET.  That is not likely to change as the economy of building the compiler and tools based on the Mono/Xamarin open source toolset allows us to do more with less resources.

However, that being the case, we do not want to make the .NET runtime a fixed dependency for either ActionScript or PlayScript.  The runtime environment itself uses the Xamarin toolset to target mobile, but we also target the Web with Flash and soon JavaScript, and also potentially C++ with a simple conservative garbage collector (or a simple mark/sweep system). 

What this means is that we will soon be introducing a cleaner separation between .NET and PlayScript/ActionScript so that you can be aware of how and where you are introducing .NET dependencies in your code.

1. You will get errors when you use .NET methods not found in ActionScript unless you specifically import .NET namespaces in your code files (i.e. you must import System.* to use System.Object, ToString(), GetHashCode().

2. By default, you will get portability warnings when you import .NET namespaces/packages in your code.  This is somewhat controversial, so we'd be interested in your feedback on this.

3. Runtime code will not expose .NET dependencies by default.  You will need to access private interfaces to access .NET specific methods.

[alex...@digikama.com]

Thank you for a detailed answer, Ben! 

Flash, JS and .NET targets are great, but it's hard to understand the reason behind adding C++ target. I understand the awesomeness of being able to have only a part of code unmanaged and super fast (I don't know if such thing possible in .NET/Mono), but wouldn't it be less complex (in terms of Playscript project scope) to use .NET target for all those platforms like iOS, Android, Windows, Mac?

[Ben Cooley]

We've debated how useful the C++ target would be given the advantages of the mono runtime.  I'm not sure it will be a very high priority.