Quests Development Log

This is a dump of my unfiltered, unedited notes... Some of it will be complete sentences, a lot of it might be fragments or quick notes. I'm planning to update this page every month or so with notes copied from my JOURNAL file. Enjoy!

May 16 2020

Added icons for showing other players' resources.

Experimented briefly with building up what I have in Unity. It's goofy because building what I have should be extremely simple. But within seconds I ran into a bug where their transparency sorting was showing my sprites in the wrong order, and there was no good way to set up the paths connecting two locations. It's so true that if you're not building the specific kind of game that their editor was built for, it doesn't really save you time. Of course, if I wanted fancy 3D rendering it might save me time. But I get the feeling that if I really wanted to do 3D I'd have a fine time implementing it myself... it would just take quite a while.

There's something wrong with the networking setup :\ Now if you have 3 players connected it takes forever to verify your move. Changing the server to only send game state when it changes seemed to help. Maybe old packets were getting buffered for a long time?

Next up on the todo list is EVENTS... ugh that seems like a huge step. Maybe lets do a smaller thing first and rename "resources" to "items".

May 12 2020

Another open question about locations and events... what happens if you go to a location and none of your resources match the event? Or you have no resources? Does every location need to have a default event, or should those locations just do nothing? Maybe a default for the whole region or for broad types of places?

It occurs to me that resources is a pretty overloaded term... confusing between ingame resources and like... art assets and stuff. Maybe I'll rename them to "items".

Displaying the player's resources is in. Not sure what to do next... show the other player's resources?

For map visuals... might be cool to do a little perspective distortion. Tried to make a hacky version, can't figure out the math :( I'm guessing because I want a kind of angled thing I might need to use a quadratic or some trig somewhere... will have to think it through properly sometime.

May 11 2020

A hand of resources for each player. Sounds simple, but seems like it's too big of a task... because I can't really figure out where to start beyond just listing a bunch of possible resources.

I suppose to start, I can add a list of resource IDs for each player. We'll need it on the server (game state authority of course), but also on each player. I'd like to experiment with starting with open information, and then only closing it if I think it will be an improvement. It seems like this kind of game always starts with each player having a closed hand etc. etc... but does it actually make this more interesting? I think having quests be closed but everything else be open lets you speculate about what your opponents are doing... instead of it feeling super random.

Along those lines, I think it would be good to have a "rumor" system in the game. This would hint to the player what could happen if they visit a certain location. An example might be "... I heard fish are more abundant in a *Distant Land*". If the player travels there, the current event might reward the player with more fish than an event at the Coast.

And keeping with the theme of open information and not making the player keep track of things, after they uncover this rumor the map would show the rumor in that location's detail box. If another player goes and triggers the event, causing a new event to spawn in that square, the rumor would vanish. (Or perhaps better, the rumor could be displayed on screen, and be clicked to pan the map to that objective... that might help give players easy access to locations they might be interested in without panning around the map and reading a ton of stuff.)

Joel brought up an interesting idea about events. Should a location have several events, and each event is "taken down" once it's claimed? Or does it have an event that rotates over time? Does visiting a location take down all of the events there?

May 9 2020

Multiple players can now connect, and you can see other players spawn in when they join.

Next up is to get them reporting moves to the server and showing those moves over the network.

Aaand that was easy. Now I think it's time for some cleanup... and maybe addressing that the network may not be reliable. Turning on clumsy pretty quickly shows that the current code will break easily.

switching the server to frequently send the world state helps... but the issue is still very obvious when trying to connect or make moves. the server can just spam world states to ensure the clients eventually get an update... but the clients need to also have a solution for spamming the server until their moves are acknowledged.

Client now maintains a queue of packets to send. Each packet has a sequence number, and the client will resend until the server acknolwedges its packets.

Downside is, server can't ack the packets yet. Need to reorganize so the server can check sequence before dispatching out to the individual commands, and update the sequence number if this is a new packet.

With that now working, I guess networking is going well enough. There's some weirdness still, where you can flicker back and forth a bit when you move. But the core of it is working... two players can see updates going back and forth.

Next up is to set up a hand of resources for each player.

May 6 2020

More networking basics are working. The server acks the player's connection and tells the player their starting location. I took a diversion into random number generators and found a nifty small one. So the server even generates a random starting location.

I suppose the next step is to connect two players at once.

May 4 2020

Doing some research into the nitty-gritty of UDP. There's an ominous warning in the linux man pages about receiving EMSGSIZE if your packet is larger than the MTU to the client. Seems like the guaranteed size is much lower than I was thinking... 556 bytes. (might as well do 512).

It also occurs to me that I really can just client/server this thing and avoid cheating... that's almost easier probably than the mailbox system and syncing client states that I was thinking of. - player connects - sends CONNECT command to server, with a player ID and a room number - server responds with a CONNECTED command, containing player's index - server follows up with a LOCATION index telling the player where they are starting - when the player moves, they send a MOVE command to the server and an animation starts - server replies with updated LOCATION - when animation finishes, player code confirms it got correct location from server, otherwise it moves back

May 3 2020

The paths are working, and the player can click to move to different paths.

Time to figure out networking. TCP is fine for this, since it's turn based. I think it makes sense to develop another simple mailbox server, instead of trying to do peer to peer. server: - state - events

when a client connects / reconnects; it gets the current state. when an event happens, it is broadcast out to everyone. state updates are also broadcast out to everyone. If the state gets big, I can start doing delta compression on it. state: player location [mac_address? or uuid? (for reconnecting) connected? name]

last night i had some ideas about larger design goals for this game. i think it might be interesting to explore doing long games... but it would also be ideal if players could drop in and out.

I thought about splitting the game into three "ages". the first age would be intended to be faster paced, and would set up for the long game. players could play just the first age and be done in half an hour. in the second age, the game starts slowing down... it takes longer to complete quests, but you can start setting up long term plans. In Age 3, some areas you can only reach through long term planning start to open up.

I thought TCP would be fine, but UDP is actually so much easier on the server side that I'm tempted to do that.

Apr 26 2020

This project is up and running! I Have some sprites displaying, and text rendering working (in basic form). My first goal is to get basic movement working. This will require a lot of the basic drawing stuff as well as mouse input.

Right now, I need to get paths working. I have a janky implementation sort of working, but clearly I need to use actual trig and add rotations to the draw commands.