The title says it all, Bluedo is a multiplayer game. Why am I writing a multiplayer game, and why am I telling the world about it before I've finished writing it? It's an open invitation! Step right up!

I'm new to Rust, a powerful and rather beautiful programming language. It has no garbage collector, yet is memory safe, and the code boils down to optimised machine language. If there is a compilation error, the error message is extremely helpful, offering hints as to how the error can be corrected. There are lots of other features that make this a powerful, versatile yet relatively easy language to use. Relatively? It has paradigms that don't exist in other languages, such as lifetimes, borrowing, traits and so forth.

I've written some small programs in Rust - it's probably best to categorise them as utilities - and found that I achieved the goals of those programs in a surprisingly small number of lines of code. You need to understand how I view software.

Software, from a programmer's point of view, is a collection of solutions. The program needs to fulfil some small task in order to continue, but that small task represents a problem. Providing a solution to the problem is the role of the programmer. Writing a program in a language an experienced programmer is comfortable with, usually has a singular problem: how to organise the code most efficiently.

When you are learning a new language, and want to get knee deep in all its quirks and foibles, you need a highly complex program that is going to present the programmer with issues they've never had to deal with before. By highly complex, I don't necessarily mean the program itself is complex, but it deals with important issues the programmer has never had to tackle before. In my case, that's a multi-player game.

Actually, I've written quite a few multi-player games before, but I haven't had to deal with a lot of the problems these things involve because the handling and distribution of events were dealt with by the environment.

So, writing a simple multi-player game in Rust is going to present me with many challenges, and on top of those are going to be the challenges the language itself presents because I'm still familiarising myself with it. It's a whole sackful of problems: solve one, move on to the next. Provide solutions to them all and you have a working program. After that you can sit back and say that now you understand what you were doing, would the program benefit from a re-write? Probably yes.

Bluedo is a game based on the classic Cluedo board game. Here are the goals of the project:

1. Multiple players can join. At least four, aim for twenty.
2. The 'board' is a map
3. Multiple maps can be loaded and played sequentially or in random order
4. Players can easily create their own maps
5. Multiple NPCs each hold zero or more bits of data to solve the crime
6. The criminal (an NPC) will never reveal correct information about the crime (always lies)
7. All other NPCs will always tell the truth (or what they think is the truth if incorrect)
8. NPCs will wander the map in real-time
9. An NPC will only stop if challenged by a player (all other NPCs will still wander)
10. Player characters move at 1m per step (steps controlled by the player)
11. NPCs move at half the speed (making it easier for players to find them)
12. The game runs at 60fps (frames per second - i.e. updates/second)
13. Players must solve for:
    1. Who did it
    2. What weapon/method
    3. Where the murder happened (not necessarily part of the map)
    4. When the crime took place
    5. Why it happened (motive)

On top of this there is the client program the players use to connect to the server. Because of the nature of the game, there is no advantage to running a client on the same machine as the server. When a player finds an NPC they can ask them a single question or they can state a solution to the crime. A player cannot ask an NPC two questions in a row. They must ask another NPC a question before they can return to the first NPC.

The client program offers a simple text interface. Movement is turtle-fashion (forward or backward only - left and right keys turn in those directions). When a layer collides with an NPC, the NPC stops and the player is presented with a standard set of questions they can ask (or pick the 'solve crime' option).

One more thing - the player plays the part of a blind detective.

Is this going to be an exciting game that storms the internet? Unlikely, but that's not the point. Solving all the problems and learning what this teaches me about the language is what this exercise is all about. There will be a playable game at the end of it too, even if that turns out to be boring as heck.

I could just sit down and start writing the program, but as I'm learning Rust and also figuring out event capture and deployment, plus a load of other things, I'll take a segmented approach. This is where I take a singular problem and write some stand-alone code to figure out a solution to that problem. It makes sense because I don't have to compile everything I figured out before time and time again.

If you want to rise to the challenge and write your own version of the program - in Rust or any other language, fee free to do so and let me know how you're getting along.