Case Study

Apollo VCL components

Author: Dana Dill, Senior Programmer
Company: APBA International

Introduction

I would like to take share some of my experiences in using several Apollo products. I work for APBA International, Inc., a sports game company. I am in charge of developing all their sports computer game products using Delphi from Borland.

Phase 1: Standalone/Internet Solution

Our game software is very data intensive so the first big issue we faced in designing our gaming system was to decide on the database engine. The players that use our software want a nice user interface but many of our customers buy our software because of the managerial strategies and accuracy of our statistical results and we did not want to develop our own binary file formats for storing data.

Furthermore, since this is a shrink-wrap software game that is purchased off the shelf in stores, we needed a database that would install easily and without configuration. That meant no ODBC, ADO or any other such middle-ware. Our database solution had to be small, fast, and virtually invisible to the end-user (gamer). It also had to be easy to implement.

Solution: Apollo VCL

After looking at several database products that could be used in our Delphi application we chose Apollo VCL. Apollo solved all of our problems and is now used in our baseball software and is used to collect all the data from the games and leagues across the country.

In addition to product functionality, support was a big issue. We knew that Apollo has been around for many years but after talking with the staff at ApolloDB, we felt confident that they would be able to deliver the type of support we needed. And they have.

Another nice feature is that Apollo supports SQL and we are now in the process of converting converting our code to SQL.

Apollo VCL turned out to be much faster than we had anticipated and it was truly painless when it came to deployment and installation. We have discovered that Apollo's TApolloTable.Query method is lighting fast. We also like that we can develop our application in local mode and then with minimal changes, move to a true client/server architecture using the Apollo Server. This leads me into Part 2 of this case study: Client/Server and Multi-Tier Solution.

Phase 2: Client/Server and Multi-Tier Solution

One of the major features of our game software is on-line play. We needed a solution that stored data to a centrally accessible database server so that players could play in on-line leagues that used the centrally located data to play the games

Solution: Apollo Database Server

We now needed to make the data accessible over the Internet. The following were our requirements:

• Internet accessibility
• Maintain good peformance
• Price
• Ease of integration and deployment

The solution turned out to be easier than we had anticipated. We decided to use the Apollo Database Server and run it our web server.

Not only was the Apollo Server pricing right for us with the unlimited deployments for one price policy, but the product, as it turns out is solid and FAST. We use the Apollo Database Server in a unique way: Knowing that we manage anywhere from 10,000 to 30,000 on-line players, we did not want to allow all these players to connect to our Apollo Database Server directly. So we created an application server that acts as a middle tier of our three tiered system.

Our Application Server connects directly to our Apollo Database Server and when our game client wants to play an on-line game, the game client connects to our Application Server, which in turn makes a request to the Apollo Server for the game data. This request is passed to the Apollo Server in the form of a SQL statement. A result dataset is returned to our Application Server, which in turn sends the data to the game client and the players are off and running. The data flow is very fast and works great.