Speaking of architecture, it is divided into two parts, one is the software-level code architecture, and the other is the hardware-level system architecture. At the software level, module division, code reconstruction and business layer architecture are the main focus. At the system level, network, deployment, and server clusters are the main focus. The software-level architecture lies in the early code development. The hardware-level system architecture lies in the later server deployment and online. Today's content is mainly biased towards the system architecture of the game field.
When it comes to system architecture, it is nothing more than those technologies, such as load balancing, vertical and horizontal partitioning of databases, front-end/back-end caching, and nosql. These technologies are inseparable from the architecture in almost any industry. Today I’m going to talk about the game architecture. I don’t want to bother to introduce those traditional architecture technologies. There is nothing new. Speaking of the architecture of a certain field, I think this field has any distinctive features compared to the architecture of other fields. This is the most valuable part.
Compared with traditional b/s and c/s application architectures, the
game architecture has a distinctive feature: the unique "partition" concept of the game architecture.
In order to solve the delay of players, the game architecture of the traditional IDC computer room is generally divided into two major divisions: China Telecom and China Unicom. Then, in the two major districts, they are divided into "Beijing Division", "Shanghai Division", "Jiangsu Division" and so on. This kind of logical level is divided according to region, in fact, at the physical level, servers are deployed in computer rooms in different regions. This deployment is also mainly to solve the delay of game players. For example, when a Beijing Telecom player logs on to Shanghai Telecom's server, the delay must be very high.
The architectural characteristics of the game partition determine that the architecture of the game is generally not a distributed cluster architecture (hereinafter referred to as the cluster architecture). As players, you all know that, for example, I am a Beijing Telecom player, and then log in to the Shanghai Telecom game server. At this time, you will generally find that the attributes of your game character will return to the time you first registered (for most games) , Of course, some games are not designed in this way, so I won’t introduce too much here). From this point, we can judge that the game deployment in different regions, the application layer and the database are deployed separately. With our traditional distributed cluster architecture, whether you log in from Beijing or Shanghai, your user data is unique. Because of this cluster architecture, the underlying database is not opened independently.
The architectural characteristics of the game partition determines that the scalability of the game architecture is very good. The so-called vertical partitioning and horizontal partitioning of the database, as well as the separation of mysql's master-slave read-write, this kind of database-level expansion is very cumbersome, and is generally applied to our cluster architecture. As for our game architecture, to make it simple, we only need one server to deploy the application and one server to deploy the database. If the number of users increases, such as when the number of users of Shanghai Telecom increases, one server and one database cannot hold it. At this time, we can simply add a zone, and then deploy an application and a database independently. Therefore, there is a distinction between Shanghai Telecom's first district and Shanghai Telecom's second district.
The traditional IDC computer room deploys games, and the access delay between regions has formed such a strong regional division. If we deploy through the cloud, what is the difference in this kind of partition? We know that the cloud host network is BGP (multiple operators access), which effectively solves the problem of traditional computer room deployment-the delay problem of players from different regions and different operators. Therefore, there is no such thing as Beijing Telecom and Shanghai Telecom in the division of game applications that we deploy through the cloud. We can simply call it a district, a second district, a third district, etc., and then we can also take a nice alias for the different districts. For example, the situation in the first district will be back again, the second district will compete in the Central Plains, and the third district will dominate the world.
Division is just a very prominent feature of the game industry, and almost all types of games have this feature. However, different game types are different in terms of structure and technology. Games are divided by application, mainly divided into page games, mobile games and terminal games. But what are the specific architecture and technical differences between web games, mobile games, and mobile games?
The architecture difference between
page games, mobile games and mobile games: page games are short for web games, and these types of web game applications belong to the category of B/S architecture. It should be noted that the web games I mentioned here, and the game architecture introduced in this article, do not include stand-alone games. If it is a stand-alone game, there is no need to communicate with the server at all, then there is no architecture or architecture.
Mobile games are short for mobile games, and end games are also short for client games. The characteristics of mobile games and end games require the client to be installed on mobile phones and computers. So mobile games and terminal games are typical C/S architectures.
Web games are based on B/S architecture, mobile games and mobile games are based on C/S architecture, so I may not need to say more about this. Those who have done technology may know the difference between B/S and C/S better than I do. The B/S architecture is based on the browser, so users don't need to care about the upgrade of our program. When our program is upgraded, we only need to update it on our server. The next time the client visits the browser, the latest data will be automatically returned. With our C/S architecture, every time our program is upgraded, customers may need to manually download the latest client or upgrade package on their mobile phone or computer to update.
The technical difference between
page games, mobile games, and mobile games : The back-end technologies of page games, mobile games, and mobile games may all be similar. The main technical difference lies in the front-end. For page games, front-end technologies such as html5 and flash are used. The mobile game, if it is an Android system, uses java technology. If it is IOS, mainly use object c. The end game, of course, C++ is the first.
Article source: h5 game http://www.hp91.cn/ h5 game