Nesse QuickQuest (antes Terça do que nunca...) Fernando fala sobre algo que não é nada trivial para desenvolver mas que parece ser imprescindível para a indústria - Visual Scripting (também conhecida como Visual Programming. Será que Visual Scripting é tão importante assim? Será que salva tempo? O Secco deixa a questão no ar e quer saber, vocês acham que Visual Scripting é tão importante assim ou é coisa da nossa cabeça?
Links:
Faça perguntas e sugira assuntos para os próximos QuickQuests pelo e-mail contato@podquest.com.br ou no Twitter @ThePodQuest.
Ouça no link a seguir:
(botão direito, depois "salvar como" para baixar)
Ou ainda, adicione o feed e tenha todos os episódios quando quiser!
No iTunes, vá em "Advanced - Subscribe to Podcast" e cole o endereço acima.
6 comentários:
Eu sou artista 3D e não entendo nada de programação.
Venho trabalhando com a UDK já a algum tempo e posso dizer que tanto o Kismet como o Material Editor dela são fenomenais. Já domino boa parte do editor de materiais e estou começando a fazer algumas mecânicas simples como abrir portas, desativar colisões, etc...
Os programadores daqui do estúdio acham o paradigma da UDK muito atrasado, que em termos de "produtividade programática" a Unity é bem melhor do que a UDK.
Gostaria da opinião de vocês sobre isso. Pois vejo que para na UDK, uma vez superado o problema de configuração de projeto, ela seria mais produtiva que a Unity apenas para fazer FPS. Acredito que fazer um jogo de luta como MK na UDK seria muito mais complexo do que na Unity, justamente devido a falta de nodes para ações específicas no Kismet. Todos esses nodes teriam que ser criados, para depois serem usados no Kismet, pelo pouco que entendo da mecânica de desenvolvimento da UDK, pois ela meio que força a tudo acontecer pelo Kismet.
Claro que aqui estou levando em consideração apenas a parte da programação, pois é claro que a parte gráfica da UDK (Shaders, Luz, PostProcessing) é ainda infinitamente superior a Unity.
Nunca usei VScripting mas pelo que vi é uma ótima ferramenta tanto para dev quanto artista. Pois acho eu que o desenvolvedor ao escrever seu script, ele possa ver depois em Visual Scripting. Sendo assim uma ferramenta onde o artista possa compreender e visualizar a lógica do dev.
Muito bom Fernando! Me apresentastes um adorável mundo novo, de Technical Artists que não sabem programar! Como conheço um "N" relativamente pequeno de TechArtist, e todos eles sabem programação, sempre achei que fosse um pré-requisito para exercer tal função no mercado de jogos, principalmente por que aqueles que trabalham nesta função muitas vezes precisam fazer um "meio de campo" entre o artista e o programador, e isso pode implicar em desenvolver scripts para ferramentas 2D, 3D para export de assets. Até fiquei curioso em saber como trabalham os TechArtists das empresas que vocês trabalham?
Sobre Visual Scripting, como tive momentos traumáticos com esse tipo de sistema (Virtools) que me mostraram como não é possível ter controle de todas as variáveis quando se faz um jogo realmente complexo. Desde então nunca mais mexi com nada que o valha, e sempre recomendo que o desenvolvedor dê uma olhada em alguma engine escriptada ou totalmente visual (Game Maker da vida), pois nos dois casos você sabe até que ponto você irá com o seu jogo/protótipo. Dito isso, gostaria de saber se alguém aqui utiliza uma engine/tool com Visual Scripting no trabalho, tranquilamente?
É isso, abraços!
Mais um ótimo QuickQuest.
Já usei Visual Scripting, mas depois queria saber como estava funcionando por baixo e tentar arrumar a rotina para funcionar da minha maneira.
Acho que VS é bom para artistas que não tem muita prática com código, porém o Secco também citou um ponto interessante. Se um artista aprende a lógica em VS com um pouco mais de esforço poderia aprender a implementar um método de uma classe, etc... Porém acho que isso vai acabar variando do grau de afinidade da pessoa com uma linha de código.
Tenho um exemplo concreto, de amigos que criavam games completos usando o Game Maker ou o Construct e quando passaram para a Unity (que é uma das engines mais "fáceis" de aprender) procuravam avidamente por um editor visual, na época não tinha nenhum, hoje ela já tem a UScript, PlayMaker (essa usa FSM), etc... Ou seja o processo de desenvolvimento deles que constumavam conseguir criar um game todo do zero sozinho, foi quebrado, quando foi exigida uma área que eles "não querem" adentrar.
Já usei Visual Scripting porém em games jam, onde a velocidade do desenvolvimento importa no resultado final. Mas acho que em situações normais é preferível a utilização da codificação mesmo.
Grande Fernando,
Muito legal esse seu quickquest.
No mundo do áudio, eu acho que os softwares que usam Visual Scripting são úteis quando o escopo do problema é comum e recorrente. Casos mais específicos sempre precisam de uma análise mais especializada.
O FMOD talvez seja a ferramenta mais interessante que usa esse conceito. Se usada corretamente, pode resolver problemas muito rapidamente que se aplicam a quase todos os jogos, principalmente os que usam música dinâmica.
Postar um comentário