In the first three parts of this series, I’ve looked at my basic requirements for virtual worlds, the need for more artificial intelligence, and some scenarios for moving information and assets among virtual worlds. This requirement is much faster to describe, and it is simply that the virtual world client needs to run on multiple operating system platforms.
As I’ve described elsewhere in this blog, I think we’re going to see a lot more Mac and Linux desktops out there and I would argue that, together with the shift to online web-based and virtual worlds applications, that’s where a lot of the innovation and deep intellectual progress will be made. That said, I think it would be stupid to put forward a virtual world client that did not have a Microsoft Windows client. However, I also think it would be stupid to have a long term virtual world client strategy that only included a Windows client.
A significant number of people use Macs. It may be a small percentage relative to the number of Windows users, but there are more than enough to justify a Mac client. Moreover, think about the people who gravitate toward Macs and think about how they use them. These are not people who you want to exclude from a virtual world that will need passion, creativity, and a good sense of world design.
Moreover, you need a native Mac port, not something that relies on Windows emulation or virtualization. I do not want to pay a processing cost or have inferior graphics just to run emulation software. I don’t to buy a Windows license for my Mac just to run my virtual world client. I consider both Windows and Mac virtual clients “must haves.”
This means that building your application using DirectX is out, and using OpenGL is probably in. Second Life has this right. It uses OpenGL for both Mac and Windows and, as a bonus, gets a Linux port as well.
While it would be nice to always have a Linux desktop virtual world client, today in June, 2007, I only consider it “nice to have.” I think that by June, 2009, it will have moved to “must have.” Aside from graphics infrastructure, what will make this happen? Open standards.
To achieve full multiple client portability, I expect virtual worlds to make maximum use of open standards for data formats, multimedia, protocols, and programming interfaces. While the APIs may not be standardized, they should at least be open with respect to intellectual property and therefore fully implementable in free and open source software, not to mention proprietary software.
What about platform portability for the virtual world server? If it is not open source, I may not care as long as it uses open standards as described above as well as to support the scenarios in the last blog entry. Users should not care about the server platforms unless they themselves are running them. This WILL be the case if we have a peer-to-peer virtual world, and so we will need Windows and Mac support here.
This is a bit confusing, so let me restate and expand this. If a server is only running remotely, it needs to support open standards but can be for any platform, since we are talking about software as a service (SAAS). However, if the server is open source, I expect at least one implementation to run on Linux. Regarding clients, we need to have at least Windows and Mac versions running natively without emulation or virtualization.
In the case where the virtual world client and server run on the same machine, as in the peer-to-peer situation, we must have Windows and Mac versions. I’m even more inclined to insist on a Linux version here.
I’m a big believer that there will be a lot more virtual worlds before we settle down on a few “winners.” In particular, I’m really intrigued to see if Microsoft, Apple, and Google will produce worlds that rival Second Life and have clients for multiple platforms. I think that each in their own way could do a superb job of extending the state of the art and, indeed, change our notions of what that art is.
In the same way, I hope we see some really strong “born as open source” players. Some are already on the field, so to speak, and I plan to describe my experiments with them in future entries.