Escrito por: William W. Wold

Nos últimos 6 meses, eu venho trabalhando em uma linguagem de programação chamada Pinecone. Não chamaria de madura ainda, mas já possui recursos suficientes para ser utilizável, tais como:

• variáveis
• funções
• estruturas definidas pelo usuário

Se tiver interesse na linguagem Pinecone, dê uma olhada na página inicial ou no repositório do GitHub.

Não sou um especialista. Quando comecei com esse projeto, não tinha ideia do que estava fazendo – e continuo sem ter. Nunca tive aulas sobre como criar uma linguagem, apenas li um pouco sobre isso on-line. Também não segui muitos dos conselhos que recebi.

Ainda assim, eu criei uma linguagem nova e ela funcionou. É sinal de que estive fazendo alguma coisa certa.

Neste artigo, vou me aprofundar sobre o assunto e mostrar o pipeline que a Pinecone (e outras linguagens de programação) usam para transformar o código-fonte em magia.  

Também falarei sobre algumas das concessões que fiz e no motivo de haver tomado as decisões que tomei.

Este não é, de modo algum, um tutorial completo sobre como escrever um linguagem de programação, mas é um bom ponto de partida se você tem curiosidade sobre como desenvolver uma linguagem.

Começando

"Não tenho a menor ideia sobre onde devo começar" é algo que escuto muito quando digo que estou escrevendo uma linguagem de programação. No caso de essa ser a sua reação, eu vou passar por algumas decisões iniciais que são tomadas e passos que são dados quando começamos a escrever qualquer linguagem nova.

Compilada x Interpretada

Aqui temos os dois tipos principais de linguagens: compiladas e interpretadas

• Um compilador calcula tudo o que um programa fará, transforma-o em "código de máquina" (um formato que o computador pode executar muito rápido) e depois salva esse código para ser executado mais tarde.
• Um interpretador passa pelo código-fonte linha por linha, descobrindo o que está fazendo no seu caminho.

Tecnicamente, qualquer linguagem pode ser compilada ou interpretada, mas a escolha por um tipo ou outro depende do que geralmente faz mais sentido para aquela linguagem específica. Geralmente, as interpretadas tendem a ser mais flexíveis, enquanto as compiladas tendem a ter alto desempenho. Isso, porém, é apenas o início de um tópico muito complexo.

Dou muito valor ao desempenho. Já percebi a falta de linguagens de programação de alta desempenho que sejam simples. Então, escolhi que a Pinecone seria compilada.

Isso foi muito importante para tomar uma decisão logo de inicio, porque vários designs de linguagem são afetados por isso (por exemplo, tipagem estática é um grande benefício das linguagens compiladas, mas não tanto quanto para linguagens interpretadas).

Apesar da Pinecone ter sido projetada com a compilação em mente, ela tem um interpretador totalmente funcional que, durante um tempo, foi a única forma de executá-la. Lá, veremos diversos motivos para isso, que eu vou explicar mais adiante.

Escolhendo uma linguagem

Eu sei que é um pouco fora do escopo, mas uma linguagem de programação é, em si, um programa. Por isso, você precisa escrevê-la em uma outra linguagem de programação. Escolhi o C++ por causa de seu desempenho e conjunto de funcionalidades. Além disso, eu realmente gosto de programar em C++.

Se você estiver escrevendo uma língua interpretada, faz muito sentido escrever em uma linguagem compilada (como C, C++ ou Swift) porque o desempenho perdido na linguagem interpretada e no interpretador que estará interpretando sua linguagem acabarão se acumulando.

Se está planejando uma linguagem compilada, uma linguagem mais lenta (como o Python ou o JavaScript) podem ser mais aceitáveis. O tempo de compilação pode ser ruim, mas, na minha opinião, isso não é tão importante quanto um tempo de execução longo.

Design de alto nível

Uma linguagem de programação geralmente é estruturada como um pipeline, ou seja, tem vários estágios. Cada estágio tem dados formatados de um modo específico e bem definido, além de ter funções para transformar dados de cada estágio para outros níveis.

A primeira etapa é uma cadeia contendo todo o arquivo de fonte de entrada. A etapa final é algo que pode ser executado. Tudo isso se tornará claro à medida que passarmos passo a passo pelo pipeline da Pinecone.

Lexing

O primeiro passo na maioria de linguagem de programação é o lexing, ou tokenização. "Lex" é a abreviação para lexical analysis (análise lexical, em português), uma palavra muito elegante para divisão de um texto em tokens. A palavra "tokenização" faz muito mais sentido, mas lexer é tão divertido de dizer que uso essa palavra de qualquer maneira.

Tokens

Um token é uma unidade pequena da linguagem. Um token (também conhecido como identificador) pode ser o nome de uma variável ou função, um operador ou um número.

Para que serve o lexer

O lexer deve pegar uma string contendo o código-fonte inteiro e devolver uma lista contendo cada token.

Os estágios futuros do pipeline não farão referência ao código-fonte original, portanto o lexer deve produzir para eles todas as informações necessárias. A razão para este formato relativamente rígido do pipeline é que o lexer pode fazer tarefas como remover comentários ou detectar se algo é um número ou identificador. Você  vai querer manter essa lógica fechada dentro do lexer, tanto para não ter que pensar nessas regras ao escrever o resto da linguagem, quanto para poder mudar esse tipo de sintaxe em um único lugar.

Flex

No dia em que comecei a escrever a linguagem, a primeira coisa que fiz foi um lexer simples. Pouco depois, comecei a aprender sobre ferramentas que supostamente deixariam o lexer mais simples e com menos erros.

A ferramenta que mais ajuda com isso é o Flex, um programa gerador de lexers. Você dá a ele um arquivo que tem uma sintaxe especial para que ele descreva a sintaxe da linguagem. A partir disso, ele gera um programa em C, que cria uma string com o léxico e produz o resultado desejado.

Minha decisão

Optei por manter o lexer que escrevi por enquanto. No fim, eu não vi benefícios significativos em usar o Flex, ao menos não o suficiente para justificar a adição de uma dependência e para complicar ainda mais o processo de build.

Meu lexer tem somente uma centena de linhas de código e me causa muito poucos problemas. Produzir meu próprio lexer também me traz mais flexibilidade, como a capacidade de adicionar um operador à linguagem sem precisar editar diversos arquivos.

Fazendo o parsing

O segundo estágio do pipeline é o parser. Ele transforma uma lista de tokens em uma árvore de nós. Uma árvore usada para o armazenamento desse tipo de dados é conhecida como uma Árvore de Sintaxe Abstrata (em inglês, Abstract Syntax Tree, ou AST). Ao menos na Pinecone, a AST não tem informações sobre tipos ou qual identificador é qual. Ela é simplesmente os tokens estruturados.

Tarefas do parser

O parser adiciona estrutura à lista ordenada de tokens que o lexer produz. Para acabar com as ambiguidades, o parser deve levar em conta os parênteses e a ordem das operações. Fazer o parsing dos operadores, simplesmente, não é algo incrivelmente difícil, mas quanto mais construtos da linguagem são adicionados, mais o parsing pode se tornar extremamente complexo.

Bison

Novamente, precisei tomar uma decisão que envolvia uma biblioteca de terceiros. A biblioteca mais conhecida de parsing é a Bison. A Bison funciona de modo muito parecido com a Flex. Você escreve um arquivo no formato personalizado, que armazena as informações de gramática, e a Bison usa esse arquivo para gerar um programa em C que fará seu parsing. Optei por não usar a Bison, tampouco.

Por que o personalizado é melhor?

Com o lexer, a decisão de usar meu próprio código ficou bastante óbvia. Um lexer assim é um programa simples. Não escrever meu próprio lexer pareceu tão bobo quanto não escrever... bem... meu próprio programa simples.

Com o parser, seria algo bem diferente. O parser da Pinecone neste momento já está em 750 linhas. Eu escrevi três versões de parser diferentes até o momento, pois as duas primeiras eram um lixo.

Eu tomei essa decisão inicialmente por várias razões. Apesar de não ter sido exatamente algo muito fácil de fazer, a maioria dessas razões permanece valendo. As mais importantes são:

• Minimizar a troca de contexto no fluxo de trabalho: a troca de contexto entre o C++ e a Pinecone já é ruim o suficiente sem adicionar a gramática da Bison
• Manter simples o build: sempre que a gramática for mudada, a Bison precisa ser executada antes da build. Isso pode ser automatizado, mas fica chato ao trocar entre sistemas de build.
• Eu gosto de criar coisas legais: eu não fiz a Pinecone porque eu pensei que seria fácil, então para que delegar uma função central quando eu a poderia fazer por minha conta? Um parser personalizado pode não ser trivial, mas é completamente factível.

No começo, eu não tinha muita certeza se eu estava indo por um caminho viável, mas eu ganhei um pouco mais de confiança com o que Walter Bright (o desenvolvedor de uma versão anterior do C++ e criador da linguagem D) disse uma vez sobre o assunto (referência de texto em inglês):

"Um pouco mais controverso era o fato de que eu não deveria me importar com geradores de lexer ou de parser e com outros assim chamados 'compiladores de compilador'. Eles são uma perda de tempo. Escrever um lexer e um parser é uma porcentagem mínima do trabalho de escrever um compilador. Usar um gerador levaria tanto tempo quanto escrever um por conta própria, e associará você ao gerador (o que é importante ao transpor o compilador para uma nova plataforma). Além disso, os geradores têm a reputação infeliz de lançar mensagens de erro péssimas."

Árvore de ações

Agora saímos da área dos termos universais e comuns para entrarmos nos termos que eu já não tenho tanto entendimento. Do meu ponto de vista, o que eu chamo de "árvore de ações" é muito parecido com a IR (intermediate representation, ou representação intermediária, em português) das LLVMs.

Há uma diferença sutil, mas significativa entre a árvore de ações e a árvore de sintaxe abstrata. Levou um tempo até que eu entendesse que poderia até mesmo haver essa diferença entre elas (o que contribuiu com a necessidade de reescrever o parser algumas vezes).

Árvore de ações x AST

De modo simplificado, a árvore de ações é a AST mais o contexto. O contexto são as informações como o tipo que a função retorna ou aqueles dois locais onde uma variável é usada estão usando, de fato, a mesma variável. Como ela precisa descobrir e memorizar todo esse contexto, o código que gera a árvore de ação precisa de muitas buscas nas tabelas de namespace além de outros detalhes.

Executando a árvore de ações

Ao termos uma árvore de ações, executar o código é fácil. Cada nó de ação tem uma função "executar", que recebe uma entrada, faz o que a ação deve fazer (incluindo a possível chamada a uma subação) e retorna o resultado da ação. Esse é o interpretador trabalhando.

Opções de compilação

"Espere aí", você pode dizer, "você não disse que a Pinecone era pra ser compilada?" Sim, é. A compilação, no entanto, é mais difícil que a interpretação. Existem algumas abordagens possíveis.

Criar meu próprio compilador

Essa opção me pareceu boa de início. Eu gosto muito de fazer tudo por minha conta. Fiquei me coçando por uma desculpa para melhorar meu assembly.

Infelizmente, escrever um compilador portátil não é tão fácil como escrever código de máquina para cada elemento da linguagem. Em função do número enorme de arquiteturas e sistemas operacionais, é quase impossível para um único indivíduo escrever o back-end de um compilador multiplataforma.

Até mesmo as equipes por trás do Swift, do Rust e do Clang não se deram ao trabalho de fazer isso por conta própria. Em vez disso, elas usaram a…

LLVM

A LLVM é uma coleção de ferramentas de compilação. Basicamente, é uma biblioteca que transformará sua linguagem em um arquivo binário executável e compilado. Parecia a opção perfeita. Por isso, mergulhei nessa ideia diretamente. Infelizmente, eu não vi a profundidade do lago em que eu estava mergulhando e acabei me afogando.

A LLVM, embora não seja difícil como a linguagem assembly, é uma biblioteca enorme complexa. Ela não é impossível de usar, tem bons tutoriais, mas eu percebi que precisaria de alguma prática antes de conseguir implementar plenamente um compilador para a Pinecone com ela.

Transpilação

Eu queria algum tipo de Pinecone compilada e queria isso rapidamente. Parti, então, para um método que eu sabia que poderia fazer com que isso desse certo: a transpilação.

Eu escrevi um transpilador de Pinecone em C++, adicionando a ele a capacidade de compilar automaticamente a origem do resultado com o GCC. Isso funciona, de fato, para quase todos os programas em Pinecone (embora existam alguns casos de exceção que causam erros no transpilador). Não é uma solução particularmente portável ou escalável, mas funciona por enquanto.

Futuro

Se assumirmos que eu continuarei a desenvolver a Pinecone, ela receberá suporte de compilação da LLVM mais cedo ou mais tarde. Suspeito que, não importando o quanto de trabalho eu dedique a ele, o transpilador nunca será inteiramente estável – além disso, os benefícios da LLVM são diversos. É apenas uma questão de quando eu terei tempo de fazer alguns projetos iniciais na LLVM até dominá-la bem.

Enquanto esse tempo não chega, o interpretador é ótimo para os programas simples e a transpilação em C++ funciona para a maioria dos casos que necessitam de mais desempenho.

Conclusão

Espero ter tornado linguagens de programação um pouco menos misteriosas para você. Se você quiser criar uma por conta própria, é algo que eu recomendo imensamente. Existem milhares de detalhes de implementação a serem descobertos, mas a descrição aqui deve ser suficiente para dar seu primeiro impulso.

Aqui vai meu conselho para quem está começando (mas lembre-se: eu não sei muito bem o que estou fazendo ainda, então aceite o conselho com toda a precaução possível):

• Se estiver em dúvida, escolha a linguagem interpretada. Linguagens interpretadas são geralmente mais fáceis de projetar, criar e aprender. Não é tentar impedir você de escrever uma linguagem compilada se você sabe bem o que quer fazer. Porém, se estiver em dúvida, escolha a interpretada.
• Quando o assunto for lexers e parsers, faça o que quiser. Existem argumentos válidos a favor e contra escrever seus próprios programas. No fim, se perceber que seu design e implementação fazem tudo de modo racional, não importa a escolha.
• Aprenda com o pipeline que eu acabo de descrever. Houve muita tentativa e erro na criação do pipeline que eu tenho nesse momento. Tentei eliminar ASTs, ASTs que viram árvores de ações, bem como outras ideias horríveis. Esse pipeline funciona. Então, não o altere, a menos que tenha uma ideia muito boa.
• Se não tiver tempo nem motivação para implementar uma linguagem de propósito geral e complexa, experimente implementar uma linguagem esotérica, como a Brainfuck (texto em inglês). Esses interpretadores podem ter apenas umas cem ou duzentas linhas.

Eu tenho muito pouco do que me arrepender em termos do desenvolvimento da Pinecone. Fiz algumas escolhas ruins no caminho, mas reescrevi a maior parte do código afetada por esses erros.

Agora, a Pinecone está em um estado bom o suficiente para funcionar bem e pode ser facilmente melhorada. Escrever a Pinecone foi um aprendizado e tanto para mim, além de uma experiência bastante agradável, e eu estou apenas começando.

Escrito por: YK Sugi

Olá a todos! Meu nome é YK e, atualmente, sou o responsável pelo CS Dojo, um canal de educação em programação no YouTube com mais de 200 mil inscritos. Também já fui desenvolvedor de software na Google (texto em inglês).

Duas das perguntas mais comuns que meu público me faz são:

"Qual a diferença entre os cursos de Ciência da Computação e Engenharia de Software?"

E…

"Devo escolher Ciência da Computação ou Engenharia de Software se eu quiser ser um engenheiro de software"

Nesse artigo, eu vou responder a isto e dar minha própria análise rápida sobre esses cursos.

Uma rápida visão geral dos dois cursos

• Ciência da Computação é o estudo de como os computadores funcionam, a maioria sob a perspectiva teórica e da matemática.
• Você deveria escolher Ciência da Computação se você gosta de matemática, lógica, ou se quiser entrar em um campo especializado da Ciência da Computação, como inteligência artificial, aprendizagem de máquina, segurança ou na área gráfica.
• Engenharia é o estudo de como os sistemas de software são construídos, incluindo tópicos como gestão de projetos, garantia de qualidade e testes de software.
• Você deve escolher a Engenharia de Software se estiver mais interessado na abordagem prática e se quiser aprender sobre o ciclo de vida em geral, sobre como o software é construído e mantido.
• Tanto a Ciência da Computação como a Engenharia de Software ensinam fundamentos de programação e ciência da computação. Então, você pode escolher qualquer dessas opções para se tornar um desenvolvedor de software.

Para entender a diferença entre as áreas da Ciência da Computação e da Engenharia de Software, vamos dar uma olhada nos respectivos currículos na Universidade de Waterloo, no Canadá.

Escolhi a Universidade de Waterloo para isso porque é um dos melhores programas de Ciência da Computação da América do Norte.

Perspectivas de trabalho

Vamos primeiro comparar os tipos de trabalhos e estágios que você pode ter através cada programa.

Felizmente, o site da Universidade de Waterloo dispõe de vários exemplos.

Para cada área, aqui estão alguns dos títulos que os ex-alunos detêm, e onde eles trabalham:

Ciência da Computação

• Desenvolvedor para a web/arquiteto, The Steele Group
• Programador, Harry Rosen Inc.
• Computação em nuvem/dispositivos móveis, Clearbridge Associates Limited
• Engenheiro de software, General Dynamics Canada
• Engenheiro desenvolvedor de software, Microsoft
• Engenheiro agile, Pivotal Labs
• Analista de négocios, Canadian Tire Corporation
• Consultor de desenvolvimento, Google
• Gerente de produtos, Dropbox

Engenheiro de Software

• Desenvolvedor de software, Tagged Inc
• Desenvolvedor de software, IBM Canada
• Gerenciador de software, Arius Software Corporation
• Engenheiro de software, VistaPrint USA
• Engenheiro de software, Harris Corporation
• Desenvolvedor de software, Accenture Inc.
• Gerente técnico de produtos — Designer de software e desenvolvimento , NexJ Systems Inc
• Consultor, PureFacts Financial Solutions
• Consultor de implementação, Desire2Learn

Como pode perceber, não há uma grande diferença entre os tipos de trabalhos que você pode ter.

O emprego mais comum que os graduados obtêm após receberem seu diploma de Ciência da Computação ou de Engenharia de Software é o de desenvolvedor ou engenheiro de software.

Existem também outras opções relacionadas, tais como gerente de produtos, analista de garantia de qualidade e consultor em tecnologia. Suas opções dependerão de seu conjunto de habilidades específicas.

Primeiro ano:

Agora, vamos dar uma olhada nos cursos obrigatórios de cada programa. Vamos primeiro comparar alguns dos cursos que você precisaria fazer em seu primeiro ano.

Ciência da Computação

• CC 135 — Projeto de programas funcionais
• CC 136 —  Projeto de algoritmos e abstração de dados
• Matemática 135 — Álgebra
• Matemática 136 — Álgebra linear 1
• Matemática 137 — Cálculo 1
• Matemática 138 — Cálculo 2
• Além de algumas eletivas

Engenharia de Software

• CC 137 — Princípios de programação
• CC 138 — Abstração e implementação de dados
• MATH 115 — Álgebra linear para engenheiros
• MATH 117 — Cálculo 1 para engenheiros
• MATH 119 — Cálculo 2 para engenheiros
• MATH 135 — Álgebra para o bacharelado em matemática
• ECE 105 — Física da engenharia elétrica 1
• ECE 106 — Eletricidade e magnetismo
• ECE 124 — Circuitos e sistemas digitais
• ECE 140 — Circuitos lineares
• SE 101 — Métodos de engenharia de software

Como você pode ver, os cursos do primeiro ano também são bastante semelhantes. Ambos cobrem alguns assuntos fundamentais de ciência da informação, e alguns assuntos da matemática em álgebra linear e cálculo.

A única grande diferença é que a Engenharia de Software tem componentes adicionais de física e engenharia elétrica, enquanto a Ciência da Computação tem mais algumas eletivas.

Curso após o primeiro ano:

E quanto aos cursos obrigatórios e opcionais após o primeiro ano? Vamos dar uma olhada em diversos exemplos aqui:

Ciência da Computação

• MATH 239 Introdução à combinatória
• Estatística 230 Probabilidade
• Estatística 231 Estatística
• CC 240 Estruturas de dados e gerenciamento de dados
• CC 241 Fundamentos de programas sequenciais
• CC 245 Logica e computação
• CC 246 Desenvolvimento de software orientado a objetos <- não exigido para a área de Engenharia de Software
• CC 251 Designer e organização de computadores
• CC 341 Algoritmos
• CC 350 Sistemas operacionais
• Além disso, várias eletivas de Ciência da Computação

Engenharia de Software:

• CHE 102 Química para engenheiros
• ECE 222 Computadores digitais (inclui linguagem Assembly)
• ECE 358 Redes de computadores
• MATH 213 Matemática avançada para Engenheiros de Software
• MATH 239 Introdução à combinatória
• STAT 206 Estatísticas para engenheiros de software
• MSCI 261 Economia da engenharia: gestão financeira para engenheiros
• CC 241 Fundamentos de programas sequenciais
• CC 240 Estruturas de dados e gerenciamento de dados
• CC 247 Princípios de engenharia de software <- não é necessário para a área de Ciência da Computação
• CC 341 Algoritmos
• CC 349 Interface de usuário <- não é necessário para a área de Ciência da Computação
• CC 343 Programação concorrente e paralela <- não necessário para a área de Ciência da Computação
• CC 348 Introdução a gestão de bancos de dados
• ES 212 Logica e computação
• ES 350 Sistemas operacionais
• ES 465 Testes de software e garantia de qualidade
• ES 464 Design de software e arquitetura
• ES 463 Especificação e análise de requisitos de software
• ES 490 Design de projetos
• Além disso, algumas eletivas de Ciência da Computação e da Engenharia Elétrica

São MUITAS informações para assimilar, mas aqui está o resumo

Quando se trata dos requisitos em matemática e estatística, a Ciência da Computação e a Engenharia de Software são quase idênticas. Ambas abrangem combinatória, probabilidade e estatística.

Os principais requisitos da ciência da computação também são similares, abrangendo algoritmos, estruturas de dados e sistemas operacionais.

As diferenças principais são:

• A Engenharia de Software tem mais requisitos em engenharia elétrica e fundamentos de engenharia de software, tais como testes de software, projetos e especificação de requisitos de software.
• A Ciência da Computação permite mais eletivas em disciplinas de Ciência da Computação de nível superior. Você pode escolher entre uma ampla variedade de tópicos como segurança, fundamentos de engenharia de software, visão computacional, aprendizado de máquina e gerenciamento de banco de dados.

Então, qual você deveria escolher?

Acho que isso depende principalmente da suas preferências. Em resumo:

• Você deveria escolher Ciência da Computação se você gosta de matemática, lógica, ou se quiser entrar em um campo especializado da Ciência da Computação, como inteligência artificial, aprendizagem de máquina, segurança ou na área gráfica.
• Você deve escolher a Engenharia de Software se estiver mais interessado na abordagem prática e se quiser aprender sobre o ciclo de vida em geral, sobre como o software é construído e mantido.

Mas espere — qual dos cursos, então? Qual é melhor se você quer ser um engenheiro de software?

Bem, aqui vai minha opinião. Nessa universidade específica (Universidade de Waterloo), com esse conjunto específico de requisitos do programa, a Ciência da Computação é um curso melhor se você deseja ser um engenheiro de software.

Apenas por simplicidade, vamos supor que você esteja esperando conseguir um dos empregos mais bem-pagos (cerca de U$ 100.000/ano) como engenheiro de software na América do Norte. Estes empregos são normalmente em grandes empresas de software (pense na Microsoft, Google, Amazon etc.) ou em empresas de médio porte, de alto crescimento (pense na Dropbox, Lyft, Snapchat, Pinterest etc.).

Tipicamente, o que eles procuram em candidatos a engenheiro de software é a habilidade de escrever códigos sólido e de construir projetos interessantes, bem como os fundamentos da Ciência da Computação, incluindo estruturas de dados e algoritmos.

Acho que a melhor maneira de ter este conjunto de habilidades é aprender rapidamente os fundamentos da ciência da computação e passar seu próprio tempo praticando a resolução de problemas e a escrita de códigos.

Com base no currículo de Engenharia de Software e no quanto os estudantes de engenharia tendem a estar ocupados em geral, acho que seria mais difícil fazer isso com Engenharia de Software do que com Ciência da Computação.

Outro benefício deste programa particular de Ciência da Computação é que ele permite mais eletivas em Ciência da Computação. Isto também é ótimo porque, dependendo do que estiver em demanda no mercado de trabalho, você será capaz de ajustar seus cursos. Por exemplo, se o desenvolvimento de aplicativos para dispositivos móveis estiver em demanda, você poderá aprender a fazer isso. E se a computação paralela estiver em demanda, você pode se concentrar nisso no lugar dos aplicativos móveis.

Tenho certeza de que há alguns benefícios na aprendizagem de fundamentos de engenharia de software (gerenciamento de projetos, design, testes etc.). Mas eu, pessoalmente, preferiria ter flexibilidade com relação a um conjunto pré-definido de habilidades. É por isso que eu acho que a Ciência da Computação é uma área melhor para se tornar um engenheiro de software com este currículo em específico.

Claro, esta é apenas minha opinião, e essa é apenas uma universidade em particular. Eu adoraria saber a sua opinião e como foi sua experiência se você se formou em Ciência da Computação ou em Engenharia de Software.

Algumas observações

Observação 1: Universidades diferentes têm exigências diferentes para estas duas áreas de habilitação principal. Este artigo deve ser um bom ponto de partida, mas você ainda deve dar uma olhada nos requisitos do programa na universidade que você está interessado em frequentar.

Observação 2: Algumas universidades não possuem sequer uma especialização em Engenharia de Software. Por exemplo, a Universidade de British Columbia, em Vancouver, tem graduação em Ciência da Computação e Engenharia de Computação, mas não em Engenharia de Software. No entanto, os dois cursos têm uma área focal em engenharia de software dentro de seu programa de Ciência da Computação, bem como no de Engenharia da Computação.

Se a universidade na qual você está interessado não tiver uma especialização em Engenharia de Software, eu escolheria a Ciência da Computação, se você quiser se tornar um desenvolvedor de software. A Engenharia da Computação é mais focada em hardware do que em Ciência da Computação ou em Engenharia de Software, portanto está menos diretamente relacionada com o trabalho típico de um desenvolvedor de software.

Essas são as principais fontes que usei:

• Ciência da Computação na Waterloo
• Engenharia de Software na Waterloo

Obrigado pela leitura e boa sorte escolhendo sua universidade e sua especialização!

Escrito por: Angela He

Há dois anos, eu era uma estudante do ensino médio de apenas 17 anos que não sabia nada sobre programação. De qualquer forma, eu segui em frente e, alguns meses depois, publiquei meu primeiro jogo na Steam.

Neste momento, já tenho criados mais de 10 jogos para desktop, web e dispositivos móveis, que já foram jogados, combinados, mais de 1,9 milhão de vezes.

Não importa seu nível de habilidade, você também pode fazer um jogo. Há dois anos, pensei ser impossível, mas tentei mesmo assim. Foi a coisa mais difícil que eu já tinha feito. Mas deu certo. Agora, percebo que o desenvolvimento de jogos é como qualquer outra habilidade - somente se progride fazendo, errando e melhorando.

Ensinei a mim mesma tudo o que sei. Agora, é o momento em que eu vou ensinar você.

Para fazer um jogo, você deve passar pelo os seis estágios do desenvolvimento de jogos: Design. Arte. Programação. Áudio. Polimento. Marketing.

O resto da minha publicação será estruturado de acordo com os tópicos abaixo:

• Conselhos que juntei aqui sobre minha experiência e a de outros desenvolvedores.
• Recursos que descobri que podem ser bastante úteis.

1. Design

Conselho

Você teve uma grande ideia.

Agora, como pode registrá-la por escrito?

Todos terão sua própria maneira de fazer isso da melhor maneira possível. Alguns redigem documentos de design de 60 páginas. Outros, como eu, escrevem uma página de notas de mal escritas, que outras pessoas terão dificuldade de entender. Não sei qual a melhor maneira para você, mas posso dar algumas sugestões sobre o que escrever a respeito:

• Gancho. O que faz com que a ideia para um jogo seja ótima? Para mim, essa é a coisa mais importante de se escrever. Uma vez captada, os próximos três pontos podem ser escritos facilmente. O seu jogo é estimulante? Escandaloso? É uma reviravolta para um clássico antigo? Ou é algo que nunca foi feito antes?
• Mecânica. O que o jogador faz? E qual o propósito do que ele faz? Esse é o seu jogo. Pode ser simples como apertar Q-W-O-P para se mover pelo jogo chamado QWOP ou tocar em botões para conversar em Mystic Messenger, ou podem ser combos de teclas em Dwarf Fortress.
• Estória. Que estória deveria fazer com que os jogadores lembrassem do seu jogo? Que emoções eles deveriam sentir ao sair do jogo? Todo jogo tem uma estória. Se ela não for uma estória óbvia, é criada pelo jogador. Uma estória pode ser criada a partir de números crescentes em 2048, o nascimento de um império em Civilization ou interações silenciosas em Monument Valley. Pense a estória que será encontrada em seu jogo.
• Clima. Que impressão o seu jogo deixa no jogador? Como é o visual? Sons? A primeira impressão é importante. A primeira impressão capta — e depois mantém — o jogador no jogo.  Talvez, você dê ao seu jogo uma vibe retrô, com gráficos pixelados e músicas de chiptune ou um visual moderno e limpo, com geometria planas e música instrumental.

* Está com problemas de chegar em uma boa ideia? O bloqueio criativo é algo que atinge a todos.

• Participe de um hackathon/jam de jogos. Você e outros participantes serão testados a fazer um jogo em um curto espaço de tempo. Durante, e depois, você terá o suporte de outros jammers. E a empolgação e a criatividade que se vê durante a jam são contagiantes. Não sabe por onde começar? Experimente o Ludum Dare, um dos maiores jams de jogos.
• Mantenha uma lista de ideias. Eu e outros desenvolvedores que eu conheço anotamos ideias. Dessa maneira, podemos voltar às nossas ideias antigas quando ficamos sem ideias novas.

Quando a inspiração vier, pare tudo o que está fazendo. Anote a ideia. A próxima vez em que a criatividade desaparecer, você não estará perdido.

Recursos

Todos os recursos abaixo foram provados e comprovados. (*) representa um recurso que eu uso atualmente.

Para anotações:

• Notes para o Mac (*)
• Google Docs (*)
• Trello

Para colaboração (em equipes):

• Google Drive
• GitHub (*). Requer o git e o .gitignore do Unity.
• Unity Collab. O mais fácil entre os três. A versão gratuita, porém, possui limitações.

Atenção - o Unity é o mecanismo de jogos que eu uso para fazer jogos, por isso vou mencioná-lo em todo o processo. Fique à vontade para experimentar um mecanismo diferente.

Para design de jogos:

• The Art of Game Design, de Jesse Schell
• Game Developer.com

2. Arte

Conselho

Você planejou sua ideia. Parabéns, isso é incrível. Agora você pode trabalhar no jogo de fato.

(Se você não sabe como programar, sugiro que faça a fase 3, Programação, antes da Arte. Você não quer criar um jogo que será descartado porque não consegue programar.)

Não sabe como desenhar? Não se preocupe. Qualquer um pode fazer algo bonito com os 3 princípios visuais básicos: cor, forma, espaço (texto em inglês).

UI

Pense em como você pode tornar a UI única — ter uma color distinta, fonte(s), forma(s) e ícone(s) — desde que seja funcional. As informações importantes são legíveis e óbvias? As cores/fontes/ícones distraem da ideia principal?

Animações 2D

Voce têm duas opções:

• Frame a frame. Desenhe os frames da animação. Para isso, você deve usar sprite sheets com TexturePacker (ou, se estiver usando Unity, o Sprite Packer)
• Baseada em esqueletos. Desenhe cada membro animado, depois anime a posição do membro, a rotação e tudo mais que estiver dentro do jogo. Pode ser mais rápido, mais fácil e economizar memória. Se estiver sendo feito em 2D e usando o Unity, tente editar os pivôs dos sprites ou usar o Anima2D.

Dicas gerais

Aqui estão algumas dicas gerais sobre arte diversa que se aplicam não apenas à arte em jogos, mas também a outros softwares.

• Imagens com padrões em bloco (em inglês, tiles) criam imagens em mosaico e economizam a memória.

• Imagens de 9 fatias ou trechos (9-patch/9-slice, em inglês) com bordas não dimensionáveis, mas com um centro dimensionável para criar imagens dimensionáveis e economizar memória.

• Faça das dimensões de cada imagem um múltiplo de 4 ou uma potência de 2 para economizar memória. A escolha dependerá de como você está comprimindo os recursos.
• Se estiver usando o Photoshop, use "Arquivo > Exportar > Camadas para Arquivos" para exportar rapidamente um arquivo (por exemplo, em PNG, ou JPEG).

Recursos

Criação da UI:

• Photoshop (*).
• Sketch.

Princípios de UI:

• Google Material Design (*) (em inglês).
• Apple’s UI Do’s and Don’ts  (em inglês).

Criação de imagens em 2D:

• Photoshop (*).
• Gimp.
• Paint Tool SAI. Boa para estilos suaves/de anime.

Criação de imagens em 3D:

• Blender (*). Muito bom, mas com uma curva de aprendizagem bem difícil.
• Maya. Bom para animação.
• Max. Bom para renderização.

Recursos gratuitos:

• Behance (*). Fontes + ícones + outros designs.
• KennyNL. Arte para UI/2D/3D prontas para jogos de alta qualidade.
• Open Game Dev Art. Grande biblioteca de arte gerada por usuários.

Inspiração:

• Dribbble. Designs apenas para designers convidados.
• Behance (*). Designs para qualquer um que tiver uma conta.
• itch.io (*). Lindos jogos indie.

3. Programação

Conselho

Debug.Log("Ai, não! Hora de programar!! ^_^");

Seu primeiro passo? Decidir o mecanismo de jogo e uma IDE (Integrated Development Environment — basicamente, um aplicativo que permite a você programar). Minha recomendação de mecanismo de jogo + IDEs está nas fontes abaixo.

Seu segundo passo? Programar.

Não sabe como programar? Eu entendo. Mas saiba que você pode aprender.

Esses fundamentos de Ciência da Computação devem ser o suficiente para começar (todos os exemplos de códigos aqui são em C++, uma das principais linguagens que o framework de desenvolvimento de jogos 3D da Unity utiliza).

1) Tipos de dados e variáveis. Na raiz de todo código estão os dados. Esses dados são armazenados em variáveis. Você pode declarar uma variável assim:

int i = 0;

Vamos por partes:

int é o tipo de dado. i é o nome da variável. E o = 0 atribui um zero como o valor da variável.

E quanto a isso?

string s = "pusheen é o melhor gato do mundo";

string é o tipo de dado. s é o nome da variável. E, sim — você adivinhou — "pusheen é o melhor gato do mundo" é o valor da variável.

Alguns tipos comuns de dados: int e long são números inteiros. float e double são números decimais. E strings são frases (mesmo em uma string vazia — "").

Quer saber mais? Leia isto e isto (textos em inglês).

2) Instruções com if. Instruções com if avaliam se uma determinada condição é verdadeira. Se for, o código que está dentro da instrução if é executado:

if (true){ //true é sempre avaliado como verdadeiro!

    fazerCoisas(); //Estou dentro das chaves da instrução if; serei executado!
}

Se uma condição não for verdadeira, podemos validar outra condição com else if:

int i = 1;

if (i == 0){ 

   fazerCoisas(); 
}
else if (i == 1){

   fazerOutrasCoisas(); //eu serei executado porque i não é 0!
   
}

Ou, simplesmente, executar um outro código com else:

int i = 60000;

if (i == 0){

  fazerCoisas(); 
  
} else {

  fazerOutrasCoisas(); //eu ainda serei o bloco executado.
  
}

3) Laços for/while. Laços while continuam enquanto uma certa condição for verdadeira, executando o mesmo código repetidamente. Quando a condição não for verdadeira, o laço é interrompido.

while (someBool == true){ //condição

   fazerCoisas(); //seguirei fazendo coisas enquanto someBool não for false
   
}

Pense: quanto tempo esse loop dura?

while (true){

  fazerCoisas();
  
}

Laços for são basicamente laços while onde:

int i = 0;
while (i < condicao){ 

    fazerCoisas();
    
    i++; //aumentar i após fazer coisas
}

Equivale a:

for (int i = 0; i < condicao; i++){

    fazerCoisas();
}

4) Estruturas de dados básicas. Em seguida, temos os dados e formas de manipular esse dados.  Podemos também armazenar esses dados em algumas estruturas - uma estrutura de dados. As estruturas de dados que você deveria conhecer são arrays, listas, filas, pilhas e sets  (textos em inglês).

Aqui temos um exemplo rápido de array:

/*
Suponha que você tenha os números de 0 a 9 e que deseja guardá-los em algum lugar. É possível armazená-los em um array!
*/
int[] arr = new int[10]; 
/*
Os colchetes [] declaram um array.Atribuímos um novo array a arr, de tamanho 10 - isso significa que ele pode receber 10 elementos. Arr agora tem essa aparência:

arr = [ 0 0 0 0 0 0 0 0 0 0 ]
*/
for (int i=0; i<10; i++){

    arr[i]=i; //Atribuímos seja qual for o valor de i ao i-ésimo índice do arr.
    
//Você sabia que os índices das estruturas de dados começam em 0?
}

/*
Depois de executar o laço for, nossa estrutura de dados de array terá essa aparência!
arr = [ 0 1 2 3 4 5 6 7 8 9 ]
*/

Para solidificar seus conhecimentos dos passos 2 ao 4, leia isto (texto em inglês).

5) Funções e exceções. Funções são basicamente pequenas linhas de códigos que representam muito mais código. Por exemplo, se você chamar:

comerPao();

E comerPao() tiver este conteúdo:

void comerPao(){ //<---essa é uma função. 

   paoComido=true;
   
   printf("Já posso sentir os carboidratos aumentando");
   
}

Ao chamar comerPao(), na verdade, estamos chamando as duas instruções dentro da função comerPao().

Se você fizer algo de errado em seu código, uma exceção pode ser projetada. Eles são erros vermelhos e raivosos que estão lá para dizer: Ei, volte aqui! O que você fez ali em cima não funciona logicamente. Vá lá e revise.

Para aprender mais sobre funções, vá aqui; para aprender sobre exceções, vá aqui (textos em inglês).

Há outras coisas que você precisa saber:

6) Linguagem. Em qual linguagem você vai programar? C++? JavaScript? C#? Toda linguagem é escrita um pouco diferente e pode permitir que você faça coisas diferentes.

7) API (Application Programming Interface). Depois de saber o básico, você terá que aprender sobre a API específica de seu mecanismo de jogos. As APIs são essencialmente uma coleção de objetos poderosos envolvidos em classes e funções  simples que você pode chamar. As APIs tornam a vida mais fácil, muito mais fácil.

Por último:

8) Veja um exemplo de projeto em seu mecanismo de jogo escolhido: Unreal e Unity têm milhares de exemplos de projetos gratuitos. Isso permite que você descubra como tudo é unificado. Além disso, você pode criar a ideia do seu jogo a partir do projeto (meu primeiro jogo foi criado a partir de Corgi Engine)

if (voce.chegouAteAqui()==true){
  muitoOrgulhosa=true;
  voce.conseguiu(); //HUMOR NO MOMENTO: MELHOR IMPOSSÍVEL⭐⭐
  
}

Para encorajar: Eu sei. Programar é assustador no início. Nada faz sentido, você está constantemente indo de encontro a obstáculos, e provavelmente quer desistir em função das falhas e exceções. Não significa que você é ruim em programação. Programação é um desafio. É compreensível se sentir incapaz no começo.

Isso, porém, leva tempo, como qualquer outra habilidade. Vai ficando fácil. Vai ficando divertido (ao menos, ficou para mim).

Conceitos importantes sobre a programação de jogos (referências da seção em inglês):

• Orientação a objetos. Faz a programação parecer mais natural.
• Convenções de nomeclatura. Nomeie suas classes, métodos e variáveis como algo que obviamente transmite seu propósito. Por exemplo, uma função de ataque corpo a corpo (melee, em inglês) deve ser denominada meleeAttack(), não mA() ou protectbutalsoattack(). Você (e outros que lerem seu código) deverão saber o que está acontecendo.
• Decomposição. Coloque o código que se repete em uma função separada. Chame aquela função em vez de duplicar repetidamente aquele código.
• Padrão de projeto Singleton. Permite que dados de diversos sejam armazenados em um único lugar.
• Prevenção de estática. Além dos singletons, eu evitaria fazer variáveis estáticas - sua vida é a vida útil do jogo, elas são mais lentas e podem ter comportamentos inesperados no editor.
• Padrão de projeto Observer. Permite que os acontecimentos que dependem de outro não desperdicem o tempo do computador verificando esse último.

Questões importantes especificas do Unity (referências da seção em inglês):

• Co-rotinas. IEnumerators e Coroutines permitem que você comece a fazer coisas e continue fazendo-as por algum tempo e, então, pare. Eu os usava o tempo todo: para explosões de efeitos visuais; para o movimento de interpolação linear; para esperar que uma cena seja carregada antes de obter os objetos da cena, entre outros.
• ScriptableObject. Contêm dados com menos sobrecarga do que os MonoBehaviors.

Recursos

Mecanismos de jogos (referências da seção em inglês):

• Faça seu próprio. Requer C/C++. De baixo nível (realmente, baixo).
• Unity (*). 2D/3D. Requer Javascript/C#. Nível médio. Multiplataforma.
• Unreal Engine. 2D/3D. Requer C++. Nível médio. Multiplataforma. Observação: o suporte a 2D não é muito bom.
• pixi.js (*). 2D. Requer Javascript. Nível médio. Web.
• GameMaker Studio. 2D/3D. Requer o GML. Nível iniciante. Multiplataforma.
• Corona. 2D. Requer Lua. Nível iniciante. Multiplataforma.

IDEs:

• Visual Studio Code (*). Para o MacOS. Não me dá nenhum atraso e tem características incríveis, exclusivas do VSCode (tais como informações de referências in-line e navegação rápida - com ⌘T).
• Visual Studio (*). Para Windows.
• MonoDevelop. Vem com Unity. Costuma ter lag.

Recursos gratuitos do Unity (referências da seção em inglês):

Para o Unity, existem muitos recursos livres na Unity Store, no GitHub, no Bitbucket e em outros sites. Eu costumo usar ao menos dois em cada projeto. Facilite sua vida com esses recursos, mas perceba que eles não são perfeitos. Se você detectar erros, não hesite em consertá-los e/ou sinalizar para os desenvolvedores.

• TextMeshPro (*).
• LeanTween (*).
• Fungus.
• Corgi Engine.
• Dialogue System.
• Post Processing Stack.
• Keijiro Takahashi. Funciona com o Unity. Tem projetos de efeitos visuais do Unity de código aberto incríveis!

Por último, mas não menos importante, minha solução nº 1 para problemas de programação: Google!

4. Áudio

Conselho

Primeiro: Você quer áudio?

O áudio pode fazer milagres em termos de imersão e ambientação (texto em inglês), mas o custo pode ser em termos da memória.

Se a resposta é sim, qual áudio?

Vai incluir música? Efeitos sonoros?  Narração ou dubladores?

Para qualquer uma das alternativas acima, grave e faça a remixagem de modo que combine com a ambientação do seu jogo. Por exemplo, Bastion usa sons bucais orgânicos e instrumentais, combinando com o mundo do jogo. Crypt of the Necrodancer usa uma mistura de sons eletrônicos e chiptunes para combinar com o jogo colorido e rítmico.

"A imersão é tudo!"

-Darren Korb, Supergiant Games

Se o seu áudio não combina com a ambientação do jogo, ele pode prejudicar a imersão. Como seu áudio vai combinar com o seu jogo?

Recursos

Ferramentas de áudio:

• Logic Pro. U$ 200. Somente para o MacOS .
• FL Studio (*). U$ 99 a 899. Tem demonstração gratuita.
• Reaper. U$60 a 225.
• Audacity (*). Grátis . Capacidades limitadas. Útil para a limpeza de áudio.

Geradores de efeitos sonoros retrô (referências da seção em inglês):

• Chiptone.
• Bfxr.
• Leshy SFMaker.
• as3sfxr.

Sons gratuitos:

• Soundcloud (*). A Soundcloud tem milhares de joias maravilhosas regidas pela Creative Commons (CC). Aqui você vê uma playlist para começar. Certifique-se de fornecer a atribuição se necessário.
• Incompetech (?). Música regida pela CC. É preciso atribuir.
• Bensound. Música regida pela CC. É preciso atribuir.

5. Polimento

Conselho

Nossa! Você chegou até aqui! Que incrível (é sério - se chegou tão longe, eu gostaria de saber sobre o seu game. Me mande mensagem, quando puder)!

Tudo concluído, certo?

Bem, tem uma probabilidade de 99,99999% de ter bugs.

Esse é momento para se fazer testes para ver se tem bugs.

Testando para ver se há bugs no seu jogo

1. Consiga outras pessoas — você não vale — que joguem o seu jogo. De preferência, na sua frente, porque se eles encontrarem algum bug, podem não perceber ou ter dificuldade de descrever.
2. Jogue-o em todas as plataformas de destino. O jogo pode funcionar no editor, mas será que funciona onde é importante? Para o Linux e as diferentes versões do Android, especialmente, acho que as coisas ficam um pouco confusas.

Certo. Você encontrou um bug. O que fazer agora?

1. Verifique o console para ver se há exceções. Encontrou alguma? Ótimo! Encontre o arquivo e o número da linha onde a exceção foi lançada. Se a exceção parecer algo muito maluco, procure-a no Google e aprenda sobre ela. Então, descubra por que esse número de linha está causando essa exceção.
2. Continua sem entender? Escreva para o console. Comece a solicitar registros em log nos locais que você acha que podem estar causando o problema. Imprimir no console os valores de variáveis e veja se o que é impresso é o esperado. Caso contrário, conserte o problema.
3. Quando o pior acontece, verifique os logs. Os logs do seu projeto vão dar mais informações do que o console. Leia as linhas finais onde a exceção ocorre. Pesquise tudo o que você não sabe no Google. Consegue resolver o problema agora?
4. Durma. Isso vai ter se resolvido pela manhã. Afinal, é apenas um sonho ruim., certo?

Erros comuns:

• NullReferenceException.

var.fazerCoisa(); //throws NullReferenceException: Object reference not set to an instance of an object

Problema: você esta fazendo algo com uma variável nula (inexistente).

Solução rápida: verifique se a variável é nula antes de fazer isso.

if(var != null)
    {
        var.fazerCoisa(); // faça isso com segurança!
    }

• SyntaxErrorException.

Problema: seu código tem uma sintaxe inválida.

Solução rápida: Na mensagem de Exceção, deve estar o caractere que está causando o erro. Altere-o.

Observação: se o caractere tem aspas duplas, certifique-se de usar as aspas retas no lugar das aspas curvas.

• Tela rosa ou preta.

Problema possível: Algum sombreamento não conseguiu renderizar.

Possíveis causas: você está usando um shader 3D para um jogo 2D ou está usando algum recurso de shader sem suporte no sistema operacional de destino. Certifique-se de usar shaders de dispositivos móveis para jogos nesses dispositivos.

Depois de terminar de eliminar os erros, faça os ajustes finais de seu jogo otimizando o uso de memória e o desempenho. Isto fará com que o download seja mais rápido e aquecerá menos os dispositivos de quem o jogar.

Dicas gerais de otimização (referências da seção em inglês)

• Estabeleça a taxa de quadros de destino. A taxa de quadros pode ser de 20 para uma visual novel ou de 60 para um jogo de tiro em primeira pessoa. Uma taxa de quadros inferior ao padrão permite que o jogo gaste menos tempo renderizando quadros.
• Animação / partículas / abate de oclusão. O abate significa que as coisas que não estão visíveis na câmera não são renderizadas. Os personagens só serão animados, as partículas só serão atualizadas e os modelos 3D só serão renderizados quando estiverem à vista.

• Comprimir texturas e áudio. Comprima texturas irregulares. Faça o streaming da música e descomprima os efeitos sonoros ao carregar. Diminuir a qualidade do áudio. Note que a compressão pode ou não diminuir a qualidade dos recursos de forma perceptível.
• Pooling de objetos. Evite instanciar e destruir muitos objetos ao mesmo tempo para evitar enormes picos. Em vez disso, agrupe-os em uma lista, fila ou outra estrutura de dados. Coisas como balas devem ficar em grupos de objetos.
• Não deixe que os raycasts batam em coisas que não precisam de input. Os raycasts são como pequenos raios que disparam de seus dedos ou do mouse toda vez que você toca a tela ou clica no mouse. Remova objetos que não reagem a essas entradas dos cálculos de raycast.

Se você quiser um desafio (referências da seção em inglês):

• Otimização de shaders. Dê a cada renderizador um material. Isto economizará recursos no início, já que o jogo não tem que criar novos materiais para tudo. O shader para o material inclui apenas o que é funcionalmente necessário (por exemplo, um botão que não precisa de mascaramento pode usar um shader de sprites em seu lugar).
• No Unity, use AssetBundles em vez de Resources. O AssetBundles economizará a memória buscando no armazenamento on-line (por exemplo, no DropBox) ou local (por exemplo, no disco rígido). No entanto, eu não tentei muito essas questões devido à documentação ruim.

Recursos (referências da seção em inglês)

Todos eles são do Unity, mas podem ser aplicáveis a outros mecanismos (todos em inglês).

Scripts:

• Optimização de scripts em jogos do Unity (*)

Arte:

• Um guia para otimizar a Unity UI (*)
• Guia prático de melhores Recursos de Arte (*)

Memória:

• Reduzir o tamanho de arquivo da sua build (*)
• Memória

Específicos das plataformas:

• Guia prático de otimização para dispositivos móveis (*)
• Considerações de desempenho do WebGL (*)
• Considerações de memórias ao focar o WebGL (*)
• Os sete estágios de otimização da Olly's para VR de dispositivos móveis

6. Marketing

Conselho

Parabéns! Você fez um jogo. É o momento de mostrar para o mundo o que você fez.

Pessoalmente, o marketing é o meu maior indutor de ansiedade. Se você, também, tem muitas dúvidas, a comunidade de desenvolvedores de jogos é superútil. Você não está só nisso. E chegou tão longe - pode muito bem chegar até o fim, certo?

Você nunca saberá se será um sucesso, a menos que tente.

1. Esboço. Crie esboços da pagina do seu jogo em todas as suas plataformas de destino de distribuição do jogo. Encontre uma lista de plataformas na parte de Recursos abaixo.
2. Faça o networking. Se você for até o fim no networking, vai querer enviar um e-mail para a imprensa especializada, exibir o jogo em festivais e participar de conferências.

Para a imprensa especializada, envie por e-mail a página não listada do seu jogo uma semana antes do lançamento. Dê às pessoas algum tempo para escrever sobre ele. É provável que elas não escrevam sobre ele de forma alguma. Descobri que a imprensa adora uma história atraente de desenvolvedores, um conceito único/controverso e, o mais importante, um presskit.

Como você encontra os e-mails? Você pode...

1. Encontrar escritores que você gosta e buscar pelo nome deles. O e-mail deles com certeza aparecerá em algum lugar: no Twitter, no LinkedIn etc. Ou...
2. Encontre o e-mail geral da revista/empresa de notícias na página Sobre do site deles. Normalmente, está no formato dicas@empresa.com.

Não envie um e-mail para a imprensa sobre seu jogo se eles não cobrirem explicitamente seu gênero/plataforma direcionada.

Festivais podem dar prêmios/ou reconhecimento profissional por outros desenvolvedores e pela impressa especializada.

As conferências são o que você faz delas: elas podem ter a ver apenas com networking com outros desenvolvedores, empresas e imprensa (vá e ofereça seus cartões de visita); elas podem ser para atualizar seu conhecimento em desenvolvimento de jogos com o que há de mais recente; para jogar os jogos dos outros; ou para encontrar-se com os amigos da Internet.

Os ingressos para as conferências de jogos são caros. Se você é um estudante, pense em solicitar bolsas de estudo para eles. O programa IGDA Scholars dá a você algumas oportunidades especialmente incríveis de networking e de presença em eventos.

3. Youtubers/Streamers. Você pode obter cobertura em vídeo de seu jogo por:

1. Classificação alta em plataformas de distribuição de jogos.
2. Envio de e-mails. Se você enviar um e-mail, não fale de si mesmo; fale sobre o jogo. Mantenha a mensagem gentil, breve e convincente. Use fotos e gifs que chamem a atenção.

Como você encontra os e-mails? Veja a página Sobre dos sites das pessoas e empresas. Se você não conseguir encontrá-los por lá, procure-os no Google e veja se suas outras mídias sociais o têm.

4. Redes sociais.

As redes sociais são uma ferramenta de marketing incrível. Agar.io começou a sua ascensão no 4chan, Butterfly Soup recebeu um impulso fenomenal no Twitter (textos em inglês) e algumas formas de redes sociais acabam sempre no meu top 4 de referências:

Minhas redes sociais favoritas para marketing estão listadas abaixo, em Recursos.

Uma última observação — editora ou publicação própria? Fazer marketing dos jogos é pesado demais. Você quer que uma editora se encarregue de tudo isso? Quer ir pela rota de Hotline Miami da Devolver Digital, ou contar com o boca a boca de Farmville e de Doki Doki Doki Literature Club?

Com uma editora, você terá que fazer sua pesquisa para encontrar uma boa. Em seguida, você assinará a papelada e passará por várias questões legais. Além disso, é um enorme investimento financeiro.

Sozinho, você terá que dedicar muito tempo e esforço para aprender marketing. Você pode adorar. Você pode odiar. E você também pode não fazer um bom trabalho. No entanto, é grátis e você aprende habilidades valiosas.

No meu caso, eu sempre publiquei por conta própria. Eu adoro aprender coisas novas. Além disso, acredito firmemente que um jogo realmente grande será bem-sucedido, não importa o que aconteça, desde que algum esforço de marketing tenha sido feito.

6. Hora de apertar o botão de Publicar!

Quê? Você chegou ao final, mesmo? Viva! Agora, relaxe, sente-se, pegue uma bebida deliciosa e reserve um tempo para si mesmo! Você trabalhou muito e merece um descanso!

E lembre-se de que, mesmo que seu jogo não tenha a recepção que você esperava, tudo bem. Não vai ser perfeito na primeira vez. Meu primeiro jogo na Steam tem apenas 255 downloads.

O importante é que você fez um jogo. Você aprendeu muito e isso já é o suficiente.

E há sempre uma próxima vez!

Recursos (referências da seção em inglês)

Plataformas de distribuição de jogos:

• Steam (?). PC. Requer U$ 100 de taxa por jogo.
• Origin. PC.
• GOG. PC. Publicação grátis. O jogo deve ser aceito.
• Mac App Store. MacOS. Exige conta Apple Developer.
• itch.io (*). PC/Web. Publicação grátis.
• Game Jolt (*). PC/Web. Publicação grátis.
• Armor Games (*). Publicação grátis. É preciso se candidatar como desenvolvedor.
• Kongregate (*). Web. Publicação grátis.
• Newgrounds (*). Web. Publicação grátis.
• GitHub (*). Web. Publicação grátis em seu próprio site com nome de domínio formatado como "___.github.io".
• Amazon. Web/Mobile. Publicação grátis.
• Google Play (*). Dispositivos móveis. Exige uma taxa única de U$ 25.
• iOS App Store (*). Dispositivos móveis. Exige uma conta de Apple Developer.

Imprensa de jogos:

• IndieGames.
• Siliconera.
• FreeGamesPlanet. Ótima administração.
• PCGamer.
• Kotaku.
• Rock Paper Shotgun.
• Polygon.
• Giant Bomb.
• EuroGamer.

Festivais de jogos:

• Independent Games Festival (IGF). Data limite por volta de outubro.
• Indiecade. Data limite por volta de maio/junho.
• Swedish Game Awards. Data limite por volta de julho.
• South by Southwest Festival (SXSW). Data limite por volta de dezembro.
• The Game Awards. Data limite por volta de novembro.

Conferências de jogos:

• Game Developer’s Conference (GDC). San Francisco.
• Penny Arcade Expo (PAX). Seattle/Boston/Philadelphia/Melbourne.
• Electronic Entertainment Expo (E3). Los Angeles.
• Tokyo Game Show. Japão.
• Steam Dev Days. Seattle. Somente para desenvolvedores da Steam.

Envio de e-mails:

• presskit()

Redes sociais:

• Reddit (*). Escolha um subreddit apropriado. Alguns dos meus favoritos são /r/WebGames, /r/IndieGaming/ e /r/visualnovels.

• Facebook (*). Publique em sua página do Facebook (se você tiver uma) e em seu Facebook pessoal (se você se sentir confortável com isso). Há também vários grupos do Facebook onde você pode exibir seu jogo! Aqui estão alguns:

GameDev Show and Test
Indie Game Developers
Indie Game Promo

• Tumblr (*).
• Twitter (*). Tente usar tags como #gamedev, #indiedev e #screenshotsaturday para ser descoberto.

Comunidade:

• /r/gamedev (*).
• Ludum Dare (*).
• Indie Game Devs (*).

Conclusão

Não há cheat code que facilite criar um jogo. É apenas muita determinação e esforço.

"Atrás de cada Half Life, Minecraft e Uncharted, há OCEANOS de sangue, suor e lágrimas."

— Ken Levine

Você vai ficar confuso. Vai cometer erros. Você pode até chorar (eu chorei - e ainda choro).

Mas está tudo bem. Significa que você está evoluindo. Se você está se esforçando para fazer dar certo, eu acredito em você e no seu jogo: Você pode fazer acontecer.

Se você gostou de ler meu primeiro artigo, não se esqueça de recomendá-lo para todos que puder. Seria muito legal!

Você também pode me seguir/me enviar mensagens no Twitter, no Tumblr e no GitHub. Também pode me pagar um café, se preferir.