Technical document Group 3 Mate Tomin Pieter van Ede Raymond Weijermars Daniel Faustino Stefan Hospes
Table of contents 1) Introduction... 2 2) System setup... 2 3) Implementation overview... 4 3.1) Client-side... 4 3.2) School-side... 5 3.3) Global server side... 5 4) Communication... 5 5) World representation... 6 1
1) Introduction In this document we will describe the technical design of our virtual world. First we describe what the requirements are and how the topology of servers will be. Then we will describe how the communication will be and how we will represent the virtual world in software. 2) System setup We set up our virtual world in a layered way and based on the client-server architecture. At first we have the layer 'class'. This means that students can play the game with their fellow students within their class. Just above that layer is 'school', which obviously enables students to play against or with other students from different classes of the same school. The last layer is 'world', where students can play with every other student currently in the virtual world. These are the three basic layers, but it is possible to create other layers, such as a certain region so that schools within a certain region can compete against each other. Figure 1 shows how this layered system should look. As can be seen in the same figure, there is also a the 'student' layer that represents the possibility of students playing HOP alone without being connected to the school server. Figure 1: Layered world setup Because of this wide setup, we place no restriction on the total number of users that is connected to the game world. However, we try to organize our infrastructure in such a way that this does not pose a problem. Therefore, we will describe the hardware setup from client to the top. The basic requirements on the client pc's for this system will be a moderate pc and at minimum a DSL (ADSL or SDSL) or cable internet connection. Or if the client is located at school and the server is also located at school (so not rented externally), a normal 10/100 Ethernet LAN is sufficient, and the client does not need a fast internet connection. However when the students visit the outside world, they use the same bandwidth connection as the server, which ups the requirement on the server connection. We specifically do not intend our virtual world to be run at gaming computers only, simply because not many students at high school will have access to such a machine. Therefore, computers of around 4 years old will still be able to run the game. Detailed system requirements will be found in the schema. However we do require quite a fast internet connection, because while the game does not have to be visually top-of-the-bill, it needs quite some interaction with the world. This does not pose a problem as the virtual Pentium 4 2.0 GHz or better 512 MB RAM or better 64 MB Graphics card (nvidia FX5200 or ATI 9600) or better Windows 2000 or better 2
world will be rolled out in the Netherlands at first and then in other European countries, where quite a large percentage of the population has, at minimum, a cable or DSL internet connection. Each school will need its own server, and the requirements depend largely on how many students the school has, both in terms of computer power and internet connection. This school server will not only handle authentication of the students to the world, it will also run the parts of the game world that are only accessible by the school. This is for example a practice area and an area with self made exercises. If the school has no such server, a 'city' can be rented from our company on the world server(s). Higher up in the architecture are server(s) that are run by our corporation. We have two kinds of 'superservers', which are the servers that are the highest in the architecture. The first kind are the servers that run special game world places, that are not related to a school. Since we expect to have a slow start in terms of number of students (because at first there will only be a small amount of schools participating in a pilot project and after that, other schools will buy access to the virtual world but only at the start of the next school year) the design of our server architecture was developed in such a way that the world is distributed over the servers and together they maintain the state of the world. There will be, obviously, redundancy for the servers so that if one fails, another that was performing the same calculations will take over. A routine backup is also done in the rare event that both the lead server and the backup server crash. That way the world state can be recovered from these backups. However this goes only for the special world locations, because if school servers crash, the game world of that particular school is still lost. That is why we have the second kind of superservers, which contain a copy of the game world that is seen by the schools. It is not mandatory for schools to be plugged into this system if they have a good backup system, but a professional from our corporation will have to inspect this. The reason for this is that nothing is more discouraging than a game world being deleted: students will have to start over and the further they were in the game, the less likely it is that they will resume play. So, in other words, it is necessary to have a good backup system in place to prevent schools from abandoning the project after a system crash. These superservers do not only contain saved game worlds (this backup process will be made preferably during the night), but also a backup of all of the user administration. This is needed because authentication will normally be provided by the school, so students can work at school on the game world if the internet connection breaks down, but also can access the game world from home when the school's internet connection or server breaks down, or is overused. This user administration is updated live during the day, as it does not take much data to change a password. However if a school server has a changed user administration, it will synchronize this as soon as possible with the global server. 3
Figure 2: Server architecture The above figure shows how this hardware setup will look like. The special servers are owned by our corporation and are responsible for the special game world parts, and the global server represents the server park that handles both user administration and game world backups. 3) Implementation overview Now that the global hardware architecture has been described, we can now focus a bit more on the software. As it was already mentioned, not all areas of the game are run by the same server. Here it will be explained what parts of the world are run, where and how. After this the communication will be described. 3.1) Client-side The world consist for a large part of a kind of mini games, like the cannon that was shown in the game design document. These mini games have no influence on the virtual world and therefore their physics' calculations can be perfectly done by the client. This is also the reason why it is required a little bit more power from the computer. The software is constructed in such a way, that when the user wants to start a certain mini game, the client automatically retrieves it from the server. It stores this mini game in a cache to speed up next invocations. Then when it is loaded, the user can play until the game is finished, and then the client sends the results back to the school/global server (depending on where the user was when the mini game started) if the results are needed for a scoreboard. Since playing these mini games is like playing in a sandbox, there is no synchronization needed with other players. However in the game world, we do need to prevent the avatars from just freezing near the start point of the mini game, and that is why a standard repeating animation of investigating the start point is played at the virtual world level. So the only thing that other players need to know, is that player X is going to mini game mode at spot Y. In the case of the other type of exercises, where they interact with the game world, the client 4
will still perform the physics' calculations (as explained further on this document) and also synchronize with other players in the event that some collaboration is needed or if the student is participating in a competition/tournament. 3.2) School-side At the school server, we run the part of the world that belongs to that school. As we described in the game design document, a school is depicted as a city in the game world. Translated back to the server architecture, every user that enters this town (here town also includes the area outside of the town walls), is handled by this server. This means that if schools are close to each other in real world, it is likely that students from other schools are going to visit the school's server to check the status of their friends. While this is a nice feature, this does need a good internet connection from the school. Here a normal ADSL or cable connection will not work, the school will need a SDSL or faster. In general it is assumed that schools in The Netherlands are moving slowly towards these fast internet connections, as an example a school in Nieuwegein is about to receive fiber cable internet. If schools do not have such a fast internet connection, then they can rent a server at our corporation, but with that they lose the ability to use the game world when their internet connection breaks down. In the virtual world, each city is bordered by a forest, sea, mountains or similar physical boundaries. As described in the game design document, at the moment the user walks beyond these borders it can either go back within these borders or travel to another city. This instantaneous travels are the natural point to switch servers, as these servers have a fixed entry and exit point which allows them to efficiently monitor the world status. Also the user does not see that he is transferred to another server. Synchronization at the school server is done by, at most, second order dead-reckoning. It is done in this way to reduce the burden on school servers, as most schools to not possess the budget to get powerful ones. This means that both the clients and the server perform the simulation. This does also not increase the burden on the clients as they have to perform the simulation anyway. The key advantage of using dead-reckoning here is that it greatly reduces bandwidth usage as most actions in the game world will produce predictable projectiles or other effects. The objects that need synchronization are the avatars, and objects that are involved in games at world level. While avatars move a bit less predictable because they are user-controlled, the objects that come with the game world will be governed by physics, which can be predicted quite well with at most second order formulas. The number of updates (the error margin) will also grow if users are further apart, so the bandwidth needed is even lower. 3.3) Global server side This server runs all places in the game world that are not linked to a school. These locations include special cities which are owned by our corporation which offers special buildings, contests and other rare stuff. However, technically speaking, this does not change anything for the implementation. Therefore the global server can almost be considered the same as a school server but with exclusive content. 4) Communication For getting the data of a mini game to the client and other kind of information, TCP is used because of the need to have the accurate data. However when both a client and a server are performing a simulation, like on school level or world level, then UDP is used to send the status changes to both sides. This is possible because if there's a lost packet, the status can be checked on 5
the next one that arrives. 5) World representation As written on the game design document, teachers and book publishers can create new exercises for HOP by using an in-game level editor. This also means that we, as developers, will use the same tool to create all of the mini games that are present in the game that will be shipped. So all of the mini games will be individual script files that reference textures and objects made available through the level editor, plus all of the equations and requirements needed to be solved for the mini game to be completed. An advantage of this is that these mini-games will be a lot easier to be shared through forums and communities and won t take too much space. Another advantage is the possibility of releasing only the level editor for free before the game is completed so that, as what happened with Spore 1, much more mini games can be accessible before the game is finished. The avatars' accessories and customization objects, as well as the cities', cars' and so on, won't be made available through scripts but it won't be hard coded as much as the inner workings of the game. Since the objective here is to have expansion packs and regular updates, HOP is designed in the most modular way as possible. Another reason for this choice is the fact that each computer may run an instance of roughly 30% of the game (student playing alone) or roughly 60% of the game (school servers) so it must be possible to easily separate most of the components that make up the game. There will be at least 5 main modules. Mini games, customization entities, physics handler, visual representation and game core. The physics handler will, as the name says, handle and compute the physics. It will receive input data from the game core and return the result of the simulation. The visual representation module is responsible for displaying everything to the end user and the game core is what controls everything. The game core module communicates with all modules. In short, the main objectives on the software part of the world representation are modularity and extensibility. 1 http://www.gamestooge.com/2008/06/24/sporepedia-hits-one-million-creatures/ 6