Hello, Rune-Server!
I have, over the last month, begun development on a new project. I became really interested in Go over the last few years, and had thought about doing a project like this one for a while. Recently I was going to start improving an old RSCDaemon-based codebase I'd worked on in the past, and after hacking on it for a little while, decided that it would be better, and actually probably be a lot easier, and definitely more enjoyable, if I just implemented a brand new RSClassic server using Go instead. So, about a month or so ago, I sat down and started working on it. It's now at a state to where others would find it useful, and as such, I've decided to publicize it a little.
Server: https://github.com/spkaeros/RSCGo
Client: https://github.com/spkaeros/mudclient204
HTML5 Client: https://github.com/spkaeros/rsc-client
For those that have not heard of it, Go is a programming language designed by some developers at Google which implements CSP-style concurrency, and was designed with the goal of replacing C/C++ for a lot of Google's projects. I'd say that they did a decent job, as I personally love using Go, and find it the most intuitive language I have ever learned. Plus, it compiles to native code, which I think is great.
RSCGo is being designed with performance, simplicity, and portability in mind.
It should always be able to compile and run on the three major desktop operating systems: Linux, Windows, and Mac OS X.
It should be able to handle large player loads on modest hardware.
It should leverage modern technologies to provide a responsive user experience, and run efficiently on modern hardware, using minimal resources.
For the database, I've decided on SQLite3, as I feel it is the best SQL for the job and enables easy and fast deployment, without needing any SQL server installed nor root access on the target machine. I am debating on implementing a less-powerful data store for this project so that I may remove SQLite3 as a dependency, as go-sqlite3, the package I use for my SQLite3 driver, depends on CGo, which seriously impedes portability and increases binary size a great deal. This may or may not happen in the future, we'll see.
For configuration settings, I've decided to use TOML, as I feel like YAML is kind of overkill, and INI too simple. Plus, I like the TOML API a lot better than the INI API in Go.
For command-line flags parsing, I've opted to depend on a package from a github user: jessevdk/go-flags It provides a very nice and easy to use API and much more complete parsing capabilities than the go standard flags package does.
For password hashing, I've decided to use SHAKE256, using a configurable salt, with an output length of 64 bytes, and I use the golang.org/x/crypto API for this. This is the highest security SHA3 algorithm available and while the security level may be a tad overkill, the performance hit from using this versus a less secure algorithm is negligible, and so I decided to go ahead and use it.
That's all of the dependencies for this project. Obviously to build it you'll need a working Go 1.11+ compiler. I do test builds for RSCGo on 32 and 64bit Linux and Windows, and nothing more. If anyone can help me to test against 32 or 64bit Darwin, that would be greatly appreciated. I believe that it'll compile and work well on any target system with a working Go 1.11+ compiler with CGo support and accompanying C compiler, and a working SQLite3 C driver implementation. If I ever manage to drop SQLite3 as a dependency, it should compile and run fine on any target supported by Go, which is a rather long and impressive list.
Here is a screenshot of a slightly earlier revision in action, just after multiplayer walking support was finished:
Anyways, I'm going to stop writing about it for now.
If you have any questions, comments, or suggestions, please let me know.
If you'd like to sponsor further development, or provide a server and domain for a publicly available server running RSCGo, please let me know. I'm going to attempt to work on this until it's complete, but unless someone else can provide the means for it, I am not able to host it publicly at this time.
I have, over the last month, begun development on a new project. I became really interested in Go over the last few years, and had thought about doing a project like this one for a while. Recently I was going to start improving an old RSCDaemon-based codebase I'd worked on in the past, and after hacking on it for a little while, decided that it would be better, and actually probably be a lot easier, and definitely more enjoyable, if I just implemented a brand new RSClassic server using Go instead. So, about a month or so ago, I sat down and started working on it. It's now at a state to where others would find it useful, and as such, I've decided to publicize it a little.
Server: https://github.com/spkaeros/RSCGo
Client: https://github.com/spkaeros/mudclient204
HTML5 Client: https://github.com/spkaeros/rsc-client
For those that have not heard of it, Go is a programming language designed by some developers at Google which implements CSP-style concurrency, and was designed with the goal of replacing C/C++ for a lot of Google's projects. I'd say that they did a decent job, as I personally love using Go, and find it the most intuitive language I have ever learned. Plus, it compiles to native code, which I think is great.
RSCGo is being designed with performance, simplicity, and portability in mind.
It should always be able to compile and run on the three major desktop operating systems: Linux, Windows, and Mac OS X.
It should be able to handle large player loads on modest hardware.
It should leverage modern technologies to provide a responsive user experience, and run efficiently on modern hardware, using minimal resources.
For the database, I've decided on SQLite3, as I feel it is the best SQL for the job and enables easy and fast deployment, without needing any SQL server installed nor root access on the target machine. I am debating on implementing a less-powerful data store for this project so that I may remove SQLite3 as a dependency, as go-sqlite3, the package I use for my SQLite3 driver, depends on CGo, which seriously impedes portability and increases binary size a great deal. This may or may not happen in the future, we'll see.
For configuration settings, I've decided to use TOML, as I feel like YAML is kind of overkill, and INI too simple. Plus, I like the TOML API a lot better than the INI API in Go.
For command-line flags parsing, I've opted to depend on a package from a github user: jessevdk/go-flags It provides a very nice and easy to use API and much more complete parsing capabilities than the go standard flags package does.
For password hashing, I've decided to use SHAKE256, using a configurable salt, with an output length of 64 bytes, and I use the golang.org/x/crypto API for this. This is the highest security SHA3 algorithm available and while the security level may be a tad overkill, the performance hit from using this versus a less secure algorithm is negligible, and so I decided to go ahead and use it.
That's all of the dependencies for this project. Obviously to build it you'll need a working Go 1.11+ compiler. I do test builds for RSCGo on 32 and 64bit Linux and Windows, and nothing more. If anyone can help me to test against 32 or 64bit Darwin, that would be greatly appreciated. I believe that it'll compile and work well on any target system with a working Go 1.11+ compiler with CGo support and accompanying C compiler, and a working SQLite3 C driver implementation. If I ever manage to drop SQLite3 as a dependency, it should compile and run fine on any target supported by Go, which is a rather long and impressive list.
Here is a screenshot of a slightly earlier revision in action, just after multiplayer walking support was finished:
Anyways, I'm going to stop writing about it for now.
If you have any questions, comments, or suggestions, please let me know.
If you'd like to sponsor further development, or provide a server and domain for a publicly available server running RSCGo, please let me know. I'm going to attempt to work on this until it's complete, but unless someone else can provide the means for it, I am not able to host it publicly at this time.
