제가 앱을 개발하는데에 사용하는 Cocos2d-x에 대해 그동안 생각해보지 못한게 있었고,
그부분을 정리하고자 글을 적어봅니다.
플랫폼, 엔진 등을 프로젝트 개발에 사용하기위해 고려되어야하는 부분이 몇 가지 있다고 생각합니다.
- 참고할 자료가 많은가 (책, 커뮤니티)
- 업데이트가 주기적으로 되는가 (살아있는 프로젝트인가)
- 사용하고자 하는 플랫폼, 엔진에 대한 기본적인 이해 (적어도 도메인 지식에 대한 이해)
- 만들고자하는 프로젝트에 적당한 엔진인가 (2D, 3D, 게임 종류 등등에 대한 고려)
- 개발 방향, 로드맵은 어떻게되는가
크게는 이렇게 보고 Cocos2d-x 는 어떻게 프로젝트를 진행하고 있는지, 내가 만드는 앱에 적합한지를
확인해보고자 합니다.
참고할 자료가 많은가
프로젝트를 개발하면서 정보를 얻을 일이 많습니다. 예를 들면, 내가 개발한 코드에 문제가 생긴 상황에서 보통 구글에 검색을 하죠.
하지만 검색해도 결과가 안나온다면? 혼자 삽질을 많이 하게 되겠죠.
그래서 참고할 자료가 웹 상에 많은지, 커뮤니티가 있는지,
커뮤니티가 있더라도 그 안에 정보 업데이트가 잘 되는지를 봐야합니다. (질문을 했는데 답이 없으면 커뮤니티가 있더라도 소용 없으니까요.)
구글에서는 Cocos2d-x 로 검색하면 많은 결과를 얻을 수 있습니다.
물론 좀 생소한 이슈를 검색하면 중국어 OR 일본어 자료를 볼 수 있습니다. 이 부분은 번역기로 극복..!
Cocos2d-x 는 커뮤니티가 있습니다. (다행히) http://discuss.cocos2d-x.org/ 이 커뮤니티는 영어지만.. 번역기를 잘 돌려서 질문만 한다면 어느정도
원하는 답변을 얻을 수 있습니다. (영어 잘 하시는분은 그냥 질문을..!)
어느정도 답변을 해주는 편이기도 해서 일단은 자료를 얻을 수 있어서 다행입니다.
우리나라 커뮤니티는 네이버 카페 Cocos2d-x 사용자모임(http://cafe.naver.com/cocos2dxusers)
최근에 글이 올라오지 않는 것으로 보아 우리나라에서는 Cocos2d-x 사용자는 점점 줄어드는 것으로
보입니다. (추측이지만 Unity로 넘어가는 것으로 보입니다.)
그 외에 스택오버플로우에서 많은 문제를 확인할 수 있으며
엔진의 버그도 Cocos2d-x GitHub 이슈나 PR에서 확인할 수 있어서
자료(정보)에 대한 걱정은 덜어도 괜찮을 것 같네요.
아, 추가적으로 책도 몇 권 있습니다.
- 시작하세요! Cocos2d-x 프로그래밍
- Cocos2d-x 3 모바일 게임 프로그래밍
- 등등..
최신 업데이트 사항은 포함되어 있지 않지만 한글 자료도 많습니다.
업데이트가 주기적으로 되는가
Cocos2d-x 는 업데이트가 보통 3-4개월 또는 급한 업데이트는 버그 픽스 버전업으로 올라옵니다.
최근 버전은 3.15.1 버전으로 3.15 버전 업데이트 후 버그가 있어 업데이트한 버전 입니다.
릴리즈 업데이트 말고 다른 지표들을 보겠습니다.
'코드의 변화도', '한 달동안 머지된 PR', '이슈들이 어떻게 처리되고 있는가'에 대한 이미지입니다.
중간에 코드 변화도가 크게 올라가 있는데 이 부분은 v2 -> v3 으로 메이저 버전업이 있었을 때
코드의 변화가 컸기 때문입니다.
2016년 이후로는 큰 변화 없이 개발되고 있습니다. 주로 버그 수정 및 로드맵에 따라 개발되고 있는데,
밑에서 Cocos2d-x는 어떤 로드맵으로 개발되고 있는지 더 살펴보겠습니다. (사실 어떤 로드맵으로 개발되고 있는지 잘 모르겠어요...)
사용하고자 하는 플랫폼, 엔진에 대한 기본적인 이해
기본적으로 Cocos2d-x로 C++, Lua, Javascript 3가지 언어로 게임을 개발할 수 있습니다.
처음에는 C++, Lua로 개발할 수 있었는데, 웹으로도 만들 수 있게 Javascript도 지원하기 시작한지
1년 정도된 것 같습니다.
Cocos2d-x 는 맨 처음 Cocos2d로 시작된 프로젝트인데 크로스플랫폼 엔진 프로젝트로 전환,
지금까지 진행되어 왔습니다.
유니티는 각 기능(이슈) 별로 리스트를 만들고 관리를 하고 있네요.
2017 버전이 나오면서 어떤게 업데이트가 되었는지, 앞으로 어떤 업데이트가 있는지는
찾아보고 있지만 찾기 힘드네요.
음... 일단은 비교는 했습니다만 Cocos2d-x 로드맵이 관리가 안되고 있다가 결론이네요.
현재는 잘 사용하고 있지만 Cocos2d 그룹에서 어떻게 개발이 진행되고 있는지,
로드맵은 어떤지에 대해 이야기해봐야겠습니다.
(현재 상태가 나쁘지는 않지만 어떤 방향으로 개발하고 있는지 잘 모르겠네요.)
그래들은 이런 빌드 과정을 설정하고 자동화할 수 있도록 해줍니다.
종속성을 어떻게 관리할 것인지, 빌드를 하고 나서 어떻게 처리를 할 것인지,
배포 빌드, 테스트 빌드 등 설정을 할 수가 있습니다.
빌드 구성 파일의 구조는 아래와 같습니다.
제일 위에 있는 build.gradle은 프로젝트의 모든 모듈의 빌드 세팅을 정의합니다.
/**
* The buildscript {} block is where you configure the repositories and
* dependencies for Gradle itself--meaning, you should not include dependencies
* for your modules here. For example, this block includes the Android plugin for
* Gradle as a dependency because it provides the additional instructions Gradle
* needs to build Android app modules.
*/
buildscript {/**
* The repositories {} block configures the repositories Gradle uses to
* search or download the dependencies. Gradle pre-configures support for remote
* repositories such as JCenter, Maven Central, and Ivy. You can also use local
* repositories or define your own remote repositories. The code below defines
* JCenter as the repository Gradle should use to look for its dependencies.
*/
repositories {
jcenter()}/**
* The dependencies {} block configures the dependencies Gradle needs to use
* to build your project. The following line adds Android Plugin for Gradle
* version 2.3.2 as a classpath dependency.
*/
dependencies {
classpath 'com.android.tools.build:gradle:2.3.2'}}/**
* The allprojects {} block is where you configure the repositories and
* dependencies used by all modules in your project, such as third-party plugins
* or libraries. Dependencies that are not required by all the modules in the
* project should be configured in module-level build.gradle files. For new
* projects, Android Studio configures JCenter as the default repository, but it
* does not configure any dependencies.
*/
allprojects {
repositories {
jcenter()}}
최상위 build.gradle은 프로젝트의 모든 모듈에 공통되는 gradle 저장소와 종속성을 정의하기 위해 buildscript {} 블록을 사용합니다.
모듈 레벨 빌드파일도 한번 보겠습니다. 보통의 안드로이드 앱 프로젝트라면,
project/app/build.gradle 파일을 말합니다.
/**
* The first line in the build configuration applies the Android plugin for
* Gradle to this build and makes the android {} block available to specify
* Android-specific build options.
*/
apply plugin:'com.android.application'/**
* The android {} block is where you configure all your Android-specific
* build options.
*/
android {/**
* compileSdkVersion specifies the Android API level Gradle should use to
* compile your app. This means your app can use the API features included in
* this API level and lower.
*
* buildToolsVersion specifies the version of the SDK build tools, command-line
* utilities, and compiler that Gradle should use to build your app. You need to
* download the build tools using the SDK Manager.
*/
compileSdkVersion 25
buildToolsVersion "25.0.3"/**
* The defaultConfig {} block encapsulates default settings and entries for all
* build variants, and can override some attributes in main/AndroidManifest.xml
* dynamically from the build system. You can configure product flavors to override
* these values for different versions of your app.
*/
defaultConfig {/**
* applicationId uniquely identifies the package for publishing.
* However, your source code should still reference the package name
* defined by the package attribute in the main/AndroidManifest.xml file.
*/
applicationId 'com.example.myapp'// Defines the minimum API level required to run the app.
minSdkVersion 15// Specifies the API level used to test the app.
targetSdkVersion 25// Defines the version number of your app.
versionCode 1// Defines a user-friendly version name for your app.
versionName "1.0"}/**
* The buildTypes {} block is where you can configure multiple build types.
* By default, the build system defines two build types: debug and release. The
* debug build type is not explicitly shown in the default build configuration,
* but it includes debugging tools and is signed with the debug key. The release
* build type applies Proguard settings and is not signed by default.
*/
buildTypes {/**
* By default, Android Studio configures the release build type to enable code
* shrinking, using minifyEnabled, and specifies the Proguard settings file.
*/
release {
minifyEnabled true// Enables code shrinking for the release build type.
proguardFiles getDefaultProguardFile('proguard-android.txt'),'proguard-rules.pro'}}/**
* The productFlavors {} block is where you can configure multiple product
* flavors. This allows you to create different versions of your app that can
* override defaultConfig {} with their own settings. Product flavors are
* optional, and the build system does not create them by default. This example
* creates a free and paid product flavor. Each product flavor then specifies
* its own application ID, so that they can exist on the Google Play Store, or
* an Android device, simultaneously.
*/
productFlavors {
free {
applicationId 'com.example.myapp.free'}
paid {
applicationId 'com.example.myapp.paid'}}/**
* The splits {} block is where you can configure different APK builds that
* each contain only code and resources for a supported screen density or
* ABI. You'll also need to configure your build so that each APK has a
* different versionCode.
*/
splits {// Screen density split settings
density {// Enable or disable the density split mechanism
enable false// Exclude these densities from splits
exclude "ldpi","tvdpi","xxxhdpi","400dpi","560dpi"}}}/**
* The dependencies {} block in the module-level build configuration file
* only specifies dependencies required to build the module itself.
*/
dependencies {
compile project(":lib")
compile 'com.android.support:appcompat-v7:25.3.1'
compile fileTree(dir:'libs', include:['*.jar'])}
제가 보통 보는 블록은 defaultConfig, buildType, dependencies 정도인 것 같네요.
splits나 productFlavors를 잘 사용하면 무료, 유료 앱 따로 빌드하기나
화면 해상도에 따른 빌드 설정을 각각해줄 수 있을 것 같네요.
그리고 추가적으로, 빌드할 때 필요한 설정을 가지고 있는 파일들이 있습니다.
- gradle.properties: 프로젝트 범위의 그래들 설정을 함. 예, gradle daemon 힙 크기 설정
- local.properties: 빌드 시스템의 로컬 환경을 구성. 예, sdk, ndk 경로 설정
추가, apple 문서 쪽에 openGL ES 에 대한 문서가 있는데
https://developer.apple.com/library/content/documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/Introduction/Introduction.html
같이 곁들여 보면 좋을듯.
"Web Application Vulnerability Scanners are automated tools that scan web applications, normally from the outside, to look for security vulnerabilities such as Cross-site scripting, SQL Injection, Command Injection, Path Traversal and insecure server configuration. This category of tools is frequently referred to as Dynamic Application Security Testing (DAST) Tools. A large number of both commercial and open source tools of this type are available and all of these tools have their own strengths and weaknesses. If you are interested in the effectiveness of DAST tools, check out the OWASP Benchmark project, which is scientifically measuring the effectiveness of all types of vulnerability detection tools, including DAST." - OWASP.org
해석해봅시다. :)
"웹 응용 프로그램 취약성 검사기는 일반적으로 외부에서 웹 응용 프로그램을 검색하여 교차 사이트 스크립팅, SQL 삽입, 명령 삽입, 경로 탐색 및 안전하지 않은 서버 구성과 같은 보안 취약성을 찾는 자동화 된 도구입니다. 이 범주의 도구는 종종 DAST (Dynamic Application Security Testing) 도구라고합니다. 이 유형의 상용 및 오픈 소스 도구가 많이 있으며 이러한 도구는 모두 자체 강점과 약점이 있습니다. DAST 도구의 효과에 관심이 있다면 DAST를 포함한 모든 종류의 취약점 탐지 도구의 효과를 과학적으로 측정하는 OWASP Benchmark 프로젝트를 확인하십시오." - produced by 구글 번역
이렇게 하고 저 압축파일을 풀면 html 파일이 나옵니다.
실행한 결과는 아래와 같습니다.
# 현재 테스트중에 에러가 몇가지가 났는데 확인해보니
[Arachni::Browser::Error::Spawn] Could not start the browser process.
이런 에러가 나오고 있었네요.
검색해보니 몇가지 이슈가 있었나봅니다.
이슈 링크: https://github.com/Arachni/arachni/issues/737
Git에서 트렌드로 올라와 있는 프로젝트들의 유명함, 성장 패턴, 예상, 트럭 팩터(?)를
볼 수 있는 서비스입니다.
예시로 리누즈 토발즈의 리눅스를 한번 볼까요?
star(별)을 얼마나 받았는지, 각종 수치를 볼 수 있습니다.
그 외에도 트럭 팩터, 랭킹, 컨트리뷰터 등에 대한 정보도 볼 수 있습니다.
각종 재미있는 수치들을 볼 수 있는데, 여기서 트럭 팩터란,
"Truck Factor (aka Bus Factor) is the minimal number of developers that have to be hit by a truck (or quit) before a project is incapacitated. It reveals the concentration of knowledge in individual developers."
Truck Factor (aka Bus Factor)는 프로젝트가 무능력 해지기 전에 트럭에 타격을 가해 야하는 최소한의 개발자 수입니다. 그것은 개별 개발자의 지식 집중을 나타냅니다.
http://v8project.blogspot.kr/2016/10/fall-cleaning-optimizing-v8-memory.html
이 V8엔진 블로그 글에 따르면,
V8엔진의 자바스크립트 힙 크기를 최적화하는데에 가비지 컬렉션에서의 부하와
메모리 사용량이 트레이드 오프 관계가 있는데 그 부분을 최적화하여
결과적으로 힙 크기를 줄인 것 같습니다.(기기 메모리가 작은 환경에서)
전체적으로 메모리 사용량이 줄은 것 같은데,
54버전에서는 페이스북 탭을 1개만 열어도 메모리가 70%까지 올라갔던것에 비해
55버전에서는 페이스북 탭을 6개 열어도 메모리가 51%정도라는 것에 대해
많이 최적화된것으로 보입니다.
source "https://rubygems.org"
ruby RUBY_VERSION
# Hello! This is where you manage which Jekyll version is used to run.
# When you want to use a different version, change it below, save the
# file and run `bundle install`. Run Jekyll with `bundle exec`, like so:
#
# bundle exec jekyll serve
#
# This will help ensure the proper Jekyll version is running.
# Happy Jekylling!
#gem "jekyll", "3.2.1"
# This is the default theme for new Jekyll sites. You may change this to anything you like.
gem "minima"
# If you want to use GitHub Pages, remove the "gem "jekyll"" above and
# uncomment the line below. To upgrade, run `bundle update github-pages`.
gem "github-pages", group: :jekyll_plugins
# If you have any plugins, put them here!
# group :jekyll_plugins do
# gem "jekyll-github-metadata", "~> 1.0"
# end
2. Local에서 확인할 경우
source "https://rubygems.org"
ruby RUBY_VERSION
# Hello! This is where you manage which Jekyll version is used to run.
# When you want to use a different version, change it below, save the
# file and run `bundle install`. Run Jekyll with `bundle exec`, like so:
#
# bundle exec jekyll serve
#
# This will help ensure the proper Jekyll version is running.
# Happy Jekylling!
gem "jekyll", "3.2.1"
# This is the default theme for new Jekyll sites. You may change this to anything you like.
gem "minima"
# If you want to use GitHub Pages, remove the "gem "jekyll"" above and
# uncomment the line below. To upgrade, run `bundle update github-pages`.
# gem "github-pages", group: :jekyll_plugins
# If you have any plugins, put them here!
# group :jekyll_plugins do
# gem "jekyll-github-metadata", "~> 1.0"
# end
이렇게 세팅하고
$bundle install
$bundle exec jekyll serve
