WO2015168479A1 - Déploiement d'un jeu électronique sur la base de profils de dispositifs - Google Patents

Déploiement d'un jeu électronique sur la base de profils de dispositifs Download PDF

Info

Publication number
WO2015168479A1
WO2015168479A1 PCT/US2015/028659 US2015028659W WO2015168479A1 WO 2015168479 A1 WO2015168479 A1 WO 2015168479A1 US 2015028659 W US2015028659 W US 2015028659W WO 2015168479 A1 WO2015168479 A1 WO 2015168479A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
platform
assets
asset data
translated
Prior art date
Application number
PCT/US2015/028659
Other languages
English (en)
Inventor
Adam Cory CHAPMAN
Jeffrey Norman GRILLS
Brandon Michael BARE
Mathew Adam SHAW
Original Assignee
MPH, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by MPH, Inc. filed Critical MPH, Inc.
Publication of WO2015168479A1 publication Critical patent/WO2015168479A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation

Definitions

  • the disclosure generally relates to a collaborative development system for creating electronic games.
  • FIG. 1 is a system diagram illustrating an embodiment of a collaborative game development environment.
  • Figure 2 is a flowchart illustrating a process for converting electronic assets for an electronic game for deployment on a plurality of different deployment platforms.
  • Figure 3 illustrates an example embodiment of a developer configurable N- dimension data gathering and editing system.
  • Figure 4 illustrates one embodiment of components of an example machine able to read instructions from a non-transitory machine-readable medium and execute them in a processor (or controller).
  • a Database-driven collaborative game development environment and system automatically generates runtime versions of a game for deployment on a plurality of different platforms based on predefined device profiles.
  • the development system allows developers to develop, package and publish to the multiple platforms with optimized runtime (based on device profiles) simultaneously thus improving efficiency and time to market.
  • a database-driven collaborative game development environment and system provides detailed tracking of changes made to an electronic game by multiple remote developers. Changes are tracked based on, for example, the developer making the change, the time of the change, and type of change.
  • the system aggregates the data on a cloud server and then presents analytical data in a manner useful for tracking managing development of the electronic game.
  • the data is tracked objectively and may be displayed in real time, allowing managers to see exactly how their game development team or individual employees are performing. This data may be also used to objectively report team or individual productivity or to subjectively analyze and optimize productivity.
  • One embodiment of a disclosed system, method and non-transitory computer readable storage medium includes deploying an electronic game to multiple gaming platforms.
  • a plurality of digital assets associated with an electronic game are received at a server, where each of the digital assets in a format native to a digital content creation tool.
  • the server converts the plurality of digital assets from the format native to the digital content creation tool to a generic format.
  • the server receives a plurality of platform profiles, where each of the platform profiles associated with respective different types of platforms for deploying the electronic game, and each of the platform profiles specifying platform-specific modification rules for modifying the plurality of digital assets.
  • the server modifies the plurality of digital assets according to each of the platform-specific modification rules to generate a plurality of sets of modified digital assets, each of the sets associated with one of the different types of platforms for deploying the electronic game.
  • the server then generates a plurality of runtime versions of the electronic game, each of the plurality of runtime versions using a corresponding one of the sets of the plurality of assets, where each of the runtime versions associated with one of the different types of platforms for deploying the electronic game.
  • Another embodiment allows designers to review and edit data that is pulled from multiple sources that are composed of multiple types of storage systems.
  • This system can support nearly any type of graph, directed acyclic graph file system, CSV file, or
  • FIG. 1 illustrates an embodiment of a collaborative game development system 100 for developing digital games for platforms such as, for example, gaming consoles, PCs, tablets, and mobile devices.
  • the collaborative game development system 100 enables multiple game developers, potentially working in different remote locations, to collaboratively develop a game.
  • the collaborative game development environment enables managers to effectively manage, track, and generate reports detailing progress of the game under development.
  • the collaborative game development environment enables automatic deployment on a plurality of different gaming platforms based on predefined device profiles.
  • the collaborative game development system 100 comprises a first local network 110-a connecting a first plurality of developer clients 112-a at a first location and a second local network 110-b connecting a second plurality of developer clients 112-b at a second location.
  • Each of the developer clients 112 is coupled with a local database 114.
  • the local database 114 may be stored, for example, in a storage device directly attached to a developer client 112 or elsewhere on the local network 110.
  • one or more of the local databases 114 may be shared among two or more developer clients 112 on the same local network 110.
  • the local databases 114 use a no-SQL database that uses a concept of documents rather than rows and tables.
  • the first local network 110-a and the second local network 110-b are each coupled to a wide area network 120 (such as the Internet) to connect the first local network 110-a and the second local network 110-b to a master cloud services server 130.
  • the master cloud services server 130 provides access to and controls a master content database 140, an asset file storage 150, and a master telemetry database 160 that are each accessible to each of the developer clients 112. In an embodiment, all network traffic for collaboration, asset sharing, and development telemetry pass through the master cloud services server 130.
  • the master cloud services server 130 may provide services such as, for example, authentication, database storage, file storage and collaboration tools.
  • the asset file storage 150 stores binary data for digital assets used in the game under development.
  • an "asset” comprises a digital file or object representing game data. Examples of assets include scripts, meshes, animations, textures, shaders, audio files, etc.
  • the asset file storage 150 additionally stores revisions to assets as they are being updated during development of the game.
  • the master content database 140 stores metadata associated with the game including notes about implementation, usage, materials, measurements, etc. The information dictates where, how, and when objects appear in the game, and contains all world, level, execution, and packaging data.
  • the master content database 140 furthermore stores a history of all revisions made to the game under development and project data including changes to executable code, metadata, and other components for the game under development.
  • the master content database 140 stores associations between digital assets and various metadata.
  • the master content database 140 may indicate, for example, how certain assets are being applied in the game under development (e.g., what textures are applied to a given object, what level and location the object appears, characteristics associated with the asset, etc.).
  • the master database 130 use a no-SQL database that uses a concept of documents rather than rows and tables.
  • the master telemetry database 160 stores all telemetry data from development.
  • the telemetry data may include, for example, a number of assets submitted by an individual developer, time spent developing assets, changes made to the asset (placement, scale, physics, etc.), notes added by a developer, assets imported, etc.
  • the tracked telemetry thus indicates what actions were performed by different developers during development of the game, how long the actions took, when the actions were taken, and who took the actions. Such tracking enables a manager to access information describing all changes made to the game by various developers throughout all stages of development.
  • the master telemetry database 160 also stores gameplay data such as player data, information about how, where, and when the game is played, level completion information, device information, how the players played, what gameplay decisions were made, etc.
  • the collaborative game development system 100 beneficially facilitates real-time collaborative game development and enables game developers to track every change made to the game during development, such as, for example, importing assets, changing positions of assets, writing scripts, etc.).
  • the developer client 112 making the change or import checks whether the asset already exists and modifies the corresponding local database 110 to log the change or import.
  • the developer client 112 creates and stores a log detailing the differences made (delta) by that developer client 112 from the last state of the project.
  • Each local project database 110 is selectively synced with the master content database 140 and so that changes made at one developer client 112 are propagated to the master content database 140, which is in turn synchronized to other local databases 114 for other clients 112.
  • a benefit of the distributed architecture of FIG. 1 is that the local databases 114 enables the developer clients 112 to work offline and distribute the load. Synchronizations to the master database 140 can be done when the master database 140 is available or when otherwise convenient.
  • the provided architecture supports a branching structure, so that normal operation (one or a few developers working in the same branch) do not cause contention with others. Merging may be done when the project directors determine it is time rather than constantly.
  • the architecture of F!G.1 also enables resolution of resolve granular pieces of assets to both avoid merge conflicts and allow developers to work together without conflicts.
  • Platform profiles may include profiles for platforms such as, for example, a PC, a mobile device, a tablet, a game console. Additional profiles may be included for particular operating systems e.g., APPLE OSX, APPLE iOS, ANDROID, WINDOWS, etc.), or particular game consoles (e.g., XBOX, NINTENDO, PLAYSTATION, etc.).
  • each platform profile specifies platform-specific modification rules for modifying assets being deployed to the corresponding platform.
  • the platform-specific modification rules include both developer-specified platform-specific rules that are editable by the developer and immutable platform-specific rules that cannot be changed by the developer.
  • the developer-specified portions may specify characteristics of assets that are not necessarily required by the platform, but are specified by the developer for that platform at the developer's discretion.
  • the immutable portions of the profile may specify characteristics that are not developer-editable and are always applied (and may be required) for that particular platform.
  • FIG. 2 illustrates an embodiment of a process for deploying a game to multiple platforms in the collaborative game development environment 100.
  • developers collaboratively create 202 a game, resulting in the master content database 140 being populated with all of the game assets.
  • the developer clients 112 tags each asset as it is imported with platform-based metadata. For example, each asset is tagged with a platform type (e.g.. tablet, smartphone, HD tablet, PC, console) for which the asset is intended.
  • platform type e.g. tablet, smartphone, HD tablet, PC, console
  • each asset may be tagged to indicate which other assets for different platforms it relates to.
  • the master cloud services server 130 converts 204 the assets to a generic format.
  • the assets are converted from a format native to an original digital content creation tool (DCC) to a custom format used in the collaborative game development system.
  • DCC digital content creation tool
  • the master cloud services server 130 modifies 206 the assets (if needed) based on a plurality of different platform profiles to meet developer-specified performance and payload requirements specific to each platform. This generates a plurality of parallel data sets, each corresponding to a different platform for publishing. In this step, to prepare assets for a particular platform, assets are first selected that are already tagged for that particular platform. The assets may then be further modified if needed to meet platform profile requirements specified by the developer as specified in developer-specified platform- specific rules.
  • a platform profile for a particular platform may include a developer-specified requirement that enforces a maximum texture size of 256x256 for any assets deployed for that platform for performance considerations. All assets processed by the platform profile are checked for this requirement and assets that do not meet the requirement are reduced in size. For example, a texture asset that is originally 1024x1024 in size is reduced in to 256x256 In one embodiment, an entry indicating the failure is written to a log.
  • an error may be logged and the developer notified to fix the asset to conform to the requirement.
  • a platform profile for a particular platform may include a developer-specified requirement that enforces that character polygon mesh models only have 1000 triangles for performance considerations. All assets processed by this project profile are checked for this requirement, and assets that do not meet that requirement are logged as errors and processing stops. The asset is then repaired and reintroduced by the developer before processing continues. For example, if a character polygon mesh model asset is introduced that that is 25,000 triangles in size, an error is logged and processing does not continue until the asset is recreated to and meets the requirement.
  • as script can be converted between formats (e.g., between GLES2 and GLES3 formats) to generate code specific to platform-compatible code specified by the developer in the platform profiles.
  • Each version of the data for each platform is also modified 208 according to immutable platform-specific requirements specified in a platform profile.
  • the assets are modified to ensure that the assets meet immutable requirements of a particular platform based on the immutable platform- specific rules.
  • the immutable platform-specific rules specify that for Android devices that will render with OpenGLES version 2.0 require that in order to use alpha while rendering, the color and alpha textures must be separate assets. All texture assets are checked for this requirement, and assets that do not meet the requirement are logged. A developer may then recreate the asset in order to ensure that it achieves this requirement. For example, if a color texture asset is introduced that contains an alpha channel, the server 130 applies an Android platform profile to detect that the alpha channel is present within the color texture and there is no corresponding separate alpha texture. The asset entry is rejected. An error entry is made into the log and processing does not continue until the developer recreates the asset.
  • an Apple IOS platform profile specifies that textures be square in dimension such that height and width are equal. All texture assets are checked for this requirement, and assets that do not meet the requirement are logged. A developer may recreate the assets to achieve this requirement before processing continues. For example, if a texture asset is introduced that has dimensions of 1024 x 350, the server applies the Apple IOS device profile to detect that the texture is not square. The asset entry is rejected. An error entry is made into the log and processing does not continue until the asset is recreated to meet the requirement.
  • a platform profile for a particular platform may specify a maximum texture size of 128x128. An asset that is 1024x1024 in size is reduced in this step to 128x128.
  • code can be converted between formats (e.g., between GLES2 and GLES3 formats) to generate code specific to platform-compatible code specified in the platform profiles.
  • Runtime versions of the game are then generated 210 for each platform. This creates separate optimized runtime packages for different platforms such as, console, tablet, phone, PC, etc. based on tagged assets and device profiles.
  • This process of FIG. 2 beneficially alleviates much of the duplicated effort in deploying the same game to many different devices/platforms.
  • robust device profiles allow developers to continually test their project on multiple platforms during development, allowing early testing avoiding incompatibilities or other problems at the time of compile.
  • the collaborative game development system 100 supports efficient computer processor (CPU) utilization across multiple CPU cores with functionally asynchronous rendering.
  • CPU computer processor
  • the processing of assets described in FIG. 2 above is time consuming across multiple platforms and distributing this processing across available CPU cores may reduce the time to process by a factor ten or more, thus speeding up development.
  • Multi-stage data parallelism extends the idea of data parallel execution to add in additional controls for order of execution. This is achieved through staging the order of execution. Any job in a given stage of execution can occur in random order. However everything in stage N is guaranteed to complete before stage N + 1 begins executing, allowing efficient CPU utilization with minimal resource contention. Additionally, the system 100 queues up an additional frame of information (R + 1) while the previous frame of simulation is rendering further leveraging the CPU and decoupling execution dependencies.
  • R + 1 additional frame of information
  • the collaborative game development system 100 enables multiple threading by layering a control system into a simple low level linear task model which issues larger groupings of tasks.
  • the low level linear task model also provides for the fencing which can make sure all prior tasks have completed prior to moving on to further tasks.
  • a first instruction issues 'n' divided by the number of works to each thread in the system.
  • the second instruction waits for all threads to complete working before moving on.
  • Additional distribution types can be implemented as instructions to the control flow such as lazy hierarchical task issuance for things such as hierarchical culling, specified thread counts can be used in some tasks which only distribute n-ways and many further extensions become possible.
  • the core of controlling thread synchronization and task distribution allows this greater flexibility and much higher performing solution than existing systems.
  • collaborative game development system 100 also allows developers to push asset updates without having to re-submit the core game and allows for automatic tracking and "hot swapping" of all assets. Every asset may be automatically tagged and stored in an authoring database.
  • the runtime executable may draw content from a local database 114 which receives updates from the master content database 130 and can therefore push unique content to different users (enabling multi-variant A/B testing) and updates to existing content; e.g. scripting fixes, asset swapping, etc.
  • the present system allows multiple users to be editing the same scene without conflicts by connecting to the master database 130 which holds granular detail of assets.
  • the system 100 optimizes storage and network bandwidth by de-duplicating persistent data. Due to integrated version control, once data is saved to the database, it preferably persists forever. Fields within documents that are bulk data can have a bulk data handle associated with them. That bulk data handle may be a unique identifier that can allow lookup of the bulk data within a repository or cache. The client 112 may not try to fetch the bulk data for a given handle; in that case, the file contents are not transmitted over the network nor stored on the client 112, and no resources are wasted.
  • the client 112 can request that bulk data field from the server; the server will then transmit a stored MD5 signature and pre-compressed copy of that data to the client 112, at which point the client 112 can store that data into its cache with the corresponding bulk data handle. The client 112 can then look up the compressed bulk data in its cache and decompress it to get the original field contents.
  • the client 112 may treat its bulk data collection as a cache and evict data that has not been retrieved in a specified time period in order to minimize local storage requirements. For any bulk data desired to send from the client to the server, the client 112 may calculate the MD5 cryptographic signature of the data. The client 112 can then inspect its local cache of bulk data for the MD5 and see if it might have the data present. Because cryptographic signatures cannot be guaranteed to not collide, the new data is compared to the preexisting data. If the signature matched and the data compared equally, instead of transmitting the data to the server 130, the client 112 can just send the handle associated with that bulk data.
  • the client 1 12 compresses the data and send both the MD5 signature and the compressed field contents to the server 130.
  • the server 130 may then see if it has that data in its repository in the same fashion as the client 1 12 used for looking up that data in the cache; however, the server 130 may be able to compare the compressed data instead of uncompressed for efficiency if the compression algorithm used is deterministic and the same compression parameters are used. If matching data was not found, the server 130 may create a new entry for the bulk data, store the compressed data and signature to be associated with the handle, and return that handle to the client 1 12; otherwise the server 130 returns the preexisting matching bulk data handle.
  • the client 1 12 When the client 1 12 receives the bulk data handle, whether new or preexisting, it may store the associated MD5 and compressed data with the bulk data handle into its cache. Specifically, the MD5 signature calculation and data compression may occur only on the client 1 12 to minimize load on the server 130, as well as to guarantee the data was correctly transmitted over the network.
  • the system 100 facilitates this form of data de-duplication by making sure that data is written out in a consistent and well-ordered manner such that multiple attempts to save the same data generate bitwise-identical output. For instance, if the data represented vertex positions, the data may be sorted based on x,y,z positions so that repeated exports of the same mesh positional data will match the first export and repeatedly collapse to a single bulk data object. When applied across an entire mesh, this approach facilities maximum data sharing between revisions of a mesh when only portions of it change.
  • FIG.3 illustrates an example embodiment of a developer configurable N- dimension data gathering and editing system.
  • the system includes an example attribute table 302, a master service database 304, a data input/output (I/O or IO) translation adapter 306 and one or more data input/output (I/O or IO) sources 308.
  • the attribute table 302 is stored within the master service database 304.
  • the attribute table 302 is accessible by the example data IO sources 308 through the data IO translation adapter 306.
  • the master services database 304 is similar to the master content database 140 described with FIG. 1.
  • the attribute table 302 comprises a user configurable view of many attributes about an asset. These attributes are gathered from N number of discrete sources collected from example data IO sources 308. In this example system configuration, the example attribute table 302 corresponds to an example view that a designer may see when reviewing or editing the attributes of an asset. Examples of assets within the attribute table 302 includes individual character types by row and columns that represent the type of data for the characters such as World X Loc, World Y Loc, etc.
  • the master service database 304 where the attribute table 302 is stored, also stores other discrete sources of data, for example, project scene graphs and animations definitions. Edits and changes to data in the attribute table 302 are stored with revisions information in the master service database 304. This allows viewing of changes over time and reversion as necessary. It should be noted that the master service database presents a unified view into the graphs, tables and defines that allow the designer to work more efficiently. As these graphs, tables and defines are updated or extended by other sources, the designer maintains access.
  • the data translation adapter 306 is configured to interface between the attribute table 302 and the example data IO sources 308.
  • the data translation adapter 306 understands how to read and write data to the discrete forms of table data.
  • Orc2 corresponds to a character and has data parameters associated with it as shown by the cells in the row associated with Orc2.
  • the asset data for Orc2 may come one or more of the example data sources 308.
  • the Orc2 character starts, in this example, a scene graph representation is stored in the main project scene graph database.
  • the project scene graph database utilizes animation data from a separate table that the designers have setup in a spreadsheet CSV file and an animation control define table from yet another spreadsheet that is updated regularly based on play testing of the game. It is noted that the tables/files are local to a machine of the designer or accessed in a cloud storage, e.g., via a uniform resource locator (URL).
  • URL uniform resource locator
  • this data is generated by third party tools or real world dynamic data sources. This could be data that is generated daily via telemetry or user play patterns for example. This system allows us to abstract the original source of data.
  • a system is configured to edit a plurality of attributes for an asset.
  • the system receives a plurality of asset data corresponding to an assert from a plurality of data input/output (10) sources.
  • the asset may correspond to a character, e.g., Orc2, and the asset data may correspond to characteristics of that asset.
  • At least two received asset data correspond to the asset have different data formats.
  • the received asset data from the different data formats is translated into a universal data format.
  • the system enters the translated asset data into a table.
  • the table is structured so each row corresponds with descriptions of the asset and each column corresponds with a particular characteristic of the asset in the row.
  • the system provides for receiving edits to the translated data in the table to create edited asset data.
  • the system stores changes to the edited asset data into a database, which may be a part of the storage described below.
  • the edited data may be of use with respect to the IO source from which the data was received. Accordingly, the system is configured to re -translate the edited asset data back to a format corresponding to an IO source of the plurality of IO sources of the translated data. The system transmits (or writes) the re-translated edited asset data to the IO source of the translated data. Hence, the edited data is available for later use in generating a computer designed character.
  • the disclosed embodiment beneficially imports data assets corresponding to characteristics of a computer generated character from a plurality of disparate IO sources, allows revisions and edits to those characteristics and, where updated, push back (e.g., transmit/write back) those changes to the specific IO source databases from where the characteristics came.
  • the disclosed configurations push back any changed data that was inputted back to the source from where the data was input.
  • a developer of gaming technology can manipulate characteristics data from multiple sources and then push back any changes to those manipulated characteristics back to the source so that it can be later retrieved and used in other contexts.
  • a characteristic is applied in a different way for a character and that characteristic is modified, by writing it back out to the source, that new characteristic is available for use in later contexts when it is retrieved back in.
  • FIG. 4 is a block diagram illustrating components of an example machine (e.g., a computer) able to read instructions from a non-transitory machine-readable storage medium and execute them in a processor (or controller).
  • the depicted machine or variations thereof may be used as the developer client 112, the master cloud services server 130, or other computing devices described herein.
  • FIG. 4 shows a diagrammatic representation of an example machine (e.g., a computer) able to read instructions from a non-transitory machine-readable storage medium and execute them in a processor (or controller).
  • the depicted machine or variations thereof may be used as the developer client 112, the master cloud services server 130, or other computing devices described herein.
  • FIG. 4 shows a diagrammatic
  • a machine in the example form of a computer system 400 within which instructions 424 (e.g., software) for causing the machine to perform any one or more of the methodologies discussed herein may be executed.
  • the machine operates as a standalone device or may be connected (e.g., networked) to other machines.
  • the machine may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.
  • the machine may be a server computer, a client computer, a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular telephone, a smartphone, a web appliance, a network router, switch or bridge, or any machine capable of executing instructions 424 (sequential or otherwise) that specify actions to be taken by that machine.
  • PC personal computer
  • PDA personal digital assistant
  • STB set-top box
  • a cellular telephone a smartphone
  • smartphone a web appliance
  • network router switch or bridge
  • any machine capable of executing instructions 424 (sequential or otherwise) that specify actions to be taken by that machine.
  • machine shall also be taken to include any collection of machines that individually or jointly execute instructions 424 to perform any one or more of the methodologies discussed herein.
  • the example computer system 400 includes a processor 402 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), one or more application specific integrated circuits (ASICs), one or more radio-frequency integrated circuits (RFICs), or any combination of these), a main memory 404, and a static memory 406, which are configured to communicate with each other via a bus 408.
  • the computer system 400 may further include graphics display unit 410 (e.g., a plasma display panel (PDP), a liquid crystal display (LCD), a projector, or a cathode ray tube (CRT)).
  • graphics display unit 410 e.g., a plasma display panel (PDP), a liquid crystal display (LCD), a projector, or a cathode ray tube (CRT)
  • the computer system 400 may also include alphanumeric input device 412 (e.g., a keyboard), a cursor control device 414 (e.g., a mouse, a trackball, a joystick, a motion sensor, or other pointing instrument), a storage unit 416, a signal generation device 418 (e.g., a speaker), and a network interface device 420, which also are configured to communicate via the bus 408.
  • alphanumeric input device 412 e.g., a keyboard
  • a cursor control device 414 e.g., a mouse, a trackball, a joystick, a motion sensor, or other pointing instrument
  • storage unit 416 e.g., a disk drive, or other pointing instrument
  • signal generation device 418 e.g., a speaker
  • network interface device 420 which also are configured to communicate via the bus 408.
  • the storage unit 416 includes a machine-readable medium 422 on which is stored instructions 424 (e.g., software) embodying any one or more of the methodologies or functions described herein.
  • the instructions 424 (e.g., software) may also reside, completely or at least partially, within the main memory 404 or within the processor 402 (e.g., within a processor's cache memory) during execution thereof by the computer system 400, the main memory 404 and the processor 302 also constituting machine-readable media.
  • the instructions 424 (e.g., software) may be transmitted or received over a network 426 via the network interface device 420.
  • machine-readable medium 422 is shown in an example embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) able to store instructions (e.g., instructions 424).
  • the term “machine-readable medium” shall also be taken to include any medium that is capable of storing instructions (e.g., instructions 424) for execution by the machine and that cause the machine to perform any one or more of the methodologies disclosed herein.
  • the term “machine-readable medium” includes, but not be limited to, data repositories in the form of solid-state memories, optical media, and magnetic media.
  • Modules may constitute either software modules (e.g., code embodied on a machine-readable medium or in a transmission signal) or hardware modules.
  • a hardware module is tangible unit capable of performing certain operations and may be configured or arranged in a certain manner.
  • one or more computer systems e.g., a standalone, client or server computer system
  • one or more hardware modules of a computer system e.g., a processor or a group of processors
  • software e.g., an application or application portion
  • a hardware module may be implemented mechanically or electronically.
  • a hardware module may comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations.
  • a hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.
  • processors e.g., processor 302
  • processors may be temporarily configured (e.g., by software) or permanently configured to perform the relevant operations.
  • processors may constitute processor- implemented modules that operate to perform one or more operations or functions.
  • the modules referred to herein may, in some example embodiments, comprise processor- implemented modules.
  • the one or more processors may also operate to support performance of the relevant operations in a "cloud computing" environment or as a “software as a service” (SaaS). For example, at least some of the operations may be performed by a group of computers (as examples of machines including processors), these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., application program interfaces (APIs).)
  • SaaS software as a service
  • the performance of certain of the operations may be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines.
  • the one or more processors or processor- implemented modules may be located in a single geographic location (e.g., within a home environment, an office environment, or a server farm). In other example embodiments, the one or more processors or processor-implemented modules may be distributed across a number of geographic locations.
  • any reference to "one embodiment” or “an embodiment” means that a particular element, feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment.
  • the appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment.
  • Coupled and “connected” along with their derivatives.
  • some embodiments may be described using the term “coupled” to indicate that two or more elements are in direct physical or electrical contact.
  • the term “coupled,” however, may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other.
  • the embodiments are not limited in this context.
  • the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having” or any other variation thereof, are intended to cover a non-exclusive inclusion.
  • a process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus.
  • "or” refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un environnement de développement de jeu collaboratif axé sur des bases de données et un système qui génère automatiquement des versions d'exécution d'un jeu à déployer sur une pluralité de plates-formes différentes, sur la base de profils de dispositifs prédéfinis.
PCT/US2015/028659 2014-05-01 2015-04-30 Déploiement d'un jeu électronique sur la base de profils de dispositifs WO2015168479A1 (fr)

Applications Claiming Priority (18)

Application Number Priority Date Filing Date Title
US201461987284P 2014-05-01 2014-05-01
US201461987282P 2014-05-01 2014-05-01
US201461987262P 2014-05-01 2014-05-01
US201461987237P 2014-05-01 2014-05-01
US201461987233P 2014-05-01 2014-05-01
US201461987230P 2014-05-01 2014-05-01
US201461987243P 2014-05-01 2014-05-01
US201461987273P 2014-05-01 2014-05-01
US201461987240P 2014-05-01 2014-05-01
US61/987,284 2014-05-01
US61/987,282 2014-05-01
US61/987,243 2014-05-01
US61/987,237 2014-05-01
US61/987,262 2014-05-01
US61/987,230 2014-05-01
US61/987,273 2014-05-01
US61/987,240 2014-05-01
US61/987,233 2014-05-01

Publications (1)

Publication Number Publication Date
WO2015168479A1 true WO2015168479A1 (fr) 2015-11-05

Family

ID=54359352

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2015/028659 WO2015168479A1 (fr) 2014-05-01 2015-04-30 Déploiement d'un jeu électronique sur la base de profils de dispositifs

Country Status (1)

Country Link
WO (1) WO2015168479A1 (fr)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080301231A1 (en) * 2001-11-28 2008-12-04 Samir Narendra Mehta Method and System for Maintaining and Distributing Wireless Applications
US20100077386A1 (en) * 2008-09-22 2010-03-25 International Business Machines Corporation System and a method for cross-platform porting of business applications and making them contexually-aware on target platforms
US20110143741A1 (en) * 2005-07-19 2011-06-16 AOL Inc., System and method for cross-platform applications on a wireless phone
US20120089668A1 (en) * 2010-10-08 2012-04-12 Lumi Mobile Multi-phased and partitioned content preparation and delivery
US20130219429A1 (en) * 2011-04-06 2013-08-22 Media Direct, Inc. Systems and methods for a television and set-top box application development and deployment platform
US20140047413A1 (en) * 2012-08-09 2014-02-13 Modit, Inc. Developing, Modifying, and Using Applications

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080301231A1 (en) * 2001-11-28 2008-12-04 Samir Narendra Mehta Method and System for Maintaining and Distributing Wireless Applications
US20110143741A1 (en) * 2005-07-19 2011-06-16 AOL Inc., System and method for cross-platform applications on a wireless phone
US20100077386A1 (en) * 2008-09-22 2010-03-25 International Business Machines Corporation System and a method for cross-platform porting of business applications and making them contexually-aware on target platforms
US20120089668A1 (en) * 2010-10-08 2012-04-12 Lumi Mobile Multi-phased and partitioned content preparation and delivery
US20130219429A1 (en) * 2011-04-06 2013-08-22 Media Direct, Inc. Systems and methods for a television and set-top box application development and deployment platform
US20140047413A1 (en) * 2012-08-09 2014-02-13 Modit, Inc. Developing, Modifying, and Using Applications

Similar Documents

Publication Publication Date Title
US11003422B2 (en) Methods and systems for visual programming using polymorphic, dynamic multi-dimensional structures
Taivalsaari et al. The death of binary software: End user software moves to the web
US10013157B2 (en) Composing web-based interactive 3D scenes using high order visual editor commands
Parisi Programming 3D Applications with HTML5 and WebGL: 3D Animation and Visualization for Web Pages
CN107393013B (zh) 虚拟漫游文件生成、显示方法、装置、介质、设备和系统
US10331423B1 (en) Utilizing cross platform streamable user interfaces to reduce software deployment frequency caused by user interface improvements
CN103885788A (zh) 一种基于模型组件化动态web 3d虚拟现实场景的搭建方法及系统
Ren et al. Stardust: Accessible and transparent gpu support for information visualization rendering
US20060259386A1 (en) Building digital assets for use with software applications
Santos et al. CultLab3D: On the verge of 3D mass digitization
US20150314199A1 (en) Analytics Enabled By A Database-Driven Game Development System
CN102567172A (zh) 用于应用性能测试的并行工作负荷仿真方法和系统
US20150314196A1 (en) Deployment of an electronic game using device profiles
Topcu et al. Analysis and evaluation of the riak cluster environment in distributed databases
Chen et al. A cross-platform metaverse data management system
US20150317155A1 (en) Editing Multiple Attributes of Multiple Assets in an Editor
Moloo et al. A 3D virtual tour of the university of mauritius using WebGL
EP2779112B1 (fr) Noeud dans l'établissement de rendu graphique
US20150269781A1 (en) Rapid Virtual Reality Enablement of Structured Data Assets
Kim et al. 3D CAD model visualization on a website using the X3D standard
WO2015168479A1 (fr) Déploiement d'un jeu électronique sur la base de profils de dispositifs
US20220405108A1 (en) System and Method for GUI Development and Deployment in a Real Time System
Cannon et al. How can NX Advanced Simulation Support Multi-user design
US8253753B1 (en) Dual-type component connections
Chen et al. Cloud computing platform for an online model library system

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15785874

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 29/03/2017)

122 Ep: pct application non-entry in european phase

Ref document number: 15785874

Country of ref document: EP

Kind code of ref document: A1