Task #984

Discussion on dynamic game support

Added by Packhead over 2 years ago. Updated over 2 years ago.

Status:New Start date:12/28/2009
Priority:Normal Due date:
Assignee:- % Done:

0%

Category:General
Target version:1.7.0
Blocking Target Version:

Description

There was some discussion on TeamSpeak tonight on how we could possibly handle doing dynamic-game support.

Right now we include game support (SQL and game images) for every game we support. While this means turning on a game is real easy, it means everyone has to load all the data -- whether they're going to use it or not.

With the talk of adding a web-based installer (#813) perhaps removing the games from the install pack would be advantageous to us. We could perhaps start a version number for each "game pack". So TF2, L4D, etc would each have their own version number (much like our DB version number). When people run the web-installer, we'll prompt them for what games they want to initially support. The web-installer will talk to a server on our end, pass the current game-pack version # and the server would then respond with a pack file with the appropriate contents. When we do new updates for things like TF2 award SQL stuff, administrators could go to their administration panel, see they have gamedata updates for say TF2 waiting. They press "Update TF2 Now", it downloads the changes from their TF2 game pack version number to head and executes necessary SQL.

This would be a great solution to our "exponentially growing" package sizes, plus would allow us to make minor changes to gamedata on a semi-frequent basis (much like SourceMod does for gamedata -- they don't do new release versions for new gamedata -- their releases just contain that data).

Might be something to look at doing for 1.7. Comments?


Related issues

related to HLstatsX: CE - Feature #998: download heatmaps script New 01/04/2010

History

#1 Updated by Packhead over 2 years ago

  • Category set to General
  • Target version set to 1.7.0

#2 Updated by allstats.de over 2 years ago

Do you have a workflow? I suggest to get gamecontent if an admin sets the game to show under games. I think its the right place and there is no need for additional controls in frontend.

#3 Updated by Packhead over 2 years ago

allstats.de wrote:

Do you have a workflow? I suggest to get gamecontent if an admin sets the game to show under games. I think its the right place and there is no need for additional controls in frontend.

We are replacing our current installation method with a web-based installer. At that point the administrator will be prompted for which games to download initial content for. Each game will become their own mini-versioned project inside of HLX:CE. In 1.7 we will also have an administration center "checkup" page, which will list the installed version for all components and the current version, as well as the option to upgrade.

We do not intend to "push" data to the installations -- administrators will have to go manually trigger this. I assume we'll probably also trigger it automatically, or with an option, when we release update packages for the core HLX:CE components.

#4 Updated by allstats.de over 2 years ago

Maybe you split the web and the perl part into mini projects too. So with a bugfix nobody needs to update perl part too. Meens every time no db changes appear nobody have too update perl part.

Also available in: Atom PDF