NEOPETS - 2013
Gaming System v.10.1
Design: UML, OOP, MVC
Development: Adobe Flash AS3, HTML, AMFPHP , PHP
Gaming System v.10.1
Design: UML, OOP, MVC
Development: Adobe Flash AS3, HTML, AMFPHP , PHP
As a Lead Developer at Neopets, I designed and developed a new Gaming System, including in-depth documentation and how-to guides for non-developers. The System is a piece of software that connects the games to the Neopets back-end, allowing to configure promotions, tracking, points earning and more.
Follows a short extract of the TDD outlining objectives and architecture, and some screenshots (Copyright Neopets 2018):
OVERVIEW
The Neopets Gaming System v 10.1 has been developed to be adopted in place of the current system (NP9/10) for all new and re-issued games on Neopets.
Specifically the new system addresses:
- Existing games customization (Integrated Marketing custom games, PPP reskins).
- 3rd party game engines adaptation (ie: AG engines)
- New in-house games creation.
- 3rd party games development (Vendors)
- 3rd party games integration (Integrated Marketing adapted games)
The system is being deployed together with the admin-driven Preloader system, which empowers the Graphic Designer/Marketing to setup and configure the games preloaders with no intervention of the developer.
The Neopets Gaming System v 10.1 has been developed to be adopted in place of the current system (NP9/10) for all new and re-issued games on Neopets.
Specifically the new system addresses:
- Existing games customization (Integrated Marketing custom games, PPP reskins).
- 3rd party game engines adaptation (ie: AG engines)
- New in-house games creation.
- 3rd party games development (Vendors)
- 3rd party games integration (Integrated Marketing adapted games)
The system is being deployed together with the admin-driven Preloader system, which empowers the Graphic Designer/Marketing to setup and configure the games preloaders with no intervention of the developer.
For a step-to-step guide on how to integrate a game skip to GAME INTEGRATION AND PRODUCTION
WHAT’S NEW
These are the main differences with Gaming System NP9 (and NP10, which is essentially a copy of NP9):
- The system is compiled together with the game, so there is no loader swf common to all games, like in the previous systems. The name of the swf file being loaded directly by the game page is the name determined by Games Master. (see ONLINE/OFFLINE FOLDER STRUCTURE)
- The system is now completely decoupled from the game, allowing for great versatility in how to embed, load or compile the actual game engine in the system. This is achieved via Singletons Managers and Game Events.
- New features can be added and modified, both at compile time and at run time. This facilitates the adding of game-specific features (game shell redesign, special events, additional tracking, etc.), as well as changes to the system to affect pre-compiled games. This is accomplished via a Dynamic State Machine pattern. States can be added, removed and substituted by configuring an xml file (first phase); new code and assets get loaded in with a swf. The same NP10_GameManager (and all other managers) can be modified and changed at runtime via code injection (see. EXTENDING / MODIFYING THE SYSTEM ).
- The system is been wired to accept the game configuration via AMFPHP and VOs; while this has not yet being implemented in the backend, switching to the new backend when it is developed will require changing only the abstract document class.
These characteristics aim to keep the games code much cleaner to be as specific as needed with each individual game, without 'clogging' the system.
SYSTEM ARCHITECTURE
The Gaming System v. 10.1 uses a Dynamic State Pattern along with code injection to implement great flexibility and maintainability, and allows to be customized for each specific scenario.
These are the main differences with Gaming System NP9 (and NP10, which is essentially a copy of NP9):
- The system is compiled together with the game, so there is no loader swf common to all games, like in the previous systems. The name of the swf file being loaded directly by the game page is the name determined by Games Master. (see ONLINE/OFFLINE FOLDER STRUCTURE)
- The system is now completely decoupled from the game, allowing for great versatility in how to embed, load or compile the actual game engine in the system. This is achieved via Singletons Managers and Game Events.
- New features can be added and modified, both at compile time and at run time. This facilitates the adding of game-specific features (game shell redesign, special events, additional tracking, etc.), as well as changes to the system to affect pre-compiled games. This is accomplished via a Dynamic State Machine pattern. States can be added, removed and substituted by configuring an xml file (first phase); new code and assets get loaded in with a swf. The same NP10_GameManager (and all other managers) can be modified and changed at runtime via code injection (see. EXTENDING / MODIFYING THE SYSTEM ).
- The system is been wired to accept the game configuration via AMFPHP and VOs; while this has not yet being implemented in the backend, switching to the new backend when it is developed will require changing only the abstract document class.
These characteristics aim to keep the games code much cleaner to be as specific as needed with each individual game, without 'clogging' the system.
SYSTEM ARCHITECTURE
The Gaming System v. 10.1 uses a Dynamic State Pattern along with code injection to implement great flexibility and maintainability, and allows to be customized for each specific scenario.
It uses Singleton managers that centralize operations on specific aspects (Connection, Translation, Sounds, UI Screens, etc.). Singletons offer the advantage to be easily accessible throughout the whole game; this, as well their ease to use, is an invaluable feature when having to deal with 3rd party game development (Vendors) and integration of existing games.
For example, the UI is managed by NP10_ScreenManager that creates transitions and unload screens according to the States configuration (see Screens).
The System is almost infinitely extendable at runtime by adding/removing/substituting states and loading in new classes and assets (code injection).
All communications with the backend happen via AMFPHP protocol (in the second phase). However, for this first phase of release, it has been hooked up with the current Flashvars system, since the backend has not being developed yet. All additional configuration not yet added to the Game Master admin page is delegated for now to a shellConfig.xml file (see GAME SHELL CONFIGURATION).
All communications with the backend happen via AMFPHP protocol (in the second phase). However, for this first phase of release, it has been hooked up with the current Flashvars system, since the backend has not being developed yet. All additional configuration not yet added to the Game Master admin page is delegated for now to a shellConfig.xml file (see GAME SHELL CONFIGURATION).
The following diagram is a high-level model of the architecture of the Gaming System 10.1.
NEOPETS - 2011
Customizable Games Pre-loader
Design: UML, OOP
Development: Adobe Flash AS3, HTML, AMFPHP , PHP
Neopets has different type of games and the preloader is customized to display the current advertiser content (or more than one), tracking click-throughs and loads the correct game.
The code base was messy and mysterious, with no documentation and patched up several times. Debugging was nightmarish and the process to create new preloaders was ancient.
The redesign aimed at:
- Allow non-developers to configure how and what gets loaded when a minigame starts (ads, video ads, site preloader, extra dialogs for promotions etc.) without the need to recompile the games, as the previous system required.
- Cleanup the Flashvars list (that in 5 years swelled up to more that 35 different variables, most of them with no known use)
- Add modern tracking (Google Analytics, Pixel tracking) to be configured by non-developers
- Be backward-compatible with the old system. [...]
Customizable Games Pre-loader
Design: UML, OOP
Development: Adobe Flash AS3, HTML, AMFPHP , PHP
Neopets has different type of games and the preloader is customized to display the current advertiser content (or more than one), tracking click-throughs and loads the correct game.
The code base was messy and mysterious, with no documentation and patched up several times. Debugging was nightmarish and the process to create new preloaders was ancient.
The redesign aimed at:
- Allow non-developers to configure how and what gets loaded when a minigame starts (ads, video ads, site preloader, extra dialogs for promotions etc.) without the need to recompile the games, as the previous system required.
- Cleanup the Flashvars list (that in 5 years swelled up to more that 35 different variables, most of them with no known use)
- Add modern tracking (Google Analytics, Pixel tracking) to be configured by non-developers
- Be backward-compatible with the old system. [...]