JPH0675792A - Management system in computer game device - Google Patents

Abstract

PURPOSE:To provide the system performing design in a form of being independent of application by revising a processing routine which is described in the form of a sub routine to a task of highly independent processing routine. CONSTITUTION:Each main program 1-n does not contain tasks A-Z, and only the name of the task and its procedure are described. A wide use task system associates the tasks A-Z with each main program 1-n at the time of execution. In short, the main programs 1-n calls the task system at the time of execution and delivers the name of the task to be used and the processing procedure to the task system. Then the task system calls and executes the task in the order instructed from the main program (priority order). The tasks A-Z called once may reside in a memory and the former task can be overwritten by the next task. Thus, the selection of such processing can be simply performed by means of the memory capacity and the performance of hardware.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a system for comprehensively managing a series of processes in a computer game.

[0002]

2. Description of the Related Art Normally, a program is divided into subroutines for each function, which are linked and executed as one integrated load module. Therefore, in the main program, set the parameters to be passed to the subroutine,
From calling subroutines to controlling processes,
Everything needs to be done in the main program.

[0003]

In the method using the conventional subroutine as described above, it is necessary to rewrite the main program each time the interface is changed, and it is necessary to relink all the subprograms.

Further, since there is little independence between programs, one modification affects the entire program, resulting in a significant reduction in work efficiency. Moreover, since the execution program is handled as one large load module, there is a lot of waste in terms of capacity.

An object of the present invention is to provide a system which can design in a form independent of an application without taking a description method having a high dependency between programs called a subroutine.

[0006]

According to the present invention, in a computer game device, a means for receiving a request for execution of a process that receives a priority order of the process and a call destination of the process and stores the call destination of the process internally. By providing a means for sequentially calling and executing the stored processing in accordance with the designated priority order, the subprogram which has been described as a subroutine until now is converted into a task.

Since a task is an independent program,
Developers can develop their own individual tasks.
On the other hand, develop a task program that calls this task. Regardless of the task contents, it should be possible to handle any task consistently. That is, the object of the present invention is a highly versatile task system. This general-purpose task system includes a part that receives an execution request for each process and a part that executes it (starts a task) in a specified order.

The program requested to be executed corresponds to a so-called main program. The main program informs the task system of the task name to be used and the execution order. The task system is also started by this main program.

The task system activates the task according to the task name and activation procedure received from the main program. A task automatically executes when it receives control from the task system, and returns control to the task system when it finishes.

At a certain time interval, the task system will start the next task according to the procedure.
When the series of processing is completed, the next loop is repeated. After receiving the task name and the processing procedure from the main program, the task system can store the stored task name and the processing procedure to automatically execute the same procedure without the intervention of the main program.

FIG. 1 conceptually describes the state of a conventional program structure and library. Each program is managed as one load module by linking subroutines. In the example in the figure, programs 1, 2,
n commonly includes the subroutine A. For this reason,
If the subroutine A is modified, not only the modification of the subroutine A but also the relinking of the programs 1, 2, and n is necessary. This work becomes more troublesome as the number of programs increases, which makes program management difficult.

If this is applied to the general-purpose subsystem of the present invention, it becomes as shown in FIG. Only the subroutine of FIG. 1 is changed to a task, and at first glance it does not seem to be much different from the conventional method.

However, the main difference is that each main program does not include a task, and only the task name and its procedure are described. Therefore, the program itself is very small. Moreover, since it is not included in the form of a subroutine, even if the task is modified, the main is not modified, and only the corresponding task needs to be modified.

The general task system associates a task with each main program at the time of execution. That is, when the main program calls the task system at the time of execution and passes the task name to be used and the processing procedure to the task system, the task system calls and executes the tasks in the order instructed by the main (priority order).

The task called once may be resident in the memory, or when the memory is insufficient, the next task may overwrite the previous task. Depending on the memory capacity and hardware performance, the selection of processing around this can be done easily. This is a feature of the general-purpose task system of the present invention.

[0016]

Example: Consider a game where a carboy shoots with his handgun. One of the cowboys (this is called an ally) can be operated by the player with a keyboard. Other cowboys (called enemies) work automatically at the direction of the program. In this case, prepare tasks such as moving allies, moving enemies, and shooting out bullet balls. Since the tasks are independent programs, there are no individual connections at this point.

When the main program is executed, the task system is first called and information such as a processing procedure is passed to the task system. The task system calls and executes each task in order of priority based on the received information.

After each task has been executed, control always returns to the task system. It does not pass control from subroutine to subroutine like in traditional programs.

Therefore, the processing is not complicated. FIG. 3 conceptually shows the situation. In the figure, <waiting for time adjustment> usually means waiting time until data is output to the display, that is, waiting for the vertical blanking period.

The task system shown in FIG. 3 serves as an interface between a main program and tasks. Moreover, this task system is not application-specific, and is designed to be commonly used by all applications. So-called,
It is a general-purpose system.

Of course, the task needs to be programmed according to the task system, but the task programmed in this way can be used as it is in other applications.

For example, the tasks of "moving an ally" and "moving an enemy" in FIG. 3 are versatile in a game program and can be used as they are in other games. Also, since it is loaded and used at the time of execution, a simple program description with only the processing procedure is sufficient for the main program, and the development and management of the program can be performed easily.

[0023]

The processing routine described in the form of a subroutine up to now is changed to a highly independent processing routine called a task, so that there is an effect that development can be carried out independently of other processing.

When a plurality of programmers develop one application at the same time, it becomes easy to divide the work and the programs can be developed in parallel. In addition, since the task is an independent program, it is easy to test independently. Therefore, the development period can be significantly shortened.

In the conventional subroutine type program, the execution program had to link the necessary subroutines into one load module. For this reason, some applications have the same subroutine twice.

As a result, there was a lot of waste on memory, and it was necessary to relink the associated load module each time the subroutine was modified. This process is simple, but as the number increases, it becomes quite a difficult task. Many links were missing, making it difficult to maintain the program.

However, in the general-purpose task system of the present invention, each process is described by a task and managed as an independent program group, so that it can be maintained and managed independently except at the time of execution. Therefore, the maintenance of the program is easy, and the memory for storing the program is saved.

Further, even if a large program cannot load all the tasks at once into the memory, the task system can easily execute the program. This is because one application is configured as a set of divided programs called tasks, and the task system can execute each task while loading each task, so that the program can be executed with a small memory.

Execution efficiency drops if loading is done most frequently, so the task that is the center of processing is made resident, and the task that is rarely used is loaded as needed.
It may be deleted from the memory after the processing is completed. Such a method can be easily performed because programs are managed in the form of tasks.

[0030]

[Brief description of drawings]

FIG. 1 is an explanatory diagram showing a configuration and a storage state of a program according to a conventional subroutine-type program description.

FIG. 2 is an explanatory diagram showing the contents of a main program and the storage state of tasks according to the management system of the present invention.

FIG. 3 is an explanatory diagram conceptually showing execution of a program by the management system of the present invention.

Claims (1)

[Claims] 1. In a computer game device, a means for receiving a request for execution of a process for receiving a priority order of the process and a call destination of the process and storing the call destination of the process internally. A management system for a computer game, characterized by comprising means for sequentially calling and executing in accordance with a priority order.