plitri.net 도메인을 더 이상 연장하지 않기로 결정했습니다.
본 도메인은 2019-06-23 까지만 접근 가능하며, 그 이후로는 plitri.tistory.com 으로 접근하실 수 있습니다.
폐쇄도 고려하고 있습니다.
감사합니다.
| Godot RPG 시리즈 비공개처리 (0) | 2018.02.01 |
|---|---|
| pliTri Github 그룹 개설 (0) | 2017.06.16 |
Godot 2.x 시절에 쓰려고 했던 RPG 시리즈는 잠정 중단하여, 비공개처리 하였습니다. 양해 바랍니다.
| 도메인 제공 중단 예정 (0) | 2018.10.25 |
|---|---|
| pliTri Github 그룹 개설 (0) | 2017.06.16 |
2.x 기준입니다.
OS.delay_msec 등의 함수가 있지만 이건 왠만하면 사용하지 않도록 합시다. 스레드 째로 멈춰버려서 다른 게 아예 실행이 안 될 수 있습니다. (테스트는 안 해봤음)
고도 엔진에서 대기할 일이 있으면 왠만하면 타이머 노드를 사용한다고 보시면 됩니다. 에디터에서 타이머 노드의 timeout 시그널을 함수에 연결해서 해당 함수로 시간이 경과되었을 때의 처리를 작성할 수는 있는데 이건 함수 실행 도중에 함수의 수행을 일시정지하고 기다렸다 재개하고 싶다- 라는 요구사항에는 안 맞죠.
아무튼 타이머 노드에서 필요한 시그널은 timeout 입니다. 잘 기억해둡시다.
다른 언어처럼 GDScript에서도 yield()(문서: GDScript 기본-코루틴 / @GDScript.yield )를 호출해 함수를 중간에서 멈추고, 나중에 멈춘 지점부터 계속 실행할 수 있습니다. yield() 를 호출하면 함수의 실행 상태를 담은 값(GDFunctionState)을 반환하게 되고, 이걸 resume() 하면 함수가 이어서 마저 실행됩니다.
func myfunc():
print( yield() ) # yield를 호출하는 순간 반환합니다.
func _ready():
var y = myfunc() # yield로 반환되었기에 GDFunctionState 값이 y에 할당됩니다.
print( y.resume("world") )
이걸 잘 활용하면 wait 함수를 직접 짤 수 있으나 아직 좀 번거롭습니다.
yield 함수에는 추가로 인자를 넣을 수 있습니다. yield( 대상 객체, 시그널 이름 ) 으로, 이렇게 호출한 경우 특정 개체의 시그널을 받으면 함수의 수행을 그 자리부터 재개하게 됩니다.
그래서, 유니티에서는 이렇게 하는 코드를
yield return new WaitForSeconds(.1f);
yield( timer, "timeout" ) # timer 개체의 timeout 시그널이 발생하면 여기서부터 재개합니다.
유니티에서는 타이머 객체를 필요할 때 생성하는 반면 고도엔진에서는 특정 객체의 시그널이 발생하면 해당 지점으로부터 재개할 수 있도록 바로 설정할 수 있습니다. 그래서… 씬 트리에 삽입되어있는 객체인 Timer 노드를 사용하려면 timeout이 발생할 수 있도록 사전 조작을 필요로 합니다. 타이머가 없다면 만들어 씬 트리에 넣고, 타이머를 시작할 필요가 있죠.
func myfunc():
var timer = Timer.new()
self.add_child(timer)
for i in range(10):
timer.set_one_shot( true )
timer.set_wait_time( 1.0 )
timer.start()
yield( timer, "timeout" )
timer.queue_free() # free 처리를 안 해주면 myfunc()이 호출될 때마다 타이머가 쌓일겁니다.
# 아니면 사전에 timer 노드가 트리에 있고 영속적이라면 문제가 없죠.
기억에 의하면 Timer 노드는 트리에 삽입된 상태여야지 동작하는 것 같던데 이 점은 아쉽더라구요. 노드가 아닌 타이머가 필요하다면 Reference를 상속받는 커스텀 객체 같은 걸 만들어서 yield로 호출되었을 때 별도의 코드 없이 바로 처리되게 만들수도 있을 것 같습니다.
여담인데 yield가 값이 아닌 함수의 상태를 반환하는 바람에 제너레이터 패턴을 손쉽게 만들 수 없습니다. 멤버변수 등으로 우회할 순 있겠지만요.
| [Godot] GUI를 카메라에 영향받지 않도록 하기 (0) | 2017.03.11 |
|---|---|
| [Godot] C2의 scale-in 구현 (반응형) (0) | 2017.03.11 |
| [Godot] Patch9Frame (0) | 2017.03.10 |
pliTri 관련 공개 소스코드를 따로 모아 게시하기 위해 github.com/plitri 그룹을 개설하였습니다.
현재 저장소의 코드는 다음 두 가지입니다.
Construct 2 사용을 그만둘 생각이므로 작성했던 프로젝트들을 게시해볼까도 생각중입니다.
| 도메인 제공 중단 예정 (0) | 2018.10.25 |
|---|---|
| Godot RPG 시리즈 비공개처리 (0) | 2018.02.01 |
CanvasLayer 밑에 두래요.
참고
근데 왜일까요... (...) 아, 메뉴얼에 자세한 설명이 있었군요. 어쩌다보니 까먹었지만요. ParallaxBackground 도 CanvasLayer의 자식입니다.
아무튼 저거때문에 일시정지 메뉴의 루트를 바꿔버렸습니다. 잘 되네요. 일단 사용하는 입장에서는 자세히는 몰라도 되지 않을까 싶습니다.
어 그럼 C2의 Parallax Ratio는 어떻게 구현하지...?
ParallaxBackground 아래에 두면 되지 싶은데 확인하긴 번거로우니 나중에 필요할 때 알아보기로 하겠습니다.
| [Godot] 루프에서 wait 함수 사용하기 (0) | 2017.08.21 |
|---|---|
| [Godot] C2의 scale-in 구현 (반응형) (0) | 2017.03.11 |
| [Godot] Patch9Frame (0) | 2017.03.10 |
참고자료
여러 방법이 있겠는데 저는 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() ) )프로젝트 설정은 이렇습니다.
이제 카메라 세팅하는 법 알아보러 가야...
| [Godot] 루프에서 wait 함수 사용하기 (0) | 2017.08.21 |
|---|---|
| [Godot] GUI를 카메라에 영향받지 않도록 하기 (0) | 2017.03.11 |
| [Godot] Patch9Frame (0) | 2017.03.10 |
128x128, 외곽 둥긂 32px 인 스프라이트로 확인하였습니다.
Region Rect는 스프라이트에서 9 Patch를 지정한 영역을 나타내는 듯 합니다. Width, Height 둘 다 0인 경우 아예 이미지 전체영역을 잡는 것 같습니다. 이미지 전체 기준일 경우 굳이 수정할 필요 없습니다.
Patch Margin은 상하좌우 테두리 영역인 듯 합니다.
Draw Center를 체크 해제하면 가운데가 비게 됩니다.
| [Godot] 루프에서 wait 함수 사용하기 (0) | 2017.08.21 |
|---|---|
| [Godot] GUI를 카메라에 영향받지 않도록 하기 (0) | 2017.03.11 |
| [Godot] C2의 scale-in 구현 (반응형) (0) | 2017.03.11 |
@sftblw 계정 20만 트윗 기념으로 12시간동안 하루종일 제작했습니다. 결국 임시 리소스도 교체 못 했고 맵도 다 못 만들었군요 orz
1-1, 1-2, 1-3, 1-4, 2-1, 2-2의 6개 스테이지가 있습니다. 사운드는 없는 게 정상입니다.
제작툴은 Construct 2, 마저 만들지는 미지수입니다. 좀 난장판으로 만들었거든요.
파바방! 나님 20만 트윗 축하합니다!!!
— 씨-에이치- (Ch.さん) (@sftblw) 2016년 5월 6일
사실 대부분이 RT지만요 :3#20만_트윗기념_이벤트
멘션받은 주제 중 몇 개를 골라 5분 이내 플레이타임의 게임을 만들겠습니다.
-제작 기간: 내일
-불가능한 주제는 거절가능
-주제선정: 내일 12시
조작키는 방향키와 Z 키입니다. 모바일 미지원.
플리트리는 항상 세 가지를 생각합니다.
이 아이디어에는 다음 세 가지입니다.
터치
인터렉션
전략
터치 리듬게임들이 놓치고 있는 가능성에 주목합니다. 타이밍과 이동에서 좀 더 높은 자유도를 주면서도, 더욱 많은 터치 동작의 가능성을 시도합니다. 롤모델은 비트스트림의 주변 드래그 노트와, 그루브 코스터의 다양한 노트 종류입니다.
게임은 인터렉티브 미디어입니다. 플레이어의 동작에 따라 다양한 부속 결과가 나타납니다. 현재의 대부분의 리듬게임은 점수와 체력 정도로 단편적인 상호작용만을 보일 뿐, 중간에 패턴이 동적으로 바뀌거나 하는 일은 적습니다. 롤모델은 태고의 달인과 각종 로그라이크 게임입니다.
패턴을 논파해내는데에도 전략적인 요소가 있을 수 있지만, 이래서는 여전히 단편적인 전략입니다. 게임으로서 즐길 수 있는 전략의 구성을 시도합니다. 롤모델은 JRPG와 뮤제카의 그라피카 입니다.
당장이라도 만들 것 같은 풍으로 글을 써놨지만, 단순한 아이디어 정리입니다. (웃음) 언제 만들지는 저도 모릅니다만 근시일내에는 어려울 것이라고 생각합니다.
| [번역] 어떻게 리듬게임을 음악이랑 맞추나요? (레딧 댓글) (0) | 2016.01.31 |
|---|---|
| 스킨 통일에 관하여 + 잡담 (0) | 2015.11.12 |
이 글은 번역입니다. 대충 의역한 부분이 많으니 찰떡같이 알아들으세요.
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초 정도는 이 테스트를 진행해야 신뢰할 수 있는 테스트 결과가 나온다는 것입니다. 다양한 변수로 인하여 일관적인 딜레이 값을 측정하는데 방해가 발생할 수 있기 때문에 한번의 일련의 딜레이 측정 테스트로는 신뢰할 수 있는 결과를 도출하기 어렵습니다. 이런 방해 요소는 렌더링, 키 입력 과정과 더불어 플레이어의 테스트 중 규칙적인 키 입력에서도 발생할 수 있습니다. 그렇기 때문에 반복된 검사를 진행하여 영상 딜레이의 평균값을 구합니다.
글을 대충 읽고 저는 이런 걸 짰는데요, 이것도 나쁘지 않은 것 같지만,
자세히 읽어보니 반으로 나누는 보간하는 부분이 있었군요. 보간이 있는 쪽이 없는것보다 나을 것 같긴 하네요.
아무튼 앞부분의 중요 내용은 "값이 계단지게 띄엄띄엄 나온다" 이고, 그 부분을 커버해줄 수 있는 알고리즘이 있으면 충분하지 싶습니다. 이렇게 해놓으면 싱크가 어긋나는 일은 없겠죠.
뒷부분의 딜레이 관련 내용은 귀찮으면 그저 유저에게 맡기면 되는 문제... 니까요. 오프셋 조절하셈 하고 던져주면 되는 (..
| 리듬게임 아이디어 (0) | 2016.02.08 |
|---|---|
| 스킨 통일에 관하여 + 잡담 (0) | 2015.11.12 |
게으른 것도 있고, 바쁜 것도 있고, 무엇보다도 롤러코스터 타이쿤 3가 너무나도 재밌더라구요. 릴리즈할 분량이 안 된다고 판단해서, 2월 한달간 추가제작하는 걸로 하겠습니다.
현재 제작은 2-3 까지 되어있습니다. 기본 구성은 1 월드 : 1개념 : 4 스테이지, 1 스테이지 : 4 체크포인트 입니다.
뭐라고 할까, 새로운 걸 만들긴 귀찮고 계속 잇자니 뭔가 지겹고 말이죠. 그래도 끝은 내야겠다고 생각해서 끝까지 만들어볼 생각입니다.
| 1월 한달간 폭탄피하기를 만들고 있습니다. (0) | 2016.01.13 |
|---|
이번 년도의 목표는 매달 하나의 게임을 만드는 거였습니다만 지금까지는 말 하면 안 하길래 말 안 하고 있었습니다. 이번 달 목표는 폭탄피하기를 완성해서 공개하는 것. 다음달 목표는 일러스트가 들어간 게임을 만드는 것. (추상적)
- @sftblw,왜 이걸 트윗했냐면요 2, 3일 이틀 투자해서 만들던 게임이 아직까지도 제작이 지속되고 있기 때문입니다
- @sftblw,
굳이 여기에 공약을 걸지 않는 이유는 걸 필요가 없는 거기 때문입니다 일을 잘해야죠 취미가 아니라
- @sftblw,
이번 년도는 어디까지나 게임 제작을 취미로 인지하고, 실력을 향상시키는 걸 목표로 할 생각입니다. 1년에 작은 게임 12개라면 꽤나 제작 수완이 생기지 않겠어요?
- @sftblw,
1월의 첫번째 주말 (신정 근처의 1월 2일, 1월 3일)을 투자해서 만들기 시작한 게임이 여유시간 날 때 조금씩 계속 제작중입니다. 분량있는 게임으로서는 최초의 릴리즈가 될 것 같네요.
제작 시작은 뭐 만들까 하다가 땅에서 벽을 자동으로 생성하는 걸 만드는 거였는데요, 1달 이내로 만들기 쉬운 게 뭘까 하다가 스타크래프트 유즈맵 세팅 맵 중의 한 장르인 폭탄피하기로 결정했습니다 ♪
월말 공개가 목표인데다가 제작 시작한 환경이 WebGL을 어째서인지 지원하지 않던지라, WebGL 의 화려한 그래픽 지원은 포기하려고 합니다. 그건 어쩔 수 없죠...
현재 1-1 ~ 1-4, 2-1 이 만들어진 상황이고 스타 유즈맵에서 볼 수 없었던 요소들을 하나씩 추가하는 방식으로 하려고 하는 중입니다. 공개할 걸 생각하니 벌써부터 즐겁네요~
| 폭탄피하기 게임의 릴리즈가 늦어질 예정입니다. (0) | 2016.01.28 |
|---|
1. 급하게 기존 소스를 이리저리 변경하여 블로그 스킨으로 적용하여 보았습니다. 급하게 적용하느라 아직 댓글과 카테고리 기능 등이 없는 점 양해바랍니다. 대신 홈페이지와 통일되었죠. 그 점이 제일 좋아요.
소스는 요기에 있습니다.
나름 예쁘지 않나요?
문제는 아시는 분은 아시겠지만 홈페이지의 소스가 스킨이고 뭐고 고려 안 하고 짜여있어서, 없는 부분을 만드느라 시간이 많이 쏟아들어가더군요. 밤이 늦기도 하고 해서 그만두려구요.
2. 한 달 한 껨! 같은 망상을 좀 했는데요, 생각해보니 11월, 12월동안 하기로 한 게 있더군요.1 그래서 게임 제작은 점점 뒤로 밀리게 될 것 같습니다. 아쉽군요. 시간을 비워야 하니까요.
가장 최근에 연구 (처음 만들어보기 시도) 하던건 디펜스 장르인데, 패턴이 들어가면 어떨까 하고 패턴을 따라 움직이는 적들을 만드는 정도로 끝났었죠. 과연 완성할 수 있으련지 ~_~
3. 메르니 프로젝트 + 기운의 흐름 좀 살렸으면 좋겠다는 망상이 스멀스멀 기어오르는 바쁜 일상입니다. 그나저나 글을 쓴 날이 수능날이네요. 수능러 다이죠부? 잘 보셨길 바랍니다.
| 리듬게임 아이디어 (0) | 2016.02.08 |
|---|---|
| [번역] 어떻게 리듬게임을 음악이랑 맞추나요? (레딧 댓글) (0) | 2016.01.31 |
옛날에 만들었던 게임을 안드로이드로 올려보았습니다.
https://play.google.com/store/apps/details?id=net.plitri.balltouch01
주요 변경점은 두 가지인데, 하나는 광고 (주 목적) 이고, 나머지 하나는 터치 피드백입니다. 코드가 난잡해서 크게 바꿀 수는 없었습니다.
광고 달기를 처음으로 해봤습니다. 저도 광고를 그리 좋아하지는 않기 때문에, 배너광고 외의 전면 광고는 일부러 사용하지 않았습니다. 앱이 단순해서 사용자가 광고 보기를 선택하는 등의 요즘의 추세는 따르지 못할 것 같습니다.
별개로, 가능성이 있는 게임이고 머릿속에 마구 떠올라서, 리메이크를 진행중입니다. 사실 리메이크를 시작하게 된 계기는 게임툴의 버그로 광고가 안 달리다가 하도하도 안 되길래 그냥 새로 만들어버리자 해서 시작하게 되었는데 나쁘지는 않은 것 같네요. 재미있을 것 같아요.
3주째는 안 만들줄 아셨죠? 유감! 손 대긴 했답니다~
저번주.. 아니 수요일에는 가로줄 긋는 방식으로 표시했었는데 이번엔 그냥 한 것만 직접 쓸래요. 다른 페이지를 열기 귀찮아서 그런 건 맞고요... (엉? 뭐라고요?)
사실 이름만 알파버전이지, 알파 베타 구분 없이 현재 제작중인 걸 폰으로 내보낼때마다 수동으로 설치했어야 했는데, 그게 귀찮아서 올린겁니다. 어차피 플레이에는 등록할 예정이었고요. 귀차니즘을 무릅쓰고 급하게 등록해보았습니다.
근데 테스트 버전도 어김없이 구글 플레이에 게시하는 딜레이는 있더군요. 흑.. 얼마나 더 기다려야 되려나
제작량이 적습니다. 목요일부터 오늘까지니 적을 수 밖에요... 라기보단 정말로 이대로 그냥 시간을 보내다간 일주일 이상 버려두게 될 거 같아서, 그래서 어디까지 만들었는지 까먹어버리고 결국 버려지는 프로젝트가 될 거 같아서 가까스로? 잡아서 진행했습니다. 시간이 얼마 없었던 만큼, 최우선 목표인 추가 블록 타입을 먼저 구현했죠.
실제로 이 작업은, 절반은 금요일 오후, 디버깅?은 집에 내려가는 기차 안에서 이루어졌습니다. 그게, 어째서인지 배경의 선이 안 그려지더라구요. 그거 잡는다고 좀 걸렸어요. 자세히 보니 단순한 문제였더라구요.. 으으
동생한테 보여줬더니 어디로 가야하는지 방향을 가리키는 화살표가 뒤의 잇는 선들에 있었으면 좋겠다고 했습니다. 이건 프로토타입 1, 2에는 있었던건데 현재에는 없는 부분이죠. 그게, 선의 두께가 달라지는 관계로 제작하기 좀 골치아프겠지만, 긍정적으로 생각해볼까 합니다. 시간이 남을때에? 정신적 여유가 있을 때에?
드디어 이 차례네요. 귀찮으니 과거 글에서 목록을 가져오는 대신 직접 적겠습니다.
뭐 이 정도군요.
오늘 게시글은 좀 일본어투가 많이 섞인 거 같네요. 알 게 뭐야~
웹으로든 오프라인으로든 저와 서로 알고계신 분들께서 제작중 체험 (알파 테스터 등록)을 원하신다면 언제라도 트위터 @sftblw 로 멘션 넣어주세요! 이 글의 댓글도 괜찮아요.
| 네모밍 week 2 (0) | 2015.02.11 |
|---|---|
| 네모밍 w1u1 (0) | 2015.02.01 |
게을러서 저번 주말에 올라왔어야 했는데 늦었습니다. 죄송합니다
수요일이네요. 이번주 월 ~ 지금 작성하는 때까지는 어떠한 작업도 하지 않았습니다. (어째서...
크게 Prototype 1의 수준까지 진행하였습니다. 안드로이드 앱으로 테스트도 해보았고, 제 기기에서 이상없이 동작했습니다. Intel XDK도 오랜만에 업데이트하고...
추가로 한 작업.. 으음... SpriteFont로 격파한 갯수를 기록하는 건 예전에도 있었고.. 흐음... 별 건 없군요.
블록을 결국 일반화했습니다. 패밀리로 옮겼기에 이후에 블록 추가 작업이 더 수월해질 것입니다.
이것만 해도 힘들겁니다. 블록 종류 다양화는 쉽게 할 수 있을텐데, 시퀸스 기능이 좀 많이 복잡해보이는군요.
마무리는 복붙으로
| 네모밍 week 3 (0) | 2015.02.15 |
|---|---|
| 네모밍 w1u1 (0) | 2015.02.01 |
Extra Credits의 제안에 따라, 이제부터 목표와 그 달성을 기록해보려고 합니다. 원래 그 영상은 이메일로 스스로에게 보내라고 했지만, 기록을 남긴다는 사실이 중요하다고 판단하여 그저 블로그에 짧게 짧게 남기기로 했습니다. 이는 많은 시간이 걸려서는 안 되며, 길을 잃지 않도록 일주일에 적어도 한 시간은 만들던 게임을 들여다볼 수 있게 도와줄 것이라고 생각합니다.
w1u1 이라는건 사실 버전 이름입니다. 그러니까, 만들어가는 과정을 좀 더 수치로서 기록하기 위해 이런 생각을 해봤습니다.
입력을 받는 객체와 상자를 분리하면서, C2의 한계를 절감했는데, 언제나 느끼는 거지만
좋겠습니다. 3번의 문제는 stop loop 를 쓰는 걸로 회피하긴 했지만, 바로 생성된 객체의 값을 못 가져와서 무한루프에 갇힌다던가 하는 일이 비일비재하고, 바로 생성된 객체의 Pick 도 예상과는 다르게 동작하여 결국은 input 객체에 상자의 개수를 관리하는 해괴망찍하고 보기도 싫은 방법을 사용해야 했습니다. 툴의 한계이니 어쩔 수 없죠.
위에서부터 우선순위이며, 다음주 내에 다 구현하지는 못할 분량을 썼군요. 프로토타입 1, 가끔 즐기는 그것에 구현되어있는건 프로토타입 1이라고 덧붙여 적어두었습니다.
| 네모밍 week 3 (0) | 2015.02.15 |
|---|---|
| 네모밍 week 2 (0) | 2015.02.11 |
