Let's be honest: we all love to play games, especially on our computers. Until the Internet became widespread, most of us played computer games by ourselves, usually against AI opponents. It was fun, but as soon as you realized how the gameplay mechanics worked, the game lost most of its magic.
Game 'Round the World Trainer: 1953: Chicago Coin Machine Co. IL, USA: Adobe Flash game-Cupid-200? Armor Games, Inc. Adobe Flash game-ReBound-200? Newgrounds, Inc. Adobe Flash game-TRAPPED-200? Armor Games, Inc. Acorn BBC Micro B cass.I Do Model XBX07: 1983: Acornsoft, Ltd. England: WoW Action Max VHS.38 Ambush Alley: 1987. Our Data at a Glance 180,000+ Games Comprehensive Data across PC, Console, and Mobile Millions Of Facts & Insights Upto 13,000 Possible Attributes Per Game Localized Content Across 4 Continents North America, Europe, Asia, and Australia Customized Data Solutions Data Tailored To Your Specific Needs Seamless Integration With Data Platforms Flexible APIs That Scale With.
The development of the Internet moved games online. Now, we can play against human opponents and test our skills against theirs. No more rote gameplay!
Then massive multiplayer online (MMO) games emerged and changed everything. Thousands of players found themselves in the same game universes, competing over resources, negotiating, trading and fighting. To make such games possible, a database structure was needed that could store all the relevant information.
In this article, we will design a model that incorporates the most common elements found in MMO games. We will discuss how to use it, its limitations, and its possible improvements.
An Introduction to Data Models for MMO Games
There are plenty of very popular MMO games today, and they involve all kinds of scenarios. I will focus here on strategy games like Ogame, Travian, Sparta: War of Empires and Imperia Online. These games are more about planning, building and strategizing, and less about direct action.
MMO games are set in different universes, are visually different, and use more or less different gameplay options. Still, some ideas are the same. Players compete for locations, fight for them, and form alliance with (and against) other players. They build structures, collect resources, and research technologies. They build units (such as warriors, tanks, traders, etc.) and use them to trade with allies or to fight with opponents. All of that needs to be supported in our database.
We can think of these games as online board games with many indexed squares. Each square can have many different actions associated with it; some actions will include multiple squares – e.g. when we move units or resources from one location to another.
The database is divided into five main areas:
Players / UsersAlliancesLocations and StructuresResearch and ResourcesUnits
The remaining seven ungrouped tables are related to units and describe unit position and in-game movements. We will look at each of these areas in much more detail, starting with Players and Alliances.
Players and Alliances
Without a doubt, players are the most important part of any game.
The player table contains a list of all registered players taking part in a game instance. We will store the players' usernames, passwords, and screen names. These will be stored in the user_name, password, and nickname attributes respectively.
New users will need to provide an email address during registration. A confirmation code will be generated and sent to them, which they will reply to. We will update the confirmation_date attribute when the user verifies their email address. So, this table has three unique keys: user_name, nickname and email.
Each time a user logs in, a new record is added in the login_history table. All of the attributes in this table are self-explanatory. The logout_time is specific. It can be NULL when the user's current session is active or when users quit the game (without logging out) due to technical problems. In the login_data attribute, we'll store login details like a player's geographic location, IP address, and the device and browser they use.
Most MMO games let us cooperate with other players. One of the standard forms of player cooperation is the alliance. Players share their in-game 'private data' (online status, plans, location of their cities and colonies, etc.) with others to benefit from allied actions and for the sheer fun of it.
The alliance table stores basic information about game alliances. Each one has a unique alliance_name that we'll store. We'll also have a field, date_founded, that stores when the alliance was founded. If an alliance is disbanded, we'll store that information in the date_disbanded attribute.
The alliance_member table relates players with alliances. Players may join and leave the same alliance more than once. Because of this, the player_id – alliance_id pair is not a unique key. We'll keep information regarding when a player joins the alliance and when (if) they leave in the date_from and date_to fields. The membership_type_id attribute is a reference to the membership_type dictionary; it stores the current level of players' rights in the alliance.
Players' rights in an alliance can change over time. The membership_actions, membership_type and actions_allowed tables together define all possible rights for alliance members. This model doesn't allow players to define their own levels of rights in an alliance, but that could be accomplished easily enough by adding new records in the membership_type dictionary and storing information about which alliances they are related to.
To sum up: the values stored in these tables are defined by us during the initial setup; they'll change only if we introduce new options.
The membership_history table stores all data regarding players' roles or rights within an alliance, including the range when these rights were valid. (For example, he could have 'novice' permissions for a month, and then 'full membership' from that point on.) The date_to attribute is NULLable because currently active rights have not ended yet.
The membership_actions dictionary contains a list of every action players can make in an alliance. Each action has its' own action_name and game logic is built around these names. We can expect values like 'view members list', 'view members' statuses' and 'send message' here.
The membership_type dictionary contains the unique names of the action groups used in the game. The actions_allowed table assigns actions to membership types. Each action can be assigned to a type only once. Therefore, the membership_action - membership_type pair forms the unique key for this table.
Locations and Structures
Game locations are areas where players collect resources and build structures and units. Some games have a predefined range of possible locations, while others may allow users to define their own locations.
In a 3D space, locations can be defined with [x:y:z] coordinates. If a game has a predefined range, it may not permit players to use any location out of the range [0:1000] for all three axes, so we're limited to a 1000 * 1000 * 1000 space.
On the other hand, maybe we want to allow players to enter the exact coordinates of their new location – e.g. [1001:2073:4] – and we want the game to process it for them.
We'll keep a list of all locations used in an instance of our game in the location table. Each location has its own name, but the names are not unique. On the other hand, the coordinates attribute must contain only unique values. Location coordinates are stored as text values, so we can store coordinates for 3D games as [112:72:235]. Coordinates for 2D games can be stored as <1102:98>.
In some games, locations will have a number of squares that are used to house structures or units. We'll keep that information in the dimension attribute, which is a text field. A dimension can be simply number of squares in a 2D or 3D grid. The player_id attribute stores information about the current owner of that location. It can be NULL when locations are predefined and players compete to occupy them.
The structure table contains a list of all structures we can build at various game locations. Structures represent improvements that allow us to produce better units, perform new types of research, produce more resources, etc. Each structure used in the game has its own unique structure_name. Some possible structure_name values are 'farm', 'ore mine', 'solar plant', and 'research center'.
We can expect each structure to be upgraded multiple times, so we'll also store information about its current level. Each upgrade improves structures' output, so it produces more resources or allows us to use new features in the game. We can't know the maximum level of upgrade in advance, so we'll define all the level-related stuff (costs, upgrade time and production) with formulas. All formulas stored in the database are the core of the game's mechanics, and their adjustment is crucial for game balance and gameplay in general.
That is also the case with the upgrade_time_formula attribute. An example value for this field is ' * 30 min', where represents the level we want to upgrade to.
In most cases, there are requirements that must be met before players take certain actions. Maybe we need to complete a defined amount of research before we can build new structures or vice versa. We'll store the research level needed to build structures in the prerequisite_research table. Relationships and the structure level needed to start various researches are kept in the in the prerequisite_structure table. In both tables, the foreign keys research_id and structure_id are paired to form a unique key. The level_required attribute is the only value.
These two tables, prerequisite_research and prerequisite_structure, also form the core of the game.
For each structure, we'll define a list of prerequisites: other structures and their minimum levels that players must have to begin building. We'll store this data in the structure_required table. Here, structure_id represents the structure we want to build; structure_required_id is a reference to the prerequisite structure(s), and level is the level required.
The structure_built table stores information about current structure levels on a given location. The upgrade_ongoing attribute will be set only if an upgrade is currently ongoing, while the upgrade_end_time attribute will contain a timestamp once the upgrade is complete.
The structure_formula table relates structures and resources. The foreign key pair to this table forms its unique key. This table also has two text attributes containing formulas with as parameter. We'll define these formulas, one for costs and the other for resource generation, in the database. They will be similar to the upgrade_time_formula. We need them because we must define the resources spent in building each structure. We also need to define resource production after upgrade, if structure generates any resources (i.e. ore mine will produce * 20 ore per day).
Research and Resources
Research (or technologies) in games are usually requisite to the creation of other features. Without certain levels of research, new structures or unit types can't be built. Research also can have its own requirements. One of most common is the level of a given structure, usually called a 'research lab'. Or perhaps players need to complete a certain level of research before they can start new research. All of these requirements will be handled in this section. Below, we can find the data model for Research and Resources:
The research table contains a list of all possible research actions in our game. It uses the same logic as the structure table. The research_name attribute is the table's unique key, while the upgrade_time_formula field contains a text representation of the research time requirements formula, with as its parameter. Any resources required for upgrades are defined in the upgrade_formula stored in the research_formula table.
As with structures, we'll define the list of all other researches and their levels that must be completed before we can start another type of research. We'll store this data in the research_required table, where research_id represents the desired research; research_required_id is a reference to the prerequisite research, and level is the level required.
Research is related to individual players, and for each player – research pair we must store a player's current research level and any ongoing upgrade statuses. We'll store this information using the research_level table in the same manner that we used the structure_built table.
Resources like wood, ore, gems, and energy are mined or collected and used later to build structures and other improvements. We'll store a list of all in-game resources in the resource dictionary. The only attribute here is the resource_name field, and it is also the unique key of the table.
To keep track of the current quantity of resources on each location, we'll use the resources_on_location table. Again, a foreign key pair (resource_id and location_id) forms the unique key of the table, while the number attribute stores the current resource values.
Units and Movements
Resources are used to produce units. Units can be used to transport resources, attack other players, or in general pillaging and burning.
The list of unit types used in our game is stored in the unit dictionary with only one value, unit_name; that attribute is the unique key of this table. Some common game units are 'swordsman', 'battlecruiser', 'griffin', 'jet fighter', 'tank', etc.
We need to describe each unit with specific characteristics. A list of all possible characteristics is stored in the characteristic dictionary. The characteristic_name field contains a unique value. Values in this field could include: 'attack', 'defense' and 'hit points'. We will assign characteristics to units using the unit_characteristic relation. The foreign key pair of unit_id and characteristic_id form the unique key of the table. We will use only one attribute, value, to store the desired value.
The research_unit table contains a list of all research activities that must be finished before we can start production of a given unit type. The unit_cost table defines the resources needed to produce a single unit. Both tables have unique keys composed of the foreign key pair (research_id or resources_id combined with unit_id) and one value field (cost and level_required).
And now, the fun part. Production is fun, but moving units around and taking action is even better. We've already introduced the unit table, but we'll keep it here because of how it relates with other tables.
Either units are stationed on a location or they are moving between locations. Adding the player_id field determines who owns either the location or the group that is moving between the locations.
If units are just stationed at the given location, we'll store that location and the number of units stationed there. To do so, we'll use the units_on_location table.
When units are not stationed, they're moving around. We'll need to store their departure point and their destination. In addition, we need to define possible actions during movements. All such actions are stored in the movement_type dictionary. The type_name attribute is unique while the allows_wait attribute determines if an action allows waiting at the destination point.
We can move a single unit type, but in almost every case we'll move many units of several different unit types. That group will share common data and we'll store them in the group_movement table. In this table, we'll define the following items:
- the player that initiated that action
- the action type
- the starting point
- the destination point
- the
arrival_timeat the destination - the
return_timeto the starting point - the
wait_timeat the destination
The return_time attribute can be NULL if this is a one-way journey, and wait_time is defined by the player. Units belonging to a group are defined by values stored in the units_in_group table. The foreign key pair of units_id and group_moving_id forms the unique key of the table. The number of the units of the same type within a group is defined in the number attribute.
Each movement can transport resources from one location to another. Therefore, we'll define a many-to-many relationship between the group_movement and the resources tables. Besides the primary and foreign keys, the resources_in_group table contains only the number attribute. This field stores the amount of resources players move from the starting point to their destination.
In most cases, players can call others to join their adventure. To support that we'll use two tables: allied_movement and allied_groups. One player will initiate joint action, and that will create a new record in the allied_movement table. All groups of units that take part in an allied action are defined by values stored in the allied_groups table. Each group can be assigned to an allied action only once, so foreign keys form the unique key of this table.
This model gives us the basic structure needed to build an MMO strategy game. It contains the most important game features: locations, structures, resources, research, and units. It also relates them, lets us define prerequisites in the database, and stores most of the game logic in the database as well.
Pc Game Free
After these tables are populated, most of the game logic is defined and we wouldn't expect new values to be added. Almost every table has a unique key value, either a feature name or foreign key pair. Changing units' characteristics and production/cost formulas will allow us to change the game balance in the database layer.
How would you change this model? What do you like, and what would you do differently? Tell us in the comment section!
notified about the latest posts.
You may also like
A Database Model for Simple Board Games
Pc Game Download
7 Common Database Design Errors
Database Design: More Than Just an ERD
5 Steps for an Effective Database Model
Rawg Video Game Database
A Simple Online Store Model: Sell, Ship, and Get Paid
Can Python Help You Win Scrabble?
Pc Game Downloads Windows 7
Recently Browsing 0 members
Similar Content
- By zikalifySteam Play will allow Linux users to play Cyberpunk 2077
by Paul Hill
Valve has just released Proton 5.13-4 which, according to the release notes, allows Linux users to play Cyberpunk 2077 via Steam Play. For those who've not used it, Steam Play utilises Proton, a compatibility layer that allows Linux users to play games that were designed for Windows.
Cyberpunk has suffered numerous setbacks during its development but it's finally being released for Windows, PlayStation 4, Stadia, and Xbox One on December 10. The game is currently available for pre-purchase on Steam and it's recommended that you have an Intel Core i7-4790 or AMD Ryzen 3 3200G processor, 12GB RAM, and an NVIDIA GeForce GTX 1060 or AMD Radeon R9 Fury. If you plan to run it on Linux, Phoronix notes that your system will need Mesa 20.1-devel Git installed; you can check what version of Mesa you have by typing glxinfo | grep Mesa in the terminal.
Valve's Proton software has been a big win for gaming on Linux as it has made many more games in Steam's library available on Linux. While more game developers have been adding native Linux support, the vast majority still do not but Proton goes a long way to bridging the gap.
It won't be clear until tomorrow when the game is released how well it will perform on Linux. If you plan on trying it out on Linux all you'll need to do is check the Steam settings to ensure that Proton 5.13-4 is selected before proceeding to launch the game.
Via: Phoronix - By LoneWolfSLMedal of Honor: Above and Beyond multiplayer gameplay shown off
by Pulasthi Ariyasinghe
Respawn Entertainment showcased the multiplayer gameplay of Medal of Honor: Above and Beyond for the first time today. The virtual reality title had so far only received single-player campaign gameplay. Catch the new action-packed multiplayer trailer above.
Above and Beyond players will have five multiplayer modes to play around in at launch, them being Team Deathmatch, Deathmatch, Domination, Mad Bomber, and Blast Radius. Mad Bomber seems to be a spin on the standard bomb plant game modes seen in other shooters, while Blast Radius is described as King of the Hill but with rocket launchers. All of these modes get some time in the spotlight in the trailer above.
While the number of maps included was not confirmed today, Respawn said players will be fighting in 'sites across Europe.' Multiplayer matches will have up to 12 players, with both human and AI opponents being supported. Players will also need to learn how each weapon handles and their unique reloading mechanisms to become proficient at battling opponents.
Medal of Honor: Above and Beyond is releasing on December 11 across the Oculus Store and Steam. Fans will be happy to know that cross-play between the two stores will be enabled, letting players from both platforms join each other in multiplayer sessions. - By Usama Jawad96How to refund games on Steam
by Usama Jawad
Holiday sales across gaming platforms on PC and consoles are in full swing and many gamers are using their savings to capitalize on this by buying their favorite titles at discounted prices. While you would hope that once you purchase a game, you can quickly download it, fire it up, and play it without any issues, but sometimes things can go a bit awry.
The game might not be in a playable state, have too many bugs, or simply might not be as fun as you expected it to be. There's also the chance that when buying dozens of games during the sale, you skimmed over the technical requirements section and didn't notice that your rig isn't powerful enough to run the game optimally. In cases like these, the easiest way out is to quickly get a refund. In this piece, I will walk you through the refund process on Steam.
Step 1: Navigate the Steam client
Valve's own FAQ for the refund process requires you to login to their support webpage but quite frankly, I find that method cumbersome. Why not use the Steam client itself when you have it installed on your PC? Of course, if you don't have it installed, then it's understandable to visit the website. However, for the purpose of this article, I will assume that you do have it installed to make the process more streamlined.
Now that you have fired up the Steam client, find the game you want to refund in the left panel and click on it. This will open a dedicated section for the problematic game on your screen. Click the 'Support' button on the main options bar for the title. This will take you to a new support page and the second step of this process.
Step 2: Filling in the details
On the Support page, the Steam client will show you a list of options that you can choose from to indicate what kind of problem you are having with the game in question, as shown above. With respect to requesting refunds, only the following options are valid:
It's now available cheaper Gameplay or technical issue It's not what I expected For other options, Steam informs you that it can't help out and requests you to get in touch with relevant parties such as key sellers and developers.
Clicking on any of the three valid options mentioned earlier takes you to a submenu asking you further questions. For the purpose of this guide, I clicked on 'Gameplay or technical issue', which took me to the submenu shown above. Here I clicked on 'The game runs poorly'.
This took to me to another page providing me a couple of options as can be seen above. Depending upon the prior options you selected, you might see different alternatives on this page. Here, Valve typically recommends you some options to resolve problems with your game such as getting in touch with the game's developer. However, you can choose to forego all the other options and directly click on 'I'd like to request a refund'.
Step 3: Requesting a refund
Selecting 'I'd like to request a refund' will take you to the final page which will require input from your side. Knowing the details of this step is important. Valve typically issues refunds only for games that have less than two hours of playtime and have been purchased less than 14 days ago. If you do not fulfill these qualifications, Valve may still offer you a refund, but the chances of that happening are very slim. Personally, I have tried this a couple of times with detailed reasoning, but Valve has never issued a refund to me on games that have more than two hours of play time or were purchased more than 14 days ago.
Speaking of 'detailed reasoning', the 'Notes' section is where you can fill that in. However, I've found that a one-line explainer like 'it's not that good' works as well. Furthermore, you can choose where the refund amount will go: it can either go to the original payment method or your Steam Wallet. If you plan to spend it on Steam again, I highly recommend going for the second option since it doesn't involve other parties and is much quicker.
Furthermore, another thing to remember is that games you got via promotional keys - such as those offered by the developer - cannot be refunded. The refund amount depends upon the price you purchased a title at, not it's current value. Lastly, you can refund games that you received as a gift but the monetary value will be returned to the person who gifted you those titles, not to your account. If you're fine with all of these things, click on 'Submit request'.
Step 4: The wait
Now all you have to do is wait for Valve to approve your refund request. Provided that you fulfill all of their requirements related to playtime and ownership, refunds are usually granted by the company. In my case, I've noticed that these requests are generally approved within a couple of hours.
Valve says that it may take up to seven days for funds to appear on your account, but for Steam Wallet funds, it only takes a couple of days at maximum in my personal experience. For international payment methods which involve your bank, this process may take more than seven days. In case it does, Valve recommends that you reach out to your bank and inquire details from them.
Provided that everything goes smoothly, your refund request will be approved and completed within a couple of days. However, if for someone reason, your request gets declined and you want to contest that decision, Valve suggests that you issue a new request so another agent can have a look at it.
Last but not the least, Valve does not limit the number of refund requests you make but if it thinks that you're abusing the option, it may place restrictions on your account. In my case, I once bought nearly 15 games and then had a few of them refunded as I played them one by one and realized that I didn't enjoy all of them. At that time, Valve did caution me via email to use the refund option carefully based on the high number of requests coming from my account.
With that said, use this option wisely and happy gaming! - By LoneWolfSLSteam Autumn Sale is now live alongside the 2020 Steam Awards nominations
by Pulasthi Ariyasinghe
The yearly Steam Autumn Sale has opened its doors once again, offering discounts on more games than anyone could possibly browse through. Once again, the sale is accompanied by The Steam Awards event, letting PC gamers vote for games they deem worthy of receiving nominations for a number of awards.
Considering the sale just kicked off, and as expected of every major event, the store is having a hard time opening and displaying correct pricing right now, but it should be solved shortly. Some of the highlights Valve is promoting on the first day include sales for hits such as Fall Guys, Star Wars Jedi: Fallen Order, Doom Eternal, and Death Stranding, among many others.
Keep in mind that sale prices remain static during the entire event and the front page only showcases different items every day.
As for The Steam Awards nominations, users will find standard categories they may vote for such as Game of the Year, Visual Style, Soundtrack, and Innovative Gameplay, as well as more entertaining ones like 'Best Game You Stuck At', and 'Better With Friends'. Those who participate in the nomination procedures get some bonuses too, with Valve offering Steam profile badges for completing tasks.
The Steam Autumn Sale will keep its discounts running through December 1. Meanwhile, the elected Steam Awards nominees will see the light of day during Valve's next major sale event in December, the Steam Winter Sale, with a final popular vote happening to decide the winners. - By LoneWolfSLRockstar will offer Red Dead Online as a standalone game priced at $4.99
by Pulasthi Ariyasinghe
Rockstar Games' open-world western epic Red Dead Redemption 2 is gaining a new version soon, as the studio today announced that its online mode is being spun off to be offered as a standalone game. The release date is set for December 1, and it will be available for $4.99 as an introductory price.
The Red Dead Online standalone version will be the complete online experience, with story-based cooperative missions, player vs player Showdown modes, Specialist Roles, Free Roam Missions, and much more available across the massive open world.
The $4.99 introductory price will go away after February 15, 2021, bumping up the cost of the standalone multiplayer game to $19.99. Rockstar will also offer an option to unlock the Red Dead Redemption 2 story mode from within this variant, but the exact cost of this upgrade was not announced today.
Although it is a standalone experience, it doesn't appear as though the installation size requirements are changing, as the studio revealed the game will require up to 123GB of free space.
Red Dead Online will be available for PC (Steam, Epic Games Store, and Rockstar Games Launcher), Xbox One, and PlayStation 4. Xbox Series X|S and PlayStation 5 users will be able to play the game using backward compatibility also. Moreover, since this is a fully multiplayer experience, PlayStation Plus and Xbox Live Gold memberships are required for console players.
