plitri

검색어 '전체'로 14개의 글을 찾았습니다.

  1. 2017.06.16 pliTri Github 그룹 개설 
  2. 2017.03.11 [Godot] GUI를 카메라에 영향받지 않도록 하기 
  3. 2017.03.11 [Godot] C2의 scale-in 구현 (반응형) 
  4. 2017.03.10 [Godot] Patch9Frame 
  5. 2016.05.08 팬티클락 ver 0.0.1 
  6. 2016.02.08 리듬게임 아이디어 
  7. 2016.01.31 [번역] 어떻게 리듬게임을 음악이랑 맞추나요? (레딧 댓글) 
  8. 2016.01.28 폭탄피하기 게임의 릴리즈가 늦어질 예정입니다. 
  9. 2016.01.13 1월 한달간 폭탄피하기를 만들고 있습니다. 
  10. 2015.11.12 스킨 통일에 관하여 + 잡담 

pliTri Github 그룹 개설

2017.06.16 15:28소식

pliTri 관련 공개 소스코드를 따로 모아 게시하기 위해 github.com/plitri 그룹을 개설하였습니다.

현재 저장소의 코드는 다음 두 가지입니다.

Construct 2 사용을 그만둘 생각이므로 작성했던 프로젝트들을 게시해볼까도 생각중입니다.

신고

'소식' 카테고리의 다른 글

pliTri Github 그룹 개설  (0) 2017.06.16
태그github

[Godot] GUI를 카메라에 영향받지 않도록 하기

2017.03.11 14:47학습/Godot 엔진

CanvasLayer 밑에 두래요.

참고

근데 왜일까요... (...) 아, 메뉴얼에 자세한 설명이 있었군요. 어쩌다보니 까먹었지만요. ParallaxBackground 도 CanvasLayer의 자식입니다.

아무튼 저거때문에 일시정지 메뉴의 루트를 바꿔버렸습니다. 잘 되네요. 일단 사용하는 입장에서는 자세히는 몰라도 되지 않을까 싶습니다.

어 그럼 C2의 Parallax Ratio는 어떻게 구현하지...?

ParallaxBackground 아래에 두면 되지 싶은데 확인하긴 번거로우니 나중에 필요할 때 알아보기로 하겠습니다.

신고

'학습 > Godot 엔진' 카테고리의 다른 글

[Godot] GUI를 카메라에 영향받지 않도록 하기  (0) 2017.03.11
[Godot] C2의 scale-in 구현 (반응형)  (0) 2017.03.11
[Godot] Patch9Frame  (0) 2017.03.10

[Godot] C2의 scale-in 구현 (반응형)

2017.03.11 12:33학습/Godot 엔진

참고자료


여러 방법이 있겠는데 저는 keep-width와 keep-height를 거꾸로 적용하는 방법으로 갔습니다.

저는 아래 코드를 자동로드(autoload / 싱글톤)에 넣고 구동했습니다. OS.get_window_size()가 모바일에서도 동작하는지는 아직 확인하지 않았습니다.

# https://godotengine.org/qa/9947/responsive-to-fit-multiple-resolutions
# https://sites.google.com/site/dsgodot/code-snippets/viewport-size
extends Node

var min_screen = Vector2(Globals.get("display/width"), Globals.get("display/height"))

func _ready():
	get_tree().connect("screen_resized", self, "_screen_resized");
	_screen_resized()

func _screen_resized():
	var scene_rect = OS.get_window_size()
	# print("DEBUG","Scene resized : " + str(scene_rect) )
	if scene_rect.width > scene_rect.height:
		get_tree().set_screen_stretch( SceneTree.STRETCH_MODE_VIEWPORT, SceneTree.STRETCH_ASPECT_KEEP_HEIGHT, min_screen )
	else:
		get_tree().set_screen_stretch( SceneTree.STRETCH_MODE_VIEWPORT, SceneTree.STRETCH_ASPECT_KEEP_WIDTH, min_screen )
	# print("DEBUG","Scene resized : " + str( get_tree().get_root().get_node("level_player/pause_ui").get_size() ) )

프로젝트 설정은 이렇습니다.

  • width, height 지정
  • stretch_mode - viewport
  • stretch_aspect - keep
  • 씬의 루트 노드는 풀스크린 앵커링된 컨트롤


이제 카메라 세팅하는 법 알아보러 가야...

신고

'학습 > Godot 엔진' 카테고리의 다른 글

[Godot] GUI를 카메라에 영향받지 않도록 하기  (0) 2017.03.11
[Godot] C2의 scale-in 구현 (반응형)  (0) 2017.03.11
[Godot] Patch9Frame  (0) 2017.03.10

[Godot] Patch9Frame

2017.03.10 02:29학습/Godot 엔진

128x128, 외곽 둥긂 32px 인 스프라이트로 확인하였습니다.




Region Rect는 스프라이트에서 9 Patch를 지정한 영역을 나타내는 듯 합니다. Width, Height 둘 다 0인 경우 아예 이미지 전체영역을 잡는 것 같습니다. 이미지 전체 기준일 경우 굳이 수정할 필요 없습니다.

Patch Margin은 상하좌우 테두리 영역인 듯 합니다.

Draw Center를 체크 해제하면 가운데가 비게 됩니다.

신고

'학습 > Godot 엔진' 카테고리의 다른 글

[Godot] GUI를 카메라에 영향받지 않도록 하기  (0) 2017.03.11
[Godot] C2의 scale-in 구현 (반응형)  (0) 2017.03.11
[Godot] Patch9Frame  (0) 2017.03.10

팬티클락 ver 0.0.1

2016.05.08 13:32게임들

@sftblw 계정 20만 트윗 기념으로 12시간동안 하루종일 제작했습니다. 결국 임시 리소스도 교체 못 했고 맵도 다 못 만들었군요 orz

1-1, 1-2, 1-3, 1-4, 2-1, 2-2의 6개 스테이지가 있습니다. 사운드는 없는 게 정상입니다.

제작툴은 Construct 2, 마저 만들지는 미지수입니다. 좀 난장판으로 만들었거든요.


파바방! 나님 20만 트윗 축하합니다!!!
사실 대부분이 RT지만요 :3#20만_트윗기념_이벤트

멘션받은 주제 중 몇 개를 골라 5분 이내 플레이타임의 게임을 만들겠습니다.

-제작 기간: 내일
-불가능한 주제는 거절가능
-주제선정: 내일 12시

— 씨-에이치- (Ch.さん) (@sftblw) 2016년 5월 6일

조작키는 방향키와 Z 키입니다. 모바일 미지원.

웹 플레이

다운로드 (Seagate NAS 경유)




신고

'게임들' 카테고리의 다른 글

팬티클락 ver 0.0.1  (0) 2016.05.08

리듬게임 아이디어

2016.02.08 16:52기타

플리트리는 항상 세 가지를 생각합니다.
이 아이디어에는 다음 세 가지입니다.

터치
인터렉션
전략

터치 리듬게임들이 놓치고 있는 가능성에 주목합니다. 타이밍과 이동에서 좀 더 높은 자유도를 주면서도, 더욱 많은 터치 동작의 가능성을 시도합니다. 롤모델은 비트스트림의 주변 드래그 노트와, 그루브 코스터의 다양한 노트 종류입니다.

게임은 인터렉티브 미디어입니다. 플레이어의 동작에 따라 다양한 부속 결과가 나타납니다. 현재의 대부분의 리듬게임은 점수와 체력 정도로 단편적인 상호작용만을 보일 뿐, 중간에 패턴이 동적으로 바뀌거나 하는 일은 적습니다. 롤모델은 태고의 달인과 각종 로그라이크 게임입니다.

패턴을 논파해내는데에도 전략적인 요소가 있을 수 있지만, 이래서는 여전히 단편적인 전략입니다. 게임으로서 즐길 수 있는 전략의 구성을 시도합니다. 롤모델은 JRPG와 뮤제카의 그라피카 입니다.

당장이라도 만들 것 같은 풍으로 글을 써놨지만, 단순한 아이디어 정리입니다. (웃음) 언제 만들지는 저도 모릅니다만 근시일내에는 어려울 것이라고 생각합니다.

신고

[번역] 어떻게 리듬게임을 음악이랑 맞추나요? (레딧 댓글)

2016.01.31 19:34기타

이 글은 번역입니다. 대충 의역한 부분이 많으니 찰떡같이 알아들으세요.
https://www.reddit.com/r/gamedev/comments/13y26t/how_do_rhythm_games_stay_in_sync_with_the_music/c78aawd

반가워요. 저는 리듬게임을 작업한 적이 있습니다. (영상, 영상, 영상)

고려할 게 두 가지가 있습니다. 가장 중요한 하나는 어떻게 플레이어의 입력을 정확하게 받아들이는 걸 보장해서 플레이어가 정확하게 보상받는 것처럼 느끼게 하느냐이고, 약간 덜 중요한 하나는 그래픽이 음악에 맞도록 보장해서 노트와 음악이랑 사용자 동작이 들어맞는 것처럼 보이게 하는 것입니다.

두 번째 거, 그러니까 사용자 동작/그래픽이랑 음악이 맞도록 하는 것부터 시작하겠습니다. 만드는 게임이 DDR이나 기타히어로랑 비슷해서, 음악이 재생하는 것에 따라 노트가 "판정선"(strum bar)을 향해 떨어지고, 노트가 그 막대기에 닿는 순간 플레이어는 키를 눌러야 한다고 가정해봅시다. 쉽네요. 그쵸? 그냥 이런 함수를 쓸 수 있겠죠.

(역주: 쓰지 마세요! 이후를 위한 예제입니다.)

renderNoteFallingDownScreen(id:int) {
    note[id].y = strumBar.y - (mySong.position - note[id].strumTime);
    // 노트[id].y = 판정선.y - (노래.현재위치 - 노트[id].판정시간);
}

이제 이런 함수를 썼고, 컴파일을 할 테지만, 놀랍고도 무섭게도, 모든 게 엉망진창입니다. 노트는 버벅버벅 더듬거리고[각주:1], 마침내 가까스로 아래로 내려와도, 특히 프레임이 떨어진[각주:2] 동안에는 판정선에 노래의 한 0.5초 이후에 도달할 겁니다. 그래서 이게 뭔 말인데요?

먼저, 노래 파일을 재생하는 대부분의 환경에서 (아니면 최소한 제가 작업했던 환경에서 : AS3, javascript, C#), 음악 파일의 정확한 재생위치, 그러니까 충분한 비율로 갱신되는 (~60FPS) 재생 위치를 얻기란 매우 어렵습니다. 모든 게 완벽한 세계에서, 매 프레임마다 음악의 재생 위치를 추적하면, 이런 결과가 나올겁니다.

0, 17, 33, 50, 67, 83, 100, 117, 133...

하지만 실제 세계에서는, 결과는 이런식으로 나올 겁니다.

0, 0, 0, 0, 83, 83, 83, 133, 133, 133, 133, 200, 200...

정확하고 일관적인 결과를 주는 대신, 재생위치는 건너뛰며[각주:3] 갱신될 겁니다. 이제 멀티플레이어 게임에서 보간하는 것과 똑같이 이 건너뛴 사이들을 보간[각주:4]해야겠죠.

이걸 하는 가장 쉬운 방법은 재생 위치를 특정 변수에 보관해놓고, 매 프레임마다 자동으로 시간을 더하는 거겠죠. 다음은 별로 안 좋은 방법입니다.

everyFrame() {
    songTime += 1000/60; // 1초에 1000ms, 1초당 60프레임
}

그리고 이걸 하는 약간 더 나은 방법입니다.

songStarted() {
    previousFrameTime = getTimer();
}

everyFrame() {
    songTime += getTimer() - previousFrameTime;
    previousFrameTime = getTimer();
}

// OR:

songStarted() {
    startTime = getTimer();
}

everyFrame() {
    songTime = getTimer() - startTime;
}

하지만, 이 세 방법은 모두 완벽하지 않습니다. 아니, 좀 더 정확히 하자면, 여러분의 음악 재생 방식이 완벽하지 않습니다. 어느쪽이 됐던, 갑작스럽게 여러분의 쬐끄만 변수 songTime은 실제 노래의 재생위치와 어긋나게 될 거라는걸 의미합니다. 특히 재생 환경이 음악을 건너뛰고, 버퍼링하고, 뭉개고[각주:5] 하는 환경이라면 이런 일이 일어날 가능성이 높습니다 - 웹 게임이나 파일에서 노래를 재생하는 대신 스트리밍해서 노래를 재생하는 게임 같은 경우 말이죠. 또, 대부분의 음원 재생 루틴은 극초반에 재생할 때 머뭇거리기[각주:6] 때문에, 어긋난 상태로 재생될수도 있습니다 - 특히 인코딩 데이터를 구워놓은 MP3 파일을 쓰고있다던가[각주:7], 느린 하드디스크에서 오디오 파일을 읽어오고 있다던가, 여러분의 게임이 쓰레기같은[각주:8] 크롬의 내장 "pepperflash" 플러그인을 쓰고있다면 말이죠.

그래서, songTime을 불러오고 실제 음원 파일의 재생위치에 맞도록 유지하기 위해, 매번 재생 위치를 새로 가져올 때마다 그 값을 교정하기 위한 기본적인 보간[각주:9] 알고리즘을 사용하고 싶군요. 이렇게요.

songStarted() {
    previousFrameTime = getTimer();
    lastReportedPlayheadPosition = 0;
    mySong.play();
}

everyFrame() {
    songTime += getTimer() - previousFrameTime;
    previousFrameTime = getTimer();
    if(mySong.position != lastReportedPlayheadPosition) {
        songTime = (songTime + mySong.position)/2;
        lastReportedPlayheadPosition = mySong.position;
    }
}

이 함수는 수동으로 추적중인 songTime 변수를 자동으로 가져와서 새 재생위치를 알게 되었을 때마다 실제 알아낸 재생위치와 평균을 낼 것입니다. 새로운 재생위치를 받았을 때에만 이렇게 하는데요, 새로운 값[각주:10]을 받는 사이사이에 "계단진" 값을 향해 계속 보간[각주:11]하다보면, 또다시 버벅거리는[각주:12] 재생위치를 얻게 될 것이기 때문입니다. 그 대신, 새로이 값을 받아올 때까지는 계속 수동으로 songTime을 증가시킬 것입니다.

하지만 아직 재밌는 부분이 끝난 건 아니죠!


※ 이 부분은 @Tis_Lenia 님에 의한 번역입니다. 늦은 반영 죄송합니다. 검토는 하지 않았습니다.

보시면 알다시피, 모든 렌더링 경로(pipelines)는 각각 상이한 지연 시간을 갖습니다: 지연 시간에는 영상(scene) 자체를 렌더링하는데 소요되는 시간과 사용자의 모니터 자체에 띄우는 작은 딜레이가 포함이 됩니다. (만일 사용자가 일반 모니터가 아닌 TV와 같은 디스플레이를 사용할 경우 후자의, 화면에 띄울 때 소요되는 시간은 늘어납니다.) 그래픽(영상) 화면에 뜨는데 발생하는 딜레이에 더하여 플레이어가 키보드를 누르고 그 입력이 프로그램에 전송될 때에도 딜레이가 발생합니다. 대부분의 게임에서 키 입력상에서 발생하는 딜레이는 무시해도 큰 문제가 되지 않으나, 리듬게임에 있어서는 이 딜레이는 철저한 계산이 요구되며 이는 제작자가 다른 게임에서는 무시되는 키 입력상에서 발생하는 이 딜레이를 고려해야함을 의미합니다.

허나 불행하게도, 모든 플레이어가 같은 모니터와 입력 장치를 사용하지 않는데, 이는 playhead에 삽입할 일정한 공통 기준이 존재하지 않음을 의미합니다. 따라서 타 리듬게임, Rock Band나 Guitar Hero에서 채용하고 있는 것과 같이 플레이어가 딜레이를 시각적으로 확인/조정할 수 있는 테스트가 필요합니다. 앞에서 언급된 두 리듬게임은 두 테스트를 사용하는데 이 중 하나에 대해 먼저 언급한 후 나머지를 설명하겠습니다.

이 테스트를 하는데에는 다양한 방식을 사용할 수 있습니다. 화면을 일정한 패턴으로 깜빡이는 것으로 딜레이 시간을 측정하는 것이나, 혹은 메트로놈(연주에 사용하는 박자기) 같이 시각적인 지표(노트)를 주어 플레이어에게 이에 맞춰 키를 누르게 하는 방법을 사용할 수도 있습니다. 이 테스트를 할 때에는 영상의 딜레이를 확인하기 위함이지 음향의 딜레이를 확인하는 것이 아니기 때문에 음악을 재생하여서는 안됩니다. 매 순간 화면이 깜빡일 때 (혹은 메트로놈이 똑딱일 때) 그 사이의 시간을 측정합니다. 그 다음에 플레이어로부터 키 입력을 받고 그 사이의 시간을 또 측정합니다. 화면을 깜빡일 때 발생한 딜레이를 키 입력까지 발생한 딜레이에서 뺀 시간이 시각적(영상) 딜레이입니다.

이론적으로는 시각적(영상) 딜레이는 렌더링 딜레이와 키입력의 딜레이의 합이기 때문에 마이너스의 값이 발생할 수 없으나 플레이어가 습관적으로 실제로 입력해야한다고 생각하는 순간보다 노트를 빨리 입력하는 버릇이 있을 수도 있습니다. 만일 플레이어가 이와 같은 습관을 가지고 있고 모니터와 입력 장치 모두 딜레이가 짧은 장비들이라면 마이너스의 딜레이를 갖는 것도 불가능하지는 않습니다. 따라서 게임을 제작할 떄 이 이론상으로 존재할 수 없는 마이너스 값의 딜레이에도 대응할 수 있도록 해야합니다.

또한 중요한 점은, 15초에서 30초 정도는 이 테스트를 진행해야 신뢰할 수 있는 테스트 결과가 나온다는 것입니다. 다양한 변수로 인하여 일관적인 딜레이 값을 측정하는데 방해가 발생할 수 있기 때문에 한번의 일련의 딜레이 측정 테스트로는 신뢰할 수 있는 결과를 도출하기 어렵습니다. 이런 방해 요소는 렌더링, 키 입력 과정과 더불어 플레이어의 테스트 중 규칙적인 키 입력에서도 발생할 수 있습니다. 그렇기 때문에 반복된 검사를 진행하여 영상 딜레이의 평균값을 구합니다.


글을 대충 읽고 저는 이런 걸 짰는데요, 이것도 나쁘지 않은 것 같지만,

자세히 읽어보니 반으로 나누는 보간하는 부분이 있었군요. 보간이 있는 쪽이 없는것보다 나을 것 같긴 하네요.

아무튼 앞부분의 중요 내용은 "값이 계단지게 띄엄띄엄 나온다" 이고, 그 부분을 커버해줄 수 있는 알고리즘이 있으면 충분하지 싶습니다. 이렇게 해놓으면 싱크가 어긋나는 일은 없겠죠.

뒷부분의 딜레이 관련 내용은 귀찮으면 그저 유저에게 맡기면 되는 문제... 니까요. 오프셋 조절하셈 하고 던져주면 되는 (..

  1. jittery/stuttery [본문으로]
  2. dip [본문으로]
  3. in steps, "단계별로"가 일반적인 번역이겠지만 의미가 와닿지 않을 것 같아서 수정 [본문으로]
  4. interpolate. "선형 보간"을 검색해보세요. 찾을 시간이 없으시면, 사잇값을 구한다는 느낌으로 받아들이시면 될 듯. [본문으로]
  5. skip, buffer, or crash [본문으로]
  6. hiccup [본문으로]
  7. 이 구문은 무슨 말인지 몰라 그대로 적었습니다. if you're using MP3 files that have encoding data baked in [본문으로]
  8. piece of shit (똥조각) [본문으로]
  9. easing [본문으로]
  10. 원문에 valuable이라고 되어있는데, variable의 오타일 겁니다. (자동완성의 폐해...) [본문으로]
  11. easing [본문으로]
  12. stuttery [본문으로]
신고

폭탄피하기 게임의 릴리즈가 늦어질 예정입니다.

2016.01.28 14:37제작일지

게으른 것도 있고, 바쁜 것도 있고, 무엇보다도 롤러코스터 타이쿤 3가 너무나도 재밌더라구요. 릴리즈할 분량이 안 된다고 판단해서, 2월 한달간 추가제작하는 걸로 하겠습니다.

현재 제작은 2-3 까지 되어있습니다. 기본 구성은 1 월드 : 1개념 : 4 스테이지, 1 스테이지 : 4 체크포인트 입니다.

뭐라고 할까, 새로운 걸 만들긴 귀찮고 계속 잇자니 뭔가 지겹고 말이죠. 그래도 끝은 내야겠다고 생각해서 끝까지 만들어볼 생각입니다.

신고

1월 한달간 폭탄피하기를 만들고 있습니다.

2016.01.13 14:51제작일지

이번 년도의 목표는 매달 하나의 게임을 만드는 거였습니다만 지금까지는 말 하면 안 하길래 말 안 하고 있었습니다. 이번 달 목표는 폭탄피하기를 완성해서 공개하는 것. 다음달 목표는 일러스트가 들어간 게임을 만드는 것. (추상적)
- @sftblw,

왜 이걸 트윗했냐면요 2, 3일 이틀 투자해서 만들던 게임이 아직까지도 제작이 지속되고 있기 때문입니다
- @sftblw,


굳이 여기에 공약을 걸지 않는 이유는 걸 필요가 없는 거기 때문입니다 일을 잘해야죠 취미가 아니라
- @sftblw,


이번 년도는 어디까지나 게임 제작을 취미로 인지하고, 실력을 향상시키는 걸 목표로 할 생각입니다. 1년에 작은 게임 12개라면 꽤나 제작 수완이 생기지 않겠어요?
- @sftblw,

1월의 첫번째 주말 (신정 근처의 1월 2일, 1월 3일)을 투자해서 만들기 시작한 게임이 여유시간 날 때 조금씩 계속 제작중입니다. 분량있는 게임으로서는 최초의 릴리즈가 될 것 같네요.

제작 시작은 뭐 만들까 하다가 땅에서 벽을 자동으로 생성하는 걸 만드는 거였는데요, 1달 이내로 만들기 쉬운 게 뭘까 하다가 스타크래프트 유즈맵 세팅 맵 중의 한 장르인 폭탄피하기로 결정했습니다 ♪

월말 공개가 목표인데다가 제작 시작한 환경이 WebGL을 어째서인지 지원하지 않던지라, WebGL 의 화려한 그래픽 지원은 포기하려고 합니다. 그건 어쩔 수 없죠...

현재 1-1 ~ 1-4, 2-1 이 만들어진 상황이고 스타 유즈맵에서 볼 수 없었던 요소들을 하나씩 추가하는 방식으로 하려고 하는 중입니다. 공개할 걸 생각하니 벌써부터 즐겁네요~

신고

스킨 통일에 관하여 + 잡담

2015.11.12 03:39기타

1. 급하게 기존 소스를 이리저리 변경하여 블로그 스킨으로 적용하여 보았습니다. 급하게 적용하느라 아직 댓글과 카테고리 기능 등이 없는 점 양해바랍니다. 대신 홈페이지와 통일되었죠. 그 점이 제일 좋아요.

소스는 요기에 있습니다.

나름 예쁘지 않나요?

문제는 아시는 분은 아시겠지만 홈페이지의 소스가 스킨이고 뭐고 고려 안 하고 짜여있어서, 없는 부분을 만드느라 시간이 많이 쏟아들어가더군요. 밤이 늦기도 하고 해서 그만두려구요.


2. 한 달 한 껨! 같은 망상을 좀 했는데요, 생각해보니 11월, 12월동안 하기로 한 게 있더군요.[각주:1] 그래서 게임 제작은 점점 뒤로 밀리게 될 것 같습니다. 아쉽군요. 시간을 비워야 하니까요.

가장 최근에 연구 (처음 만들어보기 시도) 하던건 디펜스 장르인데, 패턴이 들어가면 어떨까 하고 패턴을 따라 움직이는 적들을 만드는 정도로 끝났었죠. 과연 완성할 수 있으련지 ~_~


3. 메르니 프로젝트 + 기운의 흐름 좀 살렸으면 좋겠다는 망상이 스멀스멀 기어오르는 바쁜 일상입니다. 그나저나 글을 쓴 날이 수능날이네요. 수능러 다이죠부? 잘 보셨길 바랍니다.

  1. 게임 제작이 아닌 다른 일입니다. [본문으로]
신고
12