AI "Make it real" converte desenhos em jogos funcionais

Um novo modelo AI consegue converter desenhos e descrições em interfaces e jogos funcionais.

No futuro, a vida de um developer poderá aproximar-se mais da de um designer ou escritor do que da de um programador convencional. Pelo menos, assim parece tendo em consideração a evolução de ferramentas AI, que converterão os desejos dos utilizadores em produtos funcionais.

Este Make it Real está a dar que falar, ao ter sido treinado para fazer isso, deixando que o utilizador crie esboços e escreva instruções do que pretende; mas cujas capacidades surpreenderam o seu criador quando descobriu que era capaz de criar jogos do estilo Breakout / Arkanoid, entre muitas outras coisas

Yea… I am done. lol 🤯

I just drew a game and it works… 💀 pic.twitter.com/GczEz4BAwe

— Andreas Klinger 🏝 (@andreasklinger) November 16, 2023

Por um lado, serve como demonstração das tecnologias AI, e de como uma simples developer individual pode tirar partido disso para fazer coisas impressionantes. Por outro lado, põe-nos a cabeça a andar à roda só de tentar imaginar quantas mais coisas se tornarão possíveis daqui por dez ou vinte anos.

A vida de um developer poderá ser passar o dia a dialogar com uma AI, a explicar o que se quer e como se quer.

As (muitas) dificuldades de fazer um jogo

Podemos passar horas em jogos de computador e consola, mas raras vezes se perde um segundo que seja a pensar na dificuldade que foi criar tudo aquilo que vemos no ecrã.

Como jogadores, somos rápidos a notar todo e qualquer bug ou detalhe que não seja do nosso agrado. Talvez seja o braço do personagem a atravessar uma porta, ou os pés a patinarem no ar enquanto sobe uma escada, ou a impossibilidade de um boneco que nuns sítios salta 10 metros no ar conseguir saltar por cima de uma pequena barreira que limita o caminho. Mas aquilo em que não pensamos, é que tudo o que aparece num jogo representa uma enorme dificuldade para quem o fez, e não seria má saber um pouco mais sobre isso.

Pegue-se no exemplo da porta. Uma porta parece ser algo simples, mas quando é posta num jogo vem acompanhada de uma série de complicações. Faz-se a porta abrir magicamente sem ninguém lhe tocar? Faz-se o braço e mão mover-se realisticamente para a abrir? E se do outro lado estiver outro personagem a bloquear a porta? E depois de passar, fica aberta ou fechada? E se for fechada da mesma forma, não vai isso frustrar um jogador que esteja a correr para fugir de um inimigo, e vê o seu boneco parar pacientemente para fechar a porta... se é que a pode fechar, se entretanto o seu perseguidor ficar a encravá-la?

Nos elevadores temos outro conjunto de circunstâncias. E se um personagem ou objecto fica a encravar as portas? E se algo se consegue infiltrar por baixo do elevador (ou por cima) e fica preso contra o chão (ou tecto)? Uma resposta rápida seria: destrói-se tudo o que estiver nessas condições. Mas, e se forem coisas que são essenciais para a evolução do jogo e que não podem ser destruídas?

Isto não se aplica apenas aos jogos 3D, sendo que até jogos estilo plataformas 2D também têm todo o seu conjunto de detalhes que dão dores de cabeça aos seus criadores, e que ajudam a perceber porque motivo até jogos "simples" podem demorar anos a serem concluídos - e mesmo assim, sendo praticamente impossível que alguns desses detalhes, opções ou decisões, impeçam que alguns bugs ou frustrações cheguem até aos utilizadores.

Google vai encerrar serviço de jogos multiplayer do Google Play Games em 2020

A Google volta a demonstrar o risco que é depender dos seus serviços, anunciando que irá encerrar o serviço de suporte de jogos multiplayer real-time e turn-based do Google Play Games.

Os jogos multiplayer representam uma grande fatia dos jogos mobile, e não foi surpresa ver a Google a querer facilitar o trabalho dos developers. Com o Google Play Games, criou múltiplos serviços que facilitavam o processo de criação de jogos que mantivessem tabelas globais de pontuação, gestão de amigos, e também tratavam das comunicações no caso de jogos multiplayer em tempo real ou por turnos.

Pois bem, agora todos esses jogos irão deixar de funcionar, pois a Google anunciou que irá encerrar esses serviços a 31 de Março de 2020.

A situação mais chata será no caso de jogos mais antigos, já abandonados pelos developers, e que iam funcionando em multi-player graças a estes serviços da Google. A partir daquela data, deixarão de funcionar, sendo pouco provável que os seus criadores estejam dispostos a implementarem alternativas que seguramente obrigariam a um esforço substancial tanto a nível de programação, como depois a nível de sustentar o serviço economicamente.

Seja como for, será mais uma lição para o futuro: há que pensar duas vezes antes de considerar qualquer dependência num serviço da Google (e não só).

Humble Unity Game Development Bundle

Fartos de jogarem jogos feitos por outras pessoas? Têm uma ideia que acham que se poderia tornar no novo jogo do século? Então estão com sorte, pois temos um Humble Bundle dedicado à criação de jogos com o Unity.

Como é habitual, cada um é livre de pagar o valor que quiser, com vários patamares disponíveis, mas bastam 23 euros para se ter acesso a tudo, o que inclui - entre outras coisas - o Complete C# Unity Developer 3D, RPG Core Combat Creator, C# Unity Developer 2D, Learn Unity 3D Game Kit - Make Games Without Coding. Sendo que alguns destes conteúdos, por si só, custariam várias centenas de euros.

É uma excelente oportunidade para quem se quiser iniciar, ou aprofundar, no mundo dos jogos em Unity.

Sceelix - motor procedimental feito em Portugal

O meetup de Realidade Virtual que se realizou no Porto permitiu-me conhecer muitas pessoas envolvidas em projectos fascinantes. Um deles, que nem fazia ideia de que pudesse existir em Portugal, é o Sceelix, que facilita a criação de todo o tipo de coisas geradas matematicamente.

A geração procedimental (procedural) não é nova, e é algo que recentemente adquiriu um pouco mais de notoriedade graças ao No Man's Sky, o jogo que nos deixa explorar todo um universo com triliões de planetas, que se tornam possíveis graças à magia da matemática. É precisamente o tipo de coisas que o Sceelix permite fazer, e que está a ser feito aqui no Porto.

Usando o Sceelix, que é uma ferramenta destinada a developers, é possível criar coisas como paisagens, cidades, estradas, edifícios, florestas, e praticamente tudo o mais que se desejar - sem que seja necessário criar manualmente todo e cada elemento. Por exemplo, se quisermos criar uma cidade usando um editor 3D, é fácil copiarmos um edifício para que se fiquem com 100 (ou 1000), mas não seria muito realista ter uma cidade com centenas de edifícios exactamente iguais. Isso obrigaria a andar manualmente a aplicar variações, e facilmente ocuparia dezenas ou centenas de horas. Com o Sceelix, bastará definir os parâmetros pretendidos, e isso pode ser feito de forma quase instantânea e aplicar-se não só ao tamanho e formato dos edifícios, mas às próprias texturas e outros elementos. E tal como as cidades, também o mesmo se aplica a florestas, paisagens, e demais coisas que se quiserem fazer.

É bom ver que temos pessoas a trabalhar em coisas deste tipo mesmo aqui à porta de casa, e se também andarem pelo Steam, não deixem de deixar um voto positivo no Sceelix, que se encontra lá no Greenlight.

O Making-of de Bioshock

A edição de Novembro da revista GameDeveloper traz um artigo dedicado ao desenvolvimento do jogo Bioshock (um dos maiores sucessos do ano).

Inicialmente apresentado em 2006, o jogo foi evoluindo através do feedback obtido através das várias demos:

Our first public presentation was at E3 2006. We had developed a great deal of content before that point, but hadn't yet built a space that really demonstrated the game experience to our satisfaction. The E3 demo forced us to focus the whole team on what the user experience should be. We defined a message for the demo - player choice - and built a narrative around that message. Even though the experience was highly scripted at the time, it effectively demonstrated the feel of the game we wanted. Another example of demo-inspired development was the "Hunting the Big Daddy" demo. Though Big Daddies and Little Sisters had been part of the game in some form since the beginning, initially the player could confront Little Sisters directly without necessarily needing to dispatch the Big Daddy that protected them. During the development of this demo, the team discovered that with some polish and tuning changes the act of dealing with a Big Daddy could be a truly epic battle in itself. This led to the realization that Big Daddy battles should be the key to player growth, essentially providing a roving boss battle that players could undertake at a time and place of their choosing."

Ao que se seguiu um teste final, para assegurar que tudo funcionava como era suposto:

"The first external BioShock focus test was meant to be a sanity check: to get a better sense of what was working well but needed polish and what wasn't working at all.

At this point we had already done one small round of internal focus testing with friends of friends, which had turned out mostly positive feedback. So, just after the first beta, the entire design team plus a contingent of 2K producers headed off to see how a group that knew nothing about our company or BioShock would react to the first level.

It was brutal.

The first level, they said, was overly dense, confusing, and not particularly engaging. Players would acquire new powers but not know how to use them, so they stuck to using more traditional weapons and became frustrated. They didn't interact with the Big Daddies, and they didn't understand (or care) how to modify their characters. They were so overwhelmed by dialogue and backstory that they missed key information. A few of the players did start to see the possible depth of the game, but even they were frustrated by the difficulty of actually using the systems we had created.

Based on this humbling feedback, we came to the realization that our own instincts were not serving us well. We were making a game that wasn't taking the initial user experience into account, and we weren't thinking enough about how to make it accessible to a wide variety of players.

After the focus test, we went back to the drawing board for the entire learning sequence of the game. We scrapped the gameplay in the first two levels entirely and re-architected them to be a much slower paced experience that walked the player through the more complicated gameplay verbs, such as "one-two punch"-combining weapons and plasmids.

We changed the medical pavilion from having sandbox-style gameplay to using a series of locks and keys that were set up to ensure that the player knew how to use at least a few key plasmids. And we made a development rule that future changes would be data-driven, not based solely on our own instincts."

Para quem estiver interessado em saber mais sobre o desenvolvimento dos jogos, e que se passa "por dentro", a GameDeveloper é uma referência obrigatória.

via [GamaSutra]