While we often think of single-player games not requiring an internet connection, and certainly many of us do play our roguelikes offline, there are advantages to implementing optional online features in a roguelike.
Browser games, or roguelikes that require a persistent server connection to handle gameplay/content, are beyond the scope of this article. Those are also more likely to be real time or multiplayer (i.e. “less roguelike”) and require a connection anyway, while here I’m talking about single-player turn-based roguelikes that can also/normally be played offline.
Many of the original classic roguelikes, pretty much anything that runs in a terminal, can be set up to work through a connection (telnet etc.). (See here for a collection of classics accessible via this method in your browser.) But there is so much more you can do than simply play a roguelike hosted on a server by feeding it commands. What about value-added features?
Now that most players have access to the internet, modern roguelikes are using the web in new and interesting ways. The two best examples are Dungeon Crawl Stone Soup (DCSS) and Tales of Maj’Eyal (ToME 4). These are games fully playable offline, but with many additional benefits to online play.
DCSS has a wonderful so-called “webtiles” system whereby you can play online, watch others as they play, and chat with them in game. It also collects stats you can browse, and is naturally a great system for hosting competitions. Back when I used to play a lot of DCSS (in the pre-son days when I had this thing called “free time”) I wanted to use webtiles (mostly as a way to force me to be honest--no temptation to savescum, and also to take part in competitions), but latency is a huge problem for me since there are no servers nearby. I did occasionally watch other players, though, a fun learning experience.
I’m less familiar with ToME4 because it’s not really my type of roguelike, though it’s easy to see that Dark God has built quite an expansive virtual empire via online support for his game. The website has player accounts, character dumps, real-time stats from everyone playing the game, and, most interesting of all, there’s in-game chatting with anyone else playing the game. Classic roguelike mechanics don’t lend themselves to the multiplayer format, and as single-player games they miss out on potential unique benefits of playing with others, be it asking for help or sharing an experience. In-game chat is one way to bridge that gap.
What can single-player roguelikes gain from integrating some degree of web support?
- Metrics. Stats collected during normal play are both fun for players and useful for developers looking to improve the game. Real numbers are more useful than player feedback when looking to balance content, because players’ opinions can be skewed by many different elements contributing to their personal experience. (That’s not to say player balance feedback should be ignored, but we should compare it to the numbers and hopefully see a more complete picture.)
- Leaderboards. Even in single-player games, many players enjoy comparing their progress and strategies to those of other players. Providing an automated way to upload scores and stats simplifies the process and helps build a stronger community. Sure it’s possible to hack these systems unless the game is actually played out and/or verified in its entirety on the server side (another advantage of DCSS webtiles), but it’s still fun.
- Data sharing. Some types of roguelikes can benefit from automated sharing of data between players, like morgue files (for player ghosts), maps, and other content-specific information. If I was a more savvy web developer, I’d almost certainly try out a concept roguelike that enables the game to asynchronously share data between players even in a turn-based environment (included as a major feature of the game design, of course).
- In-game news and update notifications are good for keeping players up to date. This is especially useful for roguelikes which may be updated quite frequently and/or over a very long period.
- Automated error reporting lessens the burden on the player to report a problem, and increases the likelihood and efficiency of a solution on the dev’s end.
- (This is a basic list, as there are many more possibilities. Get creative! Feel free to share other ideas in the comments.)
I’m more interested in design than banging my head against technical problems I don’t understand (I love solving challenging technical problems, but only those for which I’m likely to already have most of the required background knowledge), so I avoid web development whenever possible.
That said, ever since the first Cogmind design doc I’ve imagined and hoped that the game would support at least some web-enabled features. For the 7DRL I even held a tournament (more of these will happen, only bigger and better =p), though scores were provided by e-mailing them to me. Not so efficient, and it definitely doesn’t scale well.
More recently as I moved to plan for a first release and decide what that release absolutely must have, the usefulness of an optional web connection made it a higher priority. After a day or so of research I went for the simplest solution possible (for me): An SDL_net-based class that can send HTTP POST messages combined with a tiny bit of corresponding PHP to talk to the game from the web.
What does this little bit of code do for Cogmind?
First, and most importantly for a game that will have frequent substantial releases, we now have an update checker. All this does is retrieve the latest Cogmind version number from the server, and check whether it’s newer than the current local version. Because it’s easy to add extra info to the data transfer, I made it possible to send a text message along with the version number, in case there’s some kind of important game-related announcement. So this feature doubles as a news checker. Here you can see it in action:
This is not an automatic updater--you’ll still have to go download the new version yourself, it’s just a reminder/notice. To make sure you know there’s a newer version available, until the update/news page is opened its button will glow in the game menu:
This and all web features are optional, and all but update checking are disabled by default. While the other features come disabled, I do hope you turn them on ;).
In addition, there are now automated crash log uploads. If the game crashes for whatever reason, which is unlikely but not impossible during early releases, before shutting down it will try to upload the precise reason and a reference to the source code that caused the crash. With this system in place we should be able to fix any serious bugs very quickly (assuming you turn it on).
Score sheet submission is also automated. All this feature does is upload the same score and stats file you see in .txt form after a victory or loss, but it’s a lot better than sending the file manually! Very convenient for anyone who wants to help improve Cogmind’s balance, take part in tournaments, and contribute to anonymous overall game stats published for reference.
As part of these new features, I’ve revamped the score record system, and added “player name” to the game options (you can also choose to upload data anonymously). While we may see a more robust web interface for Cogmind in the future, with even more features, I can’t guarantee it. Even if it does happen, it will almost certainly be handled by someone other than myself, and would require the use of an actual server-side database (interested parties have already contacted me; we’ll see).
On a technical note, because I wouldn’t want the game to be stopped while it waits for a data transfer or response from a slow or unavailable connection, all the web code is managed from separate threads, so Cogmind is technically now multi-threaded for the first time :D.
Update 15/10/20: I’ve written more on this and related meta topics in a post on Morgue Files.