The game design seeks to create engaging game play within fixed technical and resource constraints. It trades game play features against number of concurrent players, player immersion, and size or complexity of the game world to simplify implementation, deployment, and maintenance.
In some cases the game’s marketing strategy includes the server as part of the distributed retail product so that players and third parties may host games independently.
- Our development resources and time constraints limit the scope and complexity of implementation.
- Developers must be able to run the entire game in their personal development environments.
- Minimal resources exist for development of support tools.
- We must reduce our operations support costs related to computing, network, and staff resources.
- We must minimize the effort required to deploy to production, possibly even supporting user or third-party deployment.
- Our business strategy emphasizes creation of new titles or sequels over refinement or expansion of current title.
- To increase the game’s player capacity, we must run new instances of the game on separate computers.
- Adding players to the game will not enhance the players’ in-game experience.
- We have few options for adding or enhancing game play features without degrading the players’ current experience.
Build a server that implements the entire game in a single process on a single computer. If needed, implement persistence using common database technologies that run on the same or a separate computer.
Apply sound engineering principles where it makes sense to enhance software quality and aid development during the current development cycle. Don’t over-engineer for reuse that will never happen, however.
We have a stand-alone game server that is easy to deploy and performs well enough to meet its original game design goals. The server can easily support more players as long as we continue adding hardware. If we try to enhance the current game by adding features or capacity, we will most likely find we need to rewrite the server to use a distributed architecture style, or start a new project instead.
Multiplayer games are inherently complex, so it’s natural to try to simplify development when possible. This pattern trades tight resource constraints for ease of development and deployment. This approach might be perfect for development teams with limited time, budget, or experience, as long as they have reasonable expectations about the game’s growth potential. Ideally, if a team releases a successful title using this model, they can invest the proceeds and experience gained from that project into developing a new, more ambitious title.
Note that the Monolithic Architecture pattern is considered an antipattern for many applications. This is usually the case when we apply it without fully accepting the constraints it imposes. In general, the pattern is not suitable for commercial-grade massively multiplayer games that require high player concurrency and persistent world state.
Watch this space…
- Multiplayer First Person Shooter (FPS) games.Examples include:
- Multiplayer Online Battle Arena (MOBA) games. 1)“Thread: Server Architecture for MOBA Like Game Types.” Unreal Engine Forums. Epic Games, INC., 2014. Web. 1 Oct. 2015. <https://forums.unrealengine.com/showthread.php?15106-Server-architecture-for-MOBA-Like-Game-Types>.
- Small-scale, independent MMO games with limited scope.