Hoje, o aprendizado on-line está começando a realmente prejudicar o aprendizado em tempo integral. Até algumas universidades russas progressistas estão lentamente introduzindo cursos on-line projetados para substituir casais dentro dos muros das instituições de ensino. Mas quão real é tudo isso? Hoje falaremos sobre os problemas e as tendências do aprendizado on-line moderno.
E o que é mais conveniente para você: ir às aulas ou estudar em casa, envolto em uma manta?
Dou a palavra ao autor.Neste artigo, gostaríamos de compartilhar com você pensamentos sobre os problemas e as tendências do aprendizado on-line moderno, bem como sobre a possibilidade de criar projetos de RV que possam ser integrados ao e-learning moderno.
No mundo moderno, o conceito de aprendizagem on-line (e-Learning) é complexo e inclui vários componentes:- Aprendizado misto - treinamento que combina aulas com um instrutor e treinamento on-line com opções para atividades "fora da sala de aula". Um aluno pode criar projetos, usar a ajuda de mentores e assim por diante. A aprendizagem combinada pode ser síncrona e assíncrona (a versão síncrona implica feedback instantâneo sobre o desempenho acadêmico do professor. A assíncrona usa o conceito de tarefas independentes em casa);
- Aprendizagem móvel - Treinamento usando dispositivos móveis;
- Aprendizagem informal - atividade fora do ambiente formal (aula, aula on-line etc.). Esse tipo de aprendizado funciona através da interação social.
Se considerarmos a evolução do aprendizado on-line no contexto das teorias socioculturais, o desenvolvimento ocorreu do behaviorismo ao construtivismo social. Inicialmente, o sistema de treinamento foi construído com base em princípios comportamentais - o professor estava localizado no centro e ao seu redor havia alunos que o ouviam silenciosamente.
A transição para modelos de aprendizagem mais complexos começou com o trabalho de Lev Vygotsky, que sugeriu que a aprendizagem ocorre como resultado da interação social com outras pessoas. A partir desta tese, surgiram teorias construtivistas. Eles sugerem que o conhecimento não é externo ao aluno, ou seja, cada aluno constrói seu próprio modelo de conhecimento específico. Usando esses modelos, o foco muda de professor para aluno, que extrai conhecimento de várias fontes.
Mais alguns conceitos de aprendizagem são modelos conectivistas e sociais. Eles sugerem que o conhecimento é uma rede de várias fontes interconectadas. Consequentemente, a quantidade de conhecimento aumenta à medida que as fontes são adicionadas à rede. As fontes podem ser, por exemplo, pessoas ou livros ou a Internet.
Realizando conceitos
Surge a pergunta: "Como implementar todas as formas de treinamento?" Tradicionalmente, se considerarmos o desenvolvimento da esfera do e-Learning, enormes sistemas e protocolos foram criados sob o conceito behaviorista (baseado em instruções). Mas o ponto era que todos os sistemas foram construídos sob a presença de um certo pacote de conhecimento. Ele pode ser formado na forma em que é necessário para a integração em um sistema específico.
Construindo um sistema de aprendizado centrado no aluno e um novo protocolo de aprendizado
Historicamente, o protocolo SCORM foi inicialmente usado ativamente na Força Aérea dos EUA e assumiu um sistema de treinamento comportamental. E isso implicava que as ações do aluno eram completamente irrelevantes - ele deveria simplesmente memorizar todas as informações fornecidas. O SCORM, no entanto, está se tornando obsoleto e se tornando menos eficaz ao longo do tempo. Agora surge a questão com mais urgência: "Como organizar um sistema educacional centrado no aluno usando serviços on-line no mundo moderno?"
Para responder a essa pergunta, três pontos devem ser levados em consideração:
- O sistema deve ser centrado no aluno;
- O sistema deve apoiar o aprendizado combinado;
- O treinamento no sistema deve ser com experiência social.
Para levar em conta a primeira tese, você precisa usar caminhos de aprendizado individuais. No entanto, com essa abordagem, torna-se necessário obter uma enorme quantidade de dados sobre o comportamento do aluno.
Para resolver o problema estipulado na segunda tese, chegamos à idéia das características dos atuais protocolos SCORM e AICC. Eles sugerem trabalhar on-line, ou seja, se o treinamento ocorrer em uma sala de aula ou em uma sala de aula, então automaticamente seu uso se torna impossível.
O principal problema no campo da educação social, como fala a terceira tese, é a falta de desenvolvimento. No entanto, agora há muita conversa sobre esse tipo de treinamento, mas ninguém realmente sabe como implementá-lo corretamente. Chegou a hora de introduzir novos padrões para os protocolos de treinamento. SCORM é substituído por xAPI.
xAPI
A principal idéia por trás do desenvolvimento do xAPI é a separação das estatísticas do conteúdo do próprio material de treinamento. Isso é necessário para opções mais flexíveis para coletar essas estatísticas. Por exemplo, se o material didático não existir em formato eletrônico, digamos que o aluno receba informações por meio de um livro.
Outro paradigma é a simulação, sempre se destacou. A simulação é um ambiente em que o aluno pode fazer o que quiser. No entanto, para alcançar o resultado desejado, a pessoa recebe dados de entrada, mas ele escolhe a “rota” para passar a simulação. Atualmente, todo treinamento em VR e jogos sérios funcionam fora dos sistemas de treinamento, quase sem troca de dados. O xAPI permite integrar a troca de dados ao treinamento em VR, o que não é possível usando o protocolo SCORM.
Construindo espaços virtuais
Tradicionalmente, os sistemas de e-learning evoluíram como sistemas da web. Consequentemente, o vetor de desenvolvimento passou da Web 1.0 para a Web 2.0 - isto é, para a criação de conteúdo gerado pelo usuário. E esse paradigma é muito adequado para sistemas de treinamento, principalmente devido ao fato de oferecer aos professores meios bastante simples para criar conteúdo educacional.
Se você olhar para qualquer Sistema de Gerenciamento de Aprendizado agora, ele fornece meios muito bons para criar apresentações, vários testes e tudo o necessário para o desenvolvimento de um curso de treinamento, enquanto tudo isso é feito diretamente no navegador. Obviamente, existem várias ferramentas de autoria de terceiros e elas são ativamente usadas, especialmente para criar um conteúdo mais complexo - mas no final da cadeia ainda temos a Internet e a publicação em um formato adequado para incorporação em uma página da web.
Mas o desenvolvimento de vários sistemas para trabalhar com conteúdo 3D deu completamente errado. Antes de tudo, nem todos os jogos (e os jogos eram longos o suficiente e permanecem agora, um dos motores do progresso nessa área) precisavam de uma rede. E especialmente - a rede é complexa. Além disso, os meios para criar conteúdo personalizado não são apenas algo novo (os editores de nível já têm muitos anos de idade), mas os meios para criar uma funcionalidade fundamentalmente nova, a modificação profunda já é visivelmente mais jovem. Tradicionalmente, acredita-se que um modder sabe o que está fazendo, isto é, pelo menos um pouco, mas ele sabe que a programação tem uma idéia de um pipeline para trabalhar com modelos 3D e outras coisas específicas.
Mas, neste caso, isso não é muito adequado, pois é necessário criar um sistema de treinamento e torná-lo acessível a todos. Ou seja, é necessário simplificar e, ao mesmo tempo, complicar a “modificação”, tornando-o mais semelhante ao modelo da Web 2.0., Sem perder a multiutilização. Vamos tentar ver como um jogo MMO padrão geralmente se parece e pensar sobre o que está faltando nessa arquitetura.
Diferentes Gerações MMO e Abordagens de Arquitetura
Se olharmos (a partir de uma altura muito alta, sem detalhes) sobre como qualquer espaço 3D multiusuário é organizado, por exemplo, o MMO padrão da era WoW, veremos algo como o seguinte:
Naturalmente, há um cliente e servidor. A principal tarefa do servidor é sincronizar as ações de vários usuários. Para isso, é determinado um protocolo fixo de comunicação entre o cliente e o servidor, com o qual podemos enviar mensagens do cliente para o servidor e, no caso mais simples, enviá-lo para todos os outros clientes. (É claro que há uma enorme camada de nuances associadas à implementação desse processo - por exemplo, o servidor é autoritário, como é compensado o atraso, como está o trabalho com a física, etc. -, mas nesse nível do circuito vale a pena pular isso). Além disso, você precisa rastrear a lógica das interações no servidor, por exemplo, scripts de jogos. Para isso, provavelmente, você precisará de algum tipo de script no lado do servidor. Para simplificar a vida, os scripts no lado do cliente também são muito úteis.
No entanto, surge a pergunta: "E de onde vem o conteúdo real desse esquema, isto é, modelos, texturas, sons e tudo isso?" Tudo isso está dentro do cliente. É por isso que os clientes MMO costumam ser tão pesados em termos de tamanho. Quando algo novo é adicionado, os usuários devem baixar a atualização e apenas o próprio desenvolvedor, seus programadores e artistas podem adicionar algo novo.
Surge a pergunta: "O que precisa ser alterado na arquitetura para permitir que os usuários criem conteúdo?"
A idéia aparece imediatamente para armazenar conteúdo no lado do servidor. Nesta versão, o cliente é mais como um navegador da web - ele baixa tudo o que você precisa e armazena em cache.
Vários projetos foram feitos nessa direção, o mais famoso dos quais, talvez, é o Second Life. O uso desse esquema em sua forma pura nem sempre é justificado - algumas vezes uma abordagem híbrida é melhor quando parte do conteúdo é baixada diretamente (por exemplo, ao carregar uma nova cena) e parte é carregada dinamicamente.
A próxima pergunta é o que fazer com a lógica. Mesmo assim, o Second Life ofereceu um esquema de script de servidor, que era bastante exclusivo na época - o usuário escreveu o código do comportamento do objeto no editor de cliente embutido e, em seguida, o script foi enviado ao servidor e executado nele. Mas aqui também há uma série de perguntas. Primeiro, o script deve ter acesso a alguns subsistemas principais de servidores e surge a pergunta - quantos subsistemas devem ser e quais devem ser? Em segundo lugar, há uma pergunta sobre como a linguagem deve ser e como deve ser sua biblioteca padrão - a LSL, a linguagem de script do Second Life, era bastante primitiva e complicada ao mesmo tempo (por exemplo, não havia trabalho normal com matrizes e não havia OOP em princípio).
Extremo Oriente
O conceito é um pouco semelhante ao SL, mas difere em vários detalhes. Um elemento de um ambiente virtual pode ser um aplicativo completo que compila e tem toda a lógica necessária do trabalho "dentro" de si, ou seja, um tipo de caixa preta em termos de todo o sistema cliente-servidor e outros aplicativos. Ao mesmo tempo, todo o ambiente virtual pode atuar como uma interface de aplicativo possível, mas não a única. Ele complementa a biblioteca padrão, fornecendo várias funções para trabalhar consigo mesmo. Em outras palavras, isso é análogo a um aplicativo comum em um sistema operacional moderno, apenas o próprio ambiente executa a função do SO.
Além das interações no espaço 3D, o aplicativo virtual tem acesso à interface do cliente e a capacidade de criar suas próprias partes da interface. O restante - idealmente - o aplicativo não deve saber nada sobre a divisão em cliente e servidor. O código deve ser escrito da mesma maneira que um aplicativo comum de usuário único seria gravado.
Um ambiente virtual, cujos objetos são esses aplicativos, chamamos de ambiente virtual dinâmico.
No entanto, várias questões bastante óbvias surgem sobre a implementação prática de um sistema como: como combinar esses princípios com confiabilidade, desempenho e muitos outros critérios, e como implementar a arquitetura específica de tal projeto? Falaremos sobre isso no próximo artigo.
Os autores
A Jedium é uma empresa parceira da Microsoft que trabalha no campo da realidade virtual aumentada e da inteligência artificial. A Jedium desenvolveu uma estrutura para simplificar o desenvolvimento de projetos complexos no Unity, parte dos quais está disponível publicamente
no GitHub . A Jedium planeja reabastecer o repositório com novos módulos de estrutura, bem como soluções de integração com o Microsoft Azure.
Vitaliy Chashchin - Desenvolvedor de software com mais de 10 anos de experiência no design e implementação de aplicativos cliente-servidor tridimensionais - do conceito à completa implementação e integração de aplicativos e soluções no campo da realidade virtual. Arquiteto de Sistemas Jedium LLC, MSc em TI.
Alexey SarafanovGerente de Marketing na Jedium LLC.
Sergey KudryavtsevCEO e fundador da Jedium LLC.