[구글/페이스북] 계정연동 Tip

클라이언트에 구글과 페이스북 계정연동을 할 땐 구글 로그인 버튼/ 페이스북 로그인 버튼/ 각각 사이트에서 제공하는 이미지와 규격대로 적용해야 합니다.

 

페이스북 로그인 버튼 ——————————–

https://developers.facebook.com/docs/facebook-login/web/login-button

 

구글 로그인 버튼 ——————————–

https://developers.google.com/identity/sign-in/web/build-button

[버전관리] Base

버전 관리(version control, revision control) 란?

동일한 정보에 대한 여러 버전을 관리하는 것을 말한다. 공학과 소프트웨어 개발에서 팀 단위로 개발 중인 소스 코드나, 청사진 같은 설계도 등의 디지털 문서를 관리하는데 사용된다. 그러한 문서의 변경 사항들에 숫자나 문자로 이뤄진 (“개정판 번호”나 “개정판 레벨”이라고도 불리는) “버전”을 부여해서 구분한다. “버전”을 통해서 시간적으로 변경 사항과 그 변경 사항을 작성한 작업자를 추적할 수 있다. 간단한 버전 관리 방법으로는 처음 작성한 코드에 버전 번호 1을 부여한다. 변경 사항이 생기면, 버전 번호를 2로 증가시킨다. 이처럼 추후 변경 사항이 발생 시마다 버전 번호를 1씩 증가시킨다.

소프트웨어 엔지니어링에서는 일반적인 소프트웨어 소스 코드만을 관리하는 내역을 주로 버전 관리라고 정의하게 된다. 일반적으로 산업 공학이나 이전 생산 기반 제조 공학 등에서 소프트웨어 쪽으로 넘어오는 학문적 관심에 의해 이전 생산 공학에서 사용하던 개념을 가져오게 되었고, 그에따라 버전 관리(Software Version Management)와 형상 관리(Software Configuration Management)의 개념들이 따라왔다고 볼 수 있겠다.

한국의 경우, 대부분의 서적들이 일본어를 거쳐 중역(重譯)되면서 오역된 경우가 많고 관련된 분야에 대해 정확하거나 깊은 이해 없이 단순 소개하며 넘어간 경우가 대부분이라 아직도 정확한 버전 관리와 형상 관리의 구분이나 이해가 없다고 보는 것이 맞다.

버전 관리 소프트웨어 도구들은 거의 모든 소프트웨어 개발 프로젝트에서 필수적인 요소로 인식되고 있다.

[출처 : 위키백과]

 

빌드관리는 정해진 형식이 없다. 작업자와 해당 버전에 대한 규정을 정해놓고 진행하면 된다.

간단한 예를 들자면 작업용 빌드의 g0.001.0721.03라는 버전이 존재

g0 : google 빌드한 0번째 버전 [대규모 업데이트 등]

001: 등록한 횟수

0721: 날짜

0.3: 세번째로 빌드한 버전

 

배포용 빌드의 버전은 작업용빌드와 순서만 맞춰주면 된다.

[FTR Sprint Rule] Base Flow

Sprint?

스프린트는 어려운 프로젝트를 빠른 시간 내에 효율적으로 해결하기 위해 만들어진 팀에 구체적인 방법을 제시하는 5일짜리 프로그램입니다.

[출처 : 구글 검색]

 

FTR Sprint?

앞에서 설명한 스프린트를 FROMtheRED만의 스타일로 적용시킨 프로젝트 진행 단계

문서는 되도록 PPT 사용

1.  컨셉기획

2. 논의

3. 프로토 버전 기획

3_2. 프로토 버전 리소스 제작

4. 프로토 플레이 후 프로젝트 진행 방향 결정

4_2. 재미에 관한 검증이 되었다면 프로젝트 진행 (상세기획, 오픈용 리소스 제작, 프로그래밍)

4_3. 재미에 관한 검증이 부족하다면 드랍 & 홀드

 


 

1. [FTR sprint] 컨셉기획?

아이디어에 관한 핵심적인 부분을 간단한 부분만 설계하기 위한 기획.

되도록 아이디어를 1page에 담아 한눈에 볼 수 있도록 정리

필수항목 1 : 플레이 목적

필수항목 2 : 게임 승리/종료 조건

필수항목 3 : 게임의 시작부터 끝까지 핵심적인 기능을 플레이 하기 위한 Flow

필수항목 4 : 조작법

※ 선택항목 1 : 대상에게 기획자의 아이디어에 대한 공감과 재미를 주기위한 간단한 벨런싱

※ 선택항목 2 : 대상에게 기획자의 아이디어에 대한 공감을 심화시킬 수 있는 레퍼런스 자료

ㄴ 생각한 컨셉과 가장 비슷한 자료 단 몇장이면 충분!

 

Tip a. 컨셉과 아이디어의 연관관계가 쉬울수록 대상의 공감을 이끌어 내기 쉽습니다.

Tip b. 설명이 없어도 컨셉만으로 대상에게 룰을 인식시킨다면 best! 그러나 3번 정도 플레이 했지만 핵심룰을 학습시키지 못했다면 더 많은 고민이 필요합니다.

Tip c. 화면전환은 적게 할 수록 유저가 지속적으로 게임에 집중할 수 있습니다.

Tip d. 구현하는 아이디어가 hyper casual라 불리우는 아이디어라면 초저사항의 플렛폼도 즐길 수 있도록 과한 연출은 자제하며 유저에게 많이 노출되는 부분에 연출을 더 가미한다면 넓은 유저층을 확보할 수 있습니다.


 

2. [FTR sprint] 프로토 리소스 제작

회사에서 일을 하는 행위가 될 수 있고 프로토라는 특성상 쉽게 여러가지를 만들어 낼 수 있어야 합니다.

수십가지의 아이디어가 있는 기획자와 함께하는 디자이너나 프로그래머는 통일된 리소스로 아이디어만 검증할 수 있다면 잡업이 훨씬 수월해 집니다.

Ex> 캐릭터는 ㅇ , 적은 ㅁ, 총알은 ㅣ와 같이 서로 합의하에 규격을 정한다면 점차 아이디어 검증 작업이 쉬워질 것입니다.

리소스가 쌓여간다면 그만큼 공통적으로 사용하는 부분도 많아지고, 어쩌면 프로토버전을 만들 땐 이미 있는 리소스만으로도 누구나 아이디어를 실현 할 수도 있게 됩니다.

 

 

[컨텐츠 기획서] 작성 요령 base

컨텐츠 기획서?

시스템을 활용한 요소들을 설정하는 기획서

컨텐츠 기획서를 작성할 땐, 생각을 전달하기 위한 참고자료가 중요합니다.

전달이 되지 않는 기획서는 열어봐도 소용없는 메모리일 뿐이니까요.

 

참고자료는 아이디어와 관련된 이미지를 찾고, 문서에 포함하는 것이 좋아요.

이미지만 문서에 넣는 것이 아니라 이미지에 관한 설명도 포함하는 것이 좋죠.

사용한 이미지의 파일을 따로 저장한다거나 출처를 기록해서 회의나 발표 활용하면 더욱 공감할 수 있습니다.

 

※ 흔히 사용하는 왼쪽의 당구장 표시는 부연설명을 쓸 때 많이 쓰입니다.

[Milestone] Alpha Build

※ 마일스톤(milestone)이란 프로젝트 진행 과정에서 특기할 만한 사건이나 이정표를 말한다. 예를 들어, 프로젝트 계약, 착수, 인력투입, 선금 수령, 중간보고, 감리, 종료, 잔금 수령 등 프로젝트 성공을 위해 반드시 거쳐야 하는 중요한 지점을 말한다.

※ Alpha란 소프트웨어 테스트를 시작하는 첫 번째 단계.

Alpha 소프트웨어는 불안정해질 수 있으며 충돌 또는 데이터 손실을 초래할 수 있습니다. Alpha 소프트웨어에는 최종 버전을 위해 계획된 모든 기능이 포함되어 있지 않을 수도 있습니다. [2] 일반적으로 오픈 소스 소프트웨어는 종종 공개적으로 사용 가능한 알파 버전을 가지고있는 반면, 독점 소프트웨어 에서는 알파 소프트웨어의 외부 가용성이 드문 경우가 있습니다. 알파 단계는 일반적으로 기능 고정 으로 끝나며 더 이상 기능이 소프트웨어에 추가되지 않음을 나타냅니다.

마일스톤 알파버전 체크리스트

  1. 구현하기로 했던 작업에 관한 기능적 완료여부 (TC)https://wordpress.com/posts/my/ftredblog.wordpress.com 참고
  2. 목표기능(콘텐츠) 적용(정상) 여부
  3. 탐색적 test
  4. 네트워크 test

※ 네트워크가 필요한 컨텐츠라면 갑자기 끊어졌을 때와 같이 네트워크상에서 일어날 수 있는 상황을 시나리오화 해서 몇가지 케이스를 테스트 하는 행동입니다.

QA 항목 설정 요령

품질 보증 ( QA )은 제조 된 제품의 실수 나 결함을 예방하고 고객에게 솔루션이나 서비스를 제공 할 때 문제를 피하는 방법입니다.

개발을 하다 보면 QA를 진행해야 하는 상황이 필수적으로 나타납니다.

그중에 탐색적으로 정해진 행동이 아닌 돌발행동을 했을 때 나타나는 현상들을 문서화 시키기 위해 지극히 주관적인 관점으로 설정한 항목을 정리한 문서입니다.

—————————————————————————————————————————————–

※ Client  : 만약 테스트 해야하는 클라이언트의 종류가 있다면 구분하기 위한 항목

※ Type : 발견하거나 발생한 현상이 버그인지, 이슈사항인지, 개선사항인지 등을 구분하기 위한 항목

※ Improvment : 해당 현상의 작업처리 우선순위를 선정하기 위한 항목

ㄴ 긴급 : 처리가 되지 않으면 진행되지 않는 수준의 현상

ㄴ 중요 : 구현방향에 따라 정상적으로 구현되지 않은 수준의 현상

ㄴ 일반 : 구현되지 않은 기능이 게임진행에 큰 영향을 미치지 않지만 작업이 안된 부분

※ 발생빈도 : 10회플레이 등 기준을 설정하고, 해당 현상의 발생빈도를 체크할 수 있는 항목

※ 발생조건 : 해당현상을 일으키기 위한 사전 행동들을 정리하는 항목

※ 개발 방향 : 해당현상을 구현하기로 했던 원래의 방향을 명시하는 항목

※ 개선방향 및 조치 : 해당현상에 관한 조치 및 개선방향을 제시하는 항목

※ 담당자 : 해당현상을 발견하거나 개선을 요청하는 담당자를 명시하는 항목(적어놔야 개발담당자가 궁금한 사항들을 물어보고 빨리 이해할 수 있음)

※ 처리상태 : 해당현상에 관한 상태

ㄴNew : 새로 등장한 상태

ㄴDoing : 버그수정 및 개선을 진행중인 상태

ㄴ Done : 버그수정 및 개선을 완료 한 상태

ㄴ Pending : 해당 현상의 구현이 어렵거나 개발방향에 의해 보류한 상태

※ 개발 담당자 : 수정 및 개선 담당자의  코멘트를 적을 수 있는 항목


 

위 항목들은 개발사나 개발구성원에 따라 달라질 수 있습니다.

게임 제안서 작성요령

제안서?

아이디어를 문서화 하여 왜 해야하고 어떤 것을 노려서 무엇을 어떻게 얻을 것인가를 대상에게 제안하기 위한 문서.

 

게임 제안서?

게임에 관한 아이디어를 표현하고 게임의 목적 및 효과를 전달하기 위한 문서

 

※ 제안서를 읽게되는 독자를 이해시킬 수만 있다면 충분한 문서입니다.
※ 정석이 없는 문서이지만 제가 습득한 요령 몇가지를 정리해 보겠습니다.

 

1. 제안서의 가장 중요한 요소인 목적에 집중 하는 글 (제목부터 목표가 명확하게 드러나면 집중도가 높아짐)
ㄴ 어떤물건을 만들어서 돈을 벌겠다와 약간의 시장, 타겟이 들어가는게 좋음
ㄴ 제목에서 명확한 목표가 설정된다면 일단 관심끌기 성공
ex>[온라인 상에서 혼자 플레이할 수 있는 경영시뮬레이션게임 개발 및 상용화]

2. 기승전결로 구성(목적에 대한 배경 >> 목적을 담은 제품 >> 판매전략 >> 목적 달성의 기준)
ㄴ단,추상적인 전개는 피하는게 좋음

3. 이유가 포함된 제안요소는 더욱 풍부함

4. 최대한 간단하게 작성 (짧고 명확한 용어, 확실한 방향과 표현)

5. 도표, 플로우차트, 스크린샷, 다이어그램, 예제로 시각적 효과를 극대화 많을수록 효과적

6. 읽는자를 고려한 서식의 배치

7. 질의를 시뮬레이션 하며 관련 된 응답용 페이지를 만들어 보기
ㄴ 무조건 쓰이지는 않지만, 이런 내용이었죠? 하며 답하는 것이 훨씬 심적으로 안정된 방법