Lecture for intermediate



Lecture for those who intend to become intermediate

  • Introduction
As you, designers who are familiar to the development of OKEs some degree, may know that clear goals are not exist in this game. You can play it in any direction, and it is free that how far you elaborate. It can be thought that, the goal setting is also a part of the contents of this game already. That is, as you become more familiar, how to enjoy and how to beat becomes more different from each other.

For example, there are some people pursue every day how well avoid mines. But next to it, there are some people do everything in their power to assault by destroying all mines. Descriptions satisfy both at the same time is extremely difficult.
As you become more familiar, as it becomes finer contents, your own strategy is going to be made.

For these reasons, it is difficult to determine what to lecture for intermediate people or what is the definition of intermediate in the first place.
So first, for those who intend to become intermediate, I entered from the description of the timing and execution speed of the program that are essential knowledge for creating large programs.


  • For the reaction rate of OKE and scale of the program
A CPU that you select in Hardware has parameters of "storage capacity", "execution speed" (and weight). "Execution speed" represents the execution speed of the program and the unit c/s means "(the number of executing) chips per second".
The highest execution speed of CPU is 240c/s; you can execute 240 actions or decisions per second. Looks ridiculously large numbers at first glance, but is not really so much. Let's take a closer look.

In this game, various judgment of combat takes place on a frame-by-frame basis. Frame is a still image that makes up a video. When you choose "frame advance" of the system menu in combat you can check the status of frame-by-frame.
This game is 30fps, 30 pictures will be displayed per second. Therefore, if the CPU is 240c/s, you execute 240 chips per one second (= 30 frames), 8 chips per frame (= 1/30 sec).
To pause during the battle actually, you can check the number of executing chips that appears bright.

This number will significantly affect the "reaction rate of OKE". OKE runs all the actions as instructed in chips read in that time.
Even though you made an excellent program, not only it becomes waste unless it is done when it is needed, but also it may cause trouble when it is executed with unnecessary timing.

So let's look at an avoidance decision. There is a branch of “whether there is a bullet around the body” at the beginning of the avoidance decision, perform the avoidance maneuver If this were yes, go to the next process if it was no. What is needed in this case is that the first branch is executed when there is a bullet in the vicinity of the body. For example, if you set the range of around the body radius 100m, it is best to branch to avoidance decision with a margin of distance of 100m.

But if the code is longer, for example, what happens if a program executes about 40 chips until return at earliest?
Even with the fastest CPU, it takes 5 frames or more to go around once. If there is only once decision per go-around, avoidance maneuver is performed 5 or more frames late when a bullet comes at the worst timing.

5 frames = 5/30 of a second, it is about 0.17 seconds. During this time, AP ammunition flies about 50m; beam and rail gun flies about 80m. That is, then you will get a direct hit with no reaction if it was shot from the distance. Even though you perform reaction, if not even 30m away at that time, it is too late to act. Leaving aside one shot of beam gun, in case of rail gun, even a hit is directly linked to defeat frequently.

The avoidance decision was given as an example here, but I can say the same thing to the decision of all of course.
As it become a larger-scale program, more complex assessment of the situation and actions can be performed by OKEs but the reaction rate will reliably drop instead. Stack of subtle reduction of reaction rate affect more than a little on combat result.
If you create a large program without thinking about the reaction rate, most will weaken comprehensively than small and medium-sized programs.

There are mainly two know-hows to maintain the reaction rate when you building a large program, utilizing subroutine and utilizing loop.


  • Utilize subroutine
In the CPU with a maximum storage capacity, there are two areas that can be form subroutines of 7× 7 size on the right side. It is possible to run the subroutine from the chips of the “SUB: 1” “SUB: 2” placed in the main program of the left side. When the executed subroutine is completed, the process proceeds to the next of “SUB” chip which was placed in the main routine.

By placing regularly this "SUB" chips in the main routine, it becomes possible to execute programs implemented into the subroutine several times until go around a main routine.
For example, implement avoidance decision into a subroutine, when you call the subroutine whenever the main routine proceeds about 10 chips, reaction rate is significantly improved because it began to determine once per about two frames whether it is necessary to avoid.

It should be noted that, of course main program is stopped at the place of "SUB" chip while executing subroutine.
If there is a long program that is always executed in the subroutine, the rotation of the main program will be dull depending on the number of calls.
Although rate of behavior that implemented into the subroutine improves, all other actions are delayed slightly.

Therefore, you must be sure to execute subroutines only when necessary.
To give avoidance as an example, if the OKE is quick moving or jumping already, it is not needed to execute subroutine.
By increasing the rotation speed of the main routine even slightly by reducing unnecessary processing, let's improve the rate of each operation.


  • Utilize loop
To tell the truth first, loop may cause a fatal bug in high probability if you are not familiar.
What is the loop, about the risk and the usefulness of the loop, I describe a simple example together.
Please see the image below.


This is avoidance decision of the program that is described in "Lecture for beginners", introduced the missile countermeasure.
Missile detection is added before scanning for a high-speed flying object. It is built with the assumption that the behavior " Continue to lie down when a missile is detected to 100m range, then jump to avoid after it approach to 20m" .
As long as the missile does not come within 20m, it will continue to run the operation of lie down repeatedly.

This portion that is run repeatedly, this is the loop. By looping temporarily here, at the moment the missile enters the 20m range, you will be able to perform reaction immediately.
To execute the process that you want to run on certain situations quickly, or in order to run an action timely at the moment the situation has changed, loop processing is quite useful.

Now tested the program of the sample image, then it was confirmed that it is possible to avoid opponent’s missile on a one-to-one. So I organized a three-machine team triumphantly, and fought with a team that has missiles, then, OMG! There is an OKE that continues to lie down and does not move at all!
Of course playing possum like that definitely not effective to OKEs, they were wiped out within a numerical disadvantage. What on earth was the problem?

This sample is the form of,
"Detected a missile coming towards in the 100m distance " → "loop until a missile is detected in the 20m range"
The problem is that, in the first place, it has formed a loop on the assumption that "missile coming towards" is reach to the location of the OKE reliably.
The missile coming towards is aimed at the OKE really? Or there is not an obstacle before it reaches?
In such a variety of reasons, if the missile did not come in the 20m range, you will not be able to get out of the loop.

In this case, you can solve the problem by modifying like the image below.



By only one shifting of the ahead of an arrow, you will leave the loop if the missile does not come to 20m range.
In the case also maintaining a bidirectional loop, you can resolve the problem as the image below.



When you specify the range, you can be outside the range around your OKE by up and down key while holding down R button.
By utilizing this, form a loop of “Continue to lie down if there are one or more missiles between 20m and 100m, proceed to avoidance decision when there are no missiles”.
In this way, you can perform jump by avoidance decision when the missile is coming within 20m. In addition, even though the missile towards different direction or disappear, loop is always released.
(There are waste and problem still in this example, I set it aside for the time being)


It was long, but in short, it is that want you to understand firmly the risk and benefits of loop processing.
Because bugs of this kind occur frequently, let's repeat behavior test and thoroughly verify when introducing a loop.
If you will master successfully, quick reactions become possible in limited situations and that slight differences lead to great results.

[Summary]
When building a large program, needs attention to the execution timing of behaviors that require quick responses.
The more complex and courteous programs, the more reduced the reaction rate is. Beware treatment of unnecessary processes in many cases.
Consider the timing that should be executed and the need for each decision. For example, execute a long thinking process during operation that cannot be canceled, etc.
Subroutine and loop are useful, but you should utilize it after a solid understanding of its risk.
If the subroutine that will be called each time is long, the main program will not go around quickly.
Wrong release condition of the loop leads to defeat very likely.

[Supplemental Commentary: loop examples]
Although I gave the missile countermeasure loop as a reference, in addition, describe an example of a relatively safe loop to be able to make easy.Conducting enter and exit of the loop in accordance with the each state of OKE, it will be safety and quick loop process.
For example, because it will not be able to perform the most operations when the OKE is struck and overturning, there is a way to check the situation in the dedicated loop and determine whether activate options or not, take evasive action to avoid additional attack immediately after the state recovered. In opposite, if the target is struck and overturning, it might be interesting to enter the loop for pursuit and additional attack.
Because the state recovers automatically, it will be expected a certain effect without causing an infinite loop.


  • Narrow down the processes
There are many processes that you want to monitor situation changes constantly such as Scan for Projectiles, Activate Option, and process during overturning, etc.
You can easily monitor such processes constantly by putting in places to pass frequently (Top of main and top of sub used frequently).
However, in other words, would be referred to as "regardless of need or not, have repeated frequently the same process ", it is a waste of processing power.
This will cause delaying the response.

For example, in the case of Self-Cooling System of options, you do not have to monitor the amount of heat of body constantly in many cases.
Mostly the purpose of starting the cooling is either, prevent thermal damage when it is struck or increase the frequency of fire.
If the purpose of preventing thermal damage, it is only necessary to assess once when entering or exiting the process of when be struck or avoiding. If you increase the frequency of fire, it is only necessary to assess when it refrain from attack due to the heat.
In this way, it is possible to improve the throughput performance if you stop constantly monitor the processes being monitored constantly.

However, by stopping the constant monitoring, it is possible that the case that cannot be monitored occurs.
In the case of cooling system, if you assess only when entering or exiting the process of when be struck or avoiding, there is likely to be roasted by "beam from close range (undaunted, cannot detect by Scan for Projectiles)" or "heat generated by the flames of napalm (undaunted, are not projectiles )".
Although you should assess elsewhere to avoid this, the mounting area increases in this instance, and eventually you would waste the processing power if you assess too much.
It is necessary to narrow down and pinpoint the necessary timing of decision, or if you do not narrow, must be determined after having analyzed trade-off among the mounting area, effect and risk when stopped constant monitoring.