-
Notifications
You must be signed in to change notification settings - Fork 25
/
Thoughts.txt
163 lines (125 loc) · 10.1 KB
/
Thoughts.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
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
https://www.youtube.com/watch?v=ha1-ZfeIbfQ&list=PLzVi6Kh_HMIWKS1aXOV4XobuymoF0P-_S
Players will always be testing boundaries
I'm new to this, what can I do, what feedback can I get
what happens if I just fuck around
what happens if I fire this gun at this other player
guns will fire, trolls will troll
When you're online and in near-anonimity, you have very little to lose
The most you can lose is your own in-game investments
This can be applied to more vulnerable mechanisms, so that players use them consciously
interactions can be locked behind time investment, or resource investment
State vs Events
Lobby state:
onwership of WorldSessions
it is small and doesnt change very often
is very critical that it is received asap when changes occur
if the change is so rare and so important wouldnt it be easier to work with events?
Are states that send every tick just worse events? because they also cause the "unchanged" sends
I'm starting to think ownership-state is special
note, currently using events that have a delta-state in it lolmao
note, switched back to state now that states handle deltas nicely
Handshaked events
If I'm sending something "to owner" because owner is the only one who can handle it, then it should be a handshaked event, because by the time the event gets there owner might not be owner anymore and ask me to retry.
Entities
I can "join" with an entity I control, I can be "joined" by entities I don't control.
I can "leave" with an entity I control, I can be "left" by entities I don't control.
I can "request" entities I want to control, I can "release" entities I don't want to control anymore.
release goes to a supervisor (oe.highestResource.owner) and ideally should transfer back to a room-participant, just like a resource release
gamemode: meadow: stays in game, infinite cycle, no ways to die or sleep, quits to lobby-screen
Options:
visibility:
-Friends Only
-Public
max players:
defaults to 32? load critical on world owner if all in world
Rules:
- no other mods?
- players join a lobby
- in the lobby, players can
- pick which persona they'd like to go in game as
- see unique collectables they've found in the world
- see progression for:
- unlocking new personas
- unlocking new skins for each persona
- unlocking new emotes for each persona
- players enter the game as personas, not necessarily slugcat
- in the game
- players see eachothers personas
- there are no roaming creatures
- there are no items
- only cosmetic placedobjects are placed
- personas dont collide with eachother
- the only things the player can find:
- eachother
- collectables the player picks up by colliding with
- unique plants
- unique replicas of game items
- I'm thinking the plant-items really
- progression bits
???
- puzzles
and what I mean by this is something it takes more than 1 player to do
- food to eat and share?
- there is no cycle timer
- gates have no requirements
- or maybe... require X players, but going back is always unlocked?
- that drop into sub though, or other one-way situations... could be bad
- dying in a pit puts you back
- to the room entrance?
- to the spawn position?
- can't run out of air when swimming
- any other ways to die?
- coils in 5p stun only...
- check dnspy I guess
- sleeping in a shelter plays a short animation
- saves your spawn position
- from a shelter you can teleport to any other shelter that you know
- need full food
- doesn't close the shelter and doesn't end the game
gamemode: online coop story mode : juuuust like couch coop
needs a more fine grained description here
essentially need to meet a set of expectations, but better have all of those written out
- there is a host
- there is a savestate or savefile to be used
- players want to play together and make progress together
- even though we could have them save position separetedly, makes more sense to keep everyone together
- respawn in last shelter vs respawn with host (or other alive player)
- what if the host died
- there is a rain cycle, players must be all asleep or dead for the cycle to tick
- engine stuff missing:
grasps
eating
ai creatures doing consistent things
cycle
going in and out of game
Rain Meadow devlog (this also helped me organize my ideas)
Studies
I've been studying multiplayers and how they do netcode and sync. Most games have a host, either host-peer in p2p, or server in cli-serv, that has the full state of the world or the full state of the areas that are loaded, and feed that state to other client/peers. Some of the physics and collisions might be resolved locally (extrapolation) so it feels less laggy, but typically there's a server correction mechanism and the server has the final say on everything.
Assumptions
For Rain World, seemed unreasonable to have the host load all rooms, I haven't tried but I doubt it'd perform any good, and working around the limitation of one active world at a time seemed like a hassle. Insted, I've developped a resource ownership and lease mechanism, so that players could load and handle rooms themselves, while still being coordinated by a common host. You load it first, you own it and you're the room-host. If you loaded it after, you're now subscribed to whoever loaded it first, and the host has the final say on any conflicts.
Lease System
This ownership system has three levels: the lobby, the world, and the rooms. Roughly, the lease happens as follows: The lobby owner is picked by steammatchmaking automatically and unambiguously, and as players start to load worlds in-game, they'll request the lobby owner for the ownership of the world they're trying to load if they think it's free, otherwise they'll query the current world-onwer for a subscription to the world-state. With the state of the world in hands, the players now look into loading rooms and the same process happens, they'll query the world-owner for a room they think is free, otherwise subscribe to an existing room-host.
It took me a couple weeks maybe more to get this lease system right, but at the end of it I had 3 test players running around on their own game, and at every moment they either had ownership of the resources they were using, or they had access to the full state of it (nothing much at the time except for lease info) as it was being loaded.
Entity System
Next I stated looking into synchronizing objects. To simplify things, I've initially handled entities as if they would belong to a room (more on this later). As players tried to add entities to the room, they'd notify the room-host of the new entity, of if they were the room-host, they'd notify everyone else about all entities added to the room. Similarly for entities leaving the room, once an online (not local) entity would have left the room, boom, gone from the game, because again they existed at a room level. Entities are defined by object-type and creature-template in order to recreate a similar enough object on the other side, and are identified with both the owner's ID and the ID of the entity in the owners world, so there's zero collisions (that's actually 12 bytes and could be trimmed down a bunch).
This got me two players on screen when there should be two players on screen etc, but no movement sync yet.
State Feed:
In order to syncronize position and whatever other relevant state there is to objects, the "owner" of the object has to provide that data. The owner of the entity is by default whatever player added that entity to the room and notified the room-host about it. The owner is then responsible for feeding the state of that object into the room-owner physics, and the room-owner then rebroadcasts the physics of all entities to all players in the room except the owner of each entity.
The result of this is that your entities (such as your player character) are controlled by you and if you're not the host it's syncronized to the host's game, and the entities from eveyone else are moved by information that the room-host sends to you. I haven't bothered with anymations, but synchronizing chunk positions made the slugcats move around on eachothers screen and that was enough for a prototype. This system was flexible enough that creatures added by either player to the room would also sync over to the other player's world.
Entities in a world:
I realized that I wanted to have player positions on map, and not being limited to loaded rooms. Again, with the current system, entities only existed in loaded rooms and would get removed from the game as they left them. I could have a separate system that would feed map info, but instead I've decided to rework the system so that entities can be added/removed from both a world and a room, so that players who were subscribed to a world with an entity would receive "abstract level" information about the entity, and players in a room with the entity would receive physics information about the entity.
I soon realized that with a system like this would be perfect for creature sync at a world level, by letting the world-host spawn in creatures and let realized-room-owners snag those creatures as they are realized with the rooms in order to control an broadcast their pysics. The only addition needed was a mechanism for requesting/transfering entities between players.
I'm currently still implementing missing features and fixing some bugs with this system, but this is pretty much where I am at at the moment, and everything seems to point to creature-synched co-op soon-ish.
My game added a slugcat to the region, it's mine
I detect it being added to a room
It should be synched in region, fire up newapoinregion
newapoinregion detects it's new and has no onlineentity attached to it
create new onlineentity attached to this
tell region-owner about new entity in region
it's got to be the owner, so handshake and retry on fail
"new entity" and "enter region" as separate events?
region-owner receives the event, recreates entity, does nothing with it? places it in absroom?
also because it's owner rebroadcast to others
what if received as non-owner? how can we detect the mistake?
"Join with Entity" that only owner can process