Multiverse Toolbox Preview
From Multiverse
| Multiverse Tools |
|
Overview • Installing |
| Tools UI References |
| Working with Terrain |
|
About Terrain • Using L3DT Pro • Using EarthSculptor • Using PnP TerrainCreator • Importing Heightmap Terrain • Using Mosaic Creator |
| Other Tools |
Contents |
Overview
This document outlines plans for a comprehensive new tools framework, called the Multiverse Toolbox. The Multiverse Toolbox is a major part of our long-term tools strategy that will provide key world development tools and a comprehensive and powerful tool API for tool developers.
This document describes at a high level our plans but does not include specific schedules or screen shots; it's not a marketing feature summary or user's guide. It's intended to help you understand our guiding philosophy, start discussion, and serve as a reference as we create the next generation of Multiverse tools. It's a summary of what we think, how we think, and how we intend to go about solving problems.
This document focuses on:
- Our goals, development principles, and high-level plans.
- The tools vocabulary.
- An high-level outline of the tools API.
- A list of potential future tools so you can start thinking about how your own development tasks fit into this system.
What is the Multiverse Toolbox?
The Multiverse Toolbox is:
- A "graphical developer command center" that integrates all the Multiverse GUI tools.
- A set of open APIs that both Multiverse tools and third-party tool developers use.
The Multiverse Toolbox will be a coherent, easily extendable integrated development environment (IDE) for creating and managing world content and assets. Whenever a world developer wants do something with a GUI, they will go to the Toolbox; generally, it will be where world developers spend most of their time. It will also provide a central starting point for tutorials, wizards, and documentation. Fundamentally, it's a content generator and packaging system for the Multiverse platform. Ultimately, a world developer will be able to create a world entirely within the Toolbox, from start to finish. For example, you'll be able to create objects, place them in the world, and configure quests and instances with a minimum of text editing or coding.
The Toolbox APIs will engender a whole new community of tool developers to create powerful tools for the Multiverse platform. The Toolbox API will address common scalability and usability issues and will provide tight integration with the runtime platform. The Toolbox framework will minimize the need for each tool to "reinvent the wheel", and so it will ultimately save work, both for Multiverse and for tool developers.
Conceptually, the Multiverse Toolbox is similar to the Eclipse open development platform, but specifically focused on the Multiverse platform.
Goals
The Multiverse Toolbox will provide:
- A complete solution to create a simple game and publish it to a server.
- A customizable solution to create and maintain a complex and massive game.
- A production tool set that can perform the tasks that content creators spend the majority of their time doing.
- An intuitive customization system to adapt the tools to a developer's needs.
- A guided learning environment that breaks game development into a series of understandable tasks.
- A focal point for developing a game on the Multiverse platform.
Notably, the Multiverse Toolbox will support runtime server management tools as well as development tools.
Usability
From a usability standpoint, the Multiverse Toolbox will:
- Be accessible to first-time users who may not be technically sophisticated.
- Give advanced developers with intimate knowledge of the platform the capabilities and information they need to accomplish advanced tasks.
Like a game, the learning curve will move smoothly from beginner to advanced user. You will start at the tutorial level that explains the basics and gives you some ideas of the tools' capabilities. As you become more proficient, you will be able to learn how to perform specific tasks as needed, without having to learn everything at once.
Customization
The Multiverse Toolbox will be customizable at several levels:
- Basic users can set extensive preferences.
- Power users can write simple scripting extensions similar to "macros."
- Advanced users (tool developers, really) can write Python or C# code to create new tools to be added to the Toolbox.
As users graduate into creating their own custom tools for their content pipeline, the level of customization will also be graduated in complexity to suit the task at hand. You will be able to perform the most common customizations using Python, avoiding the complicated process of creating a new C# DLL, complex APIs and widgets. The most advanced users can create full-fledged "tool plug-ins" with C#.
Milestones
Developers are clamoring for tools for the Multiverse platform (the Multiverse Client and servers). So, our basic philosophy is "something is better than nothing" and "sooner rather than later."
We're still working out the details of when we will be able to start releasing the Multiverse Toolbox; and of course it's all subject to limited resources and shifting priorities. However, we can identify some overall high-level milestones:
- The initial API structure is in place, the Multiverse Client graphics engine is integrated, and you can invoke existing tools.
- The existing World Editor functionality is integrated or replicated in the new environment through the viewer and object editor systems.
- The existing Terrain Generator is integrated or replicated in the new environment.
- The existing asset management and importer functionality is integrated or replicated in the new environment through the project system.
- The Toolbox API is fully capable of creating a tool without using private APIs and all existing tools use the public APIs.
- You are able to create a new gameworld with a simple character and save objects to the local machine.
- You are able to publish a local game to an external server and monitor it as it is running.
We will be able to parallelize some of these milestones and then based on progress, decide when public releases will be most beneficial. Some of these milestones may also occur out of order because of scheduling and availability.
Preview releases
After reaching the first few milestones listed above, we plan to provide one or more early preview releases so tool developers can start working with the Toolbox API. The preview release will provide some level of integration of the existing tools, perhaps just launching them "as is." The new implementation will be more streamlined and intuitive, with tighter integration between the tools themselves. We expect the first such preview release to happen in the second quarter of 2008.
Subsequent releases
In time, we'll rework the current tools to use the Multiverse Toolbox API, improving their usability and enhancing their utilty at the same time. Over time, Multiverse and independent developers will build additional tools for the platform, to provide additional and enhanced capabilities to handle things like particles, animations, scripts, and server code through the same user interface. In short, you'll get a tool that's capable of building an entire Multiverse gameworld through a single GUI environment.
Design principles
Design principles often read like a list of obvious platitudes; something you read over and go "Yeah, yeah, yeah." Nevertheless, it's easy to make decisions that aren't consistent with the principles, because it's more expedient to do it another way, or for some other reason. Due to scheduling or resource constraints, we won't always live up to these ideals. Every design choice that we make should be viewable against these principles and either follow them, or have a good reason not to.
Graduated complexity
If you don't need to see something at a given time, you probably shouldn't see it. Being overwhelmed by the controls of a space shuttle launch doesn't really help when you're starting out; it should be possible to get the full cockpit view, but only if you want it, or somewhere you can observe it unobtrusively. Where possible, complexity should be avoided altogether. You know when a design is finished not when you have nothing more to add, but when you have nothing more to take away.
See Layout system for an example of how the Toolbox will implement this principle.
Guided task-based organization
It's often easier to organize by feature, but when a user sits down with the tool, they generally have a task in mind that they want to perform. The first thing they'll wonder is "How do I...?" The task system will guide the user through the steps they need to complete the action, letting them pick up how the features work together as the system demonstrates the way to do it, so they can customize individual steps as they need to and learn how to use the features individually at their own pace.
See Layout system for an example of how the Toolbox will implement this principle.
Consistent behavior
Tools that show up in the same application should, wherever possible, work, look, and feel the same way. This includes things like organization, shortcuts, shared implementation of common cross-tool features, vocabulary used, and consistency with other applications or the operating system. Innovation is good, where it improves the system and is intuitive, but users don't spend their entire lives in our tool, so they shouldn't need to remember its peculiarities when they bring it up.
Stability and scalability
Even if a tool doesn't initially scale—the framework itself is likely not to scale to dozens of tools when it's first created—it should scale in the future, and be informed by the kind of things needed for a massive world. For the framework itself, this will include delay-loading tools, delay-loading world fragments, and making sure that a single tool can't slow down or crash the entire system. Like a mail server, it's never OK to lose something: even if something goes wrong, the tools should have graceful recovery and minimal data loss.
Start to finish, left to right
Like a book, people tend to work from top to bottom, left to right as they move through the steps in a task. Every task has a story, and figuring out the flows and branches of that story and working with them will boost the intuitiveness of a tool.
Optimize for the eighty percent case
With any task, eighty percent of the time you perform the same actions in various guises to complete the task. So, this path should be straightforward and intuitive to follow. The other twenty percent of the time you will need to deviate from the usual playbook, and in these cases, it's OK if the complexity of the operation increases significantly.
Server education
Where possible, the tool should teach the user how the server is involved, and how to make changes to it. The user should be gradually introduced to server concepts, how to use it to build gameplay, and how to introduce custom logic.
Intuitive naming
It should be readily apparent from the name of a tool what it does. The names can be creative, but no additional knowledge should be needed to at least glean the general purpose of the tool.
Tools and Tasks
In understanding how tools will operate, a key concept is the project. The project is a collection of all the assets and code in a world, including everything sent to the Client via the patcher, the world file and everything it references, and any custom server code. In other words, the project manages and references anything you would want to update in a world.
Fundamentally, most tasks you do with the tools will have three basic phases:
- Browse: Find or create the asset you want to work with.
- Edit: Iterate through changes on the asset until it looks right.
- Build: integrate the asset into the world itself, and tweak its interaction and behavior.
In some tasks, you may repeat some of the phases, but usually looping through the browse-edit-build sequence.
Browsing, editing, and building are actions you take that affect the project or its contents. If browse, edit, and build are the verbs, the project and its contents are the nouns. Project management includes everything from importing the asset, declaring what's in the game, getting it into your local source control repository, and updating the server.
Core tools
As a starting point, we'll create the tools that make up the core of the Toolbox framework. These tools create the end-to-end content pipeline; content creators will probably spend a majority of their time in these tools.
- Project Manager - implements the concept of the project, and serves as the focus for manipulatiing active content in the game.
- Importer - gets models and required files out of the modeler and into the project.
- Viewer - displays Multiverse objects in the Client rendering engine. We will extend this to enable multiple views of a scene or a specific object from a scene.
- Asset Browser - adds and removes Multiverse objects from a project; modifies what objects (and what versions of the objects) are included in the game.
- Object Editor - enables you to edit Multiverse objects' properties. Properties include metadata to specify whether they are exposed to the user, what widget to use to edit the value, and how they are displayed, including placing the object in the scene.
Note that the Object Editor and the Viewer roughly comprise the functionality of the current World Editor.
Other tools
Although the core tools can handle many tasks, intuitive task-based organization calls for a set of specialized tools that transform a set of features into a coherent easy-to-use toolset. This list of specialized tools is by no means exhaustive, nor are they in any particular order: we've almost certainly forgotten someone's favorite tool. But it's helpful to imagine the kinds tools we'd like to build and think about how they'd be built with the proposed framework.
We are not promising to deliver all of these tools; this list is meant to help visualize where the tool framework could go, and what kinds of things you could build with the Multiverse Toolbox API.
- Terrain editor
- Source repository integration
- Server management tools
- Administrative / GM tools
- Material editor
- Animation tool
- Particle tool (Particool)
- Optimization tool
- Streaming tool (Flow)
- Building editor (Edifice Rex)
- Texture tool
- Scripting tool
- AI tool
- Physics tool
- Modeling tool
- Mob tool
- Dialogue tree tool (Speak and Splat)
- Quest tool (Shrubbery)
- Event tool
- Python editor / debugger
Layout system
The Toolbox will provide graduated complexity with a customizable layout system and viewport control. By default, the view of the project and the tools will be as simple as possible. Once you're ready, you can unlock the layout and display other things as needed; or rearrange the tools to better fit the way you prefer to work. Once you've found a comfortable layout for a given task, it will be simple to save the layout and jump between tasks. The docking layout system enables you to arrange the windows in the framework as desired; hide, dock, or float any of the windows; put windows into customized tab sets; and save and recall particular layouts. It will generally have the same functionality found in the Microsoft Development Studio docking layout, but with the ability to save particular layouts and then restore them at will.
Along these lines, early in development you may want multiple viewports onto the data, but you won't be required to understand it from the outset. For example, imagine creating a particle system. Initially, as you define the particle system, you want to see it by itself. Once you place it in the world and are ready to start tweaking the parameters, though, it is most intuitive to have two views: one of the particle system itself, and another of it in the world. And in some cases you may want to see the particles from multiple angles simultaneously. These views will work with the docking layout system as well.
A beginning user may want a set of suggestions to guide them through some tasks, while an advanced user doesn't want to be bothered. On the other hand, everyone sometimes just wants someone else to do the thinking. For the first phase of development, a comprehensive set of "How do I...?" wizards and tutorials can guide the user and help them understand what has to happen to implement a feature, and why. Once they progress to basic understanding, they may simply need a hint from time to time about the next step of the process. Advanced users probably want to see the direct output from the engine as they're performing the tasks. A comprehensive output window with text highlighting that has help tidbits on one level, errors on another, and engine output as the last makes this transition smoother and lets you choose how much spam you want to be assaulted with.
API types
In an ideal world, we would create a recommended API that we promise to support for at least two releases no kidding, and we would then transition people from deprecated API to the new recommended API, and tool creators would keep updating their tools to keep up with these updates. In reality, people write tools, they don't have the time or inclination to touch them after they're mostly done with them, we don't give out enough API to do the job, we decide our architecture is the broken and we need to change it in some radical way, or the API is simply baffling without being able to trace into what it does. I propose we should structure the API into the following categories:
Recommended API
We think this API is a good idea and we're going to stick with it. At least, that's the idea. Anything that goes into the recommended API should be pretty well thought out because we're going to have to live with it. It should be possible to implement everything you need with only the recommended API. Other types of API may not be visible to the developer by default; if someone is not using the recommended API, it should be a conscious decision and one that Multiverse knows about so we can fix it.
Deprecated API
At one point, we thought this API was a good idea, and now we've changed our minds and seen the light, perhaps with the help of our users. A deprecated API will go away in some specified amount of time, and if you're still using it then, you're out of luck.
Experimental API
This API is fresh and steaming, right off the presses still warm landing in your outstretched hands. Use this API if you want to be the coolest kid on the block testing out the hot new features that everyone's talking about, but don't be surprised if they're constantly changing on you.
Private API
This API delves too deep into how the features are actually implemented, such that you are no longer calling an API to declare your intention to do something, you're calling the functions that actually do it. While this API should be marked private, users should be able to access these functions with the caveat that we will have no sympathy whatsoever if you use the private API and don't tell us. Private API can be promoted to public API with sufficient outcry if it's not too limiting to the architecture.
API structure
We have moved this section of the document to a separate location. This API document will be updated more frequently as we make changes during development.
If you're still reading this document, get up, go get some sunshine, see your family for a bit. That's really way too much text to digest. Get a tasty snack, you've earned it.
What does it all mean?
Most of what this document means is that the Multiverse tools team is going to be busy for a while. To you, the world developer, it doesn't mean much until it's something tangible and usable. But it represents a chance to give early feedback on ideas that are great, horrible, or somewhere inbetween, and a chance to avoid duplicated work. Ultimately, though, this document should serve as a reference as we implement the strategy it lays out, so we can make sure everything we create fits with our goals and our design.
