Web Deployment...is it working yet?

#101 Good to see you Josh and thanks for repying. You are one of my heroes.

Quote:Mac support would seem a more important priority.

That makes me shutter.


I agree a Flash, Silverlight, or Shockwave plugin might be the best choice and those are not always easy to gain.

After digging into this further I think the real issue stems from size. The majority of Unity games you see on the web are not "streaming" either. Unity just was able to package the game into a small enough package to make it work. It actually only compiles what you use. You can drop 300 megs of assets into a project but only use 20 megs. When you compile it to the web you get a around 5 meg file, engine and all.

That I think is the major breakage. You are stuck with streaming option with Torque as the oputput result is too large. Now Unity Pro does have streaming and it works well as I have used it as does Neo-Axis and others.

I think the point has been made here, the web is important and Torque users do want it. Like another poster said so well. There is no better way for a indie to get exposure. It is the future.
I think tasking a "thread complete" by changing the "in minutes" is not a solution or the original concept of this thread. The phrasing on the site originally was even worse when I started the thread.

It is funny but this thread and all the responses has got me to pick up Torque again and play around. While the web plugin maybe fail the networking blows Unity's away by 400mph. So all in all I think the buzz is out there and maybe soon we will see some progress. Just make sure I am a tester ;)

#102 If you download the tools demo, you can package the demos for the web, put them on your own server, and serve them out as demos to get a feel for the speed/bandwidth, etc. The tools demo already has them compiled for the web. It just needs to be packaged and put up on the site.

Sorry if I wasn't clear on that point.

#103 When Josh talked about flash I think he was referring to the Stage 3D tech in flash 11 that gives hardware acceleration support with it's own shader language(s) and not a plugin for flash.

Stage 3D is indeed impressive but the rest of the app is still going to be actionscript which is slow. Now that adobe is pushing forward with the Alchemy compiler, which will compile c++ code to actionscript, it may become a viable option for 3D games soon . Unfortunately even Alchemy compiled ActionScript is quite a bit slower than native code (anywhere for 2-10 times slower per Adobe), so things like realistic physics and AI are still a ways off. I suspect the situation will improve with HTML5 encroaching on Flash In the traditional rich web app space Adobe will start focusing more on Flash as a gaming platform and produce something faster.

We'll see.

#104 @hallsofvallhalla: Thanks :) Even with streaming, the assets still need to be optimized and organized and good luck getting users to install your plugin. You're also opening yourself up supporting a custom plugin on existing and new versions of multiple browsers. I would never do this as an indie.

@Gerald: I've been following Alchemy closely for a couple years and have used it in some contract gigs. I also got Quake2 running under it with the software rasterizer just to push it. The Flash VM is quite fast, AS3 is difficult for a compiler to optimize (and the compiler has historically kind of sucked), but the VM is good. This is also shown by haXe. I am very glad to see Adobe pushing Alchemy forward, Epic used it to compile out some millions of lines of C++, so I am thinking the latest version, that they'll be productizing, will be solid

#105 @Josh

Thanks for that video, I see they're targeting 80% of native speed for the production version of Alchemy. That would be pretty awesome.

#106 A Reddit thread about people backing away from installing the Unity browser plugin.

www.reddit.com/r/gamedev/comments/lu0z2/does_anyone_else_feel_unity_webgames_sca...

#107 That 90% is a farce! Show me the stats. I have around 20%. If your gameis not interesting enough to get somone to install a 1 meg plugin then blame it on yourself and not the plugin.

So if 90% back out because of a 1 meg plugin how many backout with a 1 gig client??? 99.9%

That sucks for Torque users then.

Those 90% were 1 time 1 minute players if that number is true.

#108 90% sounds worse than I've heard as well. Again, my experience has been closer to 50%, even with small downloads. I think there are a lot of factors.

And yes, I agree, you should not be making a 1 gig client using Torque web distribution. We are going to put disclaimers about streaming as part of our 1.2 push.

My best suggestion, until we have a better tech solution, is to make a very small training level to try and hook people into grabbing a larger download. I've heard anecdotally that this has worked well for other people in the past.

#109 Adding to Eric's suggestion of using smaller levels to capture people's interest you can trim the stock Full Template (~200mb) down to about 20 mb (there's a lot of fat buried in the core). So it's very possible to have episodic content (20mb - 100mb) that players download and play as they go instead of progressing through a "full" game. Maybe not the fully streaming experience that many desire, but still better than a 1gb+ download just to play.

#110 well torque is missing a key component that Unity has that makes the browser deployment much more usable. Unity only includes what is needed in the build. So you can pack the project with 100gigs of media but it will only package what is actual used. Unless i am wrong Torque does not do this causing far more development time and planning to make a smaller build.

Just a suggestion for future fixes or features.

Once again sorry for comparing to Unity as i am no fanboi just comparing the web deployment.

#111

Quote:well torque is missing a key component that Unity has that makes the browser deployment much more usable. Unity only includes what is needed in the build.

That's not realistic for T3D. In Unity - at least the least expensive versions - you essentially have to do all of your loading and placement of content directly in their editor, allowing the editor to keep a complete list of everything that you're using. Whereas in Torque people often use scripts and C++ code to dynamically specify and load content at runtime. In that case there's no way for a packaging utility to know what content is going to be used and what is not going to be used, unless it can somehow execute the game through all possible control paths - at all quality settings - prior to packaging.

Packing a project directory tree with 100 gigs of data, most of which is not used in the project, is a pretty bad project management style anyway. Ideally you should strive to keep all of your assets in a separate location and import them into your directory tree only as you need them in your current project. Having to wade through zillions of files to find a file you want anytime you want to tweak something outside of the World Editor has to cost you more time in the long run than the little bit of time it takes to keep things clean and organized from the start.

#112 "Packing a project directory tree with 100 gigs of data, most of which is not used in the project, is a pretty bad project management style anyway."

We agree, and this is something we are working towards fixing.

#113 @Eric

For the record that really wasn't a complaint about the stock Torque project templates, just that general style of cluttering up the project workspace that I've seen so many people do over the years.

Having ready access to those assets from the editors is probably useful for people just learning the tools. On the other hand, if you could extricate all unnecessary stuff into a separate (and configurable) assets folder, with a quick and simple (one-click) way to browse to that folder from the editor, and just copy/instance the assets that are accessed in the editor into the project workspace as they're added, that would probably be better.

#114 I actually read that as 100MB, not 100G. Either way, we are looking into ways that we can reduce the work involved in cleaning up a game for distribution.

#115 Well my point was based around the level distribution comment. Your whole project, say 10 levels could be broken into 10 smaller levels if the engine will only include what is needed for each level.

I have not attempted the "web packaging" in torque in some time. Does it compress the data to make it smaller for deployment? If so what's the ratio?

BTW thanks for all the comments. The response is amazing and the best I have seen from an engine. This topic alone has me back playing with Torque and soon to buy the update.

#116 You know what? Gimme a week or two and I'll start playing with the Empty template to see what minimum stripped version I can get away with. Maybe I can come up with a Web Empty Template that can be used as the starting point for these projects. Then, with proper asset management and planning one could more easily create and package a web distribution.

I'm a little busy now, though....

#117 Awesome! I will be happy to test it and use it to build a quick project.

#118 You know, streaming could be pulled off in a sort of scotch-tape-and-bubble-gum sort of way if the TCPObject and HTTPObjects were modernized. As it stands now, when I want to use TCPObject, I implement a fix from the forums to be able to use it properly, and even then I can't download binary files (see this thread). If it was easier to do so (and even better- multi-threaded!), then people could set up their own dynamic loading of content for several situations, not just web-deployed games.

#119

Quote:Well my point was based around the level distribution comment. Your whole project, say 10 levels could be broken into 10 smaller levels if the engine will only include what is needed for each level.

You'd need some way to let the engine know what is included in each level, I doubt it's feasible for the engine to figure things out on it's own. That's one of the side effects of having the source code and intrusive scripting capabilities; you gain greater flexibility, but also greater responsibility for your own project management, as the greater access breaks any assumptions the engine can safely make about required content.

Personally I've been using the CMake build system to manage assets. Mainly because it's a tool that I'm used to as a programmer, but it's worked out well. Each level has it's own CMakeLists.txt file that specifically lists all assets for each level, and copies them into a staging area on release builds. I haven't really been doing anything with web distribution, but it wouldn't take much to create a CMake macro that would generate a zip file for each level's unique contents for separate distribution. If assets are shared between levels, the assets could be included in only the first level where they appear, with more universal assets like player character models and GUIs included in the core distributable.

Maybe if they could include tools for a similar process in the engine distribution it would make for a little smoother workflow. You'd still likely have to do some of the work yourself, though.

#120

Quote:You'd need some way to let the engine know what is included in each level, I doubt it's feasible for the engine to figure things out on it's own.

It wouldn't be particularly hard to modify the PersistenceManager to parse level files and script files for references to art assets. You would then need to do a pass on your C++ code to make sure all of the art references there are being driven through scripts/levels rather than being hardcoded (which is a good idea in general).