Resposta originalmente postada no Quora, por Renato de Pìerri em 28/07/2019
Personagens Clássicos
Por que contamos histórias? A motivação de contarmos histórias, segundo Carl Jung, pode ser explicada a partir da noção do inconsciente coletivo. Trata-se de um conhecimento nato que podemos passar a vida inteira sem nunca o notarmos.
Dentro desse inconsciente coletivo há temas universais e personagens que se manifestam em nossa cultura na forma de histórias e estão presentes na literatura, música, arte, filme e jogos.
O inconsciente coletivo do Jung é a base de nossa conexão a certos tipos de personagens universais e esses personagens são utilizados em toda a área do entretenimento para aumentar a conexão entre a audiência e a história.
Herói:
O herói é o personagem central em um jogo single player. Ao criar um personagem herói, tenha em mente que esse herói será o avatar do jogador e o jogador deve se identificar e gostar desse personagem. Ao herói sempre é apresentado um problema no início do jogo e ele entra em uma jornada, física ou emocional, a fim de resolver o desafio. O herói executa a maioria das ações e assume a maioria dos riscos e responsabilidades. Luke Skywalker é um tipo clássico de personagem herói
O sombra é um personagem extremamente importante. Ele representa o oposto do herói, é o vilão da história. Trata-se do responsável por todos os problemas do herói. Dependendo do jogo, esse personagem fica escondido até chegar ao climax da história e nada impede que o shadow seja o lado negro do herói. Darth Vader, por exemplo.
O mentor orienta o heroi dentro da trama da história (ou jogo). Provê informações para o herói, faz a função de conselheiro e pode orientar pois tem experiência prévia. Obi Wan Kenobi e Yoda são exemplos de mentores. Ah! O mentor também pode dar orientações furadas e colocar o herói em apuros.
O aliado é um personagem que ajuda na evolução do heroi durante a jornada e pode ajudá-lo em tarefas difíceis de se executar sozinho. Han Solo e Chewbacca do Star Wars são exemplos de aliados.
Guardião:
O guardião está lá para “atrapalhar” o progresso do herói se valendo de todas as artimanhas que forem necessárias, até que o herói prove seu valor e o guardião o libere. Podemos considerar um guardião clássico a Esfinge que guarda os portões de Tebas na peça grega Édipo. A Esfinge (guardiã) testa o Édipo (herói), propondo uma charada. Édipo a responde corretamente e consegue entrar em Tebas continuando sua jornada, caso contrário seria devorado.
Trickster (trambiqueiro):
O trambiqueiro é um personagem neutro que está lá para enganar. Pode causar um dano severo por conta de suas pegadinhas, interrompendo a evolução do personagem ou podem ser um personagem cômico para suavizar a trama da história. C3PO E R2D2 são exemplos de personagens trickster e podem assumir a posição de co-adjuvante do heroi ou até assumir o papel de sombra.
Herald (mensageiro):
O mensageiro serve para facilitar a mudança de rumo (ou de level) na história e fornecer orientação. Um exemplo de personagem ‘herald’ seria a princesa Leia que pede por ajuda e acaba motivando Luke Skywalker a seguir sua jornada.
Protagonista:
Dentro dos arquétipos de Carl Jung, o primeiro deles é o protagonista, que pode se confundir com o arquétipo do herói. Trata-se do personagem principal. Jogos single-player são centrados nesse personagem e a história do jogo é contada a partir do ponto de vista do dese personagem, mesmo que o jogo não seja em primeira pessoa. Gordon Freeman em Half-Live, por exemplo.
Uma das funções do protagonista é levar a história adiante, agir antes de reagir e fazer as coisas acontecerem. O protagonista pode até perder o controle por conta de um ataque, mas ele sempre recupera o controle da situação. Lara Croft (Tomb Raider) e Ezio Auditore da Firenze (Assasin’s Creed II) são protagonistas.
Outro ponto importante no protagonista é que ele tenha falhas como qualquer humano, aproximando-o de sua audiência e gerando empatia. As falhas podem ser na forma física como uma paralisia, ser feio, ter culpa por um crime cometido no passado ou ser como o Super Homem que não aguenta nem uma Kriptonita.
Antagonista:
É o contrário do herói. É o vilão do jogo. Do ponto de vista do Jung seria o arquétipo do sombra, porém nem sempre o antagonista é malvado. O pró e o antagonista podem simplesmente ter pontos de vista diferentes como liberal x conservador, privado x público ou mesmo estilo de vida diferentes entre um e outro.
Caso protagonista e antagonista tenham um mesmo objetivo em uma história, eles podem se aliar, o que é chamado de união de opostos, dado que a resolução de um determinado conflito é mais importante no momento.
Co-Protagonista:
Co-Protagonista une forças com o protagonista na história. Muitas vezes esses personagens aparecem em games multiplayer massivos (MMOs) que precisam de times. Esse tipo de personagem pode iniciar no jogo como antagonista, mas no decorrer do game se tornam co-protagonistas a partir de um determinado evento ou embate.
Fonte:
NOVAK, Jeannie. GAME DEVELOPMENT ESSENTIALS: AN INTRODUCTION. 3. ed. United States: Delmar Cenage Learning, 2012. 514 p. ISBN 13: 978-1-111-30765-3.
Se você instalou o Maven para Rodar com o Windows e está tentando usar o Oracle JDeveloper ou alguma outra IDE da Oracle e as coisas não estão funcionando muito bem, talvez seja a hora de ajustar algumas configurações no seu Windows.
Baixe o Maven do site da Apache próprio para o Windows, descompacte e mova a pasta com o Maven para a pasta Arquivos de Programas ou para o diretório de sua escolha.
Em propriedades do sistema do Windows, adicione a variável de ambiente M2_HOME com o valor do caminho do Maven
Adicione a variável de ambiente M2 nas variáveis de ambiente com o valor %M2_HOME%\bin
Adicione a variável de ambiente MAVEN_OPTS com o valor -Xms256m -Xmx512m
Adicione a variável de ambiente JAVA_HOME. Ela deve apontar para o diretório raiz do JDK (o diretório do JRE não serve para nada).
Inclua %M2% na variável de ambiente Path
Inclua %JAVA_HOME%\bin na variável de ambiente Path
No prompt de comando execute mvn –version para verificar se o Maven instalou ok.
Olha, dei uma lida no Sommerville e lá está escrito mais ou menos o seguinte:
Requisitos funcionais:
É
a definição das funcionalidades que um sistema de software deve
fornecer. Esse tipo de requisito informa como o sistema deve trabalhar
os dados de entrada e quais informações devem ser geradas na saída.
Serve
para definir o comportamento do sistema em situações específicas. Os
requisitos funcionais também servem para definir o escopo do sistema de
software ao limitarem explicitamente o que o sistema deve ou não deve
fazer.
Requisitos não funcionais:
Esse
tipo de requisito trata das limitações nos serviços ou funções
oferecidas pelo sistema baseando em parâmetros como “número de
transações por segundo”, “número de usuários operando o sistema ao mesmo
tempo” ou limitações impostas por padronizações, por exemplo.
Requisitos
não funcionais muitas vezes se aplicam à implementação e operação do
sistema como um todo ao contrário de focar em funcionalidades e ou
serviços individuais de sistemas.
Na
verdade, há uma linha não muito clara entre o que é requisito funcional
e não funcional. Dependendo da abordagem isso pode ficar confuso.
Um
requisito de usuário de segurança como limitar o tempo de acesso de
usuários autenticados, pode se enquadrar como requisito não funcional.
Entretanto
quando visto com mais detalhes, o requisito de limitar o tempo de
acesso de usuário pode se desdobrar em outros requisitos claramente
funcionais.
Esse desdobramento pode levar o requisito da limitação do tempo de acesso a ser tratado como um requisito funcional.
Isso
mostra que requisitos de um sistema de software são interligados e um
requisito pode gerar limitações, influenciar ou mesmo acabar gerando
outros requisitos.
Os requisitos de sistema entretanto não só especificam serviços ou funcionalidades do sistema.
Eles também especificam o que é necessário para assegurar que os serviços e funcionalidades sejam efetivamente entregues.
Aí galera, segue a minha visão sobre o assunto depois de dar uma lida no Sommerville.
Um
dos objetivos do processo de elucidação de requisitos é conhecer o
trabalho que os stakeholders (interessados no projeto) querem
implementar no sistema, de forma a ajudá-los em suas atividades.
Durante
a elucidação de requisitos, os engenheiros de software trabalham junto
com os stakeholders para entender o domínio da aplicação.
Os
engenheiros de software levantam as atividades trabalhadas, os
serviços, as funcionalidades que precisam ser implementadas no sistema,
bem com tomam conhecimento da performance desejada e assimilam as
limitações impostas pelo hardware, dentre outros pontos.
Dado
que pessoas, incluindo stakeholders, normalmente tem dificuldades em
definirem requisitos de forma abstrata, muitas vezes eles são levantados
a partir de exemplos da vida real, mais fáceis de serem obtidos.
Pessoas
são capazes de descrever como enfrentam situações particulares ou são
boas em descreverem como seria possível, a elas, melhorarem seus métodos
de trabalho.
Levantamento
de histórias e cenários é uma ferramenta poderosa para que engenheiros
de software capturarem esse tipo de informação, normalmente descrita em
linguagem natural.
De
posse dessas histórias e cenários, o engenheiro de software os utiliza
nas reuniões com os stakeholders para definir quais funcionalidades do
software devem ser implementadas e ou deprecadas.
Para saber mais:
SOMMERVILLE, Ian. Software Engineering: Tenth Edition. 10. ed. Boston: Pearson, 2016. 796 p. ISBN 13: 978-0-13-394303-0. –
Esses
dias eu estava acessando alguns sites e começou a dar aquele maldito
erro informando que a conexão não é confiável, cada vez que tentava
acessar sites do governo.
Isso
acontece porque o governo emite seus certificados de segurança e por
algum motivo o certificado raiz não consta na instalação do Windows e
Linux. Fica faltando e é uma droga.
Como faz para resolver esse B.O?
O
incomodado tem que sair procurando o certificado certo, fazer o
download e instalar. É um inconveniente no calor das entregas das
tarefas do escritório, fora que se formatar o computador, tem que fazer
tudo de novo.
Isso é um saco para quem manja de TI e deve ser Aramaico para quem é de humanas.
Esse funcionário público que teve essa ideia merece uma caixa de Bis de presente. Quem o conhecer, mande os parabéns!
Uma
vez encontrado um arquivo com todos certificados, bastaria descompactar
e instalar os certificados, mas aí o problema complica:
São 164 certificados (em 2022)!
Cada um tem que dar uma meia dúzia de cliques nos locais certos.
Se fizer errado, o certificado não instala direito, fica tudo zoado e não funciona.
Há risco de esquecer de instalar alguns certificados.
Há o risco de ficar reinstalando certificados já instalados.
O processo é demorado pra caramba, leva cerca de 1 hora por computador, muito tempo para uma pequena empresa, por exemplo.
“Ainda bem que sei programar” entra a partir desse ponto.
Após uma breve internetada, achei um script de PowerShell, o ajustei para as minhas necessidades e mandei rodar.
Como eu fiz?
O código pronto está aí embaixo. em linhas gerais:
Baixei e descompactei o arquivo em um diretório temporário
Abri o editor do PowerShell e naveguei até o diretório
Dei um “ls>diretorio.csv” para listar o diretório em um arquivo csv
Abri o arquivo no Excel e com umas fórmulas, montei o caminho dos arquivos
Depois usei essa informação para montar o script
Instalou todos certificados de uma vez em menos de 1 minuto.
Na prática fazer isso pela primeira vez levaria o mesmo tempo que fazer manualmente, mas dessa forma todos certificados foram instalados corretamente (com certeza), com os cliques corretos e sem esquecer de ninguém. Fora que nas próximas, supostamente sofrerei menos com a instalação de certificados, fora que hoje 07/2022 eu tive de repetir essa instalação e rodou em minutos, pois eu já tinha feito o caminho das pedras 🙂
Programadores entenderão:
O script está aqui, é específico para minha máquina e não segue nenhuma das boas práticas de programação, mas resolveu o B.O.
Um
Schmitt trigger é um circuito comparador com histerese implementado
pela aplicação de realimentação positiva à entrada não inversora de um
comparador ou amplificador diferencial.
Ele é um circuito ativo que converte um sinal de entrada analógica em um sinal de saída digital.
O
circuito é chamado de “gatilho” (trigger) porque a saída retém seu
valor até que a entrada mude o suficiente para disparar uma mudança no
sinal de saída.
O
Schimitt trigger possui dois níveis de disparo que são o ‘limiar
superior’ e o ‘limiar inferior’ conforme indicado na função de
transferência exibida abaixo:
Os
eixos horizontal e vertical correspondem respectivamente à tensão de
entrada e de saída. T e −T são os limites de comutação, e M e −M são os
níveis de tensão de saída.
O diagrama abaixo compara o comportamento de um circuito Schimitt triger com um buffer, ambos não inversores.
Configuração inversora e não inversora:
Na
configuração não inversora, quando a entrada é maior que o limiar
superior, a saída é alta. Quando a entrada está abaixo do limiar
inferior, a saída é baixa e, quando a entrada está entre os limiares
inferior e superior, o valor na saída do circuito é constante.
Na
configuração inversora, quando a entrada é maior que o limiar superior,
a saída é baixa. Quando a entrada está abaixo do limiar inferior, a
saída é alta e, quando a entrada está entre os limiares inferior e
superior, o valor na saída do circuito é constante.
Esse
comportamento de limiar de disparo duplo que o sinal de saída muda
quando o sinal de entrada atinge valores limiares distintos, é chamada
de histerese. Podemos até dizer que o Schimitt trigger possui memória e
pode atuar como um multivibrador biestável (latch ou flip-flop).
Existe uma estreita relação entre os dois tipos de circuitos: um Schimitt trigger pode ser convertido em um latch e vice versa.
Schimitt trigger serve para fazer o condicionamento de sinais em circuitos digitais reduzindo o ruído dos mesmos, particularmente reduzindo (não elimina completamente em alguns casos) o efeito de repique (bounce) de chaves eletromecânicas. Também são utilizados em configurações com feedback em loop negativo, implementando osciladores de relaxamanto que encontram aplicação em geradores de função e fontes de alimentação chaveadas.
Há várias maneiras de se implementar um circuito Schmitt trigger e uma delas seria pela utilização de um amplificador operacional.
Pode-se
fazer um conversor analógico-digital utilizando um amplificador
operacional cuja entrada analógica recebe o sinal e a saída do
amplificador operacional fornece o sinal de saída digital.
Isso
é possível por conta do alto ganho do amplificador operacional e quando
o sinal passa de um certo limite, a saída satura ou corta imediatamente
como em um processo de avalanche.
Abaixo
seguem dois diagramas básicos (não são circuitos completos), um
utilizando a entrada não inversora e outro utilizando a entrada
inversora de um amplificador operacional:
Comparador não inversor:
Para
o comparador não inversor os dois resistores R1 e R2 formam um somador
de tensão paralela. Ele soma uma parte da tensão de saída à tensão de
entrada, aumentando-a durante e após a comutação, que ocorre quando a
tensão resultante está próxima de zero. Este feedback positivo paralelo
cria a histerese necessária que é controlada pela proporção entre as
resistências R1 e R2. A saída do somador de tensão paralela é em relação
ao terra, então o circuito não precisa de um amplificador com entrada
diferencial. Como os amplificadores operacionais convencionais têm uma
entrada diferencial, a entrada inversora é aterrada para criando o ponto
de referência zero volts.
Comparador inversor:
Para
a versão utilizando o comparador inversor, a atenuação e a soma são
separadas. Os dois resistores R1 e R2 atuam apenas como um divisor de
tensão (atenuador “puro”). O loop de entrada atua como um somador de
tensão simples que soma uma parte da tensão de saída em série à tensão
aplicada no circuito de entrada. Este feedback positivo em série cria a
histerese necessária que é controlada pela proporção entre as
resistências de R1 e a resistência do conjunto R1 e R2. A tensão efetiva
aplicada à entrada do amplificador operacional está flutuando, logo, o
amplificador operacional deve ter uma entrada diferencial.
Maiores detalhes sobre essa configuração pode ser vista na Wikipedia e está bem detalhada no livro The Art of Electronics.
Na eletrônica digital:
A implementação desse tipo de circuito é representada pelos símbolos abaixo e normalmente estão dentro de circuitos integrados:
Símbolo
que representa um Schmitt trigger. Ele possui o desenho de uma curva de
histerese dentro do símbolo lógico de um buffer, cuja saída pode ser
normal ou inversa (com a bolinha). Detalhes acerca do comportamento de
um circuito integrado Schmitt trigger deve ser verificada na
documentação do componente, que é fornecida pelo fabricante.
O
código binário refletido (reflected binary code – RBC), também
conhecido como código binário refletido (reflected binary RB) ou código
cinza (Gray code – depois dos estudos de Frank Gray), consiste da
ordenação do sistema numeral binário de maneira tal que dois valores
binários sucessivos tenham apenas um bit de diferença entre ambos.
O
código Gray foi inicialmente projetado para minimizar o efeito de
ruídos aleatórios causados pelo chaveamento de dispositivos
eletromecânicos como relés.
Hoje
em dia o código Gray é largamente utilizado para facilitar a correção
de erros em sistemas de comunicação digital como em televisão e em
alguns sistemas de TV a cabo.
Considerando
um sistema de posicionamento eletromecânico que faz uso de uma contagem
binária, é muito improvável que interruptores físicos consigam comutar
simultaneamente à medida que ocorre o posicionamento desse sistema e
essa falta de sincronismo causa ruídos no circuito. Para contornar essa
limitação, foi criado o Gray Code, que somente uma chave por vez muda de
estado à medida que o posicionamento acontece, contornando o problema
da falta sincronização na atuação das chaves mecânicas.
Abaixo
segue uma tabela exibindo a diferença entre o código binário e o código
Gray. Conforme dito, note que no código Gray, apenas um bit muda entre o
valor anterior e o valor posterior.
Aplicações:
Em matemática pode ser aplicado na resolução do problema da Torre de Hanoi.
Émile Baudot utilizou o código Gray nos telégrafos em 1878.
Frank
Gray patenteou em 1953 um método para converter sinais analógicos para o
código Gray utilizando válvula,que fez o sistema “pegar o seu nome”.
Minimização de circuitos booleanos (lógica digital) na rotulação dos eixos do mapa de Karnaugh.
É
utilizado em sistemas de posicionamento tanto lineares como rotativos
(encoder). Inicialmente era eletromecânico e atualmente utiliza sensores
óticos, de efeito hall ou usa outras tecnologias eletrônicas.
Figura: Petruzella
Também pode ser aplicado em outras áreas como algoritmos genéticos, minimização de circuitos eletrônicos e correção de erros, por exemplo.
O Game Design Document (GDD) é muito mais que um documento de conceito ou proposta de negócio.
É
normal que um GDD tenha algo entre 50 e passe de 200 páginas. O
propósito do GDD não é servir de apoio para vender uma ideia. Pelo
contrário, seu principal objetivo é ser um guia de referência ao
processo de desenvolvimento de um jogo (game).
O
GDD tem que focar no modo de jogo (gameplay), roteiro (storyline),
personagens, interface e regras do jogo. O GDD deve especificar o
projeto com detalhes suficientes e de tal forma que seja possível, em
teoria, jogar o jogo sem o uso de um computador.
Inclusive
poder jogar uma versão em papel do jogo construida a partir do GDD é na
verdade um modo barato de se entender e depurar o projeto do jogo. A
prototipagem em papel sempre deve ser considerada durante o processo de
desenvolvimento do game.
Devido
ao tamanho do GDD, um índice deve ser inserido logo após a página de
título do documento. Esse documento tem que ser entendido como parte do
processo de desenvolvimento do jogo e deve ser atualizado constantemente
à medida que o projeto é desenvolvido.
Como
boa prática deve-se ter certeza que o GDD esteja disponível a todos no
projeto de tal forma que os membros do time possam fazer as atualizações
conforme o necessário a qualquer tempo (obviamente um controle de
versionamento tipo GIT deve ser adotado).
O GDD deve conter em sua descrição basicamente os seguintes elementos, não se limitando à lista abaixo:
Interface do jogo
– indicando os elementos do jogo, tempo de produção, custo, requisitos
das interfaces, viabilidade da interface, audiência e gênero do jogo.
Mundo do jogo
– níveis e elementos presentes em cada nível do jogo bem como a
descrição dos mesmos. Inclui arte, cinemática, animações, itens
disponíveis e informações acerca de itens perigosos.
Habilidades dos personagens e itens – como funciona o ataque e defesa dos personagens, o que faz cada NPC, o que e como os personagens podem pegar de itens.
Game engine
– o que pode ser feito e o que não pode ser feito no desenvolvimento do
jogo. Esta parte do GDD serve para manter todos desenvolvedores
alinhados com os recursos disponíveis e comportamento geral do jogo
abordando tópicos como número de personagens por tela, animações por
personagem, restrições de câmera, paleta do mapa de textura e outras
informações que padronizem o desenvolvimento do game.
Você
utilizará como game engine a interface 2D do GameSalad, ou utilizará a
engine 3D do Unity? Sites exibidos logo a seguir. Essa decisão, por
exemplo, é definida na seção Game Engine.
Tenha
em mente que o GDD pode variar dependendo no nível de detalhes e
demandas do projeto, mas é para isso que ele serve e o que ele
basicamente deve conter.
Fonte: NOVAK, Jeannie. GAME DEVELOPMENT ESSENTIALS: AN INTRODUCTION. 3. ed. United States: Delmar Cenage Learning, 2012. 514 p. ISBN 13: 978-1-111-30765-3.
À medida que o tempo passa e que uma música é tocada conforme indicado na figura abaixo, ocorre o seguinte processo:
Diagrama geral da conversão Analógica para digital
Um sistema de sincronismo, gera um sinal de clock que vai sincronizar o trabalho todo.
Esse
sinal de clock de tempos em tempos dispara uma ordem para que seja
“tirada uma foto” da música que está tocando. Em outras palavras: o
clock aciona um circuito para tirar uma amostra do sinal de áudio.
Essa amostra do sinal de áudio corresponde ao volume do som que está sendo tocado, é uma voltagem que pode ser maior ou menor.
Esse
amostra indicando a intensidade instantânea do som é enviada para um
conversor analógico digital que converte esse valor para um número
digital, composto por zeros e uns.
Por último esse número digital é gravado na memória.
Na
hora de tocar a música, basta fazer o caminho contrário: Ir lendo na
mesma velocidade que foram gravados esses números e ir convertendo esses
números para intensidade de som (converter de digital para analógico)
para depois acionar o alto falante e reproduzir a música.
Abaixo
tem o diagrama em blocos de um circuito integrado conversor Analógico –
Digital mais antiguinho com saída em dados paralela (D0 – D9) para ser
gravado na memória:
E
aqui o diagrama em blocos de um conversor Analógico – Digital, mais
moderno com interface SPI para conectar em um Arduino, por exemplo:
Pergunta originalmente postada o Quora, em nov/2016
Em circuitos digitais quando:
Um sinal é ‘ativo baixo’, significa que o sinal irá executar sua função quando seu nível lógico for 0
Um sinal é ‘ativo alto’, significa que o sinal irá executar sua função quando seu nível lógico for 1
Considerando o sinal ‘habilita_clock’, a figura abaixo mostra um exemplo de sinal ativo alto no lado esquerdo e um exemplo de sinal ativo baixo no lado direito da figura.
Diferença entre ‘ativo alto’ e ‘ativo baixo’.
Simples assim. Espero que ajude. Dê uma setinha para cima se você achar útil.
