Moai Roadmap - What New Features Do You Want to See?

[mikea]

Beta developers: what features do you most want to see come to Moai next?  This thread is about creating a great "most wanted" list, not about ranking ideas against each other.  



I'll start:

• Sound support - in progress


• Ready to use social network features


• Game analytics


• Virtual currency support


• Offers support (for app monetization)


• Building blocks for online community


• Building blocks for multiplayer (e.g. in-game chat)

Mike.

[todd]

How about these?

• More docs


• More sample code


• Source code to Wolf Toss!

[mikea]

And a few more requests from beta signups:

• 3D


• WebOS PDK support

Mike.

[dissidently]

Open GL 2.0 



And I'll second the 3D requests.



WebOS PDK support is interesting.

[patrick]

WebOS PDK looks like a workable environment for Moai. Any volunteers to collaborate on a reference project for it?

[dissidently]

I can't think without blends.  Hamstrung designer brain.  Is it possible to do additive blends between sprites layed one above the other relative to the camera in Moai?



Sorry if this is a dumb question.  Retarded designer looking at code is not a good mix.

[patrick]

Sure. You can set OpenGL style blend modes using MOAISimpleShader. Moai defaults to add alpha, but you can control that when loading your textures. With the right blend settings you should be able to lay one prop over another and fade it out to create a dissolve effect (or set its alpha to 0 to create an additive highlight effect).

[sanghuacai]

I want to know when the MOAI will release to public.

So exciting to hear about this project, and I am waiting to get the MOAI SDK to dev an IOS game by LUA!

[patrick]

We're shooting an open beta later this month. Stay tuned!

[javidcf]

Great!! I'm so excited to start playing with it

[sanghuacai]

• openfeint

• in game purchase

Waiting public beta !

[herbert.danzinger]

AWESOME stuff guys.

I'm a little overwhelmed with the featureset that is already in place in MOAI.



And when it comes to 'features' I'd vote for:

- more tutorials

- more case studies

[thebullno1]

• Virtual filesystem. Currently Moai's Android reference host use a very inefficient method for accessing assets (extracting at startup time). A pluggable virtual filesystem can help Moai to be truly portable. On Android, we can mount the apk and access it as if it is part of the filesystem. It can also enable us to create "DLC packs" for our games: The user downloads additional data/content from our server as a compressed archive. The game mount this archive onto the filesystem and access it as if it is bundled with the game. With the help of Moai Cloud, I believe many interesting things can be done.


• Better documentation


• An unified plugin/extension framework so that they can be shared across the community. Since Moai targets platforms where C++ is not the primary language, platform-specific extensions mostly consists of writing wrapper/stub in the "primary" language (Objective-C, Java) and passing it to C/C++ functions which are bound to Lua functions. An unified way of structuring those extensions(where to put the .jar, .a, .lib, .so, .dll, .lua files, what kind of manifest files need to be written...) can help to unite the community efforts to make Moai more powerful. I think this should be scheduled after Moai becomes stable.

Anyway, MOAI in its current state is already pretty awesome.

[patrick]

I took another look at the Android SDK docs. Are you thinking about the StorageManager OBBs? We had missed that my first time through. Are the DLCpacks also just OBBs? Let me know your thoughts and we'll definitely update the Android host. We have a client releasing a big iPhone project in the next few weeks, but need to be on Android shortly thereafter. The approach you're outlining sounds like a much better way to go.

Haha! Yes, documentation. We need to get a wiki set up. And write some.

Happy to hear your thoughts on a better plugin framework. My approach so far has been to put extensions in static libraries and inject them into the runtime - like the FMOD and Untz extensions. Would be nice to have an official recommendation on how to prepare plugins for contributors. Would also be nice to enable contributors to create commercial plugins if they so desire.

Thanks for all your feedback! We have so much more to do. 

[thebullno1]

Actually, that was the first time I heard about OBB , I want my game to be available to cheaper phones in the market (with Android 2.0+) so I haven't done any research on 2.3. But OBB also fits into the system that I'm describing.



First, we have a VFSManager. Hmm, there's no code box in this forum.

A more readable version of the code can be found here: https://gist.github.com/1062847



class VFSManager

{

//Add a filesystem to a stack of managed filesystem

void mountFilesystem(IFileSystem* fs, const char* name);

//Remove a filesystem

void unmountFilesystem(const char* name);

void getMountedFilesystems(IStringIterator* it) const;

//Similar to dir/ls

void listFiles(const char* path, IStringIterator* it) const;

bool fileExists(const char* path) const;

//return null if file can't be found

IInputStream* openFile(const char* path) const;

//Other stuffs
};

VFSManager serves as a container for other subsystems. listFiles, fileExists, openFile will iterate through the filesystem stack, calling the desired method on each filesystem either until it gets the desired result: non-null return or until it reaches the end of the stack.



IFilesystem is specified as:



class IFilesystem

{

void listFiles(const char* path, IStringIterator* it) const = 0;

bool fileExists(const char* path) const = 0;

//return null if file can't be found

IInputStream* openFile(const char* path) const = 0;

};



And IInputStream:

class IInputStream

{

int getSize() const = 0;

bool eof() const = 0;

//return number of bytes read

int read(MoaiDataBuffer* buff, int numBytesToRead) = 0;

void seek(int offsetType, int value) = 0;
}; 



We can implement different filesystem based on this interface. Here are some that I can think of right now:

• NativeFilesystem: just wraps C's file functions. Not really useful on Android


• ZipFilesystem: mount a zip file


• AndroidAssetsFilesystem: inherits ZipFilesystem, mount the apk but treat all paths as relative to the assets folder


• OBBFilesystem: use JNI to provide C++ access to OBBs.


• NetworkFilesystem: grab data from an asset server to let designer experiment with their assets without having to rebuild. Removed in release build.

Since filesystem are added to a stack, the last added filesystem will have a higher priority. Thus, things like theme/expansion pack can be easily implemented. Just mount the active pack as the last filesystem. It will override bundled assets. Needless to say, all current file IO(texture, font, audio loading) need to wrapped through VFSManager.

Yep, it looks a lot like PhysFS, but I dislike PhysFS since it is not really open to plugins and does not support password-locked archive, which is important if you want to protect your assets for some reasons (eg: hide source code to prevent hacking of online/competitive games)

I'll be happy to contribute if given some guideline on coding conventions, library structures, etc… so that it fits into the current framework.



About the plugin framework, I believe Moai is still too young for that. But if you have time, you can take a look at how Appcelerator, Unity and Airplay do it.

[patrick]

Ah - so VFSManager is a proposed architecture? I had misread your original post to mean that there was already VFS support native to Android.

I had a look at PhysicsFS. Lack of password protection and plugins notwithstanding, it may be good as a quick fix. It's certainly better than our current solution! It may be a while before I can put an engineer on a bespoke implementation, so wrapping something like PhysicsFS could be way to go.

Let me do a little more research. I see PhysicsFS is released under the zlib license, so that's good. Will look into it and see how quickly it can be integrated. Once we understand it we can write our own, or maybe contribute a plugin architecture and password authentication to PhysicsFS.

[yuewah]

Better development workflow, e.g. when main.lua is loaded to moai, a shortcut key, menu button, or auto reload when I changed the main.lua

[muhammed.abdallah]

i think you need a better scene management, like the Director class in Corona SDK ;)

[patrick]

Haha! I think that's a great idea, but also think it's something that should be written in Lua. Each game we've seen so far has taken its own approach to scene management and has been the better for it.

I'm really hoping that people in the community will share their own scene managers. You should have a go at writing one - it might be easier than you think. You should be able to match Corona's paradigm if you want to. If you run into trouble, post in the support forum and I can help you out.

I've also asked Andy to add a scene manager example to his tutorial backlog.

[thebullno1]

Make Untz independent of ATL.

ATL is not available in the Express version of Visual Studio and it's not like Untz make extensive use of it (it only uses CComPtr and CComQIPtr). When I saw the error message "Cannot find atls.lib" today, I was like "Huh? where does that come from?" and it actually took me a while to figure it out.

I'll try to provide an alternative implementation of CComPtr and CComQIPtr. Hope nothing will go wrong, it's just AddRef and Release right?