Editores e tabelas de configuração têm suas próprias vantagens.
Não importa quão complexo seja o jogo de cartas, mesmo que seja Fantasy Westward Journey, Westward Journey ou mesmo Wow, não há problema em usar uma mesa correspondente. Mas Honkai Impact 3, ou Devil May Cry, jogos de luta e editores visuais são as únicas opções.
Quando comecei a configurar habilidades nos estágios iniciais de desenvolvimento, a experiência do editor superou completamente a tabela de configuração. Mas na fase posterior, quando eu queria ajustar muitas habilidades, estava realmente "chorando e gritando" (mas então pensei que se fizesse uma ferramenta para tornar o editor uma função de importação e exportação para a tabela de configuração (pode também ser xml ou json), deve ser capaz de resolver alguns problemas). Se a lógica for suficientemente clara, combinar tabelas é a maneira mais eficiente de trabalhar, mas a capacidade expressiva das tabelas é muito fraca e os picos de efeitos especiais (pontos centrais) de algumas habilidades muitas vezes não são o que parecem ser.
Atualmente, nosso projeto usa tabelas de configuração. Há alguns dias, quando estávamos fazendo um herói, encontramos uma armadilha. O centro de efeitos especiais e o centro de posição real não estavam no mesmo lugar. Como usamos tabelas de configuração, foi particularmente difícil de depurar, então escrevi um simples A lógica de visualização
usa Unity OnDrawGizmos.
OnDrawGizmos é um método de retorno de chamada no Unity, usado para desenhar gráficos de depuração na visualização da cena para ajudar os desenvolvedores a depurar visualmente a posição, limites, caminhos e outras informações de objetos de jogo. Esses gráficos serão exibidos apenas no editor e não aparecerão no jogo real construído. Isso é útil para depuração e layout de cena.
código mostrado abaixo
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
public class BulletVisual : MonoBehaviour
{
public float r = 3;
private void OnDrawGizmos()
{
DrawCirCle(gameObject.transform.position, r);
}
private void DrawCirCle(Vector2 center,float Radius,int VertexCount=50)
{
float deltaTheta = (2f * Mathf.PI) / VertexCount;
float theta = 0f;
Vector3 oldPos = center;
Debug.Log(oldPos);
for (int i = 0; i < VertexCount + 1; i++)
{
Vector3 pos = new Vector3(Radius * Mathf.Cos(theta), Radius * Mathf.Sin(theta), 0f);
Gizmos.DrawLine(oldPos, (Vector3)center + pos);
Gizmos.color = Color.red;
oldPos = transform.position + pos;
theta += deltaTheta;
}
}
}
Alguns amigos que escreveram isso podem perguntar: por que não usar o BoxCollider? Ele não forneceu uma linha visual?
Porque em projetos reais, os objetos com os quais colidimos geralmente são dados em vez de entidades. Na função DrawCirCle, podemos passar um conjunto de vetores vector2 para visualizar colisões "nos dados", o que é útil para depurar habilidades de escrita de tabelas de configuração. Útil, e você pode querer desenhar alguns gráficos personalizados na visualização da cena, não apenas formas simples de colisor. Por exemplo, você pode querer exibir um caminho, uma área de disparo, um alcance de proteção virtual, etc. na cena. Esses requisitos excedem a funcionalidade padrão do BoxCollider e você pode usar OnDrawGizmos para implementar visualização personalizada.
Lembre-se de habilitar Gizmos no SceneView.
É isso. . . . Procurei em toda a Internet por uma pergunta simples, mas não encontrei resposta. Gostaria de registrá-la aqui. Não percebi que o Gizmos estava fechado no SceneView, então nunca liguei para ele...