History of the Platform

Origins

The platform's journey began with a relatively simple structure, comprising three core components:

• MySQL Database: The backbone for storing game data.
• PHP Game Code: Specific PHP scripts for each game type.
• Adobe Flash Game Clients: The primary interface for users

All of these were organized within a flat directory structure, with a simple game launch file called index.php at the root, with the MySQL datbase being accessed via a file called database.php

• URL/
  • server/
  • games/
  • index.php
  • database.php

Major Milestones

• Introduction: of HTML5 Clients
• Change: Addition of HTML5 game clients alongside existing Flash games.
• Implementation: Modified the game launch code to support both Flash and HTML5 clients.

This caused the game directory structure to change a little

• URL/
  • server/
  • games/
    • html5_assets
    • flash_assets

Note: That the Flash launch code remains in place, despite Flash's obsolescence in modern web browsers.

Virtual Football Integration

• Addition: Incorporated a virtual football game platform, now obsolete.
• Development: Primarily developed using the Erlang programming language,

Note: Although these games are now obsolete, there is some continued support in the game launch code, and a few other places.

The Pulse Platform Development

• Evolution: Transition from a flat HTML directory structure to a more organized format with generic and customer-specific directories such as integration.
• Current Status: This reorganization process is ongoing, marking a significant evolution of the platform’s infrastructure.

• URL/
  • integration
    • env.php
  • pulse
    • server/
      • database.php
    • games/
      • index.php

Adoption of CDN (Content Delivery Network)

• Function: Utilizes a network of servers distributed globally to efficiently deliver game client content to users based on their geographic location.
• Objective: Aims to enhance high availability and performance by spatially distributing the service relative to end-users.
• Application: Primarily used for distributing game clients, improving user experience through faster and more reliable content delivery.

Excuses and Caveats

What this is about

• This section aims to provide context for the system's design and implementation choices.
• These are not justifications for poor practices, but explanations of choices made under specific circumstances.

List of Common Issues

• Inexperience with Tools/Languages: How our initial unfamiliarity with certain tools or programming languages influenced certain design choices or led to less optimal implementations.
• Refactoring Challenges: This discusses the difficulties of refactoring code that is live and in use by players. Highlighting the risks and challenges associated with making changes to such a system.
• Resource Limitations: A discussion of any constraints like time, budget, or manpower that impacted development choices.

Legacy Decisions:

• A discussion of any early decisions that were made without full knowledge of how they would impact the system long-term.