GateShift Online Project

 

This will be the first discussion of the various practices we will implement in the process of designing and building GateShift. I hope to post information from our development of GateShift about these processes on the blog with as much information as possible regarding the practices as we progress. This will hopefully answer questions as to why we follow these practices to maintain a consistent environment.

Our first pattern we use is called the Repository Pattern. This pattern allows us to maintain a completely abstracted Data Layer that can be tested independent of the Business Layer. This also means, because the data is returned in an abstract way, that our Business Layer can benefit too. Because the business layer does not have to use the real database to test, you can write an in memory collection and fly through unit testing. Finally, you can switch out data sources (as long as the structure is the same) at any time to a new source. Currently, this practice only affects the server side.

“In such systems it can be worthwhile to build another layer of abstraction over the mapping layer where query construction code is concentrated. This becomes more important when there are a large number of domain classes or heavy querying. In these cases particularly, adding this layer helps minimize duplicate query logic.” (Hieatt & Mee)

Let’s start off with a basic diagram of what a repository allows us to do:

As you can see from the diagram, there are several steps involved in getting data from the database. The first thing that occurs is the Business Layer makes a request to a specific IDataProvider (in our case, SQL) to get a specific type of ITableRepository. The business layer has no idea what the official type of ITableRepository is except that it has a specific set of methods for retrieving and managing data for the specific type of ITableData it is looking for. The IDataProvider then creates an internal class that has all the code for managing ITableData in the SQL database and returns a reference as ITableRepository. Then the business layer takes the created instance of ITableRepository and asks it to perform a task on ITableData. It makes the call and for anything that returns ITableData, it creates an internal object representing the data and returns it as ITableData. That is the basic overview of how the repository system works.

In our situation, we use Microsoft ADO.NET Entities provided with the recent .NET 3.5 framework with Service Pack 1. This allows us to handle nearly 0 lines of SQL inside of the data layer and gives us a base class to tag the ITableData onto. It also allows us to use LINQ to create our queries. There are articles on the internet that describe allowing LINQ to be exposed to create truly dynamic queries from the business layer, but the problem is they require us to get rid of ITableData. This will not work because we would then be dependent on the ADO.NET framework no matter what data source. You can read more of applying LINQ to the pattern on http://www.codeproject.com/KB/architecture/linqrepository.aspx.

While this pattern increases the complexity overall because of there being more classes, the benefits for abstraction and dependence defiantly outweigh the cons. Down the road, this could also mean that we could have an a team working on nothing but the Data Layer and another on the Business Layer without conflicting (as long as the results are expected).

I hope this post gives you a wonderful idea of the time taken to design a scalable system for an MMO. Even though C++ may be faster in the long run, our code will be more scalable with less recompilation or additional specialized applications. Be sure to stay tuned on the project site to see exactly how our process for coding the pattern will take place and keep checking back for more patterns.

Sources:
Hieatt, E., & Mee, R. (n.d.). P of EAA: Repository. Retrieved 02 20, 2009, from P of EAA: http://www.martinfowler.com/eaaCatalog/repository.html

 
The First Post 02/19/2009
 

Hello world... We have heard this term too many times. Where do you go after the first program called "hello world"? Do you make one for hello universe or for hello friend? Do you follow the rest of the world of programming or do you think outside the box?

Sometimes thinking outside the box can be the next best direction to proceed, and sometimes it can be a downfall. The inspiration for GateShift is a game of "why not". Why can you not have a game where your primary goal is to quest and kill masses of creatures and combine it with a game where your primary purpose is to be the king of the economy?

Creating an environment that does not limit the player to one specific path, but allows them to branch out to show how their personality really is could be the key to the next long term game. If a player can join with the intention of being either an epic player or an economic leader, you can attract more people into the game.

There are many people in the industry that say that something of this magnitude should not be attempted and there are many that say that it would just be impossible to do. GateShift challenges that through open-source distribution and intelligent design. GateShift will provide the player with a world of “why not” and allow them to choose their destiny.

The design GateShift will implement allows teams to work on components to “plug in” on the live server to expand playability. This means that a hosting company can ultimately choose just the pieces they really want to run. It also means that they can add new features as they are released that should reduce time of deployment.

Our design will include many well known business driven design practices to make the system scalable and the release cycle shorter. Our hardest obstacle is the graphic and sound content needed for a game this size.

Stay tuned for more articles on how our plan will develop as the days go by. We are already underway and have quite a bit of code behind us.