WO2022178072A1 - Procédé et système de développement d'applications par l'intermédiaire d'une interface utilisateur graphique utilisant une architecture de système à composants entités - Google Patents

Procédé et système de développement d'applications par l'intermédiaire d'une interface utilisateur graphique utilisant une architecture de système à composants entités Download PDF

Info

Publication number
WO2022178072A1
WO2022178072A1 PCT/US2022/016712 US2022016712W WO2022178072A1 WO 2022178072 A1 WO2022178072 A1 WO 2022178072A1 US 2022016712 W US2022016712 W US 2022016712W WO 2022178072 A1 WO2022178072 A1 WO 2022178072A1
Authority
WO
WIPO (PCT)
Prior art keywords
scene
actor
actors
behaviors
gui
Prior art date
Application number
PCT/US2022/016712
Other languages
English (en)
Inventor
Benjamin Carroll Alcala ROTH
Jesse Kicho RUDER
Nikhilesh SIGATAPU
David Anthony COLE
Charles Duplain Cheever
Original Assignee
Monterey's Coast, 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
Priority claimed from US17/673,284 external-priority patent/US20220269489A1/en
Application filed by Monterey's Coast, Inc. filed Critical Monterey's Coast, Inc.
Priority to EP22708660.0A priority Critical patent/EP4295226A1/fr
Publication of WO2022178072A1 publication Critical patent/WO2022178072A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/34—Graphical or visual programming

Definitions

  • Embodiments of the present invention generally relate to application development and more specifically, to a method and system for video game development via a graphical user interface using an Entity-Component-System (ECS) architecture.
  • ECS Entity-Component-System
  • a common architecture that is used for the development of video games is an entity-component-system architecture.
  • Each entity, component, and system has a distinct role.
  • One system performs actions on entities possessing a component of that particular system.
  • An entity-component-system architecture may be advantageous because it provides an efficient and intuitive model for defining and organizing video game objects.
  • some game development tools use object-oriented architectures, which include class inheritance.
  • class inheritance is ill-suited to describe video game environments because the inheritance tree becomes too complex. In these circumstances, where objects may mix and match a wide variety of different traits, an entity-component-system architecture is advantageous.
  • a method for application development via a GUI using an ECS architecture may include receiving, via a GUI, a selection of at least one actor to be part of a game scene; displaying a representation of the at least one actor in the game scene; receiving, via the GUI, a selection of one or more behaviors to associate with each of the at least one actors in the game scene; storing the selected one or more behaviors as associations with each of the at least one actors, wherein the associations are stored in a hash table; updating, via one or more handlers, each of that at least one actors and their associated behaviors; and automatically creating an executable video game based on the at least one actor and associated behaviors in an ECS architecture without the need for user written software code.
  • Figure 1 depicts a block diagram of a video game development system using an Entity-Component-System (ECS) architecture, according to one or more embodiments of the invention
  • Figure 3 depicts a flow diagram of a method for video game development via a graphical user interface using an Entity-Component-System (ECS) architecture, according to one or more embodiments of the invention.
  • ECS Entity-Component-System
  • Figure 4 depicts an exemplary system that may be used for video game development via a graphical user interface using an Entity-Component-System (ECS) architecture, according to one or more embodiments of the invention.
  • ECS Entity-Component-System
  • the word “may” is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must).
  • the words “include”, “including”, and “includes” mean including, but not limited to. DETAILED DESCRIPTION OF EMBODIMENTS
  • Embodiments of the invention provide a system and method for video game development via a graphical user interface (GUI) using an Entity-Component-System (ECS) architecture, according to one or more embodiments.
  • ECS architectures are different than Object Oriented Programming (OOP) architectures. Where OOP has Classes and Objects and complex inheritance structures, an ECS architecture has Entities, Components and Systems that don’t use such complex inheritance structures.
  • Entities are the fundamental conceptual building block of the system, with each entity representing a different concrete in-game object. For every discernible “thing” in your game-world, you have one Entity. Entities have no data and no methods. In high level terms, Components label the Entity as possessing a particular aspect or characteristic. Meanwhile, each System runs continuously (as though each System had its own private thread/handler) and performs global actions on every Entity that possesses a Component of the same aspect as that System.
  • Components are simple data buckets, they have no dependencies. Each system will typically register the Components an Entity must have for the System to operate on it. For example, a render system might register the model, transform, and drawable components. It will then check each entity for those components, and if the Entity has them all the System will perform its logic on that entity. If not, the Entity is simply skipped, with no need for complex dependency trees.
  • the Objects in OOP applications tend to be connected by many indirect references, specifically references between objects themselves, and also all of the virtual table lookups incurred when methods are called on objects. 00 objects are also allocated as necessary and spread all over the memory space. This random distribution of necessary data across memory causes the CPU to behave inefficiently as it constantly waits for memory accesses.
  • an interactive game experience in an ECS architecture environment takes place in what is referred to as a scene.
  • One or more scenes describe a world in which the interactive experience takes place.
  • the scenes may be played or edited.
  • the user experiences the interactive world as it was designed by the creator.
  • a scene is edited, the creator interacts with a GUI to edit the contents of the scene.
  • Each piece of content in a scene is referred to as an actor.
  • an actor is an Entity in the ECS architecture described above.
  • an actor is selected by the creator via the GUI, it is placed in the scene.
  • an association between the scene and the actor is created.
  • behaviors are systems and the associations between the actor and the behaviors are referred to as Components in the ECS architecture described above.
  • Behaviors may include physical traits (e.g., possessing a body with position, rotation, width and height); interactive controls (e.g., following the user's touch on their mobile device screen when dragged); physics-based behaviors (e.g., responding to the force of gravity); association of metadata (e.g., containing identifying tags); and the like.
  • behaviors are selected for an actor, an association is stored between the actor and the behavior, said association stored as a component.
  • Pre-built code is used by the game engine, such that when the creator plays the scene, the game engine interprets the association tables of that scene, making all of the actors selected for the scene perform based on the associated behaviors, thereby creating a video game in an ECS architecture without the need to write software code or use complex inheritance structures.
  • scenes are comprised purely of data.
  • the game engine includes pre-built code, such that when game creators provide the data of the scenes in the form of association tables, the pre-built code that is part of the existing game engine interprets the data to render a scene.
  • such quantities may take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared or otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to such signals as bits, data, values, elements, symbols, characters, terms, numbers, numerals or the like. It should be understood, however, that all of these or similar terms are to be associated with appropriate physical quantities and are merely convenient labels. Unless specifically stated otherwise, as apparent from the following discussion, it is appreciated that throughout this specification discussions utilizing terms such as “processing,” “computing,” “calculating,” “determining” or the like refer to actions or processes of a specific apparatus, such as a special purpose computer or a similar special purpose electronic computing device.
  • a special purpose computer or a similar special purpose electronic computing device can manipulate or transforming signals, typically represented as physical electronic or magnetic quantities within memories, registers, or other information storage devices, transmission devices, or display devices of the special purpose computer or similar special purpose electronic computing device.
  • FIG. 1 is block diagram of a system 100 for a for video game development via a graphical user interface (GUI) using an Entity-Component-System (ECS) architecture, according to one or more embodiments of the invention.
  • the system 100 includes a mobile device 102 and a game creation server 104, communicatively connected via network 106.
  • the mobile device 102 may comprise a Central Processing Unit (CPU) 110, support circuits 112, a GUI 114, and a memory 116.
  • the CPU 110 may comprise one or more commercially available microprocessors or microcontrollers that facilitate data processing and storage.
  • the various support circuits 112 facilitate the operation of the CPU 110 and include one or more clock circuits, power supplies, cache, input/output device and circuits, and the like.
  • the memory 116 comprises at least one of Read Only Memory (ROM), Random Access Memory (RAM), disk drive storage, optical storage, removable storage and/or the like.
  • the memory 116 comprises an operating system 118 and a game creation application 120.
  • the game creation application 120 may be downloaded from an e-commerce mobile application store (not shown), for example, the APPLE ® App Store or the GOOGLE ® Play Store.
  • the game creation application 120 includes an association table generator 122 for storing associations selected by a creator via the GUI 114 during game creation.
  • the game creation application 120 also includes a plurality of association tables 124 for holding the associations between actors and behaviors, lastly includes an interpreter 126 for interpreting said association tables 124 during game play.
  • the operating system (OS) 118 generally manages various computer resources (e.g., network resources, file processors, and/or the like).
  • the operating system 118 is configured to execute operations on one or more hardware and/or software modules, such as Network Interface Cards (NICs), hard disks, virtualization layers, firewalls and/or the like.
  • NICs Network Interface Cards
  • Examples of the operating system 118 may include, but are not limited to, various versions of IOS, ANDROID, and the like.
  • the game creation server 104 is a computing device, for example, a desktop computer, laptop, tablet computer, and the like, or it may be a cloud based server (e.g., a blade server, virtual machine, and the like).
  • a suitable computer is shown in Figure 4, which will be described in detail below.
  • the game creation server 104 includes a Central Processing Unit (CPU) 130, support circuits 132, and a memory 134.
  • the CPU 130 may include one or more commercially available microprocessors or microcontrollers that facilitate data processing and storage.
  • the various support circuits 132 facilitate the operation of the CPU 130 and include one or more clock circuits, power supplies, cache, input/output circuits, and the like.
  • the memory 134 includes at least one of Read Only Memory (ROM), Random Access Memory (RAM), disk drive storage, optical storage, removable storage and/or the like.
  • the memory 134 includes an operating system 136, a database of compiled code 138, and blueprints 140.
  • Blueprints 140 include one or more actors 142 for the game creator to select from.
  • Each of the one or more actors 142 may be associated with one or more behavior components 144.
  • Each of the one or more behavior components 144 may be associated with one or more rules 146, while each of the one or more rules 146 may contain one or more triggers 148 and responses 149.
  • a plurality of handlers 150 are implemented for the one or more behavior components 144. Created games are stored as saved games 152.
  • An object in the scene is referred to as an actor 142.
  • the creator adds actors 142 to the scene from their mobile device 102 by revealing a menu in the GUI 114.
  • the association table generator 122 stores the association between the scene and the actor 142 in one or more association tables 124.
  • the Lua scripting language is utilized and the association tables 124 are of a Lua data type: table.
  • the association tables 124 or other data structure holds the associations that will be interpreted by the game engine to render the scene.
  • the association tables 124 allow for common behaviors among actors without using inheritance.
  • the GUI 114 displays a representation of the actor 142 that has been added to the scene.
  • the creator may select one or more actors 142 in the scene by tapping the representation of the actor 142 in the scene's GUI 114.
  • Actors 142 are composed of one or more behavior components 144. When an actor 142 contains a behavior 144, the effects of that behavior are applied to that specific actor 142. Actors 142 may contain behavior components 144 at the initial moment the creator adds them to the scene. For example, an actor 142, upon creation may contain a behavior 144 for “Body”, and have a default position in the physical space of the scene.
  • the behavior 144 is stored as an association with the actor 142.
  • Different behavior components 144 contain actor-specific data about how the actors 142 should behave.
  • two different actors 142 may each contain a component for the Body and therefore each have a position in the scene space, but the two actors 142 may have different positions from one another.
  • Two actors 142 may each contain a behavior 144 for the Gravity behavior and therefore both respond to the force of gravity, but the force of gravity on each respective actor 142 may be of a different magnitude.
  • the actor-specific data fields for a particular behavior 144 are referred to as its properties, and the values of these properties are referred to as property values.
  • Behavior components 144 may be enabled or disabled.
  • a disabled behavior 144 remains part of the actor 142 (i.e. , remains associated with the actor 142 in the association table 124, and retains its property values, but the effects of that behavior 144 are not applied by the behavior until the behavior 144 is enabled.
  • Behavior components 144 are enabled by default.
  • the creator Upon selecting one or more actors 142 in the scene GUI 114, the creator is presented with a summary of all the behavior components 144 contained by the selected actor(s) 142, including the specific properties and property values of each behavior 144, and whether each behavior 144 is enabled.
  • the GUI 114 consists of a drawer element that contains a scrollable list of behavior components 144.
  • the creator may modify the behavior components 144 for a selected actor(s) 142 in the GUI 114. For example, the creator may add or remove behavior components 144 to the selected actor(s) 142 using a menu which lists all available behaviors components 144. The creator may then configure behavior components 144 contained by the selected actor(s) 142; e.g., they could change property values, such as a gravity constant of the Gravity behavior, or a position of the Body behavior. The creator may also enable or disable the behavior 144. In some embodiment, the creator may modify each property value with a number input or a text input GUI element, and the user may enable or disable the behavior 144 with a switch GUI element.
  • Behavior components 144 may be modified in response to events while the scene is played.
  • the system that defines how behavior components 144 change at play time is a particular behavior referred to as a Rules behavior 146.
  • a Rules behavior 146 may consist of zero or more Rules. If a currently selected actor 142 contains the Rules behavior 146, a list of Rules for that actor 142 is shown in the GUI 114. The creator may activate a GUI 114 control to add new Rule to an actor 142 or remove existing Rules from an actor 142.
  • Triggers 148 may consist of a variety of events, including input events (e.g., the user taps on this actor 142); physical events (the actor's Body collided with another actor's Body); state events (the scene started to play, or a behavior property changed its value); and the like.
  • Responses 149 modify the contents of the scene, including the property values of a behavior 144 of an actor 142 and whether the behavior 144 is enabled. For example, the creator may change the gravitational constant of an actor's Gravity behavior 144. Responses 149 may also add or remove one or more actors 142 from the scene, or change the scene state (for example by restarting the scene, navigating to a different scene), and the like. Responses 149 may also indirectly cause further triggers 148 to fire. For example, a response 149 may move an actor 142 into another actor 142 in the physical scene space, and either actor 142 may further contain a trigger 148 that fires when the two actors 142 collide.
  • a response 149 may optionally depend on the prior state of the scene; for example, a response 149 may modify a behavior property by a value of 1 , relative to its previous value. Therefore, the exact outcome of the given response depends on the prior value of that behavior property.
  • Triggers 148 and responses 149 may each contain parameters.
  • the trigger 148 "When this actor collides with another actor” contains a parameter to specify which subset of other actors 142 should qualify for this trigger when collided.
  • the response 149 "Create an actor” contains a parameter specifying what kind of actor to create. The creator may access a GUI 114 input to modify the value of each Rule parameter.
  • the list of possible triggers 148 and responses 149 for an actor 142 is derived from the behavior components 144 contained by that actor 142. For example, the trigger 148 "When this actor is dragged" is defined by the Drag behavior, and is only available to actors that contain a behavior 144 for the Drag behavior.
  • Each component behavior 144, trigger 148, and response 149 is different.
  • the Body behavior gives actors 142 a physical presence in scene space
  • the Movement behavior gives an actor 142 the ability to move in the scene space
  • the gravity behavior causes actors 142 to fall
  • the drawing behavior allows actors 142 to display unique artwork in the scene.
  • all behavior components 144 follow a common protocol to manage their respective components when the scene is played.
  • each behavior 144 associated with an actor 142 implements generic handlers 150 for different pre-defined moments in the scene.
  • handlers 150 include passing a frame of time, drawing to the screen of the device, enabling or disabling a specific component behavior 144, and the like.
  • handlers 150 Each time a handler 150 is run, the behavior has an opportunity to take action or perform a side-effect based on the entire set of that behavior's components present among all actors 142 in the scene. Therefore, a single behavior is able to continually manage all actors 142 that contain that behavior's components.
  • Behaviors also define all possible triggers 148 and responses 149 that could be applied to Rules for actors 142 that contain this behavior.
  • behaviors define handlers 150 that are executed by the Rules engine for a given response 149 and component when that Rule is triggered.
  • the Movement behavior may define a Rule response 149 "Move this Actor toward another actor” with a handler 150 that defines how to move the given actor 142 toward another actor 142.
  • Behaviors also define whether they depend on other behaviors. For example, an actor 142 cannot have a component for "Moving” without also having a component for "Body", because having a physical position in scene space (a Body) is a prerequisite to being able to change that position (Moving).
  • the GUI 114 for adding behaviors prevents the user from adding any behaviors to an actor 142 that lacks their prerequisite behaviors.
  • each property contains a property spec.
  • the property spec defines what type of value is expected (e.g., a number, a string, an enumeration), any constraints on that value (e.g., a maximum or a minimum value), and any other GUI-related metadata (e.g., a human-readable label or description of that property).
  • the Body behavior has a property called Density, which is used to calculate the mass of the Body when performing physics- related calculations in the scene.
  • the property spec for Density indicates that Density must be a number, and that it must be greater than or equal to 0.1.
  • Rule triggers 148 and responses 149 contain a parameter spec for each possible parameter.
  • Rule parameter specs follow the same base schema as behavior property specs.
  • the GUI 114 responds to the metadata contained in a particular property spec or parameter spec. For example, a property whose property spec specifies a number displays a GUI element consisting of a numeric input, whereas a property whose property spec specifies a string would show a GUI element consisting of a text input.
  • the spec's constraints are enforced in the GUI 114. For example, if the spec contains a maximum value, the creator is prevented from providing a larger value than the maximum in the GUI 114.
  • Rule responses 149 may directly or indirectly change the value of different behavior properties. When such a change occurs during play time, the property spec is reviewed to ensure that the constraints of the spec are respected.
  • a Rule response 149 causes a body Density of an actor 142 to drop from 1 to -1 , the body Density of the actor 142 is set to a value of 0.1 because the density property spec indicates a minimum value of 0.1.
  • behavior property specs indicate whether they are readable and writeable by Rules. For a Rule to change the value of a behavior property while the scene is played, the spec for that behavior property must indicate that the property may be written. For a Rule to read the value of a behavior property while the scene is played (e.g., to assign its value to a different property), the spec for that behavior property must indicate that the property can be read.
  • Figures 2A - 2F depict the graphical user interface 200 used for creating a video game using an Entity-Component-System (ECS) architecture.
  • Figure 2A depicts a new game screen 202. Any one of the actors 204 may be selected.
  • a selection of the ball places a solid circle on the game screen 202.
  • a selection of the wall places a solid rectangle on the game screen 202.
  • a selection of the text box places a block of text on the game screen.
  • the Figure 2B depicts the GUI for selecting general attributes for the ball, including a size with respect to width and height scale 208, a starting position 210 per x and y coordinate positions, and the like.
  • Play Once, and Loop are properties of the Drawing behaviors that may be used to animate an entity. Relative to camera identifies whether the actor lives in a camera-coordinated-space or a scene-coordinate space.
  • Tags are a behavior, typically used for referring to actors inside of Rules. For example, Move toward the actor with the tag “target”. The size and starting location are stored for the ball.
  • Figure 2C depicts the GUI the Movement screen for adding movement-related behaviors to the ball.
  • this screen shows a list of which movement-related behaviors the actors currently possesses.
  • a creator may select whether their ball remails still, moves at a constant rate, or moves dynamically (i.e. , is moved by other forces, such as bumping into other actors).
  • each behavior is selected, each is stored as an association between the ball and the behavior.
  • the creator may then select the “Add physics or controls” field 218.
  • Figure 2D depicts the design options available under the “Add physics or controls” menu.
  • the creator may select types of collisions 220 the ball experiences with other actors in the scene, behaviors associated with physics 222, and other controls 224, such as an analog stick, drag, or slingshot. As behaviors are selected, the may be stored as associations between the ball and the behavior, or additional menus are displayed via the GUI to refine the selected behavior.
  • Figure 2E depicts options available when the analog stick toggle switch 226 is selected. A user may further select a turn friction, axes affected, and a speed for the ball.
  • Figure 2F depicts the game screen 202 when a wall is selected to be placed on the game screen 202 with the ball.
  • the wall has two behaviors. With respect to motion, the option “none” 228 is selected and the toggle switch 230 is selected to make the wall solid. Associations between the wall and the motion and solid behaviors are stored.
  • the tables are stored as hash tables.
  • the associations are stored in a data file that represents the table of associations. This is a simple example; however, extremely elaborate games may be designed by simply selecting actors and behaviors via the GUI. Although an X depicts a simple behavior, each X had many different properties attached to it.
  • the association tables are ultimately interpreted by the game engine to render a scene.
  • FIG. 3 depicts a flow diagram of a method 300 for video game development via a graphical user interface (GUI) using an Entity-Component-System (ECS) architecture, according to one or more embodiments of the invention.
  • the method 300 starts at 302 and proceeds to 304.
  • GUI displayed space in which the actors will interact.
  • the user adds actors to the scene from their mobile device via a menu in the GUI.
  • the method 300 proceeds to 306.
  • a representation of the actor is added to the displayed scene.
  • the user may select the actor for the scene by tapping their representation in the scene’s GUI.
  • one or more behaviors is received.
  • an actor includes a behavior
  • the effects of that behavior are applied to the actor.
  • Actors may contain behaviors at the initial moment the user adds them to the scene.
  • an actor may include a component of Body and have a default position in the physical space of the scene.
  • Other behaviors may be added, such as responding to a force of gravity, or having a specific location as a starting position in the scene space.
  • the received behavior is stored as an association with the actor.
  • the method 312 proceeds to 304, where the method iterates until at 312 it is determined that the creator is done adding actors to the scene and the method 300 proceeds to 314.
  • a request is received to run the scene.
  • the creator may select a run button from the GUI.
  • the game engine interprets the association tables to render the scene.
  • the game experience is played based on the creator’s stored associations between actors and their behaviors.
  • the entire game creation and execution is performed completely through a GUI without the creator writing any code.
  • the method 300 ends at 318.
  • Figure 4 depicts a computer system 400 that can be utilized in various embodiments of the present invention to implement the computer and/or the display, according to one or more embodiments.
  • GUI graphical user interface
  • ECS Entity-Component-System
  • FIG 4 depicts a computer system 400 that can be utilized in various embodiments of the present invention to implement the computer and/or the display, according to one or more embodiments.
  • One such computer system is computer system 400 illustrated by Figure 4, which may in various embodiments implement any of the elements or functionality illustrated in Figures 1-3.
  • computer system 400 may be configured to implement methods described above.
  • the computer system 400 may be used to implement any other system, device, element, functionality or method of the above-described embodiments.
  • computer system 400 may be configured to implement the method 300 as processor
  • computer system 400 includes one or more processors 410a-410n coupled to a system memory 420 via an input/output (I/O) interface 430.
  • Computer system 400 further includes a network interface 440 coupled to I/O interface 430, and one or more input/output devices 450, such as cursor control device 460, keyboard 470, and display(s) 480.
  • any of the components may be utilized by the system to receive user input described above.
  • a user interface may be generated and displayed on display 480.
  • embodiments may be implemented using a single instance of computer system 400, while in other embodiments multiple such systems, or multiple nodes making up computer system 400, may be configured to host different portions or instances of various embodiments.
  • some elements may be implemented via one or more nodes of computer system 400 that are distinct from those nodes implementing other elements.
  • multiple nodes may implement computer system 400 in a distributed manner.
  • computer system 400 may be any of various types of devices, including, but not limited to, a personal computer system, desktop computer, laptop, notebook, or netbook computer, mainframe computer system, handheld computer, workstation, network computer, a camera, a set top box, a mobile device, a consumer device, video game console, handheld video game device, application server, storage device, a peripheral device such as a switch, modem, router, or in general any type of computing or electronic device.
  • computer system 400 may be a uniprocessor system including one processor 410, or a multiprocessor system including several processors 410 (e.g., two, four, eight, or another suitable number).
  • processors 410 may be any suitable processor capable of executing instructions.
  • processors 410 may be general-purpose or embedded processors implementing any of a variety of instruction set architectures (ISAs). In multiprocessor systems, each of processors 410 may commonly, but not necessarily, implement the same ISA.
  • ISAs instruction set architectures
  • System memory 420 may be configured to store program instructions 422 and/or data 432 accessible by processor 410.
  • system memory 420 may be implemented using any suitable memory technology, such as static random access memory (SRAM), synchronous dynamic RAM (SDRAM), nonvolatile/Flash-type memory, or any other type of memory.
  • SRAM static random access memory
  • SDRAM synchronous dynamic RAM
  • program instructions and data implementing any of the elements of the embodiments described above may be stored within system memory 420.
  • program instructions and/or data may be received, sent or stored upon different types of computer-accessible media or on similar media separate from system memory 420 or computer system 400.
  • I/O interface 430 may be configured to coordinate I/O traffic between processor 410, system memory 420, and any peripheral devices in the device, including network interface 440 or other peripheral interfaces, such as input/output devices 450.
  • I/O interface 430 may perform any necessary protocol, timing or other data transformations to convert data signals from one component (e.g., system memory 420) into a format suitable for use by another component (e.g., processor 410).
  • I/O interface 430 may include support for devices attached through various types of peripheral buses, such as a variant of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard, for example.
  • PCI Peripheral Component Interconnect
  • USB Universal Serial Bus
  • I/O interface 430 may be split into two or more separate components, such as a north bridge and a south bridge, for example. Also, in some embodiments some or all of the functionality of I/O interface 430, such as an interface to system memory 420, may be incorporated directly into processor 410.
  • Network interface 440 may be configured to allow data to be exchanged between computer system 400 and other devices attached to a network (e.g., network 490), such as one or more external systems or between nodes of computer system 400.
  • network 490 may include one or more networks including but not limited to Local Area Networks (LANs) (e.g., an Ethernet or corporate network), Wide Area Networks (WANs) (e.g., the Internet), wireless data networks, some other electronic data network, or some combination thereof.
  • LANs Local Area Networks
  • WANs Wide Area Networks
  • wireless data networks some other electronic data network, or some combination thereof.
  • network interface 440 may support communication via wired or wireless general data networks, such as any suitable type of Ethernet network, for example, via telecommunications/telephony networks such as analog voice networks or digital fiber communications networks; via storage area networks such as Fiber Channel SANs; or via any other suitable type of network and/or protocol.
  • general data networks such as any suitable type of Ethernet network, for example, via telecommunications/telephony networks such as analog voice networks or digital fiber communications networks; via storage area networks such as Fiber Channel SANs; or via any other suitable type of network and/or protocol.
  • Input/output devices 450 may, in some embodiments, include one or more display terminals, keyboards, keypads, touchpads, scanning devices, voice or optical recognition devices, or any other devices suitable for entering or accessing data by one or more computer systems 400. Multiple input/output devices 450 may be present in computer system 400 or may be distributed on various nodes of computer system 400. In some embodiments, similar input/output devices may be separate from computer system 400 and may interact with one or more nodes of computer system 400 through a wired or wireless connection, such as over network interface 440.
  • the illustrated computer system may implement any of the operations and methods described above, such as the operations described with respect to Figure 2 and Figure 3. In other embodiments, different elements and data may be included.
  • computer system 400 is merely illustrative and is not intended to limit the scope of embodiments.
  • the computer system and devices may include any combination of hardware or software that can perform the indicated functions of various embodiments, including computers, network devices, Internet appliances, PDAs, wireless phones, pagers, and the like.
  • Computer system 400 may also be connected to other devices that are not illustrated, or instead may operate as a stand-alone system.
  • the functionality provided by the illustrated components may in some embodiments be combined in fewer components or distributed in additional components.
  • the functionality of some of the illustrated components may not be provided and/or other additional functionality may be available.
  • instructions stored on a computer- accessible medium separate from computer system 400 may be transmitted to computer system 400 via transmission media or signals such as electrical, electromagnetic, or digital signals, conveyed via a communication medium such as a network and/or a wireless link.
  • Various embodiments may further include receiving, sending or storing instructions and/or data implemented in accordance with the foregoing description upon a computer-accessible medium or via a communication medium.
  • a computer-accessible medium may include a storage medium or memory medium such as magnetic or optical media, e.g., disk or DVD/CD-ROM, volatile or non-volatile media such as RAM (e.g., SDRAM, DDR, RDRAM, SRAM, and the like), ROM, and the like.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Processing Or Creating Images (AREA)

Abstract

L'invention concerne des systèmes et des procédés de développement d'applications par l'intermédiaire d'une interface utilisateur graphique (GUI) utilisant une architecture de système à composants d'entité (ECS). Dans certains modes de réalisation, un procédé de développement d'application peut comprendre la réception d'une sélection d'au moins un acteur devant faire partie d'une scène de jeu ; l'affichage d'une représentation du ou des acteurs dans la scène de jeu ; la réception d'une sélection d'un ou de plusieurs comportements à associer à chacun desdits acteurs dans la scène de jeu ; le stockage du ou des comportements sélectionnés en tant qu'associations avec chacun desdits acteurs, les associations étant stockées dans une table de hachage ; la mise à jour de chacun de ces acteurs et de leurs comportements associés ; et la création automatique d'un jeu vidéo exécutable sur la base du ou des acteurs et des comportements associés dans une architecture ECS sans avoir besoin de code logiciel écrit par l'utilisateur.
PCT/US2022/016712 2021-02-22 2022-02-17 Procédé et système de développement d'applications par l'intermédiaire d'une interface utilisateur graphique utilisant une architecture de système à composants entités WO2022178072A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP22708660.0A EP4295226A1 (fr) 2021-02-22 2022-02-17 Procédé et système de développement d'applications par l'intermédiaire d'une interface utilisateur graphique utilisant une architecture de système à composants entités

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US202163152120P 2021-02-22 2021-02-22
US63/152,120 2021-02-22
US17/673,284 2022-02-16
US17/673,284 US20220269489A1 (en) 2021-02-22 2022-02-16 Method and system for application development via a graphical user interface using an entity-component-system architecture

Publications (1)

Publication Number Publication Date
WO2022178072A1 true WO2022178072A1 (fr) 2022-08-25

Family

ID=80682569

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2022/016712 WO2022178072A1 (fr) 2021-02-22 2022-02-17 Procédé et système de développement d'applications par l'intermédiaire d'une interface utilisateur graphique utilisant une architecture de système à composants entités

Country Status (1)

Country Link
WO (1) WO2022178072A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110173587A1 (en) * 2010-01-11 2011-07-14 Alien Tool Kit Software Inc. Method and system for game development for mobile devices
US20200278924A1 (en) * 2018-06-12 2020-09-03 Unity IPR ApS Method and system for improved performance of a video game engine

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110173587A1 (en) * 2010-01-11 2011-07-14 Alien Tool Kit Software Inc. Method and system for game development for mobile devices
US20200278924A1 (en) * 2018-06-12 2020-09-03 Unity IPR ApS Method and system for improved performance of a video game engine

Similar Documents

Publication Publication Date Title
US10331315B2 (en) 3D user interface for application entities
Luke Multiagent simulation and the MASON library
JP2023036711A (ja) 複合現実システムにおいて仮想コンテンツを管理および表示する方法およびシステム
Buttfield-Addison et al. Unity game development cookbook: essentials for every game
Manning et al. Mobile Game Development with Unity: Build Once, Deploy Anywhere
Oehlke Learning Libgdx Game Development
Boyer et al. Android application development cookbook
US20220269489A1 (en) Method and system for application development via a graphical user interface using an entity-component-system architecture
Nair et al. Learning LibGDX Game Development
WO2022178072A1 (fr) Procédé et système de développement d'applications par l'intermédiaire d'une interface utilisateur graphique utilisant une architecture de système à composants entités
Wasty et al. ContextLua: dynamic behavioral variations in computer games
US10387540B2 (en) Generating a visual layout tree using caching techniques
US10430500B2 (en) Detecting and animating a change in position of a visual layout node of a visual layout tree
Manzur et al. Godot Engine Game Development in 24 Hours, Sams Teach Yourself: The Official Guide to Godot 3.0
US20170017612A1 (en) Generating a visual layout tree based on a named point within a visual description node
US10353991B2 (en) Generating a visual description tree based on a layout interruption record
Maskrey et al. Pro IPhone Development with Swift 4: Design and Manage Top Quality Apps
Itterheim et al. Learn cocos2D game development with iOS 5
Nhan Saving and Restoring World Mapping Data to Create a Persistence AR Experience
US20170017613A1 (en) Generating visual layout nodes to fill a display area based on an anchor point
Zirkle et al. iPhone game development: developing 2D & 3D games in Objective-C
US11003833B2 (en) Adding visual description nodes to a visual description tree during layout
Allen Understanding Activities
Sumpter et al. Create Positioning and Movement
US10402478B2 (en) Linking visual layout nodes of a visual layout tree using positioning pointers

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: 22708660

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2022708660

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2022708660

Country of ref document: EP

Effective date: 20230922