arquivos externos e funções obsoletas

Estou migrando para o GMStudio. Com todos os meus vícios, todas as minhas manias, estou entrando no GMS.
Aí, eu tenho esse projeto de jogo educativo, o de ligar pontinhos e formar figuras. O projeto já está bem encaminhado e eu até pretendo postar a engine, porque a forma de carregar as imagens, modéstia à parte, ficou show!
Mas ainda está na versão "game genérico" e eu queria postar um .gmk. Achei que seria legal usar o GMS e aqui estamos nós.

O que rola é que na versão "game genérico", TUDO é feito através de arquivos externos. Aí eu me acostumei com esse recurso. E achei legal permitir ao jogador criar suas próprias imagens, com um arquivo de texto simples pras coordenadas dos pontos. Quer dizer, não dá pra não usar arquivos externos, porque o JOGADOR vai criar arquivos e mais arquivos externos.

Aí eu leio o seguinte comentário, no manual do GMS:

manual do GMS escreveu:Obsolete Dynamic Functions
These functions deal with the generation of resources at run time.
(...)
execute_string
Execute the piece of code in the string str with the indicated arguments.
execute_file
Execute the piece of code in the file with the indicated arguments
(...)
Why These Are Obsolete
These functions cannot be used any more due to changes in the underlying runner that GameMaker:Studio uses to generate the device specific packages making it impossible to generate objects and code "on the fly".

... E então? Não tem jeito mesmo? Nada de game genérico no GMS? Nada de criação de recursos?
Gozado, as funções sprite_add e background_add ainda estão sendo aceitas no manual.

Hm... posso simplificar ainda mais os arquivos de texto e simplesmente carregar as coordenadas, transformando strings em números... Vai ser meio desorganizado de criar e ler os arquivos, mas ainda fica viável. Mas ainda mantenho a pergunta, acabou a farra de arquivos externos?

o Execute String é até perigoso dependendo de como você está usando.

Aparentemente não é possível gerar código "on the fly" mesmo, não tem como, o que é uma pena, já usei um bocado esse recurso.

shatterhand2 escreveu:o Execute String é até perigoso dependendo de como você está usando.

Perigoso como?
Eu costumo usar mais é execute_file mesmo, nas seguintes situações:
- No primeiro step do jogo inteiro, pra gerar todos os recursos e gravá-los em globais. Normalmente faço isso na fase de programação, o produto final, quando chega a sair, sai com os recursos dentro do executável mesmo.
- Substituindo scripts, também na fase de produção, desde que o script não seja usado o tempo todo

Uma utilidade que eu descobri, recentemente, pra execute_string é a produção de botões. Eu tenho uma rotina-padrão pros botões que fazem eles ficarem apertados ou soltos na hora certa. As únicas coisas que mudam é o que o botão faz ao soltar o botão e as sprites. Aí, quando eu tenho dezenas de botões, eu faço um objeto só e, ao criar a instância, enfio um código, uma string, dentro de uma variável e mando executar essa string ao soltar o botão.
Bom, posso manter essa rotina na fase de produção e criar scripts pras açoes dos botões, na versão final. Vai ser barra de me adaptar, mas é possível.

shatterhand2 escreveu:Aparentemente não é possível gerar código "on the fly" mesmo, não tem como, o que é uma pena, já usei um bocado esse recurso.

Uma pena mesmo. Ah, qualquer restrição é uma pedra no sapato, o que varia é o tamanho da pedra. A gente se adapta.
Provavelmente a restrição é causada pela estrutura da linguagem c++, já que é isso que mudou radicalmente do 8.1 pro studio. Provavelmente essa mudança que possibilitou as novas exportações. Se for assim, acho que é um preço aceitável a se pagar pelas novas possibilidades.

Perigoso como?

• É lento.
  
• Para ter esse recurso o executável se torna facilmente decompilável por causa do código on the fly.
  
• É inviável para outras linguagens não por ser impossível de reproduzir mas por ser trabalhoso e deixar o código complexo e pesado. Imagine um interpretador em tempo de execução de GML em Javascript...
  
• Não é uma boa prática de programação. É possível fazer coisas como manipular variaveis atraves dos nomes como as funções variable_get/set em C++ e algumas outras linguagem atraves da velha gambiarra mas isso torna o código instável e hackeavel. Imagine no caso do Javascript, no GMS o código gerado é ofuscado e todas as variáveis tem seus nomes alterados, uma função como variable_get seria impossível.
  Se você quer achar valores atráves de nomes é muito mais adequado usar ds_map. Qualquer boa linguagem tem algo equivalente as datas estruturadas presentes no GM.

Você pode abrir arquivos externos se coloca-los nos "Included Files".
Por padrão você so pode ler arquivos no working_directory que é onde os arquivos inclusos ficam e ler e escrever na area de save. No entanto você pode usar get_save/open e a pasta que o jogador escolher poderá ser usada normalmente. É como pedir permissão ao usuário antes de mexer no seu HD.

Quanto aos scripts se não for preciso alterado-los em tempo real você pode criar scripts normalmente e usar suas ids como os objetos e sprites

Código:

// set_red()
draw_set_color(c_red);

// set_blue()
draw_set_color(c_blue);

acao[0] = set_blue;
acao[1] = set_red;
botao = 1;

execute_script(acao[botao]);

Se precisa altera-los em tempo real então o único jeito é fazer uma forma de interpretar comandos prefinidos.
Por exemplo:

Código:

// arquivo texto script1.txt
A4
D5
G8

// executar_script(fname)
...

switch(opcode) {
    case "A4":
        dominar_o_mundo();
    break;

    case "D5":
        dominar_o_pais();
    break;

    case "G8":
        dominar_a_cidade();
    break;
}

É trabalhoso mais é uma opção...

O screen_redraw também esta obsoleto mas é possível substitui-lo com as novas funções.
O equivalente a desenhar toda a tela em uma surface no GMS seria:

Código:

vsurf = surface_create(640,320);
view_surface_id[0] = vsurf; // linka a surface com a view 0
// tudo que aparecer na view 0 sera automaticamente desenhado na surface
// e então você usa surface_copy para fazer o que quiser com a duplicata ou adicionar os efeitos no original mesmo logo antes de desenha-la no evento Draw mas lembre-se que ela é atualizada sozinha a cada step

Ainda é possível desenhar até mesma uma view que não esta visível para o jogador. Imagine uma TV que mostra uma outra parte da room. Gostei bastante dessa adição!
O melhor disso é que é multiplataforma. Funciona para Windows, HTML5, Android e todos os outros.

Enfim, eu não reclamei dessas perdas de funções porque a maioria tem meios equivalentes e/ou mais adequados de se reproduzir e para muitas delas seria realmente melhor se não existissem.

Hmmm... acho que como eu nunca me preocupei com segurança, não via a o perigo. Eu só me preocupava com performance, e eventos de botões acontecem tão esporadicamente que não fazia diferença usar strings ou códigos diretos.

Kabeção escreveu:O screen_redraw também esta obsoleto mas é possível substitui-lo com as novas funções.

Cara, dessa eu não sabia! tenho que reaprender a usar o game maker...
Eu já sabia que as room transitions tinham ficado pra trás, mas não esquentei a cabeça, porque tinha bolado uma rotina de:
- criar uma surface do tamanho da room, desenhando a tela nessa surface
- criar um objeto na room seguinte que destiva as outras instâncias e usa essa surface pra mostrar a tela anterior, estática
- sumir com essa surface da forma que eu quiser, gerando uma "transição"
- reativar todas as instâncias ao fim da transição, eliminando o objeto e dando seguimento ao jogo
Se você não postasse essa alternativa, eu iria pensar em desenhar os backgrounds e objetos um-a-um. Não seria algo generalizável e ainda corria o risco de ficar ruim.
Valeu!

PS: existe uma lista de funções obsoletas? Não estou em casa, então não tenho acesso ao help...

Mas a Perda do EXECUTE_STRING é uma Perda Imensa, como por Exemplo, eu Poderia fazer um Criador em que o Jogador pudesse usar as Funções GML direto, como eu posso substituir esta Função?

e tambem, como ele poderia ser Fácilmente decompilavel por causa do on the fly, o que é isto?
e como usa e para que serve esse on the fly?

theguitarmester escreveu:Mas a Perda do EXECUTE_STRING é uma Perda Imensa, como por Exemplo, eu Poderia fazer um Criador em que o Jogador pudesse usar as Funções GML direto, como eu posso substituir esta Função?

É a base do game genérico. De fato, uma pena, mas fiquei com a impressão que é por isso que agora podemos exportar pra outros formatos. Quer dizer, ao migrar pra C++, ficou possível exportar pra outros formatos, mas impossível usar execute_string e execute_file. Sendo esse o preço pros jogos tornarem-se comercializáveis, acho que até que não está tão caro.

theguitarmester escreveu:on the fly, o que é isto?
e como usa e para que serve esse on the fly?

"on the fly" (durante o vôo) é uma expressão que, em tradução livre, significa "enquanto o jogo está rolando" ou, como eu já vi escreverem, "em tempo de execução".
Eu uso muito o execute_file quando não tenho certeza se meus scripts vão funcionar. Aí, eu faço um arquivo externo e mando executar o arquivo ao, por exemplo, apertar espaço. Se o resultado não sai como esperado, não preciso fechar o jogo pra alterar o arquivo, mando brasa com o jogo rodando mesmo, salvo a alteração e aperto espaço de novo. Isso é alterar o arquivo "on the fly".
Se você for criativo, pode fazer isso com strings e alterações automáticas. Mas não estou recomendando que faça isso, apenas comentando que é possível.

Eu ja usei execute string dentro de um laço para pegar uma série de sprites que se chamava spr_carta1, spr_carta2, spr_carta3 .....

Como o kabeção falou, com uma lista seria mais seguro, mas com o execute_string foi mais rápido de desenvolver.

Mas além de ser mais lento e pouco seguro, fica um código bastante ilegível.

Mas a Perda do EXECUTE_STRING é uma Perda Imensa, como por Exemplo, eu Poderia fazer um Criador em que o Jogador pudesse usar as Funções GML direto, como eu posso substituir esta Função?

Nesse caso você poderia jogar o código no Create de um objeto e instanciá-lo. Opa, isso também está obsoleto.

Funções obsoletas (sem contar as de CD e as de registro): http://pastebin.com/WA6r65qs

Quer dizer, ao migrar pra C++, ficou possível exportar pra outros formatos, mas impossível usar execute_string e execute_file.

Na verdade, qualquer coisa que existe nas versões anteriores poderia ser feita usando o C++. Só que os navegadores, o iOS e o Android não suportam muitas dessas funções. O Windows obviamente suporta todas. Então, mesmo que fosse feito em Delphi, para exportar para outros formatos seria necessário remover essas funções.

A limitação não está no C++. O Runner em C++ que roda os jogos para Windows poderia muito bem rodar essas funções. Resumindo tudo: por causa das outras plataformas, não podemos ter mais as funções possíveis no Windows. Há também outros fatores, que o Kabeção citou.

Sendo esse o preço pros jogos tornarem-se comercializáveis, acho que até que não está tão caro.

Acho que o GM:S deveria permitir que você usasse essas funções, mas alertasse que não seria possível exportar para as outras plataformas.

Até mais!