Interfaces allow people to experience the way that models behave, and the consequences of their decisions on that behavior. You can add motivation and excitement to that experience by not only having users interact with a model, but also with one another.
You can get multiple people or teams to interact with any interface, but by using the mutiplayer capabilities in Stella, you can decrease or eliminate the need for facilitation. The software automatically coordinates actions and keeps the participants synchronized. Games can be played with participants in the same location working on separate computers, or remotely, with everyone in a different location.
You can publish multiplayer games on the isee Exchange and make the available for anyone to use as long as the model used is within the limits for free multiplayer game publishing. See
To have a multiplayer game, you need to start with a model that has multiple roles. Typically, those roles are either cooperative (for example, a supply chain, with a producer, distributor, wholesaler, and retailer), or competitive (for example, two companies competing for market share), though more complex arrangements, such as cooperating teams playing against one another, are also possible. For each of the roles, there are decisions that need to be made during the course of the game. In a model, these might be represented by equations combining different inputs. In a game, these decisions can be made by the players, and they'll require that information be made available to them. This is no different from single user interface development, but having multiple players increases the amount of variety.
If you have an existing model that you want to use with a multiplayer game, you may need to make some adjustments to it so that the decision inputs of the different players are clearly localized. When doing so, it's a good idea to maintain the model structure necessary to support the equations behind those decisions. This will allow you to have a working simulation model that generates reasonable behavior and can be used as a debriefing tool for game participants (either in person, or in an interface).
If you're building the model to support the game, then you may be able to simplify its construction by leaving the decisions as constants. This has the disadvantage of making the model less usable for debriefing. However, once structured in this manner, if you want to add in detail representing the decision making, this can be done without making any changes to the interface.
The design principles for games with multiple players are essentially the same as they are for regular interfaces (see Building Interfaces). The main difference is that you need to make sure the interface works for the different people who will use it, each of whom will have different decisions to make and, potentially, different results to review.
Multiplayer games are built around different roles. A role represents a position, company, department, team, or other distinct group or person. The decisions associated with a role will be made by one of the people logged into a game (or a group of people, if they're working together on a single computer).
Roles are defined in the Multiplayer Options dialog One of the key attributes of a role is that you'll specify which page the player in that role will start on. This is the most straightforward way to customize pages for different roles (see Building a Multiplayer Game for an example).
You can also conditionally specify both button actions and simulation event actions based on roles. This allows you to navigate all players to a common area, and then navigate them to their own specific decision or information pages.
You can have both required roles and optional roles. All the required roles must be filled before a game can start, but none of the optional roles are necessary. If an optional role isn't filled, you should include model logic to make decisions in place of a person playing the game (the same is true if an optional, or required, role exits the game early).
Multiplayer games require that a game be started, and that different people then join the game. The details of how this works are described in Playing Multiplayer.
The coordination of activities in multiplayer games is automatic. If you expect people to use the game autonomously, you'll need the progression from starting through debriefing to be as simple as possible. If you're working with a group of people, in person or via an electronic meeting, you'll have more flexibility in designing the flow, but generally, it needs to be simpler than for a single user interface. Once people have to wait for one another, you can't provide too many side paths for individuals to pursue.
Because games coordinate the actions of different people, all of the activity needs to go through a central nexus. To support this, published games connect to the isee Exchange, and the game itself is run on the isee Exchange (this is the reason that there's a limitation on model size for publishing games without charge, as large models use more computing resources). One consequence of this is that during the game all players will need to have internet access.