How it works
Tiny Land is a Typescript program, both client and servers were all done from scratch, using pure HTML 5 canvas for graphics on the client and Deno WebSockets on the server.
Because, Deno. I mean, there's not many specific reasons other than hype and experimentation. Tiny Land, back when it was called Tiny Dungeon, was conceived to be a text-based online RPG, using WebSockets (socket.io) and Node.js. As soon as we (me and andre) got the basic game working with Node, Deno was starting to rise up in popularity with the version 1.0 and we thought we might give it a try. We faced some issues using such a new tool, but we got it working nonetheless and I'm very proud to have created the very first websocket based online rpg powered by Deno.
Basically it all revolves around two files:
- Server: ./server/clientHandler.ts
- Client: ./client/src/startup/GameClient.ts
These two files keep talking to each other using WebSockets. The server sends a set of instructions, always starting with an "instruction id" (actually called Command in the code), the client parses the message, it reads what instruction is comming by it's id, then it know exactly what to expect as payload, then it uses this payload in appropriate places.
Same the other way around, the client sends some instructions, preceded by an "instruction id", the server decodes the instruction (it doesn't need apecific parsing for each "instruction id" it, since all messages sent from the client are very similar), then it does what it needs to do with the payload.
- 1: First, a player hits the "W" key and the client sends a walk request to the server, telling it wants to go up
- 2: The server receives the message, by reading the instruction id, it knows the payload also contains a "direction" since it's about movement, so it calls the respective method that deals with player movement. The server then validates if that player can walk up (maybe there's a tree on the way and stuff like that must be checked).
- 3: After the server confirms the movement and moves the player to a new position, it sends a message to the client, saying that a movement happened for that player, and the movement was upwards.
- 4: The client then takes that message and, by the instruction id, it knows the payload contains something like direction and player id, so it can draw on screen a player with that id, moving up.
By checking these files you'll be able to trace exactly the paths that all messages go trhough in order for the game to work, it's pretty simples really.
Okay, now you know how it works, how about start adding content to the game by creating your first tile?