Articles Archive
Articles Search
Director Wiki

Shockwave@6, Part 2

January 17, 2002
by Darrel Plant

Welcome to the second installement of Shockwave / at / 6, a round-table discussion and recognition of the sixth anniversary of the release of Shockwave for Director. For a brief (opinionated) history of Shockwave and the first part of this discussion, check out Part 1. The panelists are six developers who have been working with Director, Flash, and other multimedia tools for a total of well over 40 years between them.

Darrel Plant, Director Online

A lot of hope was attached to the Shockwave Multiuser Server (SMUS) when it was first released with Director 7. Some of us were hoping for a tool that would lead to an explosion of multi-user environments and games. Gary, you've used it at, and I know that Steve and others of you have used it as well. I built a off-line networked game show using version 1. What do you folks see as the strengths and weaknesses of the SMUS? How have you used it? Will you continue to use it or will you look to other tools like Tabuleiro's Nebulae or Xadra's Fortress for future projects? And have you employed other technologies for real-time multi-user projects?

Stephanie Lone,

We, as everyone else, were excited about what possibilities multiuser could bring to us and our sports applications. We envisioned multiuser chalkboards for football plays; multiuser turn-based basketball games like the old HORSE game. We dabbled in it, tried a few things and found that the user response, for us, really wasn't all that strong. We did create a multiuser chat, which we used in a few of our Live products (Tourney Live for March Madness and older versions of Basketball and Baseball Live). We found that, at the time, the limitation of 1,000 users (unless you wanted to upgrade to a paying solution like MPath's PopX) didn't pose a large problem for sports like baseball and basketball where you have many games spread out over the day and night and typically not that many simultaneous chatters; however for events like the March Madness tournaments, we had to implement a different solution since the pricing structure was more than we were willing to pay. Would we do it again? Probably, if we found the right application and the user reaction was strong.

Mark Reijnders, PegHole

I've never used the MUS in a paid project yet. I proposed it to several clients but they always rejected it. One reason was that the cost of development (and testing and debugging) of a multiuser game is considerably more than that of a "normal" game. And a MU game requires more attention, especially when there is also an in-game chat function. Companies usually don't appreciate it when visitors are using dirty language or, even worse, are venting about a company on its own website. Another reason is that many clients are afraid of what I call the "empty chatroom syndrome." They are afraid a multiuser game on their site would not be popular enough and that nobody would be there to compete against. Which is often the case in games I've visited on the Web. Another concern is that a game becomes too popular, causing too much bandwidth use and overworked servers, and thus added costs. The fact that the MUS is only available on platforms that require special server machines (all my clients to date run their websites on Unix) and the added maintenance costs of that didn't help to convince them either. I might be using Nebulea for a game that I'm working on and that screams for a multiuser version. But first I have to finish it in my own time and to sell it, since the original client went the way of the dodo.

Clint Little, Periscope3

Personally, I think the MUS is a great piece of technology that has enormous possibilities... There seems to be a much bigger focus on using it for games and all but I have used it and see its focus in many other areas. From a training standpoint, I envision this as a very strong tool to help educate students on specific topics. We have rolled out some test cases, have had talks about features, and people seem to be very excited about it. In a previous life, the MUS was an integral part of building powerful applications to help define a "community" world. In regards to the Macromedia server solution versus Tabuleiros', I have mostly worked with the Macromedia server, it is nice and has some great strengths such as server-side scripting, but you need a Windows or Mac server to run it. As with a good majority of companies, we actually run most of our servers on UNIX of some flavor, so Tabuleiro is very attractive for that. With the Tabuleiro solution, we lose the server-side scripting capabilities but gain greater administrative features and we don't need an additional server configuration. I guess in all it's sort of a toss up, but from an IT standpoint, we are leaning towards Tabuleiro.

Steve Bullock, / at / dver / at / ctive

I was one of those people you mentioned who was hoping for an "explosion" of multi-user environments and games when SMUS was first released. And as we all recognize, this didn't and hasn't happened. I certainly concur with much of what Mark described in terms of difficulty in selling multi-user games/apps to corporate clients: Fear of empty chat rooms, fear of bathroom language chatters, lack of a Unix version of the server software, and significantly higher up-front and ongoing expenses of development. We have bumped into these same problems in our sales discussions.

Nevertheless, I certainly can't fault the effort or investment which Macromedia put into SMUS. It is an extremely strong and stable piece of software on the server end, it is reasonably fast for moderate numbers of users, and the Shockwave client Lingo, though tricky, has a comprehensive set of commands and capabilities. On the other hand, a weakness of SMUS is definitely the fairly steep learning curve the first time a programmer tries to put together any sort of complex piece using the software. Though the multi-user demo movies and behaviors provided by Macromedia are quite good (chat, whiteboard, etc.), they are only the first small building blocks towards the sort of applications and interactivity that paying clients often have in mind. SMUS is not a Director feature for beginning/intermediate programmers to use -- unless they are very brave and have a lot of time to complete their projects.

We've done a number of multi-user things at Adveractive over the years. Most recently, we developed a popular multi-user bowling game for the entertainment site with a host of advanced features. In its first month on the web, the game is getting a thousand or so users a day (which means that there are typically 5 to 25 players connected at any point in time). Hence, it is certainly not "large-scale" app. I am looking forward to really putting Tabuleiro's Nebulae (Unix) software through its paces as it may solve two of the problems we have encountered in the past in client discussions: applications with very high anticipated traffic and twitch-type games that require faster UDP responsiveness. But in the meantime, I believe that SMUS is a very strong, but underutilized, feature of Director Shockwave that really rounds out its web capabilities.

Rebecca Lovelace, Funnybone Interactive

When the Multiuser technology came out, we were excited. It seemed like a great thing to have. However, we have not been able to take advantage of it for multiple reasons. One is the latency is too great for certain types of games, so you have to design a game around it. Another big stumbling block is the fact that there is no UNIX support; all our servers are handled by one of the other divisions, and they are UNIX based. In order to implement MUS we would need to manage our own server in-house which we don't have the staffing set up for, or convince the other division to set up a server. (The Tabuleiro solution seems promising in this regard, but in order to justify spending money on something you have to have a really great idea). However, the biggest stumbling block that we have found is that for multiuser games to work really well, you need to communicate with other players. Doing children's games, we are very concerned with privacy and safety issues, and could not allow an unmonitored chat. There are ways around this of course (maybe allowing a menu of canned responses) but you need to be really careful and thorough in design, and our designers have not yet come up with anything to take advantage of the technology.

Gary Rosenzweig, CleverMedia

I had actually created some multiplayer games for Shockwave even before the MUS was released. I used super-fast CGI scripts to do it. So when MUS came out, it was just a matter of converting those games to the MUS -- which was a much better way to do it. I was relieved when the MUS came out, because my previous solution only scaled to dozens of users. The MUS allowed our site to grow to hundreds.

Still, MUS has had its problems. Firewall-related issues kept a lot of at-work users away, and AOL users have always seemed to have trouble accessing it. We got a ton of complaints when we switched from CGI to MUS. Some users tried to start a petition to get us to change back! But the advantages outweighted the problems. And those problems seemed to fade away as the MUS was improved in versions 2 and 3.

We never really did a large multiuser game for any clients. Why? Well, there were several reasons. First, it was impossible to guarantee that the game would work for everyone. We didn't want to spend three months building a game only not to get paid because the CEO's nephew couldn't play the game over his AOL connection. Plus there was the issue of the server. We would have to explain to the client how they would have to set up a dedicated machine and monitor it. At first, it was confusing as to how a client would even get a MUS if they didn't own Director. So this was a far more exhausting effort to build a multiplayer game than a single-player one.

Many developers don't see the problems with multiplayer games until they are deep into building their first one. You have to consider all of the points of failure and handle them: users leaving, users getting disconnected, users not responding after a given amount of time. If every connection was clean and every user was perfect, then multiuser apps would be easy to make. But the net doesn't work like that.

I hope that Macromedia continues to support the MUS in the future. While it is great that Tabuleiro has a 3rd-party server available, we don't need anything special. But it is nice to know that there is an alternative.

Darrel Plant, Director Online

New technologies have changed the way we make Shockwave movies (and just plain Director movies) over the past six years. One thing I thank the stars for is that I haven't had to create a super palette for an 8-bit project for at least a couple of years. Nowadays we can use native JPEG-compressed imagery in movies; we've got Shockwave Audio and streaming MP3 support; Shockwave supports digital video, Real Media, and even real-time 3D with physics. Not to mention Flash. We've got all these possibilities. Do they make a difference when you're deciding on the underlying technology for a project? Or does the decision get made to use Shockwave first for some other reason, then the other technologies get thrown in because they're available? Will the newest features (Shockwave 3D and RealMedia) make it easier to decide on Shockwave for some projects?

Steve Bullock

Certainly, the rich media capabilities of Shockwave (streaming audio, video and 3-D, Flash) make a big difference when talking about projects with clients. It reminds me of the old Northwest Airlines ad where a guy says "I can do that." about eight times before he looks at the camera and asks "How am I going to do that?" Director Shockwave lets us answer "Yes, we can do that" on nearly all client queries today. Although, after the client realizes how these rich media additions impact development costs, they often drop back to simpler Shockwave formulations for their projects.

With us, Director Shockwave is always our first choice (over Flash or Java, etc.) for all development work and the newest features (3D and RealMedia) will simply help our clients, rather than us, realize that Shockwave should be their first choice for great web multimedia and interactivity.

Clint Little

I think all the possibilites Director provides makes an enormous difference. One major rule I always try to follow when developing a product is, to use the right tool for the right job, and Director seems to always be on the list as an option. As with everyone else, you always wish there was more support for this or that but taking a step back, Direcor is extremely robust and seems to catch all the mediums. Probably the two biggest reasons I choose Shockwave, more than any other technology, is due to the flexibility with the various assets and the capability to develop fairly rapidly. The newest features (Real Media and Shockwave 3D) really round out the feature set and help leverage an entirely new area for multimedia to flourish.

Stephanie Lone

Coming from my experience here at SportsLine, we do a lot of code leveraging, which makes it easy to continue moving forward with Shockwave for some of our products like our Live products (Baseball Live, Game Day Live, etc.), which have always been done in Shockwave. The new bells and whistles are a plus to make it easier for us to integrate new media types and make our products better. However, our strategy is to gather the requirements for the project and then use the best technology to accomplish the requirements.

Mark Reijnders

I'm in a different situation than you since I currently only do Shockwave/Director work. I also use Flash a lot, but only inside of Director, almost never as an independent piece. If a client wants me to do a project that is better done with another technology I will pass the project to someone else who is an expert in that particular field. But since my clients know I am a Shockwave/Director expert they often contact me after they already had decided that Shockwave/Director is the technology they want to use. But I often can surprise them with some nice features that Director (or one of the many Xtras) offers, and that they weren't aware of yet. The latest Director features aren't very important to me right now, but that could change in the near future. It's nice to know that those features exist and that I can use them if I have a project at hand that needs them.

Clint Little

I think Mark makes a great point about the Xtra support! When you think of Director and the possibilities/options it provides (i.e. Real Media, Shockwave 3D, etc.), I think we should also think of the Xtra support as an additional possibility. It has certainly been a powerful addition to the option arsenal.

Gary Rosenzweig

At this point I try to use Flash for all of my basic games and use Director when Flash can't handle it. This ends up being about half the time. The main two reasons to use Director over Flash are speed and 3D. The 3D is obvious, but speed is the real reason we use it a lot. Our benchmarks show that Lingo is 40 times faster than ActionScript. So anything arcade-like is going to run much better in Director.

The new 3D technology has really created some new possibilities for us. I'd say that we do indeed "throw in" 3D because it is available. In many cases, 3D has made it easier for us to make games. It acts as a nice canvas to draw on rather than complicate a game with tons of sprites.

This is similar to how we have adopted other technologies in the past. Streaming audio for instance. We first used the new technology in projects created specifically designed to showcase the technology. Now we use it when it makes sense, which is often. I see the same happening with 3D: We will use it when it makes sense, which will be often.

Check back in a couple of weeks for the final installment of Shockwave / at / 6!

Darrel Plant is Technical Editor of Director Online. He is the Publisher at Moshofsky/Plant Creative Services in Portland, Oregon, and the author of or contributor to a number of books on Macromedia Director and Flash, including Special Edition Using Flash 5,, Flash 5 Bible, and Director 8.5 Studio..

Copyright 1997-2019, Director Online. Article content copyright by respective authors.