STL para jogos, sim ou não? [fechadas]

Toda linguagem de programação possui sua biblioteca padrão de contêineres, algoritmos e outras coisas úteis. Com linguagens como C #, Java e Python, é praticamente inconcebível usar a linguagem sem a sua lib padrão.

No entanto, em muitos jogos C ++ em que trabalhei, nós não usamos o STL, usamos uma pequena fração dele ou usamos nossa própria implementação. É difícil dizer se essa foi uma decisão acertada para nossos jogos, ou simplesmente tomada por ignorância do STL.

Então ... o STL é um bom ajuste ou não?

Quando eu trabalhei no desenvolvimento profissional de jogos, o STL era muito imaturo e inchado. Mas isso foi há> 10 anos atrás.

Agora, trabalho em simulação militar, que tem requisitos de desempenho ainda mais difíceis (como a taxa de quadros nunca pode ficar abaixo de alguns FPS). Na simulação militar, o STL é usado em todo o lugar.

Algumas pessoas que dizem para você não usar STL usam o argumento de que nem sempre é a solução perfeita ou mesmo a melhor para o problema. Mas isso não é uma resposta para a pergunta. A pergunta deve ser: existe algo inerentemente errado no uso do STL nos jogos? Eu diria que não, o STL é, na maioria das vezes, uma implementação melhor do que o que um usuário criaria por conta própria.

Apenas certifique-se de saber como usar o STL e usá-lo em seu jogo. Leia alguns livros e veja o código de implementação no STL que você está usando.

Eu diria que, acima de tudo, é uma idéia melhor usar o STL, a menos que você saiba exatamente por que não deseja usá-lo.

Aqui está a coisa sobre o STL: ele é desenvolvido por pessoas mais inteligentes do que você. Isso não pretende ser ofensivo nem nada, é apenas que o STL é desenvolvido por pessoas cujo trabalho está realmente construindo o STL. Será praticamente tão rápido quanto a plataforma pode permitir e geralmente será muito mais robusto do que uma solução caseira (e isso deve ser uma preocupação, se não mais, do que se preocupar com a velocidade bruta - porque seu jogo precisa robustez um pouco mais do que você precisa de velocidade; o último não faz sentido sem o primeiro).

As queixas de que o STL impõe uma "visão estreita do mundo" me parecem um pouco tolas. Eles são recipientes. Eles têm um conjunto limitado de operações porque os contêineres têm conjuntos limitados de operações. O que você está fazendo que não combina com isso?

Vi poucas razões para não usar o STL para jogos.

Para os problemas de alocação de memória, muitas pessoas não sabem disso, mas você pode escrever alocadores personalizados para suas classes de contêiner STL. Alocadores são basicamente classes de política que você passa para seus modelos para determinar como as alocações são executadas. Usando esses recursos, você geralmente pode solucionar os problemas de memória que são problemáticos na sua plataforma de escolha.

Obviamente, se você estiver usando o STL e fazendo coisas idiotas, como mapas de cadeias de caracteres para tipos grandes e sem ponteiros, terá problemas maiores em sua mão.

O STL padrão tem um número razoável de problemas que dificultam o uso com jogos, especialmente quando se trata de alinhamento de memória.

Uma variante personalizada, como o EA STL, foi especialmente projetada para jogos e pode proporcionar um desempenho de memória e usabilidade do console muito melhores. Tornou-se open source em 2016, sob uma cláusula BSD-3, com um repositório no GitHub .

Aqui está o que Mike Acton (diretor de motores da Insomniac Games de Spyro the Dragon, Ratchet & Clank e Resistance) teve a dizer sobre isso quando solicitado aqui . Observe que ele foi questionado sobre o STL e o Boost em geral, relacionados ao uso no desenvolvimento de jogos.

STL / Boost, ele pertence ao gamedev? Se apenas partes dela, quais?

Você está perguntando sobre duas coisas diferentes aqui, certo? STL e Boost, separadamente. Mas, na verdade, minha resposta é a mesma: não há nada errado com nenhum deles, mas desencorajo o uso deles. O uso de qualquer um incentiva as pessoas a adaptar uma solução para um problema, em vez de encontrar uma solução para um problema. A solução deve sempre ser apropriada para os dados disponíveis e as restrições do hardware, etc. Tanto o STL quanto o Boost têm uma visão extremamente estreita do "mundo" e seu uso apropriado é limitado. Realmente, desencorajo-os porque eles levam os programadores a seguir na direção errada imediatamente; muitas vezes digo que, se você sentir que precisa de um deles, provavelmente não entenderá realmente o problema que está enfrentando. '

Também notei que a maioria dos desenvolvedores de jogos profissionais se esforça mais em C do que em C ++.

Se você se reescrever algo que já existe no STL, por qualquer motivo, pare . Use o STL.

O STL foi otimizado ao longo de anos de análise e tempo, e é uma aposta segura que você provavelmente não escreverá algo mais eficiente. Isso não quer dizer que você deva usar STL onde uma solução mais simples possa ser possível (por exemplo, usar uma matriz quando você tiver uma quantidade conhecida de coisas, não uma lista stl ::), mas se estiver escrevendo sua própria implementação de um mapa ( a estrutura básica de dados, não o mapa do mundo dos jogos), você está fazendo errado.

STL é um bom ajuste para jogos? Definitivamente. Os jogos são peças complexas de software, o STL fornece recursos que ajudam a gerenciar a complexidade, por isso é bom.

É uma boa opção para sua plataforma? Não necessariamente. Se você está escrevendo para um console, precisa ter muito cuidado com o uso de memória e cache. O STL não torna isso muito fácil.

Penso que, com demasiada frequência, confundimos "jogos" com "jogos em tempo real de alto desempenho que rodam em hardware incorporado ou sob medida", mas é importante fazer uma distinção. Se você está escrevendo um jogo do Windows que não está tentando rodar em tela cheia a 60fps constantes, não há razão para evitar as ferramentas fornecidas pela biblioteca padrão.

Sei que é muito tarde para a festa, mas as mudanças de tempo e as respostas ficam por aqui. O C ++ 11 tem mudanças bastante abrangentes, muitas das quais devem aumentar o desempenho do C ++ e da biblioteca padrão. Parece que aqueles que não usam o STL ou o Boost também tendem a não acompanhar os novos padrões, deixando as soluções em casa sem grandes melhorias, é claro que nem sempre é esse o caso.

Eu usei o STL em todos os projetos, desde meados dos anos 90 até hoje, com exceção de um curto período na EA. Eu acho que o lado anti STL teve algumas razões marginalmente racionais para não usá-lo. Aqueles se foram em grande parte. Alocadores personalizados são uma solução, usar reserva é outra e não passar coisas por valor é uma terceira, mas essas são bem simples e qualquer programador deve saber disso. Mais importante, porém, é o uso de algoritmos. Os escritores do compilador sabem exatamente o que um for_each () faz e pode otimizar o código. Isso não pode ocorrer com um loop inicial. for_each () em um objeto const é ainda melhor. A Microsoft otimiza for_each de várias maneiras, incluindo serialização. Eles também têm a biblioteca AMP que possui parallel_for_each (). Se você tiver uma chance, converse com os engenheiros do compilador sobre isso. Os compiladores de console otimizarão o que é usado, por isso ' um pouco de um problema de galinha e ovo. A Microsoft está ficando muito pesada com o C ++ 11 e o próximo XBox não será diferente. Não tenho ideia do PS4, ainda não conseguimos.

Alocadores personalizados são uma maneira de lidar com o problema de memória, mas outra opção (geralmente ignorada) é usar new e delete com base em classe. Enormes aumentos de desempenho podem ser obtidos dessa maneira.

A noção de que Boost e STL têm uma visão restrita da solução de problemas é pura insanidade. Estou surpreso com quantas coisas no STL e no Boost são personalizáveis ​​por meio de características e políticas. Procure uma comparação independente de maiúsculas e minúsculas como um exemplo.

Em relação aos longos tempos do link e ao inchaço do código, o novo modelo externo deve ajudar com isso. Geralmente, acho que os longos tempos de compilação vêm do excesso de acoplamento e uso indevido do pch.

A razão mais convincente para usar o STL em casa é que existem milhões de pessoas que podem ajudá-lo com o STL. Como sempre, não otimize prematuramente e teste, teste, teste.

Este é um tópico importante no desenvolvimento de jogos. Pessoalmente, não o recomendo, exceto, talvez, pelo EASTL, como mencionado acima. Eu tenho dois problemas principais com o STL (tecnicamente "The C ++ Standard Library", como STL não é mais o nome) nos jogos. 1) A alocação dinâmica de memória geralmente desperdiça muito tempo de execução nos jogos quando o STL é usado. 2) O uso do STL incentiva uma abordagem de matriz de estruturas à arquitetura de jogos, enquanto uma abordagem de estrutura de matrizes é muito mais amigável ao cache.

Depende. Qual é o tamanho do projeto, quais plataformas e qual é o cronograma?

Se você estiver trabalhando em um projeto grande, em plataformas com recursos limitados, com um cronograma e orçamento significativos, poderá poupar muitos problemas evitando o inferno inevitável que estará olhando para meio milhão de linhas de código de linha que é repleto de STL, não pode manter uma taxa de quadros acima de 30, consome RAM suficiente para caber em mais ativos e leva 2 horas para construir.

Em outras situações, no entanto, o STL e até o Boost podem ser muito úteis quando aplicados adequadamente. Trabalhei em títulos que usavam uma seleção de STL / Boost e eram um sonho absoluto de codificar: menos bugs / vazamentos e código de fácil manutenção, mais tempo codificando novos recursos divertidos! Especialmente para projetos de hobby, é uma grande vitória no departamento de motivação.

Saiba quando negociar desempenho por conveniência!

IMHO Eu diria que é um bom ajuste, já que o STL já funciona bem e é otimizado para as tarefas para as quais foi criado. Além disso, você está trabalhando em um jogo, portanto, use as ferramentas que você tem em mãos que tornam sua vida mais fácil e seu código menos propenso a erros.

Por que se preocupar em reinventar a roda quando você pode trabalhar em outra coisa como a IA do jogo, a experiência do usuário ou melhor ainda? teste e depuração?

O STL é absolutamente bom para uso em jogos, desde que você o entenda bem. Nosso mecanismo faz uso extensivo dele e nunca foi um problema. Não tenho nenhuma experiência com desenvolvimento de console, que pode ser uma história totalmente diferente, mas é bem suportada em todas as plataformas de PC (Windows / Mac / Linux).

O mais importante é entender quais são os pontos fortes e fracos de cada tipo de contêiner e escolher o contêiner correto para o trabalho que você está fazendo.

Meu ex-empregador deixou de usar um conjunto robusto de classes de contêineres personalizadas para a STL. Os tempos de construção aumentaram e a facilidade de depuração diminuiu, ambas de maneira bastante significativa. Se estivéssemos começando do zero, o STL (talvez melhor utilizado) provavelmente faria sentido, mas nunca ficou claro para mim que ganhámos algo ao mudar para o STL que justificasse a execução de códigos funcionais, rápidos e depuráveis.

Para meus projetos pessoais, se o STL se encaixa ou não, depende do projeto. Se estou tentando fazer algum trabalho otimizado, orientado a dados, com acesso a memória e cache, ao estilo de Mike Acton, pensarei pelo menos em rolar minhas próprias estruturas de dados personalizadas. Se eu estiver criando um protótipo de alguns algoritmos ou jogabilidade e não me importo com desempenho, escalabilidade, plataforma de destino, etc., pegarei automaticamente o STL.

Meus 2 centavos sobre isso é que o STL funciona muito bem. Estou desenvolvendo um mecanismo de jogo 3D (não de qualidade AAA, mas avançado o suficiente - tipos de entidade com script, renderizador diferido, física Bullet integrada) para PC e ainda não vi os contêineres se tornarem o principal gargalo. O uso incorreto da API 3D e algoritmos ruins foram os melhores alvos (determinados por criação de perfil!) Toda vez que entrei e tentei obter um pouco mais de desempenho.

Eu construí jogos usando STL e gosto, e parece ter um bom desempenho.

Boa pergunta! Uma pergunta mais específica é quais são alguns requisitos comuns que um jogo teria que não podem ser atendidos com STL e Boost.

Na minha experiência, as limitações limitadas de memória do hardware do console tornam qualquer tipo de contêiner de tamanho dinâmico uma má idéia, independentemente de quão inteligente seja seu alocador personalizado. Contêineres sem limites deliberados incentivam os programadores a escrever código que não restringe os limites de seus conjuntos de dados. Dependendo de inúmeras variáveis ​​difíceis de rastrear, você pode exceder as limitações de memória. Tenho um palpite de que essa é uma das principais causas de instabilidade nos jogos modernos.

Além disso, o uso excessivo de modelos pode levar a tempos de compilação muito longos em uma grande base de código e inchará o tamanho do seu executável, para que ele não caiba mais no cache de, digamos, um núcleo auxiliar em um ps3.

No entanto, para o desenvolvimento somente para PC, acho que o STL e o Boost são muito bons. Embora as soluções de casos gerais nem sempre sejam ideais, elas geralmente são boas o suficiente. Sua primeira solução para um problema quase nunca é ideal, e você aprimora ou substitui as inadequações até que sejam boas o suficiente.

O STL é adequado para o seu jogo se o STL for adequado para o seu jogo.

Como em todas as opções de tecnologia feitas durante o desenvolvimento, você precisa avaliar os prós e os contras - rolar minha própria biblioteca me proporcionará um uso, desempenho e produtividade de memória mais benéficos do que simplesmente usar o STL? Possivelmente; embora seja igualmente fácil criar uma vectorimplementação que use mais memória, seja mais lenta e exija grandes quantidades de manutenção para permanecer funcionando em comparação com o que já existe.

As pessoas não devem evitar usar o STL em seus jogos porque outras pessoas evitam usar o STL em jogos; eles devem evitar usá-lo se ponderarem todas as opções e realmente acreditarem que outra implementação melhorará a qualidade de seu produto.

Como na maioria das perguntas, a resposta nunca é "sim ou não", preto ou branco. STL é um bom ajuste para alguns problemas, usá-lo para esses problemas deve ser bom. É um erro supor que é inútil, mas também é um erro supor que é apropriado usá-lo em todas as situações.

O maior problema a ser observado ao usar STL no desenvolvimento de jogos é a alocação de memória. Os alocadores padrão da STL não parecem se encaixar bem nas estratégias de alocação preferidas para o desenvolvimento de jogos. É claro que os alocadores personalizados podem ser usados, mas isso torna a idéia menos atraente se você estiver pensando em adicionar STL a uma base de código não STL.

Adicione a isso que, se sua base de código não for STL, talvez você não tenha ninguém familiarizado o suficiente com STL ou conceitos de modelo para implementar corretamente os alocadores personalizados.

Penso que esta discussão pode ser resumida da seguinte forma:

código específico da aplicação escrito mediocramente <código geral bem escrito <código específico da aplicação bem escrito

Qualquer pessoa cuja solução doméstica se enquadre na categoria 3 certamente sabe a resposta à pergunta original para o seu problema específico. O STL cai na categoria 2. Assim, para alguém que precisa de fazer a pergunta, "deveria eu usar o STL", a resposta é provavelmente sim.

O STL é adequado para uso em um PC, porque seu sistema avançado de memória virtual torna a necessidade de alocação cuidadosa de memória um pouco menos crucial (embora ainda seja preciso ter muito cuidado). Em um console, com recursos de memória virtual limitados ou inexistentes e custos exorbitantes de perda de cache, é provável que você escreva estruturas de dados personalizadas com padrões de alocação de memória previsíveis e / ou limitados. (E você certamente não vai dar muito errado ao fazer o mesmo em um projeto de jogo para PC.)

Eu acho que essa pergunta é realmente uma pergunta não feita maior - devo usar o X no meu Y ? E a única maneira de realmente responder a isso é tentar por si mesmo. Para cada pessoa que encontrar que diz que X funciona muito bem, encontrará alguém que diz que é horrível. E os dois estão certos - para o seu projeto.

O melhor do software, diferentemente da maioria das outras disciplinas, é que você sempre pode mudar as coisas mais tarde, se achar que não está funcionando da maneira que gostaria. Você descobre mais tarde que a STL não está trabalhando para você neste projeto? Rasgue, coloque outra coisa no lugar. Não gosta de como você dividiu os deveres entre seus objetos? Refatorar. Não gosta que você tenha usado objetos? Substitua-os por métodos C retos. Não gosta que tudo seja armazenado em estruturas e métodos para manipulá-los? Substitua-os por objetos C ++.

Eu digo não ao STL. Minha razão é bastante simples:

1. Você não precisa do STL para escrever jogos. Nem mesmo os grandes.
2. O STL aumenta drasticamente o tempo de compilação.
3. Um grande tempo de compilação leva a menos iterações no seu desenvolvimento.

Eu considero a contagem de iterações da mais alta importância, portanto, apenas me afasto da STL e de qualquer outra técnica de desenvolvimento que diminua as iterações (como a arquitetura por causa disso ou as linguagens de script que precisam ser compiladas).

Iterações caras levam a grandes equipes de desenvolvimento de pessoas tentando fazer as coisas com muito pouco de fato acontecendo. Eu já vi e ouvi, e um dos culpados parece ser o tempo de compilação das bibliotecas de modelos.