The goal of the thesis is to find out what makes MMO game development so expensive and to create a simple proof-of-concept mobile MMO game with minimal resources. Analysis of MMO game development showed that content was the most expensive part of game development.
Subject and objective
Background
- MMO games
- Popular MMO games
- Technology challenges
- MMO game costs
The number of players is not the only big number for the biggest MMO games. MMO games require real-time communication over the Internet between the game server and the player's client applications.
Motivation and objectives
Another example of high MMO game costs was Star Wars - The Old Republic which was released in December 2011 and reportedly cost $200 million to develop (Fritz & Pham 2012). Jordan writes that MMO development is a "massive money sink" and that it can be "incredibly devastating" if the game isn't successful.
Requirements
General requirements
At best, the prototype created for this thesis can be used with only minimal changes as a basis for a future multiplayer game that could launch in late 2014. Hopefully, other small game companies and indie game developers will also benefit from the research conducted for this thesis.
Cost
The game content (game areas, monsters, quests, graphics, sound effects, music, etc.) is not in the scope of the thesis - only create the game architecture and a simple game prototype to demonstrate the functionality of the created framework to validate.
Technology requirements
Research approach
The analysis should lead to a variety of technologies, tools and design choices that can be used to create the game. The main construction of the project-based thesis will be the implementation of an MMO game engine and a working demo.
Approvals
Initially, the thesis aims to analyze what information is available about the development of multiplayer games, identify technologies, weigh different design choices and evaluate the technologies that could be used. After that, the game prototype can be used to verify that the implementation adheres to the predefined requirements.
Definitions
Although this thesis is about creating a mobile MMO, the literature review will mostly be conducted on PC-based MMO games. This is simply for the reason that PC-based MMO games are considered the "traditional" MMO games and on mobile platforms MMO games have not yet clearly established themselves.
Cost structure
There is plenty of software engineering research and literature on MMO game design at a high level of design, but there isn't much about the actual technologies or the architecture at a lower level. Add to that the wide range of video and sound cards that the game must meet, and the costs will only increase.” (Francis 2014).
Game design
There are tile-based 2D games (which are currently popular in mobile MMORPG games) and there are room-based 2D games. An example of a room-based 2D game is the mobile game "Avatar Fight" from the Google Play Store, which has 1M-5M downloads at the time of writing.
Game content
Gallery.html Monster images Free monster images (Note the license - uses the Open Game License). Using free game graphics and sounds will save a lot of time and money, and is probably the only way for a small indie production without funding to cost-effectively add graphics and sound to a game. The user will not be able to distinguish the fine details of animated graphics, and the user's finger will obscure part of the screen when the screen is touched.
The latter should be taken into account when dragging the avatar or other game objects across the screen. Another option is to delay the animation so that it can be seen after the finger is removed from the screen – however this will work best in turn-based games and may not be possible in real-time games.
MMO game type
Architecture
Networking
Server architecture
Even with a single-server setup, you can make future scalability easier by keeping some horizontal scaling best practices in mind from the start: decouple the services and partition the application (Shalom 2010). Jnan Dash, an “RDBMS veteran of IBM and Oracle” writes in a Zdnet article, “I know from experience that as a database grows in size or the number of users increases, many RDBMS-based sites experience serious performance issues.” He continues: “Many commercial RDBMS products also offer horizontal scaling (clustering), but these are bolt-on solutions that can be very expensive and complex. Since MMO games are a hot topic for programmers and game developers, there are many discussions on this topic.
For example on reddit.com (Reddit 2014) there is a long discussion about MMO game architecture with several MMO developers sharing their thoughts. The main conclusion to be drawn from these discussions is that there is no single "correct way" to architecture.
Client architecture
One of the most important things to consider beforehand is the database: avoid using the traditional relational database model. If an organization faces such issues, it should consider NoSQL technologies, as many of them are specifically designed to address these scaling issues (scaling horizontally or scaling out with standard servers) and performance issues.” (Dash 2013).
Technology
Client-side technologies
Server-side technologies
Servers and hosting
Implementation choices
- Game design
- Technology stack
- LibGDX
- SockJS client
- Vert.x
- OpenShift PAAS cloud platform
The server side uses the Java 7 SDK because Vert.x relies on the high-performance NIO2 network class introduced in Java 7. The Vert.X server platform supports the SockJS API server implementations out of the box, making SockJS the logical choice when using Vert.x . The Vert.x website describes the platform as: "Vert.x is a lightweight, high-performance application platform for the JVM designed for modern mobile, web and enterprise applications." (Vertx 2014).
Vert.x is a polyglot platform and supports 6 programming languages: Java, JavaScript, Ruby, Groovy, Python and Clojure. First, some general architecture issues are covered, followed by implementation details for the server and client.
Architecture
Developers can choose predefined modules (“cartridges”) to be installed on those virtual servers when creating an application on the cloud platform.
The game server
By changing the tick interval, you can speed up or slow down the game.
Server design
Incoming connections
When the server starts up, it will first start the game server (and start ticking), then it will start http servers that will start listening for incoming client connections. The game server uses the Vert.X platform's SockJS server implementation to accept incoming bidirectional connections. Messages coming from the game server will be written to the corresponding client's SockJS connection.
On errors, the connection will be terminated and the client will try to connect again (if it still works). If a client does not send a heartbeat for 40 seconds, it will be disconnected and flushed.
Game commands
This could be a lightning strike during a thunderstorm in one of the game areas in the game. NPCs could react to the lightning, and the game clients could visualize a lightning strike graphically for the players. For example, a player can say, "Hello everyone," and all players and NPCs in the room will receive it.
For example, a player may receive a message from a friend: "Freddy Friend says 'Cheers, how are you?'". In the moving left example above, the message "You can't go left" is echoed to the player if they try to move left in a room where there is no exit on the left side.
Client
Connecting the client
Deploying the ServerConnector to the HTML5-based project was straightforward, as it could use the JavaScript version of the SockJS client by importing the script from. What did the trick was to add a hidden WebView (basically a full browser) in the Android application and load a local web page that used the same SockJS-JavaScript version in the WebView. After adding some bridge methods between the WebView and the native Android code, the WebView was able to call the native code and vice versa.
Using the JavaScript-based SockJS API with a hidden browser might have worked, but since desktops were not a required platform, the ServerConnector could use pure WebSockets. The Web-Socket version still couldn't connect to the OpenShift-based server, but since the desktop version was only used during development, connecting to the local game server was enough.
User interface
To create platform-specific connection classes, the base package requires a ServerConnector interface, which will be implemented and used for each platform-specific project separately. Using WebSocket directly could have worked, but was problematic as there was a problem with the OpenShift-based server accepting WebSocket connections. To create a working demo game, the game will need to have content.
Creating a game area
Creating rooms
Creating players
Creating NPCs
The taps come at a predetermined interval (e.g. every 3 seconds) and are essentially what makes the game "tap". Besides the command script (which runs on every tap), there's another place that can be used to bring npcs to life: their reactions to visuals. Visuals are the objects sent to the player's client application so that they can "show" what is happening in the game.
Just like players, all npc characters will also receive visuals about events taking place in the same room. They can listen to what other characters in the room are saying and respond to certain keywords, for example.
Testing the game
- Log-in
- Entering the game
- Moving around the game area
- Encountering NPCs
- Multiple online players
- Test verdict
In the screenshot below, 4 new players have come online, leaving 5 players in the same room. All characters in the same room can interact with each other regardless of who is "next to whom". This is especially visible in the screenshot below which shows all 5 player screens (all in the same game room) at the same time.
The player characters always see themselves in the center (look at portraits in the upper left to see whose game screen it is). The game also worked HTML5-based in the latest versions of the Firefox, Chrome and Internet Explorer browsers.
Applicability of the results
Reusability of intruduced solutions
When you use the same programming language on both the server and client side, you can use common domain objects for both sides, making your codebase smaller, more transparent, and easier to maintain. The full source code for the game is not available as it is still a work in progress.
How could the result be improved even further
Does the game implementation fullfill the original requirements?
Summary
