Q&A와 스터디
![[레벨:5]](http://old.lameproof.com/modules/point/icons/default/5.gif "포인트:2940point (69%), 레벨:5/30"){kind=icon}
꿔니외국 개발사들이 만든 게임들 중에서는 mac 버전도 동시에 출시하는 경우가 있습니다.
우리나라 개발사들이 만든 게임은 거의 window 버전만 출시하는데요.
물론 우리나라 대부분이 window를 사용해서 일수도 있지만, mac 용으로 컨버팅하는데 무슨 기술이
필요하다거나 하는 문제가 있지 않을까 생각해 봅니다.
자 그럼 질문 입니다.
mac에서 구동되는 게임이나 그와 흡사한 서비스가 많나요?
mac의 유저는 어느정도 인가요?
mac 버전을 제작하는데 어떤 과정을 거치는가요?
우리나라 개발사들이 만든 게임은 거의 window 버전만 출시하는데요.
물론 우리나라 대부분이 window를 사용해서 일수도 있지만, mac 용으로 컨버팅하는데 무슨 기술이
필요하다거나 하는 문제가 있지 않을까 생각해 봅니다.
자 그럼 질문 입니다.
mac에서 구동되는 게임이나 그와 흡사한 서비스가 많나요?
mac의 유저는 어느정도 인가요?
mac 버전을 제작하는데 어떤 과정을 거치는가요?
![[레벨:10]](http://old.lameproof.com/modules/point/icons/default/10.gif "포인트:10175point (62%), 레벨:10/30"){kind=icon}
능구렁이
2008.07.13 14:15:15 (*.39.113.209)
.. 그것 뿐은 아니고요. 파일 관련 입출력이라던지.. OS나 플랫폼에 의존하는 부분들은 인터페이스만 노출해서 각각을 따로 작성해 줘야 되죠. dx냐 gl이냐에 따라서 같은 기능도 따로 작성해줘야 하고요.
인터페이스 노출시켜서 따로 작성하는거야 그렇게 어렵지는 않죠. 시간이 오래 걸릴 뿐이지. 문제는 과연 이렇게까지 시간을 많이 들여가면서까지 해야될 만큼 경제성이 있는지를 따져봐야 하는데
우리나라에서는 mac 용 유저를 고려해줄만큼 mac 유저층이 넓지 않죠. linux 계열도 마찬가지고요.
기술적 문제가 아니라 경제적 문제가 더 크다고 생각되네요.
인터페이스 노출시켜서 따로 작성하는거야 그렇게 어렵지는 않죠. 시간이 오래 걸릴 뿐이지. 문제는 과연 이렇게까지 시간을 많이 들여가면서까지 해야될 만큼 경제성이 있는지를 따져봐야 하는데
우리나라에서는 mac 용 유저를 고려해줄만큼 mac 유저층이 넓지 않죠. linux 계열도 마찬가지고요.
기술적 문제가 아니라 경제적 문제가 더 크다고 생각되네요.
2008.07.13 15:57:29 (*.254.183.174)
![[레벨:7]](http://old.lameproof.com/modules/point/icons/default/7.gif "포인트:4676point (19%), 레벨:7/30"){kind=icon}
Excelsis 저도 음... 님 말이 가장 큰 이유로 생각됩니다 ( 인용하기에 아이디가 미묘하군요;; )
그리고 첨언하자면 경제성이 있느냐 라고 하는 부분을 받아들일 때, 대부분의 사람들이 '돈이 되느냐, 혹은 돈을 아끼느냐' 로 받아들이기 쉬운데
시간도 자원의 하나로 보고 시간이 많이 드느냐 적게드느냐도 경제성의 척도로 봅니다.
스타크래프트 할 때도 보면 미네랄, 개스, 인구수만 자원이 아니라 시간도 자원인것처럼 말이죠
그리고 첨언하자면 경제성이 있느냐 라고 하는 부분을 받아들일 때, 대부분의 사람들이 '돈이 되느냐, 혹은 돈을 아끼느냐' 로 받아들이기 쉬운데
시간도 자원의 하나로 보고 시간이 많이 드느냐 적게드느냐도 경제성의 척도로 봅니다.
스타크래프트 할 때도 보면 미네랄, 개스, 인구수만 자원이 아니라 시간도 자원인것처럼 말이죠
2008.07.13 23:03:53 (*.178.141.80)
![[레벨:4]](http://old.lameproof.com/modules/point/icons/default/4.gif "포인트:1983point (67%), 레벨:4/30"){kind=icon}
날자고도 음.. //
OS와 플랫폼은 같은말아닌가요?
dx나 gl이냐라는 부분도 엔진레벨에서 커버되는 부분아닌가요?
엔진을 직접만든다면, 고려해야할것이 많겠지만,
OS api야 당연히 필요하긴 하지만, 게임에서 본다면, 아주 일부분이죠.
OS와 플랫폼은 같은말아닌가요?
dx나 gl이냐라는 부분도 엔진레벨에서 커버되는 부분아닌가요?
엔진을 직접만든다면, 고려해야할것이 많겠지만,
OS api야 당연히 필요하긴 하지만, 게임에서 본다면, 아주 일부분이죠.
2008.07.14 00:35:09 (*.57.237.224)
http://en.wikipedia.org/wiki/Platform_(computing) 에 platform의 정의가 나와 있는데, platform은 컴퓨터 구조, OS, 언어, 런타임 라이브러리, GUI 등을 포괄하는 소프트웨어가 실행되는 하드웨어와 소프트웨어의 집합을 말합니다. OS도 플랫폼의 일부니 말을 잘못했군요. 같은 윈도우에서 짜더라도 어떤건 .NET framework를 사용해서 짤 수도 있고 이건 닷넷 프레임워크가 깔려있지 않은 윈도우에서는 실행되지 않으니까요.
엔진을 사도 그냥 이걸 그대로 윈도우 API 사용하듯이, dx 사용하듯이 사용한다면야 아무런 문제가 없는데, 엔진을 사서 그대로 사용하는 경우는 거의 없고 게임에 맞도록 커스터마이징을 거칩니다. dx와 gl을 wrapping하고 그 윗부분만 건드린다면야 별로 문제가 없겠지만, 실제로는 그렇지 않기 때문에 상용 엔진을 쓴다하더라도 많은 수정을 거쳐야 합니다.
와우는 넷임머스라고 게임브리오 구 버젼을 사용하고 있는데, 사고 난 다음에 커스터마이징을 거쳐서 지금은 완전히 다른 엔진이 되었다고 들었습니다.
OS api의 경우 아주 일부분이라고 하더라도 중복 작업이 필요하고 인터페이스 노출이 필요하기 때문에 굳이 다른 플랫폼까지 고려해서 작업을 한다면 기존 일의 양보다 몇배는 늘어나게 됩니다.
예를 들어, 파일 패킹 작업을 하고 있는데, window 라면 MS에서 제공하면 structured storage를 쓰면 적당히 패킹을 할 수 있지만, mac, linux 까지 확장을 고려한다면
파일 시스템을 아예 새로 설계해야 되는 엄청 큰 작업으로 변해버립니다. zlib로 그냥 압축해버리고 암호를 걸어버릴수도 있겠지만 -_-; 제대로 패킹된 파일 시스템 안에서 파일 추가, 삭제, 이름 변경, 파일 암호화 등등을 고려해서 짜려면 작은 작업이 아니죠.
업데이터도 따로 작성해야 될꺼고, 다른 플랫폼마다 인터페이스가 바뀌더라도 같은 동작을 하는지 보장되어야 할테고요.
종류가 다르지만 같은 기능을 하는 것들을 모아서 하나의 인터페이스로 만들기란 짧은 시간이 걸리는 작업이 아닙니다. 기능은 같더라도 제공하는 인터페이스가 다르기 때문에 각각을 조사해서 어느 쪽을 택하더라도 효율적으로 작동할 수 있도록 인터페이스로 묶어 내는 작업은 많은 조사와 노하우를 요구합니다.
왜 수 많은 회사들이 비싼 엔진을 구입하고도 윈도우에서 밖에 서비스하지 않을까요. 엔진이 황금 도깨비 방망이는 아니죠.
엔진을 사도 그냥 이걸 그대로 윈도우 API 사용하듯이, dx 사용하듯이 사용한다면야 아무런 문제가 없는데, 엔진을 사서 그대로 사용하는 경우는 거의 없고 게임에 맞도록 커스터마이징을 거칩니다. dx와 gl을 wrapping하고 그 윗부분만 건드린다면야 별로 문제가 없겠지만, 실제로는 그렇지 않기 때문에 상용 엔진을 쓴다하더라도 많은 수정을 거쳐야 합니다.
와우는 넷임머스라고 게임브리오 구 버젼을 사용하고 있는데, 사고 난 다음에 커스터마이징을 거쳐서 지금은 완전히 다른 엔진이 되었다고 들었습니다.
OS api의 경우 아주 일부분이라고 하더라도 중복 작업이 필요하고 인터페이스 노출이 필요하기 때문에 굳이 다른 플랫폼까지 고려해서 작업을 한다면 기존 일의 양보다 몇배는 늘어나게 됩니다.
예를 들어, 파일 패킹 작업을 하고 있는데, window 라면 MS에서 제공하면 structured storage를 쓰면 적당히 패킹을 할 수 있지만, mac, linux 까지 확장을 고려한다면
파일 시스템을 아예 새로 설계해야 되는 엄청 큰 작업으로 변해버립니다. zlib로 그냥 압축해버리고 암호를 걸어버릴수도 있겠지만 -_-; 제대로 패킹된 파일 시스템 안에서 파일 추가, 삭제, 이름 변경, 파일 암호화 등등을 고려해서 짜려면 작은 작업이 아니죠.
업데이터도 따로 작성해야 될꺼고, 다른 플랫폼마다 인터페이스가 바뀌더라도 같은 동작을 하는지 보장되어야 할테고요.
종류가 다르지만 같은 기능을 하는 것들을 모아서 하나의 인터페이스로 만들기란 짧은 시간이 걸리는 작업이 아닙니다. 기능은 같더라도 제공하는 인터페이스가 다르기 때문에 각각을 조사해서 어느 쪽을 택하더라도 효율적으로 작동할 수 있도록 인터페이스로 묶어 내는 작업은 많은 조사와 노하우를 요구합니다.
왜 수 많은 회사들이 비싼 엔진을 구입하고도 윈도우에서 밖에 서비스하지 않을까요. 엔진이 황금 도깨비 방망이는 아니죠.
2008.07.14 12:28:22 (*.134.137.96)
날자고도 음 //
실제 서비스되는 부분은 c++이라서, 님이 예로 닷넷같은 것들은 의미가 없을거 같습니다.
엔진을 커스터마이징하는 부분에서는 얼마나 추가되느냐에 따라 달라질수있겠군요.
그리고, os api의 경우, 게임에서 사용하는 부분은 극히 일부분인거죠.
마치, 우리가 게임을 만들때, win api를 거의 사용안하는것처럼요
그외의 파일패킹작업들은 다들, 자체패킹을 많이 쓰지 않나요?
윈도밖에 서비스안한다는것은 단지 수요의 문제이지, 기술의 문제는
아니라고 봅니다.
만약 수요가 있다면, 어떤수라도 쓰지 않겠어요?
그러니깐, 결론은 게임개발을 할때, os에 종속적인 api는
게임코드에서 얼마안들어간다는거죠.
실제 서비스되는 부분은 c++이라서, 님이 예로 닷넷같은 것들은 의미가 없을거 같습니다.
엔진을 커스터마이징하는 부분에서는 얼마나 추가되느냐에 따라 달라질수있겠군요.
그리고, os api의 경우, 게임에서 사용하는 부분은 극히 일부분인거죠.
마치, 우리가 게임을 만들때, win api를 거의 사용안하는것처럼요
그외의 파일패킹작업들은 다들, 자체패킹을 많이 쓰지 않나요?
윈도밖에 서비스안한다는것은 단지 수요의 문제이지, 기술의 문제는
아니라고 봅니다.
만약 수요가 있다면, 어떤수라도 쓰지 않겠어요?
그러니깐, 결론은 게임개발을 할때, os에 종속적인 api는
게임코드에서 얼마안들어간다는거죠.
2008.07.14 12:59:11 (*.233.209.91)
기술의 문제라고 한 적은 없는데 -_- 이종간의 작업은 시간이 많이 걸리고, 시간은 돈이고, 시간을 들일만큼 경제성이 없어서 안하고 있는 것 같다고 적었습니다.
게임 엔진 하나도 안고치고 멀티 플랫폼 지원하는 엔진을 사서 게임을 만들었다고 합시다.
게임 코드 올릴라면 리눅스용 맥용 윈도우용 따로 컴파일해서 업데이트 따로 다 해줘야되는데 이건 누가합니까. 사람 뽑아서 시간, 돈 들여가면서 해야 되는데.
날자고도님께서는 멀티 플랫폼을 지원하는 엔진을 사면 된다고 적으셨고, 저는 엔진을 사더라도 유지, 보수, 개발하는데 시간, 돈이 들어갈 것이기 때문에 경제성 문제 때문에 안될 거라고 대답을 했습니다. ( 개발에 대한 예가 졸렬했던 건 있지만, 의미는 전달 됐을 거라 생각합니다. 멀티 플랫폼 엔진을 구입한 다른 게임 회사들이 이종 플랫폼간의 서비스를 하지 않고 있다는 얘기도 했고요. )
근데도 날자고도 님께서는 수요가 있으면 ( 경제성 문제가 해결되면 ) 어떤 수라도 쓰지 않겠냐고 다시 물어보시네요 -_-; 수요가 있으면 경제성이 있으니 돈 버는 회사 입장에서는 당연히 서비스해야죠 -_-; 시간을 투자해가면서 할만한 가치가 있으니까요.
결국 날자고도 님께서도 경제성 문제 때문에 이종간 서비스를 하지 않는다고 생각하시는 거죠? 결론은 'OS 종속적인 api가 게임 코드에 얼마 안들어간다'가 되어서는 안되고, '분명히 OS 종속적인 코드가 들어가고, 이 코드를 개발하고 유지하는데 소비되는 비용을 따져보자면 경제성에 맞지 않아 서비스를 하지 않는다'가 되어야 하지 않을까요.
게임 엔진 하나도 안고치고 멀티 플랫폼 지원하는 엔진을 사서 게임을 만들었다고 합시다.
게임 코드 올릴라면 리눅스용 맥용 윈도우용 따로 컴파일해서 업데이트 따로 다 해줘야되는데 이건 누가합니까. 사람 뽑아서 시간, 돈 들여가면서 해야 되는데.
날자고도님께서는 멀티 플랫폼을 지원하는 엔진을 사면 된다고 적으셨고, 저는 엔진을 사더라도 유지, 보수, 개발하는데 시간, 돈이 들어갈 것이기 때문에 경제성 문제 때문에 안될 거라고 대답을 했습니다. ( 개발에 대한 예가 졸렬했던 건 있지만, 의미는 전달 됐을 거라 생각합니다. 멀티 플랫폼 엔진을 구입한 다른 게임 회사들이 이종 플랫폼간의 서비스를 하지 않고 있다는 얘기도 했고요. )
근데도 날자고도 님께서는 수요가 있으면 ( 경제성 문제가 해결되면 ) 어떤 수라도 쓰지 않겠냐고 다시 물어보시네요 -_-; 수요가 있으면 경제성이 있으니 돈 버는 회사 입장에서는 당연히 서비스해야죠 -_-; 시간을 투자해가면서 할만한 가치가 있으니까요.
결국 날자고도 님께서도 경제성 문제 때문에 이종간 서비스를 하지 않는다고 생각하시는 거죠? 결론은 'OS 종속적인 api가 게임 코드에 얼마 안들어간다'가 되어서는 안되고, '분명히 OS 종속적인 코드가 들어가고, 이 코드를 개발하고 유지하는데 소비되는 비용을 따져보자면 경제성에 맞지 않아 서비스를 하지 않는다'가 되어야 하지 않을까요.
2008.07.14 14:03:46 (*.134.137.96)
날자고도 기술의 문제라고 한 적은 없는데 -_-
=>"mac 용으로 컨버팅하는데 무슨 기술이 필요하다거나 하는 문제가 있지 않을까 생각해 봅니다."
처음질문자가 올린글을 대신올립니다.
게임 코드 올릴라면 리눅스용 맥용 윈도우용 따로 컴파일해서 업데이트 따로 다 해줘야되는데 이건 누가합니까. 사람 뽑아서 시간, 돈 들여가면서 해야 되는데.
=> 자동화를 해야겠지요. 설마 윈도에서도 한사람이 빌드하면, 그거 수동으로 압축하고, 넘버링하고, 이런것을 수작업하지는 않겠지요?
멀티 플랫폼을 지원하는 엔진을 사면 된다고 적으셨고, 저는 엔진을 사더라도 유지, 보수, 개발하는데 시간, 돈이 들어갈 것이기 때문에 경제성 문제 때문에 안될 거라고 대답을 했습니다
=> 이건, 윈도용을 사도 마찬가지 아닌가요?
( 경제성 문제가 해결되면 ) 어떤 수라도 쓰지 않겠냐고 다시 물어보시네요 -_-;
=> 이건 만약, 맥용에 국한된 기술적문제가 있다면, 어떤수라도 쓰지 않겠느냐는 물음입니다.
즉, 만약진짜 기술적문제라고 해도, 인력풀의 문제이고,
맥용게임이 없다는것은 수요가 없기 때문이라는뜻입니다.
결국 날자고도 님께서도 경제성 문제 때문에 이종간 서비스를 하지 않는다고 생각하시는 거죠?
=> 경제성문제이기는 한데요, ^^;
엄밀하게 본다면, 맥용 제작시 투자인건비가 너무 추가되기때문에 그렇다기보다,
현재 맥용 수요가 거의 없어서라는 의견입니다.
=>"mac 용으로 컨버팅하는데 무슨 기술이 필요하다거나 하는 문제가 있지 않을까 생각해 봅니다."
처음질문자가 올린글을 대신올립니다.
게임 코드 올릴라면 리눅스용 맥용 윈도우용 따로 컴파일해서 업데이트 따로 다 해줘야되는데 이건 누가합니까. 사람 뽑아서 시간, 돈 들여가면서 해야 되는데.
=> 자동화를 해야겠지요. 설마 윈도에서도 한사람이 빌드하면, 그거 수동으로 압축하고, 넘버링하고, 이런것을 수작업하지는 않겠지요?
멀티 플랫폼을 지원하는 엔진을 사면 된다고 적으셨고, 저는 엔진을 사더라도 유지, 보수, 개발하는데 시간, 돈이 들어갈 것이기 때문에 경제성 문제 때문에 안될 거라고 대답을 했습니다
=> 이건, 윈도용을 사도 마찬가지 아닌가요?
( 경제성 문제가 해결되면 ) 어떤 수라도 쓰지 않겠냐고 다시 물어보시네요 -_-;
=> 이건 만약, 맥용에 국한된 기술적문제가 있다면, 어떤수라도 쓰지 않겠느냐는 물음입니다.
즉, 만약진짜 기술적문제라고 해도, 인력풀의 문제이고,
맥용게임이 없다는것은 수요가 없기 때문이라는뜻입니다.
결국 날자고도 님께서도 경제성 문제 때문에 이종간 서비스를 하지 않는다고 생각하시는 거죠?
=> 경제성문제이기는 한데요, ^^;
엄밀하게 본다면, 맥용 제작시 투자인건비가 너무 추가되기때문에 그렇다기보다,
현재 맥용 수요가 거의 없어서라는 의견입니다.
2008.07.14 15:02:38 (*.233.209.91)
흠. -_- 너무 추가되었다는 것의 의미를 생각해본다면, 내가 투자한 것 보다 덜 뽑아낼 것 같다는 뜻이겠죠? 이종 플랫폼 간의 빌드 자동화를 만들어도 시간, 돈 들어가고요.
서로 경제성이 안맞는다는 건 동의하는데 그 크기가 문제군요.
저는 꽤 비용이 많이 들어가서 맥 유저가 훨씬 더 많아야 된다는 거고, 날자고도 님께서는 개발비는 얼마 안돼도 되는데 그 마저도 수요가 없어서 서비스를 안한다는 거고요.
뭐 이건 어떻게 판단하고, 기존 구조가 어떻게 되어 있고, 어떻게 개발하느냐에 따라 다르니. 여기서 얘기하는건 별 의미가 없겠네요.
ps. 개발비 문제 말고도 접근성 차원에서 살펴본다면, 맥이나 리눅스에서는 웹을 통한 바로 실행이 안되죠? (되나요? -_- 리눅스에서 게임을 한번도 실행시켜 본적이 없어서 -_-; ) 웹에서 바로 실행을 못시킨다면 포탈의 페이지뷰를 증가시키지 못하겠고..
광고 단가는 페이지뷰로 결정될텐데 미치는 영향이 윈도우 보다 미약할테고, 포탈의 다른 컨텐츠들 또한 노출이 잘 안되니 홍보에도 그닥 영향을 미치지 않고.. 경제성이 없다고 판단할 수 있는 또 다른 여러가지 근거가 있지 않을까요?
결제 시스템도 우리 나라 대부분은 액티브 액스 기반이라. -_-
서로 경제성이 안맞는다는 건 동의하는데 그 크기가 문제군요.
저는 꽤 비용이 많이 들어가서 맥 유저가 훨씬 더 많아야 된다는 거고, 날자고도 님께서는 개발비는 얼마 안돼도 되는데 그 마저도 수요가 없어서 서비스를 안한다는 거고요.
뭐 이건 어떻게 판단하고, 기존 구조가 어떻게 되어 있고, 어떻게 개발하느냐에 따라 다르니. 여기서 얘기하는건 별 의미가 없겠네요.
ps. 개발비 문제 말고도 접근성 차원에서 살펴본다면, 맥이나 리눅스에서는 웹을 통한 바로 실행이 안되죠? (되나요? -_- 리눅스에서 게임을 한번도 실행시켜 본적이 없어서 -_-; ) 웹에서 바로 실행을 못시킨다면 포탈의 페이지뷰를 증가시키지 못하겠고..
광고 단가는 페이지뷰로 결정될텐데 미치는 영향이 윈도우 보다 미약할테고, 포탈의 다른 컨텐츠들 또한 노출이 잘 안되니 홍보에도 그닥 영향을 미치지 않고.. 경제성이 없다고 판단할 수 있는 또 다른 여러가지 근거가 있지 않을까요?
결제 시스템도 우리 나라 대부분은 액티브 액스 기반이라. -_-
2008.07.14 20:15:07 (*.134.137.96)
날자고도 음 // 네,.. ^^
저도 맥 or 리눅스프로그래머가 아니라서 장담하기는 힘들지만, 현재 웹에서 게임을 실행시키는 구조는 액티브X라서
맥용이나, 리눅스용 액티브액스같은것이 있다면, 가능할지도 모르겠습니다.
저도 맥 or 리눅스프로그래머가 아니라서 장담하기는 힘들지만, 현재 웹에서 게임을 실행시키는 구조는 액티브X라서
맥용이나, 리눅스용 액티브액스같은것이 있다면, 가능할지도 모르겠습니다.
2008.07.19 14:10:19 (*.39.234.132)
안군 기술적인 난점도 있습니다. 특히나 네트워크 게임의 경우에는 big-endian이니 small-endian이니 하는 문제도 있어서,
패킷을 설계하는데 있어서도 두 번 작업해줘야 하는 경우도 많이 생길테고, 고려할 점도 많죠.
게다가 윈도우 플랫폼이 아닌 경우에는, DX로는 게임을 만들 수 없고, OpenGL을 이용해야 하는데,
레퍼런스의 문제 뿐만 아니라, 우리나라 3D 개발자들 대다수가 DX에 특화되어 있어서요...
MS가 여러모로 장사 잘 하고 있는거죠. - -;
패킷을 설계하는데 있어서도 두 번 작업해줘야 하는 경우도 많이 생길테고, 고려할 점도 많죠.
게다가 윈도우 플랫폼이 아닌 경우에는, DX로는 게임을 만들 수 없고, OpenGL을 이용해야 하는데,
레퍼런스의 문제 뿐만 아니라, 우리나라 3D 개발자들 대다수가 DX에 특화되어 있어서요...
MS가 여러모로 장사 잘 하고 있는거죠. - -;
2013.05.19 13:18:29 (*.153.235.115)
![[레벨:3]](http://old.lameproof.com/modules/point/icons/default/3.gif "포인트:962point (24%), 레벨:3/30"){kind=icon}
bestbasci01@yahoo.com
