forked from sjbrown/writing_games_tutorial
-
Notifications
You must be signed in to change notification settings - Fork 0
/
notes.txt
96 lines (67 loc) · 3.18 KB
/
notes.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
authentication
making your own system? you have two choices:
* be smarter than everyone else in the world
* be smarter than that finite set of people that will play your game
protocol:
Twisted needs to have another Twisted client at the other end
This may not be realistic
But let's use Twisted at both ends because we're trying to do it rapidly
Ok, which chapter should be first?
I tried considering the "Messages across the wire" as the first chapter, but I think my brain wants to do first things first.
---- Chapter 0 ----
Talk about Rapid Development
---- End Chapter 0 ----
---- Chapter 1 ----
First:
simple pygame example - Chimp
code example.
critique about how this will fail under complexity
* maybe some pseudocode with a hella nested if/else
critique about how this will fail under network
* maybe the same example with a sleep(1) simulating the network
Games need a front end with NO perceptible lag for user interaction / feedback.
Model / view / controller with Event-driven can solve these two design problems
Explain MVC
Code example
Then we will also need to handle multiple Views and Controllers.
Explain Event-driven
Code example
---- End Chapter 1 ----
---- Chapter 2 ----
Strategy A: consumers can nullify events
case 1:
event comes in
click on blank part of screen
traps each get a crack at it, but do nothing
some 'other' entity must turn it into a new trap placement AFTER traps have a crack
case 2:
event comes in
click on trap
traps each get a crack at it, one catches it
this trap must change event.removeMe = True otherwise the 'other' entity will
add a trap to the blank part of the screen
Pros:
Cons: the "AFTER" is tricky and requires complexity in the events module
Strategy B: event gets classified by an outside entity, then gets put on the front
of the queue.
case 1:
event comes in
click on blank part of screen
traps don't handle raw mouseclicks
outside entity catches mouseclick, goes through each trap, sees if it collides, it doesn't, so post_at_front() a 'ScreenClick' event.
case 2:
event comes in
click on trap
traps don't handle raw mouseclicks
outside entity catches mouseclick, goes through each trap, sees if it collides, it does, so post_at_front() a 'TrapClick' event.
Pros: sets the design up for a separate GUI Model
Cons: multiplies the kinds of events there are, requires an events module API addition, post_at_front()
---- End Chapter 2 ----
Should I do some kind of *radical* client-server?
Like, start the UI, the first thing it does is ask the EventManager, "Who are the players?", "What's the game state?", maybe even "Here are my capabilities".
Hmm. the "here are my capabilities" part will probably mean more code. Scratch that.
Anyway, the idea here is that the view should not respond to BoardBuiltEvent as much as it should broadcast a query (with a TTL) like "Hey guys, send me the board object"
This approach keeps the data inside the messages, less in shared state. Synchronization will turn into scaling issues.
----
I should have a section on terminology like "main loop"
I should have a section on what "rapid development" means -- chosing from alternatives the one which gives us the highest coding speed result, often over program efficiency.