Gulp.js – 빌드 자동화 도구 사용하기

Gulp.js ?

Node.js 의 여러 모듈중 하나로 코드난독화, 최적화 등의 빌드 기능을 쉽게 처리할 수 있게 도와준다.

설치

다음 명령어를 통해 gulp를 전역으로 설치한다.

$ npm install gulp – g

다음 명령어를 통해 설치되어 있는 gulp의 버전을 확인 할 수 있다.

$ gulp -v

더 자세한 설치 방법은 링크 참조.

사용

  • 의존성 패키지를 설치

$ npm install--save-dev gulp gulp-util

  • gulp 플러그인을 설치

npm install--save-dev gulp-uglify gulp-concat

코드를 최소화/압축하는 uglify와 자바스크립트 파일들을 하나로 합쳐주는 concat 플러그인을 설치했다.

  • 프로젝트의 루트 폴더에 gulpfile.js 파일을 생성

사용할 플러그인을 선언하는 코드를 추가한다.

var gulp = require('gulp');
vargutil = require('gulp-util');
var uglify = require('gulp-uglify');
var concat  = require('gulp-concat');

 

작업을 정의하는 task() 메소드를 추가한다.
gulp.task('js', function() {
    gulp.src('./**/*.js')
        .pipe(uglify())
        .pipe(concat('min.js'))
        .pipe(gulp.dest('./dist'));
});

gulp.src('./**/*.js') 으로 타겟이 되는 js파일목록을 프로젝트에 포함되는 모든 폴더로 지정한다.
이어지는 작업들은 은 .pipe() 메소드를 통해 정의한다.
.pipe(uglify()) : 코드 난독화
.pipe(concat('min.js')) : src()a로 지정된 파일목록을 하나의 파일로 만들어 min.js 에 저장
.pipe(gulp.dest('./dist'));: 저장할 경로를 지정

  • js 태스크를 실행한다.

$ gulp.task('js');

Nexus 3.x를 이용한 사설 NPM 저장소 만들기

Nexus – npm 저장소의 필요성

  •  npm 저장소에 프록시 역할을 해줌
  •  내부적으로 만든 node 모듈이나 라이브러리의 배포를 npm을 통해 쉽게 할 수 있음

Nexus 3.x – Linux(CentOS) 설치

Nexus 3.x 설치 관련 공식 문서

리눅스용 배포판의 경우 Java 8 Runtime Environment (JRE)가 필요하다. 설치 되어 있지 않을 경우 Oracle 웹 사이트 에서 최신 버전의 Java 8을 설치한다.

참고 – 생활코딩 – 리눅스에 Java 다운로드해서 설치하기

Nexus 3.x 버전을 다운 받은 후 압축을 해제한다. ( 3.9.0-01 버전 기준으로 설명함 )

$ wget https://sonatype-download.global.ssl.fastly.net/nexus/3/nexus-3.9.0-01-unix.tar.gz

$ tar -xvzf nexus-3.9.0-01-unix.tar.gz

압축을 해제하면 nexus 3-3.9.0-01 라는 Nexus Repository Manager 어플리케이션 폴더와 sonatype-work 라는 저장소, 설정, 캐시 등의 모든 데이터가 하위 폴더로 저장되는 폴더가 보인다.

Nexus가 사용하는 8081 포트를 열어준다.

$ firewall-cmd –zone=public –permanent –add-port=8081/tcp
$ firewall-cmd –reload\

Nexus를 실행한다.

$ ./nexus run

—————————————————————-
Started Sonatype Nexus OSS 3.9.0-01
—————————————————————-

실행에 성공하면 위에 문구가 나온다.

브라우저에서 서버주소와 포트번호를 입력하면 Nexus Repositoty Manager 관리자 페이지로 접속 할 수 있다.

1.PNG

기본 ID와 비밀번호는 admin / admin123 으로 설정되어 있다.

NPM 저장소 설정하기

Administration 탭으로 이동 후 Repositories 항목을 선택한다.

2.PNG

Repositrory 에서는 npm 뿐만 아니라 여러 format의 저장소를 만들수 있다.

각 format의 저장소는 3가지 type을 가질수 있다.

  • proxy : 외부의 다른 경로를 proxy하는 역할.
  • hosted : 자체 모듈 저장소
  • group : proxy 와 hosted 들을 묶을 수 있는 단위 집단. 나열하는 순서가 라이브러리 탐색의 우선순이가 됨.

Create repository 버튼을 눌러 npm (hosted) 를 선택하고 다음 선택하여 자체 모듈 저장소를 만든다.

3.PNG

npm (proxy ) 를 선택하고 다음 선택하여 proxy저장소를 만든다.

4.PNG

npm (group) 를 선택하고 다음 선택하여 위에 만든 두개의 저장소를 묶어준다.

5.PNG

내부 NPM 저장소 사용하기

사용

npm 의 –registry 명령어를 사용하면 기본 저장소 대신 지정된 저장소를 사용할 수 있다.

npm –registry http://192.168.0.45:8081/repository/npm-group/ install ~

(192.168.0.45 는 알맞은 서버주소로 바꿔준다.)

각각 프로젝트에 .npmrc 파일을 만들어 저장소의 아래와 같이 위치를 지정하면 –registry 명령어 없이도 지정된 저장소를 사용할수 있다.

registry=http://192.168.0.45:8081/repository/npm-group/

배포

내부적으로 만든 라이브러리를 배포할때는 group 대신에 hosted 저장소를 사용해야한다.

배포에 앞서, login 명령어를 통해 로그인한다. 따로 아이디를 만들지 않았으면 기본으로 설정되어 있는 admin으로 로그인 한다. 이때 email주소는 기본정보와 달라도 상관 없다.

npm –registry http://192.168.0.45:8081/repository/npm-private/ login

6.PNG

public 명령어를 통해 pacage.json에 설정된 name 과 version으로 프로젝트를 배포할 수 있다.

npm –registry http://192.168.0.45:8081/repository/npm-private/ publish

한번 배포된 프로젝트는 버전을 다르게해야 재배포 할 수 있다.

package.json 에 아래 옵션을 넣어주면 publish의 저장소 위치를 지정 할 수 있다.

“publishConfig”: { “registry”: “http://192.168.0.45:8081/repository/npm-private/” }

배포된 모듈 및 라이브러리는 nexus 관리자 페이지의 브라우저 탭을 통해서 확인 가능하다.

7.PNG

Bluetooth 4.0(ble) 자전거용 Profile

Fitness Machine Service ( FTMS ) – org.bluetooth.service.fitness_machine
Assigned Number : 1826
UUID : 00001826-0000-1000-8000-00805f9b34fb

Indoor Bike Data – org.bluetooth.characteristic.indoor_bike_data
Assigned Number : 2AD2
UUID : 00002AD2-0000-1000-8000-00805f9b34fb
Type : org.bluetooth.characteristic.indoor_bike_data
Property : Notify

Field Format Byte Index Unit(Exponent)
Flags 16 bit 0,1
Instantaneous Speed uint 16 2,3   km/h ( Decimal, -2 )
Average Speed uint 16 4,5 km/h ( Decimal, -2 )
Instantaneous Cadence uint 16 6,7  rpm ( Binary, -1 )
Average Cadence uint 16 8,9  rpm ( Binary, -1 )
Total Distance uint 24 10,11,12 meter
Resistance Level sint 16 13,14
Instantaneous Power sint 16 15,16  watt
Average Power sint 16 17,18  watt
Total Energy uint 16 19,20 calorie
Energy Per Hour uint 16 21,22  calorie
Energy Per Minute uint 8 23  calorie
Heart Rate uint 8 24  bpm
Metabolic Equivalent uint 8 25  ( Decimal, -1 )
Elapsed Time uint 16 26,27  second
Remaining Time uint 16 28,29  second

Total byte : 30

 

Cycling Speed and Cadence – org.bluetooth.service.cycling_speed_and_cadence
Assigned Number : 1816
UUID : 00001816-0000-1000-8000-00805f9b34fb

CSC Measurement – org.bluetooth.characteristic.csc_measurement
Assigned Number : 2A5B
UUID : 00002A5B-0000-1000-8000-00805f9b34fb
Type : org.bluetooth.characteristic.csc_measurement
Property : Notify

Field Format Byte Index Unit(Exponent)
Flags 8 bit 0
Cumulative Wheel Revolutions uint 32 1,2,3,4
Last Wheel Event Time uint 16 5,6   second( Binary, -10 ) , 1/1024s
Cumulative Crank Revolutions uint 16 7,8
Last Crank Event Time uint 16 9,10 second( Binary, -10 ), 1/1024s

Total byte : 11

famobi.com에 올릴 게임 제작할 때 필요한 사항

famobi.com에 올릴 HTML5 게임을 제작할 때 확인 해야할것들 정리.

1. 로딩
– 퍼센테이지와 함께 애니메이션으로 로딩을 구현해야함.
– splash 스크린을 넣지 말아야함.
– 외부경로의 스트립트나 폰트를 넣지 말아야함.
– 게임의 로딩 용량이 5MB 넘어가면 필요한 것만 우선 로딩하고 필요한거 있을때 로딩해야함.

2. 에셋
– 스프라이트를 사용한 메인 그래픽.

3. 배경
– 게임디자인과 매치되는 배경색을 사용해야함.

4. 텍스트, 로컬라이징
(권장)게임은 어떤 텍스트도 사용하지 않고, 아이콘만 사용. ( 타이틀이나 로고, 장르는 나타내는 텍스트는 써도 됨. )
– 만약에 게임에 텍스트가 들어간다면, 모든 문자는 반드시 via 폰트나 스프라이트/비트맵 폰트들을 사용해야함.
– 지원하는 언어들. ( DE, EN, TR, PL, RU, NL, ES, PT, FR )
– 이미지 텍스트 ( 좋지 않은 방법임. )는 개발자에 의해 로컬라이징 되어야함.
– 언어 변경 버튼을 사용하지 말아햐함. ( famobi 자체 API로 변경함 )

5. UI
– 왼쪽 위 코너에 버튼이나 구성요소를 배치하지 말아야함 ( famobi UI가 배치됨)
– 가로모드 UI는 iOS에서 브라우저바를 방해하지 말아야함.
– 플레이 버튼은 반드시 스타트씬에서 가장 커야함.
– 만약에 게임에 사운드가 있다면, 스타트씬에서 음소거버튼을 만들어야함.
– famobi 독점 게임들은 credits 정보를 넣지 말아야함.
– 인게임에서 메인메뉴 버튼을 사용할수 있어야함.
– 컨티뉴버튼들은 항상 오른쪽 사이드에 위치 해야함.

6. 오리엔테이션
(권장)게임은 가로 & 세로에서 플레이 할수있어야함.
(권장)오리엔테이션에 맞게 반응형 UI를 사용.
– 게임은 블랙바없이 스크린을 채워줘야 함.
– 디바이스 회전 이미지를사용하지 말아야함.
– 전체화면 버튼을 사용하지 말아야함.

7. 파일 용량
(권장)게임은 2MB 보다 작아야함. ( 10MB보다 크면 매우 안좋음 )
– 에셋들은 반드시 최적화 되어야함. ( 압축. 2의 배수, 중복제거, 큰배경그래픽은 타일형식으로 )
– 사운들은 반드시 최적화 되어야함. ( 품질보다 크기를 줄여라 )

8. iFrame
– Famobi iframe 에서 게임이 작동해야함.
– 테스트 링크 : http : // play.famobi.com/embed-game/?url=https://example.org/game.html
– example.org/game.html 대신 게임 URL 배치

9. 사운드
(권장) BGM과 효과음 버튼을 구분해야함.
– 음소거 버튼은 모든 디바이스에서 작동 해야함.
– 게임은 포커즈를 잃었을때 음소거 되어야함.
– 게임은 다시 포커즈를 찾았을때 음소거가 해제되어야함.
– 게임은 BGM이나 효과음 없이 실행할수 있어야함.

10. 튜토리얼
(권장)텍스트가 없이 애니메이션으로 표현해야함.

11. 기타
– 게임 파일은 난독화나 최소화 하지 말고 전달해야함.
– 하드코딩된 나가는 외부링크가 없어야함.
– 디버그 아웃풋이 없어야함
– game contains natural breaks
– 포커즈를 잃으면 게임은 정지되어야함
– index file adjustments
– 이중입력 문제가 없어야함. ( 마우스입력과 터치입력을 동시에 사용하는 경우 두개다 입력이 될수 있음 )
– 탭-고정 문제가 없어야함.
– 홍보용으로 티저이미지(500*500px) 와 해더이미지(2400*1350px) .png를 만들어야함.

원문 사이트 : https://sites.google.com/a/famobi.com/api-docs/home

h1 프로젝트 – HTML5 게임개발 후기

웹뷰만 띄울 수 있으면 어느 환경에서나 플레이 가능한 강점을 가진 html5 게임을 개발하게 되었다. html5 게임은 이미 많이 대중화된 상태라 제작 관련 툴이나 엔진을 찾는데는 어렵지 않았다.

   – 참고 사이트 : https://html5gameengine.com/ – html5 게임 엔진 인기 순위.

 위 사이트에서 4위에 랭크 되어있는 Phaser라는 게임개발 프레임워크를 사용하기로 했다. Phaser는 자체만으로 엔진이라고 할 수는 없지만 렌더링, 사운드, 물리 등  게임에 필요한 거의 모든 기능들을 편리하게 제공 해주는 2D 게임 프레임워크이다.  Phaser가 제공하는 많은 예제와 커뮤니티 자료도 원할한 개발을 하는데 많은 도움을 주었다.

   – 참고 사이트 : https://phaser.io/  – Phaser 공식 홈페이지

 

기획된 게임은  두명의 플레이어가 게임오버 될 때 까지 포탄을 쏴 적유닛을 물리치는 간단한 방식의 멀티플레이 슈팅 게임이었다.

1.PNG

 

멀티플레이 인것만 제외하면 간단한 게임이어서 기본게임틀 제작까지는 시간이 오래 걸리지 않았다.  그에 맞는 빠른 멀티플레이 테스트를 위해 Node.js 와 websocket 을 이용한 임시 에코서버를 제작해 테스트를 진행 하였다. 서버와 클라이언트 모두 자바스크립트로 작성 할 수 있어서 개발속도는 더 빨랐다.

   – 참고 사이트 : http://www.html5gamedevs.com/topic/6256-simple-phaser-websocket-guide/    –  phaser 와 websocket 을 이용한 서버관련 커뮤니티글

 

게임 특성상 여러 스테이지가 필요했는데, 적은 양의 리소스로 많은 양의 스테이지를 제작하기 위해 간단한 맵툴제작과 지형을 조립가능하게 화 프리팹화 시켰다.

2.png

 

지형 프리팹화 과정에서 다양한 모양의 지형에 대처하기 위해 포탄과 지형의 충돌체크는 픽셀충돌 방식을 사용하였다. 픽셀충돌은 Phaser에서 지원해주는 충돌체크 방식이 아니다보니 테스트 해보던중 한가지 중대한 버그가 발생하였다. 싱글 플레이시에는 문제 없으나 모바일기기로 멀티플레이 테스트시 가끔 포탄발사 시뮬레이션 결과가 서로 다르게 나오는 것이었다.  원인을 파악해보니 모바일 디바이스별로 구형은 지형을 화면에 그린 픽셀들의 결과가 신형 디바이스와 미세하지만 약간 차이가 있다는 것은 발견했다. 이를 해결하기 위해 프리팹화 된 지형 별로 검은색과 흰색으로 이루어진 픽셀충돌 전용 리소스를  만들어 사용하였다.

3.PNG

 

웹뷰 환경에서 게임을 실행하는 탓에 게임은 돌아가나 성능에 관한 문제도  많았다. 같은 디바이스에서도 사용한 브라우저 별로 성능과 지원가능한 html5 기능은  많은 차이가 있었다.

–  참고 사이트 : http://html5test.com/results/mobile.html  –  브라이저 별로 사용가능한 html5 기능을 알려주는 사이트

초기 개발에서는 1920 * 1080 의 고해상도 이미지 리소스를 사용했는데 구형 디바이스에서는 말할것도없고, 신형 디바이스에서도 플레이 시간이 길어지면 발열과 잔렉이 심해졌다. 게임 로직의 부하 문제이기 보다는 렌더링 성능의 문제로 보고 게임 해상도를  960 * 540 으로 바꾸면서 모든 리소스들을  절반 크기로 줄였다. 큰 모니터 화면으로 보면  약간의 디테일 차이가 있었지만 작은 모바일 화면으로 보면 고해상도 이미지를 쓸때와 큰 차이가 없었다. 그 결과 성능은 많이 개선 되었다. 구형 디바이스에서 장시간 플레이했을시 발열의 문제는 남아있었지만 잔렉과 발열도 많이  줄어 들었다.

 

브라우저가 캐시를 남기는것도 문제가 많았다. 새로 게임을 업데이트 했어도 캐시가 남아있는 문제 때문에 업데이트 된 게임이 제대로 불러와지지 않았다. 개발  단계에서는  크롬 시크릿탭을 사용하거나 저장된 캐시를 삭제해서 게임을 업데이트 했지만 임시방편이었다.  cache.manifest파일을 작성해서 캐시될 파일과 네크워크에서 매번 가져올 파일을 설정할수 있었다.