[Cuppycake]

Alrighty, I wanted to make sure that I provide all correct technical details here, so I ran these questions by Dorian Ouer, one of our server programmers.

Originally Posted by Laladilya

Since it deploys to the Flash player can you script using Actionscript? I saw something about Metascript, and didn't even know it ran in the Flash player. Also, could it be possible to use Adobe Air to make it deploy as a desktop application?

No, as the client is in the hands of your players, you do not want to include any game-specific scripting on the client-side of what should otherwise be a game-agnostic client. The client is nothing but a rendering engine and an input handler. The game logic and scripting is done in Lua on the server side, and piped to the client for correct interpretation/display, rather than trusting the client to do its own scripting and trusting the result on the server.

Originally Posted by Torrid

irst is the lack of hardware acceleration, obviously. You can make 3d in flash, but you can run Quake without hardware acceleration as well. You just wouldn't want to say, write a serious FPS in flash. Hopefully Silverlight and Garage game's InstantAction will encourage Adobe some in this regard.

This is a downside, that’s true. While Adobe has tossed out some tantalizing hints of hardware-accelerated 3D in Flash, there’s no ETA on when, or even if, this will be delivered. However, it is also incorrect to assume that the Metaplace Flash client is the only delivery mechanism for your game. As the data protocol between the client and server is open-source and human-readable, any potential client – from a cell phone iconic representation to a fully accelerated stand-alone 3D client – can connect to and play a Metaplace world running on the same server architecture. While Flash is our first offering of an in-house client, because of its potential for embedding and Flash’s existing deep market penetration, I think it’s safe to say that we would be disappointed if it remained the highest bar on Metaplace client fidelity.

Originally Posted by Torrid

Second is that your game's content will have to be streamed and can't be preloaded, as far as I know. Content will have to be loaded on-the-fly and your game will be limited accordingly. I'm not even sure if there are caching options available.

There are a variety of ways around this: you can either preload many of the assets on login and browser/client cache them for instant load next time they play, or you can stream (“lazy-load”) in assets on demand, while still cacheing them for later. Which method is best will depend a great deal on the mechanics of your world and the user experience you wish to present. It may also vary from asset to individual asset within a world. We intend to allow world builders to have full control over how this is done in their worlds.

Originally Posted by Torrid

Third is the lack of use of the right mouse button.

This is a drawback to Flash, yes.

Originally Posted by Torrid

You can write a custom client for Metaplace, but honestly I'm not sure why you'd want to do that over just straight up using another platform (such as Torque) that may be more suited to your game and which would also probably be much less work. Unless you wanted your game to have a more traditional .exe client and also a web interface via Metaplace.

Ideally, using Metaplace, you could make your world playable from any number of simultaneous client fidelity levels. The advantage to using Metaplace as the platform backend to your game are:

• Low barrier of entry, built-in player base and community, networking with other games
• Quick iterations, multi-user workflow, ability to make sweeping world changes without a restart or recompile
• Sandboxing of scripts and game logic for greater game stability: less crashes
• Ability to simultaneously support multiple client fidelity levels and view modes
• Human-readable, easily-implemented server/client data protocol
• Lower barrier of entry for developing/using art assets
• Eventual built-in support for microtransactions, subscription models, etc for your game
• Potential for nearly seamless linking with other worlds
• Dev community with a pre-existing marketplace for selling and buying of world modules and smart objects

Originally Posted by Torrid

That said, there are some large advantages to a flash based game. Accessibility being the big one. Imagine playing a MMO on your cell phone. Your game will also run on something like 95% of desktops or whatever.

Our hope is that it isn’t one or another. Conceivably you could embed your game on a webpage that allows people to experience it with a low barrier of entry through Flash, leveraging its deep market penetration to generate initial interest. Then, should they want higher fidelity or other features, once you’ve got your players “hooked,” you could easily convince them to go download a stand-alone client and connect back in to the same world. This can help get around the fact research has shown that many users balk if they’re asked to download a 100M client before they can even begin to experience your game. If they can also then play your game from their cell phones, for example, you end up with even stronger user time investment in your world.

Originally Posted by Torrid

Ease of development is also a factor. If you're just a solo dev, trying to write a WoW killer in C++ is probably biting off more than you can chew. Writing a flash game however, is much more realistic. I played MUDs for years. Games don't need high end graphics to be good.

This is also definitely true. An engaging, creative, genuinely fun game can overcome the drawbacks of lower client fidelity. However, it’s somewhat misleading to look at our initial Flash client and assume it will always be the high bar on graphics and performance in a Metaplace world.

Originally Posted by Torrid

The big unknown about Metaplace is the server side of things. I couldn't find any information about how Metaplace will serve users. If you don't want your game to be trivially hacked, then you will need your servers to handle a lot of the code. I'd be very curious as to how they plan to host such resource intensive games for free, and what sort of limitations they will have.

In fact, all game code is handled server-side. There is no client-side code except for polish and performance aspects: interpolation, physics, etc. The server is still the ultimate authority on everything. All game-specific code is handled in “Metascript,” which is a version of Lua with a great number of game-specific infrastructure and API libraries built into it.

This code is entirely sandboxed within the server process, meaning that a faulty script or bad code can only negatively affect that particular world instance and not crash a server box or effect other worlds. This also allows sweeping code changes to your game logic and features in real-time, without a recompile or a restart of your game server.

There are checks and balances built-in to maintain some semblance of sanity about how many resources a particular world can monopolize. (HD space, bandwidth, CPU time, logfile size, etc.) We are still debating where these limits should be, and how any hosting model we come up with would potentially allow these limitations to be negotiated. We need a lot more practical data about what kinds of worlds our users will make before we start giving this serious consideration.

Hope this helps! =)