Monday, August 27, 2012

Asynchronous Roguelike idea

I was on a Roguelike forum and the topic turned to multiplayer games and whether they would be possible for a Roguelike. I posited that it was possible, and that you would want to retain the turn-based structure as much as possible. (While others talked about real-time games which are, in my opinion, not like Roguelike games at all.)

Anyway, during the discussion, I described an interaction mechanic that would scale out to asynchronous multiplayer while having turn-based combat. (I describe it in my second section below.)

More importantly, it's a mechanic that's testable in a small single-person game -- fit for a 7DRL.

[question about multiplayer roguelike and some initial discussion]

Personally, when I think "multiplayer roguelike" I don't think of an MMO. (Probably because I hate MMOs.)

My first thought is multiplayer like Civalization. It's turn-based. While each unit has few choices, each player controls a lot of units at the end.

So: a small group of friends play together.

Now consider: there is no actual requirement to keep the turns in sync across all players except when they're within line-of-sight. If I can't see you the difference of you going one turn or 10 to my one turn is meaningless.

So, when players are within line-of-sight, they need to wait for the other players to finish their turns. Talking to each other is still a free action, of course.

Next, more squelching of boring things.

If the group is moving as a unit, one player is given control and everybody moves as a single unit until enemies are encountered. This is simply squelching manual follow commands.

If a player is on auto-explore, their next command is handled automatically by the system so there is zero delay. If every one in the party is on auto-explore together, they should fan out, explore the map, then converge on the first monster found. (Given that talking is free and the first thing a person in their party would do is say, "Hey, there's something I need help with over here!")

So, yeah... the only time you should be waiting for other players is when you're near each other and monsters are around -- or you're near each other and playing non-cooperatively.

Then again, I see multiplayer as an extension of single-player multiple-character. We see those sorts of games in RPGs all the time, but they're rare with roguelikes.

[someone commented that it ruined causality]

It only ruins causality if you assume that one turn for player 1 is the same amount of game-time as player 2.

I'm saying that implication is flawed. One turn for me is not the same as one turn for you. Turns != Time.

If I'm not in the room with the other player, they could be in the middle of a Rest 1000 cycle. My character could be in the middle of a Rest 1000 cycle. It shouldn't matter.

Of course, it couldn't just be line-of-sight of other players, it needs to be line-of-sight of players or monsters that can see said player.

What it does do is ruin the possibility of having any concept of "game time" so any mechanic which relies on such a concept should really opt for something else -- like having the concept of time be tied to average player level.

Anyone who thinks you can't do real small-scale turn-based multiplayer has clearly never played Civilization with human opponents. Get yourself a copy of Freeciv (Mac, Linux, Windows) find yourself some friends and give it a go. By default it's true turn-based and if someone goes for tea, you're stuck waiting. (Though current versions of FreeCiv support 126 concurrent players, that is clearly overkill.)

With Civilization each player makes decisions at the same time. If you finish your turns at the same time there is no waiting for the other player. This approach should work for a Roguelike.

However, it's better if you only need to do this with the line-of-sight limitation I originally mentioned. If I'm playing with someone and that person needs to rest for 200 turns to heal and restore mana, I don't want to be on my own for that time. It's better if I just leave the room and when they come out they're all rested. (Though this has so many repercussions that I think the "rest to recover" logic needs dropped.)

As far as NPCs -- both friend and foe -- there would be two types: those that are only awake when in line-of-sight of players, and those that are like the players and can mysteriously know where the player is at and suddenly be within line-of-sight.

Being turn-based (even the variant where players do not take turns) should give you very much the same feel as a traditional Roguelike.

Being line-of-sight+turn-based would be a different sort of game. It requires a different concept of time.

The thing is... it's testable within the confines of a 7DRL. Not even multiplayer, as a simple single-player game. It breaks the simple "player goes" / "computer goes" logic that frequently drives simple Roguelikes. Will it feel all that different, though?

More importantly, will it feel more or less like a Roguelike when compared with a real-time game?

Sunday, August 26, 2012

Blacken Java Library update

So, when I put Blacken to the side, I had posted code, but I was unhappy with it and I was feeling pretty down with the whole thing overall.

Not so anymore. I ran across someone speaking relatively highly about it. It encouraged me to fix it. I have someone developing it with me now. I have other people writing games using it.

Next month we release Blacken 1.1. It stomps all over the 1.0 release.

I'm planning to start writing an in-depth "Developing a Roguelike Game with Blacken" tutorial after the release.

(I'm putting aside NaNoWriMo this year to work on it. I've loved NaNoWriMo, but I need to finish the first pass of big edits to my first book and... well, so far it hasn't happened. I am committed that my next NaNoWriMo related task will be to replan and rewrite my first book. It'll be mostly a rewrite, but the bones are good. I'll be keeping the good things.)

So, yeah... major changes in priorities, but these things happen periodically. As they say, "Life is change."

This actually marks the second year with a Blacken release, as I released it to the community about a year ago next month. I actually expect 2012 to see a second release, as well, as I'm planning 1.2 to be a release to fix the nits that crop up while writing the tutorial.