East Agent's Blog

일단 사용해 보면 vi도 갖다 버린다는 Sublime Text 2(ST2) 에디터를 Unity3D와 함께 사용하는 방법에 대한 글입니다. 

ST2로 Unity3D의 스크립트를 편집하기 위해서는 ST2의 몇 가지 패키지들을 설치해야 합니다. 아래 참조에 나와 있는 링크들에 자세하게 설명이 나와 있지만, 실제로 사용하기 위해서 설정해 보니 아래 링크들에서 설명하고 있는 부분과 조금 다르거나 설명이 미흡한 부분이 있어, 보충해서 글을 올립니다. 

이 때 주의할 점은 저장하는 프로젝트의 이름이 *.sln 파일에서 '-csharp'을 제외한 이름으로 저장해야 한다는 점이다. 

e.g.) SublimeUnityTest-csharp.sln 인 경우 저장하는 Sublime Text 에디터의 프로젝트 이름은 SublimeUnityTest가 되어야 한다. 

Sublime Text 에디터의 Unity Builder System에서는 빌드시 .sln 파일을 사용하는데, 사용하는 .sln 파일을 Sublime Text 에디터의 프로젝트 파일 이름에 '-csharp' postfix가 추가된 .sln 파일을 찾아서 빌드하기 때문이다. (이미지의 "cmd" 부분 참조)

Sublime Text 에디터에서 선택한 Unity3D API의 도큐먼트를 오픈하는 것도 가능하다. 사용 방법은 아래 링크에서 참조:

이 블로그에 오시는 분들 모두, 올 2010년 한 해에도 늘 즐겁고 행복한 일들과 함께 하시길 바랍니다.

(사진은 정초에 오른 북한산의 동장대에서 바라본 풍경입니다)

폭력으로 엮이고 얽힌 등장 인물들의 관계도 흥미롭고 이것을 아내와 남편 그리고 아내의 정부(더 이상이 자세한 언급은 스포일러라 생략)의 시선으로 이야기한 점도 재미있다. 또 매끄러운 번역도 추리 소설의 긴장감을 더한다. 작가의 명성에 걸맞게 번역도 흠잡을데가 없다. (...작가 미우라 시온은 나오키 상 수상자라고)

Integrating Physics with the game engine

I am not making a physics engine, just implementing 'as-much' physics as
required for my game


Once you start doing proxy-against-concave-mesh, and
multiple-contact-constraints, the difference will start to diminish.
Especially the "handle multiple contacts" part ends up more or less leading
you to actually write a physics engine. If you want physics without writing
a physics engine, use either an open source physics engine (Bullet, ODE) or
a "free for PC" commercial physics engine (NVIDIA PhysX, Havok Physics).

Regarding structure, I find that each subsystem should have its own data
structures, optimized for that subsystem. Thus, you may have a RigidBody
with some BodyCollisionShapes on it. Separately, you have an AnimatableMesh
with some Materials and Animations on it. You may also have a SoundSource
with some PlayingCues, and one or more SpecialEffects, and maybe even an
InputListener. Each of those are for a separate subsystem (physics,
animation, sound, scene graph, input in these cases).

The "game object" as such is the union of all these sub-components. There
are a few ways of doing that union:

1) Each subsystem allow *you* to define the ID of each subsystem object. You
say "create a rigid body, and call it '3'." A game entity is then just the
ID, and it's created as a collective hallucination of all the subsystems
that happen to have an object with that ID.

2) There's a bit struct with a pointer to every kind of component: struct
Entity { RigidBody *body; AnimatedMesh *animated; ... }; An entity comes to
life with NULL everywhere, and you populate it as appropriate.

3) You build an abstraction for "being a component" and for "containing
components." The entity is then a container for components. You write
component wrappers for each of rigid body, animated mesh, sound source, etc.
The entity is then created as a component container with whatever components
in it that you need. If you want editor support for arbitrary component
packages, for a fancy designer-built world, then this approach, plus XML
serialization, will get you there. The container will generally contain a
message bus, reflection support, etc.

The main problem you have to solve is how to get data from "here" to
"there." For example, the physics object collides with a wall, and thus
needs to adjust the animation to not penetrate an arm. Or the graphics scene
graph node moves, and you need the sound emitter to move as well. Generally,
this kind of data ends up in the "entity" component, so the "pure" ID
approach is not too common. However, if each of the subsystems can accept
some kind of "pull" input for common data like position, and the
authoritative source of that information can "push" it, then it can still be
done reliably and without pain.

Sincerely,

jw