Olá pessoal, segue um vídeo para ajudar quem tem projetos indies, trabalhando com amigos ou usando mais de um pc para desenvolver.
Por favor, deixem o feedback de vocês e se acharam útil, curtam o vídeo.
Valeu.
Olá .
Eu infelizmente não tenho muito tempo disponível pra aprender a usar o Perforce e muito menos pra configurar um servidor (sou usuário Git, que é inviável pros tamanhos dos arquivos binários), então uma solução mais simples como a sua é muito útil pra mim e pretendo aplicar, pelo menos por enquanto.
Mas, dito isso, vou confessar que não entendi muito bem. COMO fazer eu entendi, você foi super claro. Mas não captei porque você faz esses passos.
Por exemplo:
- Por que você tem uma pasta Local e uma Nuvem (sendo que parece que deixou de usar a Local)?
- Por que mudar a extensão do arquivo pra que “ele não possa ser executado no Dropbox”?
- Por que fazer esse “link” entre a pasta do Dropbox e outra pasta? Qual é a diferença entre fazer isso ou simplesmente criar o seu projeto já dentro da pasta do Dropbox? (editado: ok, agora saquei que, sem isso, não tem como ignorar as pastas Intermediate e Save
)
Olá Marcio Daniel,
Realmente o vídeo não está completo no quesito ‘porquês’. Agradeço o feedback e para os próximos vídeos trarei explicações mais detalhadas.
Respondendo suas perguntas:
-As pastas Local e Nuvem eram apenas para representar os locais em que os arquivos se encontravam no momento. No começo estavam na pasta Local, representando assim estarem disponíveis apenas para mim localmente. Já quando passo a utilizar a pasta Nuvem, mesmo sendo local, quis representar que os arquivos agora estavam na “nuvem”.
-Como o link criado para o .uproject é um Hardlink, ou seja, é apenas um atalho comum do windows, a não alteração da extensão faria com que, quando executado o .uproject na sua pasta local, ele seria executado também dentro da pasta do Dropbox, criando assim as pastas Intermediate e Save, o mesmo propósito da terceira questão.
Valeu.
Beleza, entendido. Valeu pelas dicas, vou tentar botar em prática.
Eu já testei essa implementação com o amigo Ricardo aqui do forum, funciona legal, mas tem um problema sério. o level (mapa) não pode ser trabalhado junto. Ou seja, duas ou mais pessoas que estiverem executando o projeto ao mesmo tempo e cada um colocar ou mover um actor no level, mudar textura ou coisas assim, corre o risco de ter perdido ou sobreescrever o trabalho de outro colaborador.
Minha sugestão é para que quando usarem isso, deixar apenas 1 colaborador cuidando do level. Os desenvolvedores e quem estiver cuidando do Blueprint, AI etc. utilizem projetos paralelos para desenvolver e depois atualizem o projeto. Tome cuidado também com o botão SAVE, salve apenas aquilo que você trabalhou, pois ele pedirá para salvar também arquivos de outras pessoas que podem estar sendo editados no momento do seu save.
Do mais é uma ótima, estamos utilizando com moderação já a algum tempo.
Só mais uma coisa, existem um vídeo ( não tenho o link aqui ) em Inglês mas de fácil acompanhamento no youtube, façam uma busca para completar o entendimento.
Sim, de fato, pra mim funcionaria porque apenas eu estou trabalhando nos meus projetos por enquanto. Até porque não é bem um controle de versão, não há histórico de alterações nem nada. É mais um backup na nuvem. Mas é melhor do que manter os arquivos apenas no HD do computador.
Pelo pouco que vi, ao usar o Perforce, você “trava” um asset antes de editá-lo e libera ao submeter as alterações pro controle de versão, impedindo que outros desenvolvedores editem o mesmo asset. O que é necessário para os arquivos binários (ideal mesmo é se alguns assets fossem em formato de texto, como os mapas, materiais e blueprints, que permitissem fazer facilmente um merge…).