(57)【要約】   本発明は、プログラム連動方法及びその装置に関するもので、特に、異機種間プログラム連動方法及びそのミドルウェアプラットホームエンジンに関するのである。本発明の一側面によると、ミドルウェアプラットホームエンジンが互いに異なる機種に用いられる目的APIと対象APIを互いに連動する方法において、(a)複数の上記対象APIにインデックス番号を与えてメモリに格納する段階; (b)上記生成される目的APIの生成に必要な上記対象APIに相応するインデックス番号を呼び出す段階; 及び (c)上記インデックス番号に相応する上記対象APIを用いて上記目的APIを生成する段階を含む異機種間プログラム連動方法を提供することができる。本発明による異機種間プログラム連動方法及びそのミドルウェアプラットホームエンジンは、従来開発された 3D ゲームを他の機種にポーティングする期間を短縮し得る効果がある。【選択図】  図１
2010517134.tif 000002
【特許請求の範囲】
【請求項１】
ミドルウェアプラットホームエンジンが互いに異なる機種に用いられる目的APIと対象APIを互いに連動する方法において、
(a)複数の上記対象APIにインデックス番号を与えてメモリに格納する段階;
(b)上記生成される目的APIの生成に必要な上記対象APIに相応するインデックス番号を呼び出す段階; 及び
(c)上記インデックス番号に相応する上記対象APIを用いて上記目的APIを生成する段階を含む異機種間プログラム連動方法。
【請求項２】
上記段階(a)は、
上記対象APIから上記目的APIが実行されるプラットホームに必要なコードを抽出して上記メモリに格納する段階をさらに含むことを特徴とする請求項１に記載の異機種間プログラム連動方法。
【請求項３】
上記段階(b)は、
上記インデックスに相応するコードを抽出する段階をさらに含むことを特徴とする請求項２に記載の異機種間プログラム連動方法。
【請求項４】
上記段階(c)は、
上記対象APIのコードを組み合わせて上記目的APIを生成することを特徴とする請求項３に記載の異機種間プログラム連動方法。
【請求項５】
互いに異なる機種に用いられる目的APIと対象APIを互いに連動するためのミドルウェアプラットホームエンジンにおいて、
複数の上記対象APIにインデックス番号を与えてメモリに格納する格納モジュール部;
上記生成される目的APIの生成に必要な上記対象APIに相応するインデックス番号を呼び出すインデックス呼出部; 及び
上記インデックス番号に相応する上記対象APIを用いて上記目的APIを生成するAPI生成部を含むミドルウェアプラットホームエンジン。
【請求項６】
上記格納モジュール部は、上記対象APIから上記目的APIが実行されるプラットホームに必要なコードを抽出し、上記メモリに格納することを特徴とする請求項５に記載のミドルウェアプラットホームエンジン。
【請求項７】
上記インデックス呼出部は、上記インデックスに相応するコードを抽出することを特徴とする請求項６に記載のミドルウェアプラットホームエンジン。
【請求項８】
上記API生成部は、上記対象APIのコードを組み合わせて上記目的APIを生成することを特徴とする請求項７に記載のミドルウェアプラットホームエンジン。
【請求項９】
上記目的APIの構造に相応するグラフィックライブラリ、メディアライブラリ、Physics ライブラリ及び AI ライブラリのいずれか一つ以上をさらに含むことを特徴とする請求項５に記載のミドルウェアプラットホームエンジン。
【請求項１０】
上記メディアライブラリはグラフィックライブラリまたはサウンドライブラリであることを特徴とする請求項９に記載のミドルウェアプラットホームエンジン。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プログラム連動方法及びその装置に関し、特に、異機種間プログラム連動方法及びその異機種間プログラム連動方法を実行する異機種間連動型ミドルウェアプラットホームエンジン（以下、単に「ミドルウェアプラットホームエンジン」という）に関する。
【背景技術】
【０００２】
従来の WIPI（Wireless Internet Platform for Interoperability）プラットホームは、ジャバ言語の長所を受容し、ネイティブバイナリーの実行性能を有するように開発されたものである。既存の無線インターネットプラットホームは、VM（Virtual Machine）技術とネイティブバイナリー技術に区別される。二つの技術は相互排他的な特性を有している。すなわち、一方の技術の長所が他方の技術の短所になり、一方の技術の短所が他方の技術の長所になる。
【０００３】
VM技術は、言葉通り仮想機械を用いてプログラムを動作させるものである。作成されたプログラムをソフトウェアCPU(Central Processing Unit)で動作できる中間コードに変換すれば、仮想機械が該当コードを実際のCPU用機械語で翻訳して実行させる方式である。
【０００４】
このような技術は、ジャバを通じて一般化されており、ジャバ仮想マシン(JVM: Java （登録商標）Virtual Machine)は無線インターネットプラットホームにも既に適用されている。また、C言語の縮小版であるMini-Cを用いたGVM(General Virtual Machine)技術が国内で開発され、サービスされている。
【０００５】
また、他の技術であるネイティブバイナリー技術は、一般に、我々がプログラムを作成し、コンパイルして実行させる方法と同一の過程を経る。すなわち、開発されたプログラムをプログラムが実行されるCPUで動作される機械語にして実行させるものである。この技術を用いた無線インターネットプラットホームがクアルコムのブループラットホームである。VM基盤の無線インターネットプラットホームは、ソフトウェアCPUを用いて中間コードを実行過程に翻訳(Interpreting)する負担を抱いており、これは、CPU性能と資源が制限された携帯電話機で使用者が相対的に非常に遅い速度を経験するようになる。しかし、VM技術は、相対的なシステム安全性を提供し、完璧な保安を提供する長所を有している。
【０００６】
一方、ネイティブバイナリーを用いるプラットホームは、VM技術とは異なり、搭載されたCPUの性能を100％活用できるため、VMに比べて非常に速い実行速度を提供する。しかし、今日のネイティブバイナリーを用いる技術は、開発言語としてC/C++を用いており、プログラム開発者により悪意的なメモリアプローチを通じたシステム安全性に危害を生じさせる要素を有している。WIPIプラットホームは、このような対照される二つの技術の長所を有するプラットホームとして計画され、開発された。すなわち、ジャバ言語の長所を受容し、ネイティブバイナリーの実行性能を有するようにするものである。
【０００７】
したがって、WIPIプラットホームは、C/C++とジャバを基本言語として採択してプログラムの開発が可能であり、端末機に搭載されるアプリケーションはネイティブバイナリーとして作られ、実行性能の保障を受ける。ここで、C/C++言語は、ネイティブバイナリーを生成するのに何ら問題がないが、ジャバ言語は基本的に仮想機械を対象とするため、ジャバをコンパイルして端末機で直接実行可能な実行バイナリーをどこかで作らなければならない。このような機能を遂行する WIPI 構成要素が正にCOD(Compile On Demand)である。
【０００８】
最近、ゲームフォンの登場による本格的なプレミアム級のゲームサービスの必要性が台頭している。WIPIと既存のOpen GL及びDirect X基盤のAPI(Application Program Interface)を Open GL ES基盤に連動し、端末機上でのゲーム駆動時に有効な性能を具現し得る機能が必要である。
ゲームミドルウェアを端末機に動的リンク(Dynamic Link)方式で具現することによりゲーム開発を容易にし、端末機の環境に最適化された性能のゲームエンジンが必要である。今後の端末機の進化及び構造的な改善を念頭に置いて多様な外部開発環境を受容し得る優れた拡張性を備えたミドルウェア(Middleware)の設計が必要である。
【発明の概要】
【発明が解決しようとする課題】
【０００９】
本発明は、従来に開発された3D ゲームを他の機種にポーティングする期間を短縮し得る異機種間のプログラム連動方法及びそのミドルウェアプラットホームエンジンを提供する。
【００１０】
また、本発明は、多様なモバイルゲームを提供することにより、モバイルゲーム産業の復興をはかる異機種間のプログラム連動方法及びそのミドルウェアプラットホームエンジンを提供する。本発明が提示する前記技術的課題及び他の技術的課題は、下記の説明を通じて容易に理解できるものである。
【課題を解決するための手段】
【００１１】
本発明の一側面によると、ミドルウェアプラットホームエンジンが互いに異なる機種に用いられる目的APIと対象APIを互いに連動する方法において、(a)複数の上記対象APIにインデックス番号を与えてメモリに格納する段階; (b)上記生成される目的APIの生成に必要な上記対象APIに相応するインデックス番号を呼び出す段階; 及び (c)上記インデックス番号に相応する上記対象APIを用いて上記目的APIを生成する段階を含む異機種間プログラム連動方法を提供することができる。
【００１２】
ここで、上記段階(a)は、上記対象APIから上記目的APIが実行されるプラットホームに必要なコードを抽出して上記メモリに格納する段階をさらに含むことができる。
【００１３】
ここで、上記段階(b)は、上記インデックスに相応するコードを抽出する段階をさらに含むことができる。
【００１４】
ここで、上記段階(c)は、上記対象APIのコードを組み合わせて上記目的APIを生成することができる。
【００１５】
本発明の他の側面によると、互いに異なる機種に用いられる目的APIと対象APIを互いに連動するためのミドルウェアプラットホームエンジンにおいて、複数の上記対象APIにインデックス番号を与えてメモリに格納する格納モジュール部; 上記生成される目的API 生成に必要な上記対象APIに相応するインデックス番号を呼び出すインデックス呼出部; 及び上記インデックス番号に相応する上記対象APIを用いて上記目的APIを生成するAPI生成部を含むミドルウェアプラットホームエンジンを提供することができる。
【００１６】
ここで、上記格納モジュール部は、上記対象APIから上記目的APIが実行されるプラットホームに必要なコードを抽出して上記メモリに格納することができる。
【００１７】
ここで、上記インデックス呼出部は、上記インデックスに相応するコードを抽出することができる。
【００１８】
ここで、上記API生成部は、上記対象APIのコードを組み合わせて上記目的APIを生成することができる。
【００１９】
ここで、上記目的APIの構造に相応するグラフィックライブラリ、メディアライブラリ、Physicsライブラリ及び AI（Artificial Intelligence）ライブラリのいずれか一つ以上をさらに含むことができる。
【００２０】
ここで、上記メディアライブラリは、グラフィックライブラリまたはサウンドライブラリであり得る。
【発明の効果】
【００２１】
本発明による異機種間プログラム連動方法及びそのミドルウェアプラットホームエンジンは、従来開発された 3D ゲームを他の機種にポーティングする期間（時間）を短縮し得る効果がある。
【００２２】
また、本発明による異機種間プログラム連動方法及びそのミドルウェアプラットホームエンジンは、多様なモバイルゲームを提供することにより、モバイルゲーム産業の復興をはかる効果がある。
【図面の簡単な説明】
【００２３】
【図１】本発明の実施例による異機種間連動型プログラム生成装置を含む異機種機器のブロック構成図。
【図２】本発明の実施例による異機種間連動型プログラム生成装置の動作を示したブロック構成図。
【図３】本発明の実施例による異機種間連動型プログラム生成装置が駆動される異機種機器のブロック構成図。
【図４】本発明の第1実施例による異機種間連動型プログラム生成装置がAPI関数を生成する方法を示した図面。
【図５】本発明の第2実施例による異機種間連動型プログラム生成装置がAPI関数を生成する方法を示した図面。
【図６】本発明の第3実施例による異機種間連動型プログラム生成装置がAPI関数を生成する方法を示した図面。
【図７】本発明の第4実施例による異機種間連動型プログラム生成装置がAPI関数を生成する方法を示した図面。
【図８】本発明の実施例による異機種間連動型プログラム生成装置の中でプログラム開発ツールのブロック構成図。
【図９】本発明の実施例による異機種間連動型プログラム生成装置中、プログラム開発ツールによるプログラム開発環境を示した図面。
【図１０】本発明の実施例によるプログラム開発ツールのブロック構成図。
【図１１】本発明の実施例によるプログラム開発ツールの中間言語及びコンパイル過程を示した図面。
【図１２】本発明の実施例による異機種間連動型プログラム生成装置のメモリ使用構成図。
【図１３】本発明の実施例による異機種間連動型プログラム生成装置の UIツールとメモリの関係を示した図面。
【発明を実施するための形態】
【００２４】
本発明は、多様な変更を加えることができ、種々の実施例を有することができるところ、特定実施例を図面に例示し、詳細な説明に詳しく説明する。しかし、これは、本発明を特定の実施形態に対して限定しようとするものではなく、本発明の思想及び技術的範囲に含まれる全ての変更、均等物ないし代替物を含むものと理解されなければならない。
【００２５】
第1、第2などのように、序数を含む用語は、多様な構成要素を説明するのに用いられ得るが、上記構成要素は、上記用語により限定されない。上記用語は、一つの構成要素を他の構成要素から区別する目的としてのみ用いられる。例えば、本発明の権利範囲を逸脱しないながら第1 構成要素は第2構成要素と命名され得、類似に第2構成要素も第1 構成要素と命名され得る。及び/またはという用語は、複数の関連して記載した項目の組み合わせまたは複数の関連して記載した項目のいずれかの項目を含む。
【００２６】
ある構成要素が他の構成要素に “連結されて”いるか、または“接続されて” いると言及された時には、その他の構成要素に直接的に連結されているか、または接続されていることもできるが、中間に他の構成要素が存在することもできると理解されなければならない。一方、ある構成要素が他の構成要素に“直接連結されて”いるか、または“直接接続されて”いると言及された時には、中間に他の構成要素が存在しないものと理解されなければならない。
【００２７】
本出願で用いた用語は、単に特定の実施例を説明するために用いられたもので、本発明を限定しようとする意図ではない。単数の表現は、文脈上、明白に異なると意味しない限り、複数の表現を含む。本出願において、“含む” または “有する” などの用語は、明細書上に記載した特徴、数字、段階、動作、構成要素、部品またはこれらを組み合わせたのが存在することを指定しようとするものであり、一つまたはそれ以上の他の特徴や数字、段階、動作、構成要素、部品またはこれらを組み合わせたもの存在または付加可能性をあらかじめ排除しないものと理解されなければならない。
【００２８】
他に定義されない限り、技術的や科学的な用語を含み、ここで用いられる全ての用語は、本発明が属する技術分野において通常の知識を有する者により一般に理解されるものと同一の意味を有している。一般に用いられる辞典に定義されているような用語は、関連技術の文脈上有する意味と一致する意味を有すると解釈されなければならず、本出願において明白に定義しない限り、理想的や過度に形式的な意味と解釈されない。
【００２９】
また、添付した図面を参照して説明するにおいて、図面の符号に関係なく同一の構成要素は同一の参照符号を与え、これに対する重複する説明は省略する。本発明を説明するにおいて、関連した公知技術に関する具体的な説明が本発明の要旨を不必要に糊塗することができると判断される場合、その詳しい説明を省略する。
【００３０】
本発明によるミドルウェアプラットホームエンジンは異機種間連動型プログラム生成装置に含まれることができ、以下では全体的な構造を説明するために、異機種間連動型プログラム生成装置を中心に説明する。
【００３１】
図1は、本発明の実施例による異機種間連動型プログラム生成装置を含む異機種機器のブロック構成図である。図1を参照すれば、アプリケーション(110)、ミドルウェアアダプテーションレイヤー(120)、ライブラリ(130)、フレームワーク(140)、ミドルウェアプラットホームエンジン(150)、異機種 Run-time エンジン(160)、ハンドセットアダプテーションレイヤー(HAL : Handset Adaptation Layer)(170)、ハンドセットハードウェアとネイティブシステムソフトウェア(180)及び必要API(190)が示される。
【００３２】
アプリケーション(110)は、異機種間に実行されるプログラムの最上位階層のプログラムであり、例えば、ゲームプログラムになり得る。以下において、詳しい説明が必要な場合、ゲームプログラムを主として説明する。また、説明の便宜のために、PC（Personal Computer）環境で実行されるプログラムをモバイル環境(例えば、携帯電話、ゲームフォン、ポストPC などの環境)で実行されるプログラムに変更する場合を中心に説明する。勿論、本発明は、その逆意過程に対しても具現されることができることは当然である。
【００３３】
ミドルウェアアダプテーションレイヤー(120)は、異機種間プログラムの連動のために準備されるレイヤーである。ミドルウェアアダプテーションレイヤー(120)は、あらかじめ設定された機能を基準として目的APIに相応する対象APIを抽出し、該当機能に対応する目的API数と対象API数を抽出する API抽出部を含むことができる。また、ゲームミドルウェアアダプテーションレイヤー(120)は、目的API数と対象API数を互いに対応させ、目的APIに対象APIをマッピングするAPIマッピング部を含むこともできる。ここで、対象APIは変更前のAPIであり、目的APIは対象APIを用いて生成されたAPIである。対象APIまたは上記目的APIは、DirectX、Open GL（Open Graphics Language）、Open GL ES（Open GL Embedded Systems）及びRenderWareのような関数のいずれか一つであり得る。
【００３４】
ミドルウェアアダプテーションレイヤー(120)は、Direct XをOpen GL ESにマッピングする場合、Windows（登録商標）基盤で設計された一般のPCゲームを容易にポーティングできるように、Direct Xモジュールを支援する。モバイル3Dの大部分がOpen GL ESになっており、これをコンバーションすることができる。
【００３５】
また、Open GLをOpen Gl ESにマッピングする場合、ミドルウェアアダプテーションレイヤー(120)は、Linux基盤で設計されたゲーム及びその他 Open GLで開発されたゲーム及びコンテンツを容易にポーティングできるように支援する。Open GL ESの場合、Open GLの一部機能のみを支援するため、支援しない機能を追加することができる。
【００３６】
また、RenderWareを Open GL ESにマッピングする場合、ミドルウェアアダプテーションレイヤー(120)は、PS(PlayStation)2、PS3、X-BOX、GameCubeなどのコンソール機器及びPCと PSP（PlayStation Portable）、N-GageなどのCross-Platform開発環境である RenderWareで開発されたゲームを容易にポーティングできるように支援する。ミドルウェアアダプテーションレイヤー(120)は、プレースチーションゲーム及びその他プラットホームゲームを容易にコンバージョンするために支援することができる。
【００３７】
また、Open GL ES 基盤の拡張ライブラリを支援する場合、ミドルウェアアダプテーションレイヤー(120)は、Open GL ESチップが内蔵された携帯電話及びモバイル端末機に基本APIを基盤に拡張された機能と性能の向上のために開発ライブラリを提供することができる。
【００３８】
ライブラリ(130)は、変更された後のプログラムで実行されるライブラリの集合である。例えば、ライブラリ(130)は、移動通信端末機及びポストPC プラットホームに最適化されたゲームライブラリになり得る。ライブラリ(130)の種類は、グラフィック、アニメーション、サウンド、Physics、AI、Ext などになり得る。
【００３９】
フレームワーク(140)は、モバイル環境のフレームワーク、すなわち、プラットホーム、H/W（Hardｗare）、I/F （Interface）などを指す。
【００４０】
ミドルウェアプラットホームエンジン(150)は、ミドルウェアエンジンとモバイル環境のエンジンを選択するエンジンセレクターで構成される。ここで、ミドルウェアエンジンは、複数の対象APIにインデックス番号を与えてメモリに格納する格納モジュール部、生成される目的APIの生成に必要な対象APIに相応するインデックス番号を呼び出すインデックス呼出部、インデックス番号に相応する対象APIを用いて目的APIを生成するAPI生成部を含むことができる。
【００４１】
ここで、格納モジュール部は、対象APIから目的APIが実行されるプラットホームに必要なコードを抽出してメモリに格納することができる。この場合、インデックス呼出部はインデックスに相応するコードをさらに抽出し、API生成部は対象APIのコードを組み合わせて目的APIを生成することができる。
【００４２】
すなわち、ミドルウェアプラットホームエンジン(150)は、ミドルウェアアダプテーションレイヤー(120)において、API別、機能別、構造別に選択されたそれぞれの関数から目的APIを生成することができる。
【００４３】
異機種Run-timeエンジン(160)、ハンドセットアダプテーションレイヤー(170)及びハンドセットハードウェアとネイティブシステムソフトウェア(180)はそれぞれモバイル環境で既存に具現されているそれぞれのレイヤーである。すなわち、これらはモバイル環境の具現のために設けられたH/WとS/Wであり、これらは必要API(190)である2D API、3D API、M&U API、Eglx API、拡張 APIと連動される。
【００４４】
図2は、本発明の実施例による異機種間連動型プログラム生成装置の動作を示したブロック構成図である。図2を参照すれば、対象API(210)、第2プラットホーム構造(220)が示される。第2プラットホーム構造(220)は、ミドルウェアアダプテーションレイヤー(225)、ミドルウェアアダプテーションレイヤーのためのエンジン構造(230)、ミドルウェアプラットホームエンジン(240)、ソフトウェア 3D エンジン(250)、目的API(260)を含む。上述したこととの差異を主として説明する。
【００４５】
対象API(210)は、DirectX(213)、Open GL/Open GL ES(215)及び RenderWare(217)になり得る。対象API(210)で用いられる関数構造とメモリ構造は、目的API(260)で用いられる関数構造とメモリ構造と互いに異なる。したがって、ミドルウェアアダプテーションレイヤー(225)、ミドルウェアアダプテーションレイヤーのためのエンジン構造(230)、ミドルウェアプラットホームエンジン(240)で関数の構造を変更して対象API(210)を第2プラットホーム構造(220)に適するように目的API(260)を生成する。
【００４６】
ミドルウェアアダプテーションレイヤーのためのエンジン構造(230)は、ミドルウェアアダプテーションレイヤー(225)に目的API(260)に適するように抽出された対象API(210)のそれぞれの関数をミドルウェアプラットホームエンジン(240)のための構造に変更する。
【００４７】
ミドルウェアプラットホームエンジン(240)は、ミドルウェアエンジン(243)とエンジンセレクター(245)を含むことができる。ミドルウェアエンジン(243)は上述したように対象APIのそれぞれの関数を用いて目的APIを生成する。生成された目的APIは、エンジンセレクター(245)により相応するソフトウェア 3D エンジン(250)で実行されるようにする。
【００４８】
ソフトウェア 3D エンジン(250)は、エンジンセレクター(245)からこれに相応する APIの入力を受けて目的API(260)を行う。 ここで、ソフトウェア 3D エンジン(250)は3Dの場合に行うエンジンであり、本発明が3Dに限定されないことは当然である。
【００４９】
図3は、本発明の実施例による異機種間連動型プログラム生成装置が駆動される異機種機器のブロック構成図である。上述したこととの差異を主として説明する。
【００５０】
ミドルウェアプラットホームエンジン(150)により生成された目的APIは、第2プラットホーム構造(350)で実行される。第2プラットホーム構造(350)は、HALまたはハンドセットハードウェアとネイティブシステムソフトウェア(353)、PDA (Personal Digital Assistants)またはモバイルセット(356)、OS(Window/Linux/Unix（登録商標）/Mac)（359）を選択的に採択して駆動され得る。
【００５１】
したがって、目的APIは、ミドルウェアプラットホームエンジン(150)により第2プラットホーム構造(350)に相応して変更されることができる。
【００５２】
以上において異機種間連動型プログラム生成装置を一般に示したブロック構成図を説明し、以下では添付図面を参照し、本発明による異機種間連動型プログラム生成装置でAPI関数が変形される具体的な実施例を説明する。本発明がこのような実施例により限定されないことは当然である。
【００５３】
図4は、本発明の第1実施例による異機種間連動型プログラム生成装置がAPI関数を生成する方法を示した図面である。
【００５４】
本発明の第1実施例は、一つの対象API(210)が一つの目的APIに対応する場合、一つの目的APIに必要な因子(420)を対象APIの因子(410)から抽出して一つの目的APIを生成する場合である。ここで、因子(410)は、対象API(210)の関数またはコードから抽出され、目的APIを形成するのに必要な構成要素になり得る。目的APIに必要な因子(420)は、ミドルウェアプラットホームエンジン(240)により目的APIの生成に利用されることができる。
【００５５】
一つの対象API(210)が一つの目的APIに対応する場合、一つのAPIの関数またはコードを分析して必要な因子のみを抽出することにより、簡便に目的APIを生成することができる。
【００５６】
また、このような因子を抽出するために、API抽出部またはミドルウェアプラットホームエンジン(240)は、対象APIの構造と目的APIの構造を互いに比較することができる。比較結果、その構造が同一な場合、ミドルウェアプラットホームエンジン(240)は対象APIをすぐに目的APIに変換することができる。また、比較結果、その構造が互いに同一ではなく、類似の場合、API 抽出部またはミドルウェアプラットホームエンジン(240)は類似の因子を抽出し、これを用いて目的APIを生成することができる。
【００５７】
また、ここで抽出された因子(410、420)は、メモリに格納され、必要時にメモリから呼出されて用いられる。抽出された因子(410、420)は、その全体がメモリに格納されることもでき、インデックスまたはメモリアドレスがメモリに格納され、必要時に該当インデックスまたはメモリアドレスにより呼出されることができる。
【００５８】
図5は、本発明の第2実施例による異機種間連動型プログラム生成装置がAPI関数を生成する方法を示した図面である。
【００５９】
本発明の第2実施例は、一つの対象API(210)が複数の目的APIに対応する場合、複数の目的APIに必要な因子(520、525)を対象APIの因子(510)から抽出し、複数の目的APIを生成する場合である。ここで、因子(510)は対象API(210)の関数またはコードから抽出され、目的APIを形成するのに必要な構成要素である因子(520、525)として活用されることができる。
【００６０】
ここで、一つの対象API(210)から抽出された因子(510)は、複数の目的APIに対応される場合を説明したが、複数の因子(520、525)が一つの目的APIを形成することもできる。
【００６１】
図6は、本発明の第3実施例による異機種間連動型プログラム生成装置がAPI関数を生成する方法を示した図面である。
【００６２】
本発明の第3実施例は、複数の対象API(210)が一つの目的APIに対応する場合、一つの目的APIに必要な因子(520)を複数の対象APIの因子(610、615)から抽出し、一つの目的APIを生成する場合である。
【００６３】
図7は、本発明の実施例による異機種間連動型プログラム生成装置の中でプログラム開発ツールのブロック構成図である。
【００６４】
本発明の第4実施例は、複数の対象API(210)が複数の目的APIに対応する場合、複数の目的APIに必要な因子(720、725)を複数の対象APIの因子(710、715)から抽出し、複数の目的APIを生成する場合である。勿論、上述したように、目的APIに必要な複数の因子(720、725)は、一つの目的APIを形成することもできる。
【００６５】
図8は、本発明の実施例による異機種間連動型プログラム生成装置中、プログラム開発ツールのブロック構成図である。
【００６６】
図8を参照すれば、源泉データリソース(810、850)、リソースコンバータ(820)、ツール(830)、ソースコンバータ(840)、エクスポート(860)、API 連結 List(870)、プログラムソース(880)が示される。プログラムがゲームプログラムの場合を中心に説明する。
【００６７】
本発明の実施例によるプログラム開発ツールは、対象APIから所定の機能に相応する関数を抽出する関数抽出部と、関数に該当するメモリアドレスを生成するメモリアドレス生成部と、メモリアドレスを呼出し、目的APIを生成時に必要な対象APIの関数を抽出し、これを用いて目的APIを生成する API 変換部を含むことができる。
【００６８】
ここで、目的APIを生成する必要な関数は、ブロックの形態で別途に定められてメモリに格納される。その後に格納された関数のメモリアドレスを呼出し、必要な関数を抽出して目的APIを生成することができる。
【００６９】
源泉データリソース(810、850)は、変更される前のデータであり、3D Object、Image、Sound、3D Max/Light wave などになり得る。
【００７０】
リソースコンバータ(820)は、対象APIの関数のリソースを目的APIが適用されるプラットホームフォーマットに変換する。リソースコンバータ(820)は、異機種機器で動作するプログラム(例えば、ゲーム)の 2D、3D、アニメーション、Moving Picture、サウンドなどのリソース(Resource)を第2プラットホームフォーマット(例えば、モバイル用フォーマット)に変換し、最適化する機能を提供する。
【００７１】
ツール(830)は、アニメーション、マップ、effect、UIと関連したデータを第2プラットホームフォーマットに適合するように変換する。例えば、ツール(830)のアニメーションツールは 3D Max、Lightwaveなどで製作されたアニメーションを Mesh別に結合する。
【００７２】
ツール(830)のマッピングツールは、背景と関連してMap Tile Pattern 設定をツール上で指定することができ、指定された Map Tileをマップ上に自動で組み合わせて Cell単位で指定する。また、マッピングツールは製作しようとするマップのサイズを 2にn乗の単位でセットし、セットされた地形の高低を Bitmap Pixelの RGB値を用いる方法とツール上に支援するブラッシュで用いる方法により、Cell別に高低を設定することができる。また、マッピングツールは、地形のCell別にVertexカラーセッティングを支援し、これは、 Characterに影響を与えることがある。また、マッピングツールは、フォッグ及びライト設定機能(マップ別にライトの明るさとカラーを指定することができ、フォッグの色相濃度を指定可能な機能)を有することができる。この場合、マッピングツールはマップを構成するオブジェクトを Cell単位で割り当てて配置することができる。また、マッピングツールは、Cell 単位で属性(移動不可、移動可、安全地帯)を指定することができ、このような機能により、オブジェクト別に移動経路を指定することができる。例えば、マッブ(mob: mobile object)、NPC（non-player character）、キャラクターそれぞれの客体別に独立的な移動経路が指定され得る。
【００７３】
ツール(830)の UI(User Interface)ツールは、インターフェース製作時にプログラマーの介入を最小化し、グラフィックデータ使用量を最適化することができる。このうち、リソースツールは TGA(Truevision Graphics Adapter)、BMP(Bit MaP)及び各種ファイルを支援し、Bitmapで必要なリソースを所望のサイズに切り取ってIDを付与する。また、リソースツールは、インターフェースに必要なリソースの自動組合せパターンを生成ボタンのアクションを指定する。
【００７４】
また、UIツール中、インターフェースツールはゲームを構成するインターフェースをフォルダ別に区分して管理し、インターフェースを構成する。また、インターフェースツールは、上述したリソースツールで指定したIDとパターンを用いて所望のインターフェースを製作する。インターフェースツールはインターフェースの初期オープン位置を与え、短縮キーを与え、インターフェースに含まれる全てのテキストを別途のファイル別に管理し、各インターフェース別にAlpha Blendの程度を設定することができる。
【００７５】
ソースコンバータ(840)は、対象APIのライブラリを目的APIが適用されるプラットホームフォーマットに変換する。ソースコンバータ(840)は Direct X、Open GL、RenderWare Graphic ライブラリをモバイル用ゲームミドルウェアプラットホーム構造に適するように自動変換する機能を提供する。ソースコンバータ(840)は、Direct X、RenderWare、Open GLのライブラリをミドルウェアプラットホームのライブラリに変換する。(例えば、DirectX-> Open GLes/ RenderWare-> Open GLes)
【００７６】
エクスポート(860)は、対象APIのコンテンツを目的APIが適用されるプラットホームフォーマットに変換する。エクスポート(860)は、モバイル 3Dゲームで用いられる2Dグラフィック、3Dグラフィック、動画等のグラフィックをポーティングしようとするモバイル環境で提供しているフォーマットに変換する機能を提供する。例えば、エクスポート(860)は、3Maxでは3Dで製作されたグラフィックをモバイルに用いる3Dフォーマットに変更する機能を有し、Photoshop、AVI(Audio Video Interleave)などの各種コンテンツをモバイル用フォーマットに変換する Explorer プログラムを提供する。
【００７７】
API 連結 List(870)は、Direct X、RenderWare、Open GLのライブラリをミドルウェアプラットホームのライブラリで連結する API 連結 List値などになり得る。
【００７８】
プログラムソース(880)は、変更される前のプログラムソースである。例えば、プログラムソース(880)は、ゲームプログラムソース及びコンテンツプログラムソースなどになり得る。ここで、プログラムソース(880)は、後述する図11のコンパイラーにおいてコンパイル時に生成される変更される前のデータになり得る。API 連結 List(870)とプログラムソース(880)は、互いに選択的に具備され得る。
【００７９】
図9は、本発明の実施例による異機種間連動型プログラム生成装置中、プログラム開発ツールによるプログラム開発環境を示した図面である。図9を参照すれば、本発明の実施例による企画者(910)、プログラマー(920)、デザイナー(930)の参加機能別の構成が示される。
【００８０】
企画者(910)は、text 入力、メニューフレーム構成、キーイベント処理、シミュレーションテスト、データローディング、メモリ管理(915)を担当する。
【００８１】
プログラマー(920)は、ゲームエンジンを開発し、フォンテストを遂行する。
【００８２】
デザイナー(930)は、キーイベント処理、メニュー/画面構成、イメージ修正、画面配置、シミュレーションテスト(935)を遂行する。
【００８３】
企画者(910)、プログラマー(920)、デザイナー(930)は上述したような UIツール 及び ゲームエディタ(940)であるプログラム開発ツールを通じて効率的にゲームプログラムを開発することができる。UIツール 及び ゲームエディタ(940)で開発されたゲームは、ゲームプレーエンジン(950)によりゲームプログラム(960)で生成される。
【００８４】
図10は、本発明の実施例によるプログラム開発ツールのブロック構成図である。図10を参照すれば、クラス階層構造(1010)、UIツール(1020)、エクスポート(Exporter)(1030)、オブジェクト(Object)(1040)、イベント(Event)(1050)、Time Line(1060)、シミューレーター(Simulator)(1070)が示される。
【００８５】
クラス階層構造(1010)は、同一の機能とリソースの相続及び再使用が可能なクラス階層構造で設計される。
【００８６】
UIツール(1020)は、既存のイメージデータとグラフィックデータを集めてデータを生成する。
【００８７】
エクスポート(1030)は、イメージ(BMP、PNG)、グラフィック、テキスト、サウンドに該当する原始ソースを受けて第2プラットホームフォーマットに適するように再加工し、UIツール 及び ゲームエディタ(940)に使用可能なオブジェクト(1040)を生成する。このようなオブジェクトは、Time Line(1060)に配列され、フレームに配置されたリソースとイベント(1050)を経時によりシミューレーター(1070)で駆動が可能にする。
【００８８】
シミューレーター(1070)は、ゲームの開発において直接端末機上にプログラムをアップロードして発生する問題を事前に解決するようにデバッギング機能及びゲームプレーが可能である。
【００８９】
図11は、本発明の実施例によるプログラム開発ツールの中間言語及びコンパイル過程を示した図面である。図11を参照すれば、スキャナ(1110、1140、1170)、パーサー(1120、1150、1180)、中間言語生成部(1130)、アセンブラ生成部(1160)、二進コード生成部(1190)が示される。
【００９０】
スキャナ(1110、1140、1170)とパーサー(1120、1150、1180)は、中間言語生成、アセンブラ生成、二進コード生成のために C/CPP または専用言語コードを読み込み、スキャン後の文法指示的変換によりパーシング過程で直接コードを生成するか、またはASP(Active Server Pages)などの中間表現を構成した後、このような中間表現から該当作業を遂行することができる。
【００９１】
中間言語生成部(1130)は、コンパイラーの全段部でソースプログラムの入力を受けて中間言語を生成する。ソースプログラムは、語彙の分析と構文分析過程を経て中間表現を生成するようになり、中間言語生成部(1130)により中間言語に翻訳される。この時、中間言語生成部(1130)は、文章の意味を分析し、正しいかを検査する意味分析過程を並行する。意味の分析を遂行することにより、適切なコードの生成が可能になり、また文法的には正しいが、意味的には違った文章を検査することができる。意味の分析で発生したエラーをコンパイラー使用者に知らせることにより、エラー修正を容易にする。文法的及び意味的に正しい文章は、中間言語に翻訳されることができる。中間言語を生成する方法には、文法-指示的変換によりパーシング過程で直接コードを生成する方法とパースツリーや AST(Abstract Syntax Tree) など中間表現を構成した後、このような中間表現から中間コードを生成する方法に分けることができる。本発明の実施例によると、中間表現としてASTを用い、中間言語としてゲーム専用中間言語を用いたが、本発明がこれに限定されないことは当然である。
【００９２】
アセンブラ生成部(1160)は、中間言語生成のような過程を経てアセンブラを生成し、二進コード生成部(1190)も同様な過程により二進コードを生成する。
【００９３】
図12は、本発明の実施例による異機種間連動型プログラム生成装置のメモリ使用構成図である。図12を参照すれば、第1 プラットホーム関数(1210)、ミドルウェアプラットホームエンジン(1220)、第2プラットホーム構造(1230)が示される。
【００９４】
第1 プラットホーム関数(1210)とミドルウェアプラットホームエンジン(1220)は、上述したように、それぞれAPI関数(DirectX、Open GL、Open GL ES 及び RenderWare など)と本発明によるエンジンである。
【００９５】
第2プラットホーム構造(1230)は、H/WとS/W(Software)によりその構造及びメモリの構造が互いに異なるため、用いられるミドルウェアプラットホームエンジン(1220)と互換されるかにより駆動するメモリ構造が異なって割り当てられる。例えば、マルチライト、バンパーマップの場合、OPEN GL ESでは支援しないため、このような場合、H/Wで用いられる構造とメモリ構造を用いることができない。この場合、S/Wで用いられる構造とメモリ構造を別途に割り当てて用いることができる。
【００９６】
図13は、本発明の実施例による異機種間連動型プログラム生成装置の UIツールとメモリの関係を示した図面である。図13を参照すれば、UI 命令に必要な共同メモリ(1310)、UI 実行命令語(1320)、関数 API(1333、1336、1339)が示される。
【００９７】
UIツールで作られた命令通り関数を呼出し、呼出された関数は、ポインタのみを持ってアプローチする。この場合、基本的な情報交換は UI 命令に必要な共同メモリ(1310)を通じて遂行される。すなわち、UI 命令に必要な共同メモリ(1310)は、変数や構造が伝達されるる媒介体としての役割をする。
【００９８】
したがって、UI 実行命令語(1320)は UI 命令に必要な共同メモリ(1310)を参照し、必要な関数 API(1333、1336、1339)を呼び出す。
【００９９】
上述した本発明の実施例による異機種間プログラム連動方法、異機種間連動型プログラム開発方法は、記録媒体に格納された後、所定の装置、例えば、移動通信端末機と結合して遂行されることができる。ここで、記録媒体はハードディスク、ビデオテープ、CD、VCD、DVDのような自己または光記録媒体であるか、またはオフラインまたはオンライン上に構築されたクライアントまたはサーバーコンピューターのデータベースであり得る。
【０１００】
上記では、本発明の好ましい実施例を参照して説明したが、該当技術分野において通常の知識を有する者であれば、特許請求の範囲に記載した本発明の思想及び領域から逸脱しない範囲内で本発明を多様に修正及び変更させ得ることを理解することができる。
【符号の説明】
【０１０１】
110  アプリケーション
120  ミドルウェアアダプテーションレイヤー
130  ライブラリ
140  フレームワーク
150  ミドルウェアプラットホームエンジン
160  異機種 Run-time エンジン
170  ハンドセットアダプテーションレイヤー
180  ハンドセットハードウェアとネイティブシステムソフトウェア
190  必要 API
【図１】
2010517134.tif 000003
【図２】
2010517134.tif 000004
【図３】
2010517134.tif 000005
【図４】
2010517134.tif 000006
【図５】
2010517134.tif 000007
【図６】
2010517134.tif 000008
【図７】
2010517134.tif 000009
【図８】
2010517134.tif 000010
【図９】
2010517134.tif 000011
【図１０】
2010517134.tif 000012
【図１１】
2010517134.tif 000013
【図１２】
2010517134.tif 000014
【図１３】
2010517134.tif 000015
【国際調査報告】
2010517134.tif 000016
2010517134.tif 000017