You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -173,7 +173,7 @@ void CCharacter::Tick()
173
173
## the idea
174
174
175
175
Have a well defined api for server side teeworlds bots:
176
-
-~~It should be easy to setup (less than 10 lines of code in mostly one place).~~**UPDATE:** this goal had to be sacraficed for hot reload and state support
176
+
-~~It should be easy to setup (less than 10 lines of code in mostly one place).~~**UPDATE:** this goal had to be sacrificed for hot reload and state support
177
177
- It should be highly portable and work in basically any teeworlds or ddnet code base.
178
178
- It should be highly debuggable via logging.
179
179
- It should be highly debuggable via visual feedback (api for drawing text and lines at coordinates)
@@ -218,12 +218,12 @@ void CCharacter::OnTick()
218
218
}
219
219
```
220
220
221
-
The api promises that it does never keep any internal state accross ticks.
221
+
The api promises that it does never keep any internal state across ticks.
222
222
All the state it needs can be extracted from the world.
223
223
The api operates on a per tick level. With one input and one output.
224
224
There is no IO or any other side effects happening in the api.
225
225
226
-
These limitations make developing bots a bit more tricky. But it allows to fullfill all the goals.
226
+
These limitations make developing bots a bit more tricky. But it allows to fulfill all the goals.
227
227
It allows for better portability. It allows for clean unit test setups. And it allows to hot reload without breaking state.
228
228
229
229
## implementation details debuggability via logging
@@ -269,7 +269,7 @@ This ensures that you can always obtain the "why" for the current state. And als
269
269
## implementation details debuggability via visual feedback (api for drawing text and lines at coordinates)
270
270
271
271
An implementation of a twbl bot should be able to give visual feedback in addition to logging for debugging.
272
-
There should be a well defined api similiar to the logging one that allows for the twbl bot code to draw lines.
272
+
There should be a well defined api similar to the logging one that allows for the twbl bot code to draw lines.
273
273
And render text at certain locations. Or render colored simple shapes such as recentangles.
274
274
It is then up to the implementation consuming the twbl bot to actually do the drawing.
275
275
This requires writing some code but it is a optional feature if not implemented the bot will still work the same so that is fine.
0 commit comments