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?
Modern Examples
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.
DCSS webtiles lobby.
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.
An excerpt from ToME’s in-game chat log, as mirrored on the website.
Benefits
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.)
Cogmind, Connected
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:
Cogmind’s news and updates page. It happens to be showing the first news item I was using for, um, “testing.”
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:
A glowing reminder that there’s a newer version or news you haven’t read yet.
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.
An excerpt of stats listed in Cogmind’s score sheet. There are currently about 300 entries. (A future post will be dedicated to exploring character dumps and morgue files in roguelikes.)
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.
RSS (posts)
Mastodon
Patreon
Discord
/r/Cogmind
Indie DB
8 Comments
And of course, if you implement any more serious online features, you can do that one thing that made playing Webtiles extra interesting -- You could meet other player’s ghosts. Now, this isn’t really a fantasy setting, so ghosts might not be appropriate, but you could probably squeeze in some reasoning to why there’s a super dangerous, but rewarding to fight PC-esque opponent. Failed attempts to clone the Cogmind or somethin? Idunno, I’m just saying, coming across ghosts in crawl was fun and also horrifying.
Thank you for reminding me, I’d forgotten about other players’ ghosts. And that is a GREAT idea! In fact, I could quite easily fit it into the existing lore (though I can’t reveal any details because it involves multiple major spoilers). This feature would ideally be done via database so it would require extra web support, but if we do get that one day I’d love to add ghosts. Adding to notes now… :D
Glad I could help. And hey, anything to make the final game as good as possible!
A helpful suggestion: Have the NEWS button flicker on for ten seconds or so, but then stay solid yellow.
That way it would attract the eye, but not constantly nag if someone isn’t interested in checking just yet. Bonus points: Yellow for new messages, red for new versions, or somethin’.
I was wondering if it might annoy anyone. Though players who are annoyed by automated notifications can just turn them off and the button will never glow. Limiting its duration could work, too, especially since the way it works now, it will continue to flash every time you start the game until you update. We’ll wait and see what kind of feedback there is on this feature during the alpha. In the early stages I’d want to err on the side of making sure everyone (with the feature active) knows there’s a new version, rather than possibly missing the notification.
Different colors for the button could be a good idea, depending on how the system ends up being used. At this point I don’t plan on using the news feature on its own--it’s intended for text that goes along with a new version release, like maybe a list of major new features/changes. We’ll see if it gets much additional use and whether that warrants additional colors. For example, I can see using it to announce a competition which wouldn’t necessarily coincide with a new version.
The main concern I usually have with such blinky things is that if I’ve just settled down to play the game, I don’t want to deal with an update right then and there -- I just started the game, after all. Whether obtrusiveness helps here or not… hard to tell.
Yeah, that makes sense. Note that the menu excerpt shown in the post is not in the main interface--that’s the game menu, which you have to first open via F1 (or by clicking on the bottom right corner of the screen). You only go there for help, options, save & exit, etc.
Oh, then it’s probably legit. Carry on!