while(true){ //게임 루프
updateScene(elapsedTime);
renderScene(elapsedTime);
}
이렇게 돌린다고 치고
void updateScene(double elapsedTime){ //업데이트(로직) 루프
foreach(GameObject obj in gameObjects){
obj.update(elapsedTime); //이렇게 각 객체를 업데이트해주면 되겠지
}
}
void renderScene(double elapsedTime){ //렌더링 루프
drawBackground(); //배경 그리고
foreach(GameObject obj in gameObjects){
obj.render(); //오브젝트 그리고
}
}
그러면 게임 루프는 신경쓸 게 없지
class Enemy extends GameObject{
int state = 0;
public void render(){
swich(state){
case 0: draw(motion1); break;
case 1: draw(motion2); break;
}
}
}
요런식으로 객체가 지가 지 상태 따라 그려주는거지
가릿?
ㅇ맞음
선 리플후 감상
오옹... 알거 같은데, 근데 죽는 에니메이션이 돌아간다고 쳤을 때, 예를 들어 destroying=100 에서 destroying=0 까지 진행되면 이제 그 에니메이션이 끝난다고 가정할 때
destroying 이라는 변수는 Enemy 가 가지고 있어야 겠네??
글케 되면 멤버변수가 너무 많아지지 않아? ... 그다지 신경쓸만한 요소가 아닌가?
ㅇㅇ 글치 elapsed time 받아서 경과시간에 따라 애니메이션의 프레임을 계산하거나 현재 위치나 상태를 바꾸거나 하는건 update 루프에서 돌리고 (gameObject 인터페이스에서 기본적으로 update 랑 render 메소드를 정의해주면 좋겠지) 렌더링 할 땐 걍 그거 따라 뿌려만 주고
그리고 그 destroying 이라는 변수를 컨트롤 하는 주체는 updateScene 가 되는게 자연스러움?
깔끔하고 좋잖앙? 그리고 detroying 같은건 사실 애니메이션이 실행되는 길이잖아? 애니메이션 객체에서 각 프레임의 딜레이랑 프레임 수만 갖고 있으면 되는거지
그리고 updateScene 에서 if(isDestroy) { destroying--; } 이런식으로 되는거죠?
근데 이럴 때 마다 if 가 중복되니까 그냥 쓰레드로 돌리는건 어떤가요? 구려요? 죽었을 당시 그냥 destroying--; 을 하는 쓰레드를 돌리는거죠. (시간 종속적으로)
obj 의 update 메소드에서 해야지 그걸
스레드로 돌리는건 바보짓이랑게
스레드가 얼마나 비싼데 폭탄 하나 터져서 캐릭터가 백 마리 죽으면 스레드 백 개 돌릴거야?
프레임속도는 CPU 속도에 비해 존나 느린시간임, 프레임 과 프레임 사이에서 존내 많은 작업 가능
요즘 cocos2d 라는 게임엔진을 써보고 있는데 여기선 쓰레드로 돌리는거 같드라고. 예를 들면 [obj runAction:[CCMoveTo actionDuration:0.6 어딘가로가라]]; 이런식으로. 그럼 메인 루프랑 상관없이 0.6 초 동안 그 스레드가 살아남아서 액션을 수행하더라고
물론 완전한 쓰레드 그런 느낌은 아니고 꽤 저렴하게 구현할 수 있는 스케쥴링 하나 생성해서... 별론가?
내가 cocos2d 를 안 써봐서 모르지만 이벤트 루프에 등록하는 방식일 거 같은데.. 스레드를 따로 생성하는 거면 너무 관리 비용이 크지 않나?
그게 나쁘단 게 아니고 굳이 그렇게까지 해야 하는 이유가 있냐는거지.. 뭐 결론은 자기 꼴리는대로 하는거긴 하지만
아 깜빡했다. 이벤트큐에 등록해서 하는 방법이었음...;
moveToRight 랑 moveToLeft 가 동시에 돌아가면 스레드 둘이 존나 싸우면서 무한루프로 갈텐데 그런 지옥을 굳이 왜..
스레드 쓰고 싶으면 풀 만들어서 쓰시고
이벤트큐도 결국은 내가 저 위에 싸놓은 그 구조의 연장이랑게
뭐 딱히 방법이 없구나. 그냥 updateScene 에서 if 검사해서 상태 업뎃하고 렌더러는 그냥 화면에 찍는 역할이고 여튼 답변 고마워~
ㅇㅇ 이해했음
저구조가 좋다는 거지 , 반드시 따라할 필욘 없는거 같음 , 여러형태로 만들어보거나 구상한거 있으면 구상한대로 해보시길
[성대아싸] // 지금 생각하고, 해왔던 구조도 저런식인데... 혹시 내가 틀린 방법으로 하고 있을까 해서. 여러 상태가 추가될 때 마다 멤버변수 늘어나고 뭔가 이상하드라고...
ㄴ destroying 같은 멤버변수 만들지 말고 애니메이션클래스 - 프레임 클래스 만들어서 애니메이션을 관리하고 state 를 enum 이나 int 같은걸로 만들어서 추상화 레벨을 한 단계 더해보면 어떨깡?
ㄴ 함 생각해보껭