Adoção do GDK
Cada GDK tem suporte por apenas um ano. Embora os jogos existentes possam continuar sendo lançados usando um GDK descontinuado, isso pode ser problemático para jogos lançados como serviço. Jogos que introduzem novos recursos depois que um GDK foi descontinuado podem encontrar bugs ou problemas de integração que não foram vistos em casos de uso anteriores do GDK. Da mesma forma, o jogo pode querer aproveitar recursos encontrados apenas nos GDKs mais recentes que estão sendo lançados. Um jogo deve ser compilado com um único GDK. Os jogos não podem misturar componentes de um GDK com outro. No console, o jogo inclui apenas um único Game OS, e as várias bibliotecas do GDK podem ter dependências desse sistema operacional subjacente. No PC, apenas uma versão do runtime de jogos é carregada no processo do jogo, criando um ambiente de “versão única” semelhante ao visto no console. É recomendável que os títulos GaaS atualizem periodicamente para um GDK lançado mais recentemente que ainda tenha suporte.Intelligent Delivery
Os títulos GaaS podem ficar cada vez maiores ao longo dos anos com a introdução de novo conteúdo. Os jogadores podem ter quantidades limitadas de espaço de armazenamento. Isso pode afetar a capacidade deles de instalar a atualização mais recente do jogo. Embora seja verdade que os jogadores podem gerenciar seus próprios espaços de armazenamento, jogos criados com Intelligent Delivery dão ao jogador mais flexibilidade e opções sobre como usar seu espaço de armazenamento, além de desinstalar jogos inteiros, e permitem que os jogadores mantenham mais jogos instalados em seus dispositivos por muito mais tempo. Usando o Intelligent Delivery, os jogos podem aproveitar recursos e receitas, escolhendo o que é instalado por padrão e dando aos jogos a capacidade de gerenciar quais partes do jogo desejam manter instaladas e quais partes podem querer remover porque não as estão mais usando. Os títulos GaaS podem optar por colocar seu novo conteúdo em recursos separados para permitir esse tipo de gerenciamento. A ideia é que o novo conteúdo seja um durável. Aqui está uma sugestão que facilitaria esse gerenciamento:- No arquivo de layout do jogo, faça com que cada durável corresponda a um Feature.
- O Feature declarará uma ou mais Tags que podem ser usadas para indicar quais blocos no arquivo de layout devem ser instalados se o jogador tiver uma licença para esse conteúdo.
- Certifique-se de que o arquivo de layout inclua uma Recipe que tenha um filho Store ID. Essa receita
deve referenciar um único recurso que corresponda ao mesmo Store ID. Adicionar a receita
garantirá que, se o jogador tiver comprado esse conteúdo anteriormente, ele será instalado
automaticamente.
[!NOTE] Pode haver outros recursos e receitas que não têm nenhuma relação com duráveis.
- Chamar XPackageEnumerateFeatures para enumerar os recursos.
- Usar o Store ID retornado que está em XPackageFeature para verificar a licença, consultar mais detalhes ou invocar fluxos de compra da loja.
Conteúdo para download
Em vez de evoluir continuamente seu pacote base, alguns títulos GaaS podem optar por evoluir ao longo dos anos usando conteúdo para download (DLC). Os jogos podem optar por colocar ativos ou código executável nesse DLC. Com código executável, há dois caminhos possíveis: DLLs e EXEs. Se o jogo colocar DLLs em seu DLC, ele poderá:- Montar esse DLC usando XPackageMountWithUiAsync.
- Usar LoadLibraryEx.
- Todo DLC montado anteriormente permanece montado.
- Montar esse DLC usando XPackageMountWithUiAsync.
- Chamar XLaunchNewGames usando o caminho do DLC montado.
- O processo do jogo existente será encerrado.
- Todo DLC, exceto o destino de XLaunchNewGames, será desmontado.
- A unidade G: continuará apontando para a raiz do pacote base e não para o EXE recém- iniciado.
Documentação de referência da API
- XPackage (conteúdo da API)
- Funções
- Estruturas
- xgame (conteúdo da API)
- Funções