due to deps update.
This commit is contained in:
@ -94,7 +94,7 @@ star: true
|
||||
|
||||
这种“等待条件”的现象与高中数学讨论的“若 p 则 q”命题(即条件命题)非常类似。一个条件命题要能判断其真伪,条件就必不可少;同样的,一个触发要能执行,首先要等待前置事件完成。在程序框图中,像这种具有前置条件的语义用**条件分支**表示(如下图),又称**选择结构**。
|
||||
|
||||

|
||||

|
||||
|
||||
从游戏实际运行的现象来看,触发会在条件满足(为真)后执行相应的“处理程序”(也就是行为),这一点符合基本印象。而当条件**尚未满足**时,触发则阻塞等待。
|
||||
假如**逻辑上**就是希望判断条件不满足(为假),由于触发一直等不到条件满足,则直到游戏结束为止这个条件都得不到任何处理。如此看来,触发的逻辑本质就是如上左图的**条件单分支结构**。
|
||||
@ -227,7 +227,7 @@ if anyEvent: # P8 任何事件(当*单独使用*时,它会令触发*立即
|
||||
|
||||
对于循环结构,[已知的触发教程](https://www.bilibili.com/video/BV1Zw411y7DZ?spm_id_from=333.1387.collection.video_card.click)大概会让你关注触发的「重复类型」:
|
||||
|
||||

|
||||

|
||||
|
||||
通常来说,选择 *2 - Repeating OR* 那一项便足以满足很多简单的重复需求。
|
||||
|
||||
@ -244,7 +244,7 @@ while True:
|
||||
|
||||
分析这个运行表现不难发现,它是类似下图图二的流程:首先它走到`while`处执行判断,由于条件恒满足,往下执行`print`;然后循环并没有结束,它重新回到`while`重复执行前面说的流程,将坏掉的乐土打字机事业推进下去~~爱莉希雅死辣~~。
|
||||
|
||||

|
||||

|
||||
|
||||
上面的`Hello World`案例也是类似图二的流程。于是,重复触发可以用`while`循环表示:
|
||||
```python
|
||||
|
Reference in New Issue
Block a user