O Desenvolvimento de Jogos em Base Livre e Open Source
Rodrigo M.Lehnemann1 João Ricado Bittencourt2
Universidade do Vale do Rio dos Sinos1
Universidade do Vale do Rio dos Sinos2
Figura 1: Logo dos programas: Visual Code, Libre Office, Make Human, Piskel, Audacity, Blender, Ubuntu, Krita, Godot, Kdenlive, Lmms e
Awesome Bump.
RESUMO
O presente trabalho apresenta uma proposta de metodologia
de desenvolvimento de jogos baseada nos modelos
utilizados pela comunidade de desenvolvimento de Software
Livre e Open Source, assim como um apresenta um conjunto
de ferramentas Open Source e gratuitas, que permitem a um
desenvolvedor indie iniciante zerar os custos de
licenciamento de Software na produção de um jogo digital. O
trabalho está essencialmente dividido em cinco grandes
seções, apresentação dos conceitos de Software Livre e
Open Source, apresentação de um conjunto completo de
ferramentas de desenvolvimento, apresentação da
metodologia de desenvolvimento de jogos e resultados
obtidos.
Palavras-chave: game development, open source, free
software.
1. Introdução
Este artigo apresenta uma proposta de metodologia de
desenvolvimento Livre e Open Source que busca
potencializar as metodologias atuais de desenvolvimento de
jogos, assim como reduzir seus custos tornando mais fácil o
ingresso de novos desenvolvedores a indústria de jogos
nacional e internacional.
Além de sua abordagem empírica, que faz uso do diário de
desenvolvimento como instrumento de coleta de dados,
apresenta-se uma caracterização da filosofia de Software
Open Source segundo a Open Source Definition, proposta
pela Open Source Initiative[2] e da filosofia do Software
Livre, segundo a Free Software Fountadtion[5], sendo
ambas as organizações de referência no assunto, assim
como a relação do software livre com a cultura criativa e a
cybercultura. Também está inclusa uma lista de ferramentas
de desenvolvimento que seguem essas filosofias e que
contemplam todas as necessidades do processo de
desenvolvimento de jogos.
Todos os dados são analisados de forma comparativa,
relacionando o material produzido com as experiências
prévias do autor dentro do contexto de desenvolvimento de
jogos, assim como uma análise referente a reação da
comunidade de desenvolvimento de jogos frente a presente
metodologia, análise essa obtida através de questionários e
da interação de desenvolvedores em fóruns online
direcionados ao desenvolvimento de jogos.
2. Justificativa
Com o crescimento da comunidade de desenvolvedores de
jogos, como parte do movimento de expansão da cultura livre
e da cybercultura, cada torna-se cada vez mais necessário o
olhar sobre as metodologias de desenvolvimento, assim
como a necessidade da desconstrução de certos conceitos
relacionados qualidade e produtividade de ferramentas e
metodologias e Livres e Open Source frente as suas contra-
parte proprietárias.
A indústria de desenvolvimento de software em geral têm
cada vez mais demonstrado uma abertura maior às
iniciativas comunitárias propostas pelos movimentos Livre e
Open Source, como evidenciado por D.Simioni[8] ao notificar
a recente parceria entre a Microsoft e a Canonical. No
entanto parece que o desenvolvimento de jogos segue
justamente um caminho contrário. Com um número muito
menor de iniciativas e produtos distribuídos sob licenças
permissivas ou recíprocas, assim como pela forte presença
de softwares proprietários nos ambientes de
desenvolvimento de jogos.
Desta forma este trabalho justifica-se como uma tentativa
de propor uma metodologia de desenvolvimento Livre e
Open Source a comunidade de desenvolvedores de jogos,
evidenciando suas possibilidades e potencialidades, tanto
referentes à qualidade final dos produtos, tempo e custo de
desenvolvimento.
3. Cultura Criativa e Cybercultura
Conforme evidencia A.Lemos[7], o compartilhamento e a
produção colaborativa são a base daquilo que conhecemos
por cultura. Sendo o Software Livre a vanguarda do
movimento copyleft que descentraliza a produção não
apenas de software, mas de todo o conteúdo midiático,
tornando o consumidor também um produtor daquilo que
consome.
Desta forma conforme aponta F.Kon, N.Lago, P.Meirelles
e V.Sabino[1], o que temos por cybercultura ou cultura
criativa, é de certa forma uma reapropriação dos serviços,
um movimento de descentralização dos produtores em
massa, que favorece o surgimento de serviços e produtos
que são desenvolvidos pelos próprios consumidores, tais
como o Uber, Canais do Youtube, Blogs entre outros.
No entanto essas mesmas transformações vividas em
outros setores e outras áreas da computação, parece não
ser algo presente na indústria de jogos. Ferramentas como
DRM’s, que tentam defender a legitimidade do produto a
ponto de prejudicar a experiência do usuário, conforme
evidencia P.Guilherme[8], ou a forte adesão a metodologia
de desenvolvimento baseada em uma metodologia de
“catedral” são evidências que indústria dos jogos parece
resistir a cybercultura e manter-se no padrão das mídias
massivas do século passado.
4. O Mundo Livre
Segundo afirma F.Kon, N.Lago, P.Meirelles e V.Sabino[1],
no início tudo era livre, antes da era windows e dos micro-
computadores a programação e a produção de softwares era
uma ciência estudada e compartilhada livremente em
universidades e em seguida no meio empresarial.
Mas com o tempo a visão comercial da época e as
demandas de mercado fizeram surgir o que hoje chamamos
de software proprietário ou software fechado, que nada mais
é que uma programa desenvolvido e mantido por uma
empresa que tem seu código fonte restrito. Sendo que seus
usuários tem únicamente a liberdade de usá-lo e em alguns
casos, apenas para determinados fins.
E foi da insatisfação de Richard Stallman e do trabalho de
Linus Torvalds que surgiram os movimentos de Software
Livre e Software Open Source, com a criação do eco-sistema
GNU e do Kernel Linux. Mas em meio a todas as ideologias
envolvidas em ambos os movimentos é necessário antes de
mais nada determinar o que exatamente é um Software
Open Source e o que é Software Livre.
4.1 Definição de software Livre
Segundo a Free Software Fondation[5], para que um
software seja considerado livre ele precisa conceder ao
usuário através de sua licença quatro liberdades:
0. Liberdade para executar o programa
1. Liberdade para estudar e modificar o programa.
2. Liberdade para redistribuir o programa.
3. Liberdade para melhorar e redistribuir as melhorias ao
programa.
4.2 Definição de software Open Source
Segundo os critérios determinados pela Open Source
Initiative[4]. Para um software ser considerado Open Source
ele precisa ter mais que seu código fonte aberto, ele
necessita seguir os seguintes critérios:
1 - Livre Redistribuição. Sua licença não pode restringir
ninguém, proibindo que se venda ou doe o software a
terceiros. A licença não pode exigir que se cobre o
pagamento de royalties ou outros valores, embora tal
pagamento não seja proibido.
2 - Código-Fonte. O programa precisa obrigatoriamente
incluir código-fonte e permitir a distribuição tanto do código-
fonte quanto do programa já compilado. Quando o produto
não é distribuído junto com seu código-fonte, é necessário
que uma forma de se obter o seu código-fonte seja
anunciada publicamente de uma forma fácil de se obter,
preferivelmente através de download gratuito da Internet.
3 - Obras Derivadas. A licença deve permitir modificações
e obras derivadas e deve permitir que essas modificações
sejam redistribuídas dentro dos mesmos termos da licença
original.
4 - Integridade do Código do Autor. A licença pode proibir
que se distribua o código-fonte original modificado desde
que, neste caso, a licença permita a distribuição de arquivos
de diferenças (patch files) contendo o código fonte que foi
modificado. A licença deve então explicitamente permitir a
distribuição do software construído através das modificações
do código fonte original. A licença pode exigir que esses
trabalhos derivados usem um nome ou número de versão
diferente do software original.
5 - Não Discriminação Contra Pessoas ou Grupos. A
licença não pode discriminar contra pessoas ou grupos. Por
exemplo, a licença não pode proibir que um programa seja
distribuído para pessoas residentes em um determinado
país.
6 - Não Discriminação Contra Áreas de Utilização. A
licença não pode restringir os usuários de fazer uso do
programa numa área específica. Por exemplo, não pode
proibir que o programa seja usado para fins comerciais, ou
para fins militares, por mais nobre que esta última possa ser.
7 - Distribuição da Licença. Os direitos associados ao
programa através da licença são automaticamente
repassados a todas as pessoas às quais o programa é
redistribuído sem a necessidade de definição ou aceitação
de uma nova licença.
8 - Licença Não Pode Ser Específica a um Produto. Os
direitos associados a um programa não dependem de qual
distribuição em particular aquele programa está inserido. Se
o programa é retirado de uma distribuição, os direitos
garantidos por sua licença continuam valendo.
9 - Licenças Não Podem Restringir Outro Software. A
licença não pode colocar restrições em relação a outros
programas que sejam distribuídos junto com o software em
questão. Por exemplo, a licença não pode exigir que todos os
outros programas distribuídos no mesmo pacote sejam
também software aberto.
10 - Licenças Devem Ser Neutras em Relação a
Tecnologias. Nenhuma exigência da licença pode ser
específica a uma determinada tecnologia ou estilo de
interface.
4.3 Distinção entre software Open Source, Livre e
gratuito
Por muito tempo o Software Open Source e o Software livre
foram tratados como sendo a mesma coisa, segundo relatam
F.Kon, N.Lago, P.Meirelles e V.Sabino[1] em seu histórico, o
Software Open Source foi concebido ser uma nova
abordagem do Software Livre, tornando-se mais atrativo
para a iniciativa privada, movimento esse que foi repudiado
pela Free Software Foundation, gerando assim um equívoco
que levaria anos para começar a ser desfeito, que é
justamente o fato de se dizer que Software Livre e Software
Open Source são a mesma coisa. Segundo os conceitos
abordados por G.Stefanuto, J.De Lucca, A.Alves[3], Open
Source Initiative[4], Free Software Foundation[5] e
D.Simioni[6]. Um software gratuito não será
necessariamente um software Open Source ou Livre,
apenas terá sua distribuição feita de forma gratuita, da
mesma forma que um software Open Source ou Livre
também não tem em momento algum a obrigatoriedade de
ser gratuito.
Existe uma diferença entre as filosofias que caracterizam
um software Livre e um Open Source. A filosofia do primeiro
baseia-se em quatro liberdades e exige que todos os códigos
que compõe um software sejam integralmente Livres,
enquanto a filosofia do segundo permite que programas
sejam compostos por códigos de diferentes licenças,
inclusive códigos proprietários e fechados. Da mesma forma
o primeiro movimento visa ser algo mais idealista e libertador
enquanto o segundo mais comercial e focado em
produtividade.
5. Liberte-se! As vantagens do Software Livre e Open
Source
Quando o assunto é software livre e open source, a
vantagem mais evidente é a justamente o custo. Dada a
natureza como a maioria dos projetos open source e livre são
construídos e conduzidos a maior parte desses softwares
tente a ser gratuito ou com custos muito menores que os
valores de um software proprietário equivalente.
Porém é justamente quando falamos do uso de
ferramentas livres e open source na produção de jogos
digitais que muitos argumentos, vantagens e desvantagens
presentes em outras classes de software mudam. A primeira
dela é em questão da comunidade, as comunidades de
usuários de ferramentas como game engines estão repletas
de usuários dispostos a socializar soluções e ajudar com
dúvidas, indiferentemente do fato de serem proprietários ou
não. A exemplo dos fóruns de Unity 3D, Unreal Engine e
CryEngine, que apesar de serem ferramentas proprietárias
suas comunidades em nada deixam a desejar frente a
comunidades Linux.
Outro ponto importante fica por questão da garantia, onde
o inverso também ocorre. Dado o estilo de licenciamento
dessas ferramentas, a maioria delas, mesmo sendo
proprietária não oferece um serviço de suporte ou garantia,
sendo essa necessidade geralmente suprida pela
comunidade ou vendida separadamente.
Salvas essas diferenças, os demais argumentos ainda são
válidos para esse tipo de ferramenta e muitas vezes o
principal argumento para se usar um ferramenta proprietária
é a “segurança” que uma empresa responsável dá ao
usuário, garantindo que a melhoria e resolução constante de
problemas. No entanto esse argumento cai por terra quando
vemos a real situação do software proprietário.
Justamente por estar coligado a uma empresa, o
desenvolvimento e manutenção do software é mantido
enquanto houver interesse da empresa em manter o projeto
ativo. Um exemplo fica por com do motor de jogo Stingray
desenvolvido e publicado pela Autodesk que foi
descontinuado pouco tempo depois de seu lançamento. Ou
do motor de jogo Xenko que foi abandonado pela antiga
mantenedora a Silicon Studios tendo seu código aberto a
comunidade.
Há também o fato de os interesses da empresa
sobreporem aos interesse do usuário final, como pode ser
visto no caso da PUBG Corps vs Epic Games, onde a
desenvolvedora (PUBG Corps) publicou o jogo Player
Unknown Battlegrounds, jogos este que resultou em um
grande sucesso, mas poucos meses depois foi ultrapassado
pelo game Fortnite produzido pela empresa desenvolvedora
do motor de jogo usado para o desenvolvimento do Player
Unknown Battlegrounds, e que segundo afirma a PUBG
Corps gozou de atualizações e melhorias não distribuídas
previamente para a comunidade de desenvolvedores.
Por fim é importante levantar o seguinte questionamento,
ferramentas proprietárias também estão sucetíveis a bugs,
que podem prejudicar o produto final. E a questão é: quando
o usuário encontrar um problema gerado pelo motor, até que
ponto esse problema é responsabilidade do desenvolvedor e
até que ponto é responsabilidade da desenvolvedora da
ferramenta? E como justificar para o consumidor final que tal
bug possa não vir a ser corrigido devido ao fato de
ferramenta ter seu código fechado?
Trabalhar com ferramenta livres e open source trás
diversas vantagens em relação ao software proprietário, o
primeiro é justamente o acesso ao código fonte o que
permite ao desenvolvedor justamente alterar e personalizar
a ferramenta caso seja preciso. Aleḿ disso a
interoperabilidade entre ferramentas livres é maior, desta
forma torna-se mais fácil e efetivo mover uma imagem do
Gimp para o Blender e do Blender para a Godot Engine por
exemplo, do que seria se toda a base fosse proprietária, pois
não requer negociações de parcerias comerciais entre as
empresas para que tais funcionalidades sejam
implementadas, visto que muitas vezes os formatos de
arquivos importados e exportados por essas ferramentas
também são proprietários e fechados. Por fim é importante
afirmar que como são as necessidades da comunidade que
ditam os rumos do projeto, é muito menos propício aos
projetos livres ou Open Source desenvolverem rivalidades
que podem existir entre grandes empresas mantenedoras de
softwares proprietários.
5.1 Ferramentas de Desenvolvimento
Dadas todas as considerações e justificativas para a escolha
das licenças de desenvolvimento, apresenta-se agora quais
ferramentas de desenvolvimento Livres ou Open Source,
gratuitas podem ser aplicadas ao desenvolvimento de jogos,
pois como aponta F. Mizutani[3], as filosofias Open Source e
Livre podem muito bem ser um novo caminho para o
desenvolvimento de jogos, frente ao crescente custo na
produção de games, especialmente os de grande porte
(triplos A). A lista completa de ferramentas e o valor
economizado está exposto na Tabela 1.
● Ubuntu: O primeiro software selecionado é a base de
toda a estrutura, o sistema operacional. Para este trabalho
foi selecionado o sistema operacional Linux através da
distribuição Ubuntu, essencialmente por se tratar da
distribuição Linux mais utilizada na data, o que garante uma
comunidade ativa e aberta.
 No entanto, um de seus contras fica justamente em sua
curva de aprendizagem, pois o programa trabalha com
diversas filosofias de usabilidade que o afastam de outros
programas similares, tornando a adaptação ao Blender mais
complicada para quem já sabe modelar com outro software.

Imagem 1: Interface do Ubuntu.

● Only Office: A escolha do Only Office como pacote office

padrão, deve-se a três critérios: alta compatibilidade com
arquivos criados com o MS Office, similaridade de uso com o
MS Office e estabilidade. O programa oferece os três
principais serviços de um pacote office, sendo um editor de
textos, um editor de apresentações e um editor de planilhas
Imagem 4: Interface do Blender.
eletrônicas.
● Piskel: Este software possui uma finalidade bastante
específica, não sendo necessariamente aplicável a todo e
qualquer tipo de projeto. Sua principal função é desenvolver
pixelart, sprites e animações nesse estilo, sendo bastante
funcional e prático.

Imagem 2: Interface do Only Office.

● Godot Engine: Esta ferramenta é um motor de jogo que

encontra-se em sua terceira versão. Ele apresenta
funcionalidades modernas em seu renderizador 3D, como
Physically Based Rendering e Global Illumination. Sua
linguagem nativa é muito similar ao Python e sua curva de
aprendizagem caracteriza-se como suave. O motor é capaz
de compilar para as plataformas Windows, Linux, Mac,
Android, IOs entre outras.
Imagem 5: Interface do Piskel.
● Krita: Mantido pela Krita Foundation, este programa
segue uma linha de desenvolvimento muito similar a do
Blender. O Krita é um software para edição e tratamento de
imagens, ele apresenta recursos e facilidades que o tornam
bastante competitivo frente a softwares proprietários como
Adobe Photoshop, apresentando resultados formidáveis.

Imagem 3: Interface da Godot Engine.

● Blender: Mantido pela Blender Foundation, trata-se de

um modelador 3D, capaz de desenvolver modelagem
poligonal e orgânica. Com o Blender é possível desenvolver
qualquer tipo de modelo 3D ou render com uma qualidade
equiparável a de qualquer outro modelador proprietário
como Maya ou 3DS Max.
Imagem 6: Interface do Krita.
● Visual Code: É uma IDE de programação mantida pela
Microsoft. Seu uso em substituição ao Visual Studio
Community só se torna justificável devido ao fato de que a
Godot Engine possui uma IDE de programação integrada, o
que minimiza a necessidade de uma IDE específica para
programação. É necessário ter em mente que o Visual Code
não possui recursos e funcionalidades que o tornem capaz
de fazer frente ao Visual Studio Community, mas dado a
subutilização de uma IDE desse tipo dentro do contexto
proposto, ele tem a capacidade de atender todas as
necessidade do projeto.
● Awesome Bump: Este software tem uma usabilidade
muito específica, mas que se enquadra facilmente em quase
qualquer tipo de projeto 3D, que é a produção de mapas de
textura. Apesar de ser pouco intuitivo, o Awesome Bump tem
resultados similares aos de softwares proprietários como o
Substance B2M.

Imagem 10: Interface do Awesome Bump.

Imagem 7: Interface do Visual Code.
● Audacity: É um software para edição e tratamento de
áudio que possui funcionalidades e efeitos capazes de
satisfazer as necessidades vindas durante a produção de um
game. Seu uso é bastante intuitivo e sua curva de
aprendizagem é suave.
● Kdenlive: Este software é um editor de vídeos, ele entra
na mesma linha de softwares como Adobe Premiere e Sony
Vegas Movies Pro, permitindo uma edição de vídeos por
faixas. É válido lembrar que o objetivo do Kdenlive é auxiliar
na produção de trailers e materiais promocionais, sendo
pouco usado no processo de desenvolvimento do jogo em si.

Imagem 11: Interface do Kdenlive.

● Natron: Um editor de vídeo com funções similares ao

Adobe After effects.

Imagem 8: Interface do Audacity. Software Livre Software Custo em US$

● LMMS: Diferentemente do Audacity, o LMMS não é um Proprietário *sem taxas
software de edição e tratamento de som e sim um software Ubuntu 18.04 Windows 10 pro 199,99
de composição e criação de melodias, que segue a mesma Only Office 5 Microsoft Office 229,99
linha de softwares como Fruit Loop Studio. Godot 3.0.6 Unity 2017.1 1500,00 /ano
Blender 2.79 Maya LT 245,00 /ano
Piskel Aseprite 19,00
Krita Photoshop 2017 239,88 /ano
Pinta Paint.net 0,00
Visual Code Visual Studio 0,00
Community 2017
Audacity Sony Sound Forge 399,95
LMMS Frutty Loop Studio 199,00
Awesome Bump Substance B2M 3 149,00
MakeHuman Fuse 0,00
Kdenlive Sony Vegas Movie 898,00
pro
Natron After Effects 300,00 /ano
Imagem 9: Interface do LMMS.
 4379,81
Economia Total por Estação de
Trabalho no 1º Ano:
2184,88
Economia Total por Estação de
Trabalho após 1º Ano:
Tabela 1: Lista completa de softwares e a economia final por
estação de trabalho
6. O Estábulo e o Bazar, metodologia de
desenvolvimento de jogos com código livre / open
source
Em a A Catedral e o Bazar E.Raymond[2] compara a
produção e desenvolvimento de Software proprietário a
construção de uma grande catedral, edificada por um seleto
grupo de mestres artesões longe dos olhos de um grande
público. Enquanto o desenvolvimento de um Software Livre
ou Open Source é algo mais similar ao agitação de um bazar,
com centenas de pessoas socializando conhecimentos e
ideias.
No entanto embora esse comparativo seja válido para a
indústria de jogos, ele não é completamente assertivo, pois
diferente de projetos como o Windows, 3Ds Max ou
Photoshop um jogo digital não almeja ser tão longevo, com
exceção de jogos do tipo massive multi-player online tendo
em geral apenas um ou dois anos de suporte e
manutenção. Assim sua filosofia de desenvolvimento e
publicação é diferente, enquanto um Software tradicional
almeja ser o mais funcional possível (ou o minimamente
funcional em alguns casos), o jogo digital além de funcional
precisa ser atrativo, divertido e propor uma bela experiência
ao usuário vendo o máximo possível em um curto período
de tempo.
Da mesma forma os sistemas de monetização propostos
pelas iniciativas livres (geralmente baseado na venda
suporte técnico e treinamento), não se aplicam a maioria dos
casos quando tratamos de jogos, visto que excetuando-se
dos e-sport’s e jogos essencialmente competitivos, os
demais usuários provavelmente não se interessariam em
jogar um jogo onde seja necessário a contratação de um
profissional para ensiná-lo como jogar.
Assim dessa forma torna-se mais interessante comparar
as grandes publicadoras a estábulos, repletos de grandes
cavalos de corrida (jogos) que são cuidadosamente criados
e tratados por especialistas a portas fechadas, aguardando o
momento de sua corrida onde disputarão entre si a atenção
do público.
No entanto cuidar e treinar esses “grandes garanhões de
corrida” tem se mostrado caro e arriscado com o passar do
tempo. Conforme as tecnologias gráficas evoluem, a
espectativa e a exigência do público também cresce, sendo
assim cada vez mais a produção de um jogo se mais cara e
os riscos mais altos, o que faz com que grandes estúdios
evitem assumir o risco de um projeto mais ousado e
diferente, preferindo manter-se em uma zona de conforto. Da
mesma forma os desenvolvedores indies, dotados de
criatividade e coragem para assumir tais riscos, muitas
carecem de recursos para desenvolverem seus projetos o
que certamente os coloca em desvantagem em relação ao
grande produtoras.
A saída no entanto é mais simples do que parece:
precisamos sair do estábulo e nos colocarmos junto ao
bazar.
7. Free não é Free, comercializando jogos em GPL
Imagem 12: Fluxograma do desenvolvimento de um software
segundo a metodologia do bazar, proposta por E.Raymond[2],
fonte (FABERLUBENS).
A ideia de desapego provocada por um projeto Open Source
ou Livre pode ser algo incômodo a maioria dos
desenvolvedores, estamos falando de uma indústria focada
em inovação e novas experiências, onde uma boa ideia em
geral é defendida com unhas e dentes e guardada a sete
chaves até momento de seu lançamento.
No entanto é necessário entender que o desapego ao
código e a produção colaborativa são essenciais para a
indústria de jogos independentes, pois permitiria aos
pequenos desenvolvedores a possibilidade de produzir
produtos e projetos com um nível altíssimo de qualidade,
pois como aponta E.Raymond[2], um projeto com o mesmo
porte do Linux e quão a mesma qualidade, dificilmente
poderia ter sido desenvolvido de outra forma, ao ponto que
ainda é possível proteger sua propriedade intelectual e
preservar o direito de venda, mesmo abrindo o código do
jogo.
E o caminho para a produção de jogos livres está
justamente naquilo que os difere dos demais softwares; arte,
som e enredo. Produzir um software livre ou open source é
mais do que compartilhar o código e sim difundir o
conhecimento produzido ao longo da produção, de forma
que o próximo desenvolvedor não necessite re-inventar a
todos os processo já desenvolvidos.
Um exemplo para esse tipo de situação pode ser visto no
que se refere aos controladores de câmera, o
posicionamento da câmera de um jogo é um dos pontos mais
cruciais de qualquer design ou projeto de desenvolvimento.
Pois além de influenciar toda a experiência e controles de um
jogo, uma câmera mal posicionada ou pouco funcional
certamente irá destruir a experiência do usuário indiferente
da qualidade do restante dos elementos do game. Ainda
assim encontrar recursos ou algorítimos que façam tal
posicionamento ainda não é algo tão trivial quanto deveria
ser, o que força os desenvolvedores a re-implementar o
sistema ou comprá-lo pronto e fechado de alguém.
Assim se a funcionalidades do posicionamento de câmera
estivesse sendo distribuída por uma licença como a GPL, os
desenvolvedores poderiam gastar menos tempo com re-
implementações e mais tempo com melhorias, gerando
controladores melhores que seriam compartilhados com a
comunidade como um todo elevando a qualidade deste
recurso ao mesmo patamar de uma solução desenvolvida
por uma grande publicadora ou até melhor.
 Ainda assim não é por que dois jogos compartilham o
mesmo posicionamento de câmera, que eles terão a mesma
experiência de jogo, ambos podem se passar em ambientes
diferentes, fazendo uso de mecânicas e dinâmicas que os
diferenciariam de tal forma que sua autenticidade
certamente estaria garantida.
Por fim é necessário desconstruir o equívoco de que um
software para ser livre precisa ser necessariamente gratuito,
embora tanto as definições tanto do software livre quanto do
open source exijam que o usuário tenha liberdade de
redistribuir o código em momento algum elas exigem a
gratuidade do mesmo.
Dados estes argumentos é possível afirmar que ao
socializar o código sob uma licença GPL, mas manter a arte
do game sob uma EULA padrão já seria o suficiente para que
o conhecimento produzido no desenvolvimento do projeto
fosse socializado com a comunidade, enquanto a
propriedade intelectual e o direito de venda (assim como o
interesse de compra) estejam assegurados, visto que para
executar a experiência do jogo tal qual ela foi concebida para
ser, demanda-se da arte produzida para o mesmo.
Como exemplo de jogos que já realizam esse tipo de
abordagem podemos mencionar: Doom 1, 2, 3, Castle of
Wolfestein, Quake 1, 2 e 3, Start Wars Jedi Academy entre
outros. Assim sendo embora qualquer desenvolvedor possa
ter acesso ao código fonte desses jogos e buscar
compreender como foram construídos e desenvolvidos, os
usuários e o público alvo ainda precisam adquirir título para
que possam usufruir da experiência de jogo, uma vez que
essa é a única forma de obter a arte do game assim como
sua versão compilada. Assim pode-se dizer que no que se
refere a estes título, o conhecimento produzido está livre
enquanto a propriedade e o interesse de compra estão
assegurados.
8. A Librestore
Imagem 13: Fluxograma de funcionamento da Librestore.
Buscando apresentar uma metodologia de desenvolvimento
de jogos em base livre e open source sob licenças
recíprocas, assim como a suas vantagens apresenta-se
agora o projeto do Librestore, link:
http://librestore.forumeiros.com/.
A Librestore visa justamente ser uma comunidade livre
onde os usuários socializarão códigos, assets e features sob
licenças permissivas como a GPL, socializando o
conhecimento gerado na produção de todos os projetos aqui
socializados, fazendo desta forma uso da produção coletiva
para buscar atingir um maior grau de qualidade.
A proposta também visa alterar a estrutura de
desenvolvimento de um jogo, que sairia do modelo de
estábulo indo para o modelo bazar, orientado a
funcionalidades.
Imagem 14: Portal Librestore.
● Planejamento das Funcionalidades: Nesta primeira
etapa o desenvolvedor após produzir a documentação
necessária para o seu projeto, elencando todas as
funcionalidades necessárias para que o mesmo seja
concluído, colocando-as na forma de um backlog, similar ao
usado em metodologias scrum.
● Visita Inicial ao Bazar: Antes de iniciar o
desenvolvimento do projeto, o desenvolvedor primeiramente
visitaria a Librestore e buscaria entre as soluções e
funcionalidades existentes todas aquelas que condizem com
as necessidades de seu projeto.
● Desenvolvimento e adaptação: Uma vez que tenha se
apropriado das soluções desenvolvidas pela comunidade o
desenvolvedor inicia processo de adaptação das
funcionalidades ao seu projeto iniciando assim o
desenvolvimento do jogo, para em seguida desenvolver
correções e novas funcionalidades necessárias ao seu
projeto.
● Socialização das Melhorias e Modificações: Ao final
do loop o desenvolvedor socializa as modificações e
melhorias feitas, assim como as novas funcionalidades
produzidas, contribuindo com crescimento da Librestore e de
sua comunidade, assim a cada ciclo a comunidade como um
todo se torna melhor e o nível de qualidade do projetos
cresce junto com a mesma.
● Socialização do projeto e de todo o conhecimento
gerado no processo: Ao final do projeto o desenvolvedor
socializa o código do jogo, com a comunidade permitindo a
essa observar todas as melhorias e inovações
desenvolvidas pela equipe fazendo com que o conhecimento
produzido se dissemine entre todos os membros, que
poderão colaborar com correções, melhorias ou novas
funcionalidades. Lembrando que o interesse de compra do
título fica resguardado pela parte artística que permanece
restrito sob uma EULA tradicional.

Imagem 15: Fluxograma de funcionamento da Librestore sob
a ótica do desenvolvedor.
Houveram quatorze inscritos, entretanto somente três
equipes se engajaram na game jam, sendo que nenhuma
utilizou os assets presentes na Librestore, e mesmo
possuindo três milestones de entrega e o incentivo para que
as equipe colaborassem entre si, não houveram interações
entre os participantes. Assim, única a contribuição foram os
jogos publicados na Librestore ao final da jam sob uma
licença GPL e que não foram desenvolvidos sobre a
metodologia de bazar.
O primeiro jogo submetido a Open Jam chamava-se Aqua
Blast, e caracterizava-se como um jogo do gênero arcade,
onde o objetivo do jogo era tocar na tela do dispositivo
móvel para emitir uma rajada de bolhas e empurrar os cinco
anéis próximos de forma a colocar o maior número deles
dentro dos três cilindros presentes na tela.

9. Processo de validação de desenvolvimento no

formato Bazar
Para validar o processo de desenvolvimento de jogos
usando a filosofia do bazar em detrimento de uma
abordagem fechada como o estábulo, foram feitos três
abordagens distintas para verificar a adesão dos
desenvolvedores de jogos à filosofia livre. Nas próximas
subseções serão descritas cada uma dessas abordagens.

9.1 Implementação da Librestore e OpenJam 2018

Imagem 17: Aqua BLast, vencedor da Open Jam 2018.

O segundo jogo submetido para a Open Jam 2018

Imagem 16: Open Jam no Itch.io.
chamava-se Dance Part Beatdown e caracteriza-se como
Uma vez definida a proposta de metodologia de um jogo de ritmo e ação, onde o principal objetivo do jogador
desenvolvimento, iniciou-se o processo de implementação. e derrotar os oponentes que surgem de ambos os lados da
Toda a Librestore fora desenvolvida dentro do formato de tela no ritmo da música antes de ser nocauteado por eles.
fórum, formato esse que já fora utilizado em outras
comunidades de desenvolvimento como CryDev,
BlenderArtists, Unity Forum e que por sua vez demonstra-se
o formato adequado para produções colaborativas.
Com a finalidade incentivar o uso da Librestore, a
produção de jogos livres e também como uma forma de
validar a metodologia proposta foi organizada a OpenJam
2018, uma game jam com regras que incentivavam o
desenvolvimento de jogos GPL utilizando a metodologia de
bazar e a proposta de desenvolvimento aqui descrita na
seção anterior. A ideia da game jam era justamente criar o
ambiente e a comunidade de desenvolvimento o mais rápido
possível e começar as interações entre os participantes.
Durante o processo de preparação da game jam, a
Librestore foi abastecida de assets, sendo um deles o Simple Imagem 18: Dance Party Beatdown, segundo lugar na Open
2D Person Controller que será analisado na próxima Jam 2018.
subseção. No entanto os resultados da game jam foram
insuficientes. O último game submetido para a Open Jam 2018 fora o
PizzaTack, é um game do gênero puzzle, onde o objetivo do
jogador é empilhar e equilibrar uma série de objetos e 9.2 Madoc Against the Deep Space Aliens e o Single 2D
personagens aleatórios em cima de um disco de pizza, controller
acumulando pontos e indo para o nível seguinte.

Imagem 20: Madoc Against the Deep Space Aliens.

Por motivos éticos o autor optou por não participar da

Imagem 19: PizzTack, terceiro lugar na Open Jam 2018. OpenJam 2018 oficialmente, pois também estava fazendo a
coordenação do evento. No entanto iniciou um projeto
Ao término da jam, foi enviado para cada participante um
paralelo junto a jam de um jogo 2D simples, para Windows,
questionário com quatro perguntas, sendo três abertas e
Linux e Android. Esse processo de criação foi feito com
uma fechada. Todos alegaram entender a proposta e as
objetivo do autor experimentar, sem concorrer com os
vantagens do desenvolvimento de jogos livres e a
participantes da jam, como seria o modelo de
socialização do conhecimento produzido ao longo do
desenvolvimento baseando-se no bazar, usando unicamente
desenvolvimento do jogo. Da mesma forma sentiram-se
Librestore e as ferramentas livres sugeridas na subseção
confortáveis em compartilhar os códigos, mesmo não tendo
3.1.
recebido auxílio das outras equipes. Conseguiram perceber
Fazendo uso do asset Single 2D Person Controller1, o
o quanto a socialização do código de projetos sob licença
autor desenvolveu um jogo de plataforma cuja principal
permissiva pode contribuir para uma possível melhora na
mecânica trata-se da possibilidade de reverter a gravidade.
qualidade do dos jogos digitais como um todo.
O jogo evoluiu até um estágio de alpha, com um nível
No entanto invariavelmente todos levantaram uma
completamente desenvolvido, junto a todas as mecânicas
preocupação em relação aos clones. Entende-se por clone,
que poderão estar presentes na jogabilidade final.
um jogo muito similar a outro em mecânicas de jogos mas
O jogo foi submetido a mais de quarenta playtesters, todos
com arte e enredo diferentes. Em ambientes como a Google
com idades entre 8 e 21 anos. Cada tester jogou no tanto na
Play a presença massiva de clones de um mesmo jogo
versão Android como na versão Windows. Quando o
acaba diluindo a base de usuários e o lucro efetivo que
personagem morria, passava a vez para outro jogador.
aquele jogo poderia ter. E que a iniciativa de
Enquanto o grupo jogava, as eles davam feedbacks verbais
desenvolvimento GPL embora não favoreça a pirataria,
para o autor quanto a jogabilidade, gráficos e dificuldade do
favorece o surgimento de clones, uma vez que estamos
jogo. O game teve uma excelente receptividade em todas as
fornecendo todas as ferramentas necessárias para se
plataformas com elogios ao gameplay e a dificuldade
replicar um jogo de sucesso, e que por mais que hajam
elevada do jogo.
vantagens na produção livre, estas podem acabar não
Quando exposto a outros desenvolvedores, estes não
compensando a perda de lucros referente os fatores acima
souberam identificar o motor de jogo acreditando se tratar de
descritos.
um projeto feito em Unity, o que demonstra que as
Claro que a amostragem de projetos analisados na
ferramentas de desenvolvimento propostas já se encontram
OpenJam 2018 é claramente insuficiente para provar ou não
em um nível de maturidade no desenvolvimento a ponto de
a validade da metodologia proposta, mas serve como uma
gerarem resultados tão bons quanto o de seus equivalentes
sondagem inicial sobre as apropriações de recursos livres e
proprietários.
o quanto que estes desenvolvedores sentem-se em relação
Referente ao Asset Single 2D Person Controller de todos
a distribuição de seus projetos de forma livre.
os assets disponíveis na Librestore esse foi o único a receber
commits externos. Com três atualizações o código já tornou-
se mais enxuto, funcional e otimizado, o que indica uma boa
capacidade da metodologia proposta, no entanto o número
de interações mais uma vez é insuficiente para provar o
conceito proposto.
Tentando aumentar o número de colaboradores do asset,
o mesmo fora socializado em diversas comunidades de
desenvolvedores Godot tanto nacionais quanto
internacionais, via Facebook. As postagens foram

1
Asset desenvolvido pelo autor, disoponível em
http://librestore.forumeiros.com/t6-simple-2d-sound-
controller. Acessado em 9 dez. 2018.
receberam muitas curtidas e comentários de agradecimento.
No entanto não recebeu mais nenhum commit até a presente
data.
9.3 GameOff 2017 e 2018
Imagem 21: Game Off 2018
Por último, buscando outra forma de validar a metodologia
proposta o autor recorreu ao arquivo dos registros da
comunidade de desenvolvedores participantes da GameOff
2017 e 2018, a maior game jam de jogos livres e open
source, realizada anualmente pelo Github. Considerando a
edição 2017, visitou-se a seção Community do site oficial2,
está contava com setenta e seis tópico, excluindo os tópicos
de recrutamento. Sem nenhuma orientação metodológica,
as postagens foram visitadas uma a uma buscando
observar-se o quanto que os membros da comunidade
discutiam sobre o desenvolvimento e socializavam durante o
desenvolvimento o código-fonte de seus projetos. Desta
forma notou-se que os desenvolvedores compartilham
dúvidas de design, mas praticamente não há
compartilhamento de código-fonte durante o processo de
desenvolvimento. O mesmo foi observado na edição 2018
até a presente data, seguindo os mesmos critérios.
É possível identificar que o compartilhamento de dúvidas e
features ocorre nas comunidades de cada motor de jogo,
fora da game jam. Como um forma de resolução de
problemas e não como compartilhamento. Mesmo nestas
situações o código é mostrado parcialmente, sendo que nem
sempre recebe uma resposta direta, levando a crer em um
sentimento de insegurança tanto de quem compartilha o
código quanto de quem responde a dúvida.
9.4 Discussão dos resultados
Embora a abordagem referente ao bazar no
desenvolvimento de jogos tenha potencialidades, como
observado no Single 2D Person Controller, a comunidade de
desenvolvedores de jogos demonstra-se pouco receptiva à
proposta de trabalho, mas reconhece sua importância.
Segundo as respostas dos desenvolvedores, demonstram
uma apreensão no momento de abrir o código-fonte de seus
projetos, em geral devido a dois sentimentos diferentes. O
primeiro é o medo de que as ideias que consideram
inovadoras sejam copiadas massivamente na forma de
clones, e a segunda é que o tempo e o esforço dedicados
para o desenvolvimento do código não retornem para eles de
alguma forma.
2
"Github Game Off - Game Off - itch.io." 1 nov. 2017,
https://itch.io/jam/game-off-2017. Acessado em 9 dez. 2018.
Esses receios parecem refrear o desenvolvimento livre em
meio a comunidade de desenvolvedores, o que impede o
surgimento de uma bazar livre, com desenvolvedores ativos
contribuindo entre si. Por mais que potencialidades sejam
evidentes, o temor de que “o resultado de sua genialidade
seja roubado” acaba levando os desenvolvedores de jogos
em um caminho contrário ao de outras comunidades de
desenvolvimento de software, como por exemplo, sistemas
operacionais e banco de dados, ou mesmo das próprias
ferramentas de desenvolvimento usadas por eles como
Godot, Blender, Krita ou mesmo a Unreal e a Lumberyard,
que são proprietárias mas trabalham com seu código fonte
aberto.
Importante observar que em game jams como Game Off e
até mesmo no experimento da Open Jam 2018, mesmo seu
regulamento evidenciando a necessidade de compartilhar o
código-fonte sob uma licença recíproca, sendo possível
afirmar desta forma que os entrantes conhecem tal critério,
não socializam o código durante o desenvolvimento,
adotando uma perspectiva mais alinhado ao estábulo do que
ao bazar.
10. Considerações Finais
Existe um crescimento evidente no número de
desenvolvedores, e isso conforme evidencia A.Lemos[7],
F.Kon, N.Lago, P.Meirelles e V.Sabino[1], deve-se a
crescente influência exercida pela cybercultura nos demais
espaços, onde o consumidor deixa de ser um mero
espectador e passa a ser também produtor daquilo que
consome, descentralizando a produção massiva de
conteúdo. Estando na vanguarda desse movimento os
movimentos do software livre e software open-source, que
influenciaram não apenas outros desenvolvedores de
software, mas também produtores de outras mídias dando
início ao movimento copyleft.
Infelizmente, mesmo com todas as potencialidades
evidenciadas ao longo de todo esse trabalho, os resultados
finais são inconclusivos referentes a metodologias,
apontando apenas que no presente momento, a comunidade
de desenvolvedores de jogos embora reconheça a validade
do desenvolvimento livre e Open Source não parece
disposta a ingressar nele, sendo possível sugerir que isso
deve-se a uma crise de confiança, onde os desenvolvedores
temem pela originalidade de suas criações.
No entanto é evidente que o movimento copyleft tende
apenas a crescer, e que em um mundo onde o Windows não
é mais o sistema operacional mais utilizado, titulo esse que
agora pertence ao Android, que por sua vez roda em cima de
um Kernel Linux, os conceitos de trabalho em rede,
socialização de dúvidas e soluções precisam fazer parte da
comunidade de desenvolvedores do jogos. Para que essa
possa tirar proveito de todas as vantagens e potencialidades
que a iniciativa copyleft e o movimento da cybercultura
proporcionam, desde o ponto de vista criativo ao quesito
qualitativo (qualidade do produto final).
Por fim conclui-se afirmando que os resultados
inconclusivos aqui obtidos abrem uma série de questões a
serem abordadas por outras áreas do conhecimentos,
questões que envolvem a confiança no desenvolvimento em
redes e a resistência a movimentos colaborativos.
Referências
[1] F.Kon, N.Lago, P.Meirelles e V.Sabino. Software Livre e
Propriedade Intelectual: Aspectos Jurídicos, Licenças e
 Modelos de Negócio, Jornada de Atualizações em Informática
(JAI/SBC), 2011.
[2] E. Raymond. A Catedral e o Bazar, Linux Kongress, Maio de
1997.
[3] G.Stefanuto, J.De Lucca, A.Alves. O impacto Software Livre e
de Código Aberto (SL/CA) nas Condições de Apropriabilidade
na Indústria de Software Brasileira, XI Seminário Latino-
Iberoamericano de Gestión Tecnológica, Outubro de 2005.
[4] Open Source Initiative. The open source definition, Março de
2007. Disponível em: <https://opensource.org/osd> Acesso
em: 1 de junho de 2018.
[5] Free Software Foundation. The free software definition.
Disponível em: <https://www.gnu.org/philosophy/free-
sw.en.html> Acesso em: 1 de junho de 2018.
[6] D. Simioni. Qual a Diferença entre Software Livre e Open
Source, Produção: Dionatan Simioni, Novembro 2016.
Disponível em: <https://youtu.be/Gz8-JsgBdtw> Acesso em: 1
de Junho de 2018.
[7] A.Lemos. Cibercultura, cultura e identidade. Em uma Direção a
uma Cultura “Copyleft”?, Contemporânea, Dez de 2004.
[8] P.Guilherme. Diretor de SimCity fala sobre o no lançamento do
game. Maio 2016. Disponível em:
<https://www.tecmundo.com.br/video-game-e-jogos/105164-
diretor-simcity-fala-fracasso-lancamento-game-video.htm>
Acesso em 4 de novembro de 2018.
[9] D.Simioni. Canonical e Microsoft anunciam o “Ubuntu on
Windows”, entenda como vai funcionar. Disponível em
<https://www.diolinux.com.br/2016/03/canonical-e-microsoft-
anunciam-o-ubuntu-on-windows.html> Acesso em 4 de
novembro de 2018.