Simple drop-in setup for UNet, PUN, and PUN2. No coding required!

Smooths Rigidbodies and Transforms over the network with ease. Just add the SmoothSync script to any game object and watch it be smoooooth.

We aimed to improve NetworkTransform on all fronts. Smooth Sync is more configurable, uses less bandwidth, and gives you smoother and more accurate syncing of your objects.

Used by over 1 million gamers!

Reduced Costs
We only send what you need, reducing the networking costs over Unity's Network Transform by up to 60%. Use Unity's own calculator to see just how fast it will pay for itself and save you money.

Interpolation and Extrapolation
Performs interpolation and extrapolation to compensate for lag.

Highly Configurable
Choose what you want to send and when you want to send it. Optionally compress floats to further reduce bandwidth. Customizable interpolation and extrapolation settings depending on your game's needs.

Example Scene
Comes with a fully functional and documented example scene.

Source Code
The full source code is provided so you can see everything with detailed comments.

Profressional Support
We have a consistent record of prompt and effective support. Contact us via email or forums any time and we will work with you to resolve any issue.

We are actively developing this plugin for use in our own multiplayer game so we are very fast to respond to issues and put out fixes.

Supports Rigidbody, Rigidbody2D, Transforms, child objects, dedicated servers, P2P setup, pausing, host migration, and authority / ownership changes. Let us know if you think we are missing something you need!

Runs on Windows, OSX, Linux, iOS, Android, WebGL, Windows Phone, Xbox, PlayStation, Nintendo. If Unity runs it, it'll run!

Asset version: 3.15


More Info: https://assetstore.unity.com/packages/tools/network/smooth-sync-96925


저작자표시

'0x0010 > Unity Asset' 카테고리의 다른 글

Mobile Fast Shadow v1.0.6  (0) 2019.02.16
Bubble Shooter Match 3 Complete Project  (0) 2019.02.16
GUI Animator for Unity UI v1.2.0  (0) 2019.02.13
LipSync Pro v1.44  (0) 2019.02.13
Easy UI Motion v1.1.4  (0) 2019.02.13




http://www.thisisgame.com/webzine/news/nboard/4/?n=91248

저작자표시

'0x0000 > News' 카테고리의 다른 글

스마트폰 시장 지각변동 이끌까? 삼성 갤럭시 S10, 접히는 스마트폰 공개  (0) 2019.02.22
엔씨소프트, 2018년 영업익 6천149억...사상 최대  (0) 2019.02.14
넷마블 "넥슨 인수, 현금·재무적 투자·차입으로 추진"  (0) 2019.02.13
순이익 90% 상승의 주역은 누구? 넥슨, 2018년 매출 2조 5,296억 기록  (0) 2019.02.13
리니지M의 꾸준한 성장세! 엔씨, 연간 매출 1조 7,157억 기록  (0) 2019.02.12




http://www.zdnet.co.kr/view/?no=20190212110916

저작자표시

'0x0000 > News' 카테고리의 다른 글

스마트폰 시장 지각변동 이끌까? 삼성 갤럭시 S10, 접히는 스마트폰 공개  (0) 2019.02.22
그저 버튼만 누르는 게임, 선형적인 게임 같은 건 만들지 않았다! 트라하 미디어 쇼케이스  (0) 2019.02.16
넷마블 "넥슨 인수, 현금·재무적 투자·차입으로 추진"  (0) 2019.02.13
순이익 90% 상승의 주역은 누구? 넥슨, 2018년 매출 2조 5,296억 기록  (0) 2019.02.13
리니지M의 꾸준한 성장세! 엔씨, 연간 매출 1조 7,157억 기록  (0) 2019.02.12







https://www.gamemeca.com/view.php?gid=1528116

저작자표시

'0x0000 > News' 카테고리의 다른 글

그저 버튼만 누르는 게임, 선형적인 게임 같은 건 만들지 않았다! 트라하 미디어 쇼케이스  (0) 2019.02.16
엔씨소프트, 2018년 영업익 6천149억...사상 최대  (0) 2019.02.14
순이익 90% 상승의 주역은 누구? 넥슨, 2018년 매출 2조 5,296억 기록  (0) 2019.02.13
리니지M의 꾸준한 성장세! 엔씨, 연간 매출 1조 7,157억 기록  (0) 2019.02.12
엔씨소프트, “넥슨 인수, 전혀 검토하고 있지 않다”  (0) 2019.02.12




http://www.thisisgame.com/webzine/news/nboard/4/?n=91180

저작자표시

'0x0000 > News' 카테고리의 다른 글

엔씨소프트, 2018년 영업익 6천149억...사상 최대  (0) 2019.02.14
넷마블 "넥슨 인수, 현금·재무적 투자·차입으로 추진"  (0) 2019.02.13
리니지M의 꾸준한 성장세! 엔씨, 연간 매출 1조 7,157억 기록  (0) 2019.02.12
엔씨소프트, “넥슨 인수, 전혀 검토하고 있지 않다”  (0) 2019.02.12
한국어와 모든 DLC 포함, '어쌔신 크리드 3 리마스터' 3월 29일 출시  (0) 2019.02.11


C++에서는 함수로부터 객체를 전달받거나 함수에 객체를 전달할 때 '값에 의한 전달' 방식을 사용합니다.

함수 매개변수는 실제 인자의 사본을 통해 초기화되며, 어떤 함수를 호출한 쪽은 그함수가 반환한 값의 사본을 돌려 받습니다.

 

위의 내용처럼 사본을 만들어내는 원천이 바로 복사 생성자 입니다.

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
class Person 
{ 
public : 
    Person(); 
    virtual ~Person(); 
 
private: 
    std::string name; 
    std::string address; 
}; 
 
class Student : public Person 
{ 
public : 
    Student(); 
    ~Student();
 
private : 
    std::string schoolName; 
    std::string schoolAddress; 
}; 
 
bool ValidateStudent( Student s ); 
 
Student plato;
 
bool platoIsValid = ValidateStudent( plato );

 

 

plato로부터 매개변수 s를 초기화시키기 위해 Student의 복사 생성자가 호출된다. s는 ValidateStudent가 복귀할 때 소멸된다. Student 객체가 생성될 때마다 string 멤버도 생성된다. 게다가 Student 객체는 Person 객체로부터 파생되었기 때문에, Student 객체의 생성자가 호출되기 이전에 Person 객체가 생성된다. Person 객체가 생성될 때에도 string 멤버도 생성된다.

이처럼 Student 객체를 값으로 전달하는 데 날아간 비용을 보면, 생성자 6번 소멸자 6번입니다.
 
위와 같은 방식의 문제점을 해결하기 위해서는?

 

bool ValidateStudent( const Student& s ); //참조의 의한 전달 방식으로 바꾸기만 하면 됩니다. 

 

이렇게 할 경우,

 

우선 새로 만들어지는 객체라는 것이 없으므로 생성자/소멸자가 호출되지 않는다.

그리고 const를 붙임으로써 전달인자로 보낸 객체가 함수에 의해 변하지 않는다는 것을 명시해준다. 원래 값에 의한 전달 방식때도 원본 객체는 보호되는데 그 의미를 그대로 적용한 것이라고 보면 됩니다.

 

또한, '복사 손실' 문제도 없어집니다. 아래의 코드를 봅시다.

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
class Window 
{ 
public : 
    std::string GetName() const; 
    virtual void Display() const; 
}; 
 
class WindowWithScrollBars : public Window 
{ 
public :  
    .... 
    virtual void Display() const; 
}; 
 
void PrintNameAndDisplay( Window w ) 
{ 
    std::cout << w.GetName(); 
    w.Display(); 
} 
 
WindowWithScrollBars wwsb;
 
PrintNameAndDisplay( wwsb );
 
 
위의 코드는 wwsb 객체가 PrintNameAndDisplay() 함수의 인자로 전달될때 값의 의한 전달을 하게되는데, 이렇게 되면 WindowWithScrollBars 객체의 구실을 할 수 있는 부속 정보가 전부 싹뚝 잘립니다.
PrintNameAndDisplay() 함수안에 w는 어떤 타입의 객체가 넘겨지든 아랑곳없이 Window클래스 객체의 면모만을 갖게 됩니다. 그래서
PrintNameAndDisplay() 함수내에서 w.Display(); 는 Window::Display() 일것니다.
 
즉! 이런 '복사 손실' 을 방지하려면
void PrintNameAndDisplay( const Window& w );
 
참조의 의한 전달로 바꾸시면 됩니다.
 

참조자는 보통 포인터를 써서 구현됩니다. 즉, 참조자를 전달한다는 것은 결국 포인터를 전달한다는 의미인데,

전달하는 객체 타입이 기본제공 타입(int, char 등) 이라면 참조자보다는 값에 의한 전달을 하는 쪽이 더 효율적일 때가 많다.

 

기본제공 타입은 대개 크기가 작은 편이다.

그러나! 타입 크기가 작다고 해서 전부 값에 의한 전달이 효율적이지는 않다.

한개의 포인터 멤버만 가지고 있는 객체가 있다면(STL 컨테이너가 대표적) 이 객체를 복사할 때 포인터가 가리키는 대상까지 복사하는 작업도 따라다녀야 해서 오히려 비용이 더 들 수 있게 된다.

 

객체 크기도 작고 복사 생성자도 간단하게 만들어졌다 해도, 일부 컴파일러에서 기본제공 타입과 사용자 정의 타입을 다르게 취급할 수 있기 때문에(레지스터에 들어가는지 안들어가는지의 차이가 존재한다) 수행 성능에 있어서 차이를 보일 수 있다.

 

또한 사용자 정의 타입은 크기 변화에 언제든 노출이 되어있다. 지속적으로 추가 될 수 있는 부분이 있다는 말입니다.

 

이것 만은 잊지 말자!

◆ '값의 의한 전달' 보다는 '상수 객체 참조자에 의한 전달'을 선호 합시다. 대체적으로 효율적일 뿐만 아니라 복사 손실 문제까지 막아 줍니다.

◆ 이번 항목에서 다룬 법칙은 기본제공 타입 및 STL 반복자, 그리고 함수 객체 타입에는 맞지 않습니다. 이들에 대해서는 '값에 의한 전달'이 더 적절합니다.



저작자표시

'0x0001 > Effective C++' 카테고리의 다른 글

[Effective C++] 항목 19 : 클래스 설계는 타입 설계와 똑같이 취급하자  (0) 2019.02.13
[Effective C++] 항목 18 : 인터페이스 설계는 제대로 쓰기엔 쉽게, 엉터리로 쓰기엔 어렵게 하자  (0) 2019.02.13
[Effective C++] 항목 17 : new로 생성한 객체를 스마트 포인터에 저장하는 코드는 별도의 한 문장으로 만들자  (0) 2019.02.13
[Effective C++] 항목 16 : new 및 delete를 사용할 때는 형태를 반드시 맞추자  (0) 2019.02.13
[Effective C++] 항목 15 : 자원 관리 클래스에서 관리되는 자원은 외부에서 접근할 수 있도록 하자  (0) 2019.02.12

C++에서 새로운 클래스를 정의 한다는 것은 새로운 타입을 하나 정의하는 것과 같습니다. 

좋은 타입이란?

1) 문법이 자연스러움

2) 의미구조가 직관적

3) 효율적인 구현이 한가지 이상 가능해야 합니다.

 

클래스 설계시 신경써야 하는 것?

 

1) 새로 정의한 타입의 객체 생성 및 소멸은 어떻게 이루어져야 하는가?

메모리 할당 함수(operator new, operator delete)들을 직접 작성시 생성자, 소멸자에 대한 설계에 영향을 미치게 됩니다.

 

2) 객체 초기화는 객체 대입과 어떻게 달라야 하는가?

초기화와 대입을 확실히 헷갈리지 않는 거이 가장 중요합니다.

 

3) 새로운 타입으로 만든 객체가 값에 의해 전달되는 경우에 어떤 의미를 줄 것인가?

어떤 타입에 대해 '값에 의한 전달'을 구현하는 쪽은 복사 생성자입니다.

 

4) 새로운 타입이 가질 수 있는 적법한 값에 대한 제약은 무엇으로 잡을 것인가? 

  

5) 기존의 클래스 상속 계통망에 맞출 것인가?

멤버 함수가 가상인가 비가상인가의 여부가 상속에 있어서 큰 요인이 됩니다.  다른 클래스들이 상속할 수 있게 만들자고 결정했다면, 이에 따라 멤버 함수의 가상 함수 여부가 결정됩니다. 특히 소멸자가 그렇습니다.

 

6) 어떤 종류의 타입 변환을 허용할 것인가?

암시적 : T1 -> T2 타입 변환시 T1 클래스에 타입변환 함수를 넣어두던가, 인자 1개로 호출되는 non-explicit 생성자를 T2에 넣는다.

명시적 : 해당 변환을 맡는 별도 이름의 함수를 만들되 위에서 언급한 것들은 만들지 않는다.

 

7) 어떤 연산자와 함수를 두어야 의미가 있을까? 

 

8) 표준 함수들 중 어떤 것을 허용하지 말 것인가? 

허용되지 않는 것은 private 멤버가 될 것이다.

 

9) 새로운 타입의 멤버에 대한 접근권한을 어느쪽에 줄 것인가? 

private, protected, public 영역 및 프렌드 등에 대한 고민이다.

 

10) 선언되지 않은 인터페이스로 무엇을 둘 것인가? 

보장할 수 있는 부분은 수행 성능 및 예외 안전성, 그리고 자원 사용이다. 보장한다고 결정하면 클래스 구현에 있어 제약으로 작용한다. 

 

11) 새로 만드는 타입이 얼마나 일반적인가? 

 

12) 정말로 꼭 필요한 타입인가? 

기존 클래스에 기능 몇개가 아쉬워 파생 클래스를 새로 정의한다면, 간단하게 비멤버 함수나 템플릿을 정의하는 것이 낫다.

 

이것 만은 잊지 말자!

◆ 클래스 설계는 타입 설계입니다. 새로운 타입을 정의하기 전에, 이번 항목에 나온 모든 고려사항을 빠짐없이 점검해 보십시오.



저작자표시

'0x0001 > Effective C++' 카테고리의 다른 글

[Effective C++] 항목 20 : 값에 의한 전달보다는 상수객체 참조자에 의한전달 방식을 택하는 편이 대개 낫다.  (0) 2019.02.13
[Effective C++] 항목 18 : 인터페이스 설계는 제대로 쓰기엔 쉽게, 엉터리로 쓰기엔 어렵게 하자  (0) 2019.02.13
[Effective C++] 항목 17 : new로 생성한 객체를 스마트 포인터에 저장하는 코드는 별도의 한 문장으로 만들자  (0) 2019.02.13
[Effective C++] 항목 16 : new 및 delete를 사용할 때는 형태를 반드시 맞추자  (0) 2019.02.13
[Effective C++] 항목 15 : 자원 관리 클래스에서 관리되는 자원은 외부에서 접근할 수 있도록 하자  (0) 2019.02.12


어떤 인터페이스를 어떻게 써 봤는데 결과 코드가 사용자가 생각한 대로 동작하지 않는다면, 그 코드는 컴파일 되지 않아야 맞습니다. 거꾸로 생각해서, 어떤 코드가 컴파일 된다면 그 코드는 사용자가 원하는 대로 동작해야할 것입니다.

 

'제대로 쓰기에 쉽고, 엉터리로 쓰기에 어려운' 인터페이스를 개발 하려면?

우선 사용자가 저지를 만한 실수의 종류를 머리에 넣어 두고 있어야 합니다.  

 

1
2
3
4
5
6
7
8
9
10
11
12
class Date
 
{
 
public :
 
    Date( int month, int day, int year );
 
}; 
 
Date d( 30, 3, 1995 ); // 3, 30 이어야 하는데 30, 3을 넣음.
Date d( 3, 40, 1995 ); // 3, 30 이어야 하는데 3, 40을 넣음. 

 

위의 코드는 어찌보면, 문제될게 없어보이지만, 사용자가 쉽게 실수를 저지를수 있습니다.

위의 주석대로 매개변수의 전달 순서가 잘못될 여지가 있습니다.

 

위의 문제는 간단한 랩퍼 타입을 각각 일, 월, 연을 만들고 이 타입을 Date 생성자 안에 두면, 어느정도 해결 됩니다.

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
struct Day 
{ 
    explicit Day( int d ) 
        : day( d ) 
    {} 
    int day; 
}; 
 
struct Month 
{ 
    explicit Month( int m ) 
        : month( m ) 
    {} 
    int month; 
};
 
struct Year 
{ 
    explicit Year( int y ) 
        : year( y ) 
    {} 
    int year;
}; 
 
class Date 
{ 
public : 
    Date( const Month& m, const Day& m, const Year& y ); 
};
 
Date d( 30, 3, 1995 );                   // 에러. 타입이 틀림.
Date d( Day(30), Month(3), Year(1995) ); // 에러. 타입이 틀림. 
Date d( Month(3), Day(30), Year(1995) ); // OK

 

위와 같이 적절한 타입만 제대로 준비되어 있으면, 각타입의 값에 제약을 가하더라도 괜찮은 경우가 생기게 됩니다.

 

예를 들어,

월이 가질 수 잇는 유효한 값은 12개이므로, Month 구조체 타입에 이 사실을 제약조건으로 부여할 수 있다.

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
class Month
{ 
public : 
    static Month Jan() { return Month( 1 );  } 
 
    static Month Feb() { return Month( 2 );  } 
 
    ...  
 
    static Month Dec() { return Month( 12 ); } 
 
private : 
    explicit Month( int m ); // Month 값이 새로 생성되지 않도록 명시호출 생성자가 private 멤버이다. 
 
    ... 
 
};  
 
Date d( Month::Jan(), Day(30), Year(1995) );

 

 

사용자 실수로 예상되는 것중에 또 하나는 다음과 같은 경우가 있다

 

if( a * b = c ) ... // '='가 '=='가 되어야 맞다

 
우리는 항목 3에 잘 설명해논, operator*의 반환 타입을 const로 한정함으로써 사용자가 사용자정의 타입에 대해 위와같은 실수를 저지르지 않도록 할 수 있었습니다.

 

 

기본적으로 우리는 int등의 타입이 어떻게 동작하는지 그 성질을 이미 다 알고 있기 때문에, 사용자를 위해 만드는 타입도 웬만하면 이들과 똑같이 동작하게 만드는 센스를 갖추어야 합니다.

 

이것은 일관성 있는 인터페이스를 제공하기 위해서입니다.

STL 컨테이너의 인터페이스는 전반적으로 완벽하진 않지만, 일관성을 갖고 있으며, 이때문에 사용하는데 큰 부담이 없습니다.

ex ) STL컨테이너 size() 멤버함수를 개방해 놓음

 

사용자 쪽에서는 뭔가를 외워야 제대로 쓸 수 있는 인터페이스는 잘못 쓰기 쉽습니다.

 

예를 들어,

이전 항목 13 에서 봤던 createInvestment() 팩토리 함수의 경우, 클래스 포인터를 반환한다.

함수에서 얻어낸 포인터는 동적 할당된 자원이기 때문에, 종료 전에 반드시 메모리를 해제해야한다.

사용자는 다음과 같은 실수를 저지를 수 있습니다.

 

1) 포인터 삭제를 잊어버렸다!

2) 같은 자원에 delete를 두번 해버렸다!!

 

이전 항목 13 에서는 이 문제를 해결하기 위해 스마트 포인터를 이용했다.

그러나 사용자는 스마트 포인터를 사용해야 한다는 사실을 모르면 어떻게 할까요?

 

그 해결책,

애초부터 팩토리 함수가 스마트 포인터를 반환하게 만드는 것입니다.

 

std::tr1::shared_ptr<Investment> createInvestment();

 

위와같은 방법으로 구현되면, 사용자는 무조건 해당 타입에 맞게 받아줘야합니다. 그렇지 않으면 에러가 납니다.

게다가 std::tr1::shared_ptr은 생성 시점에 자원 해제 함수(일명 삭제자)를 직접 엮을 수 있는 기능을 갖고 있기 때문에, 자원해제에 관련된 상당수의 사용자 실수를 사전 봉쇄할 수 있습니다.

 

또하나, std::tr1::shared_ptr은 '교차 DLL 문제'를 방지해준다.

 

서로 다른 DLL 사이에서 new와 delete를 했을 경우, 꼬여서 런타임 에러가 발생하는 것을 막아준다는 것입니다.

왜냐하면 기본 삭제자가 무조건 동일 DLL에서 이 짝을 수행할 수 있게 설계되어있기 때문이고, std::tr1::shared_ptr은 생성시에 그해당 DLL을 붙잡고 있기 때문입니다.

 

참고로, tr1::shared_ptr을 구현한 제품 중 가장 흔히 쓰이는 것은 Boost 라이브러리 입니다. 부스트의 shared_ptr은 일단 크기가 원시 포인터의 두배이고, 느리며, 내부 관리용 동적 메모리 까지 추가로 들지만, 사용자의 실수는 눈에 띄게 줄어들것입니다.

 

이것 만은 잊지 말자!

◆ 좋은 인터페이스는 제대로 쓰기에 쉬우며 엉터리로 쓰기에 어렵습니다. 인터페이스를 만들때는 이 특성을 지닐 수 있도록 고민하고 또 고민합시다.

◆ 인터페이스의 올바른 사용을 이끄는 방법으로는 인터페이스 사이의 일관성 잡아주기, 그리고 기본제공 타입과의 동작 호환성 유지하기가 있습니다.

◆ 사용자의 실수를 방지하는 방법으로는 새로운 타입 만들기, 타입에 대한 연산을 제한하기, 객체의 값에 대해 제약 걸기, 자원 관리 작업을 사용자 책임으로 놓지 않기가 있습니다.

◆ std::tr1::shared_ptr은 사용자 정의 삭제자를 지원합니다. 이 특징 때문에 std::tr1::shared_ptr은 교차 DLL 문제를 막아주며, 뮤텍스 등을 자동으로 잠금 해제하는데 쓸수 있습니다.


저작자표시

'0x0001 > Effective C++' 카테고리의 다른 글

[Effective C++] 항목 20 : 값에 의한 전달보다는 상수객체 참조자에 의한전달 방식을 택하는 편이 대개 낫다.  (0) 2019.02.13
[Effective C++] 항목 19 : 클래스 설계는 타입 설계와 똑같이 취급하자  (0) 2019.02.13
[Effective C++] 항목 17 : new로 생성한 객체를 스마트 포인터에 저장하는 코드는 별도의 한 문장으로 만들자  (0) 2019.02.13
[Effective C++] 항목 16 : new 및 delete를 사용할 때는 형태를 반드시 맞추자  (0) 2019.02.13
[Effective C++] 항목 15 : 자원 관리 클래스에서 관리되는 자원은 외부에서 접근할 수 있도록 하자  (0) 2019.02.12

+ Recent posts

티스토리툴바