Valley 1:Multiplayer

Multiplayer Design Notes

In the main, playing multiplayer is just like playing solo. You connect into a world, and you do all the same sorts of activities. These are the important differences that you need to know, though:

Important Notes About Fighting Enemies

• When fighting enemies, their health is multiplied by the max number of players who have ever been in their chunk. So if 8 of you go in, it's 8x the health of solo play. If all players leave a chunk and it gets dropped from RAM (which happens after about ten seconds of nobody being in the chunk), then that multiplier gets removed and the monster's health is reset to full. So if eight of you went in and fought it and died, and later you come back in solo and want to fight that boss yourself, then you can without any issues.

• Enemies can generally only launch as many projectiles as they can in singleplayer, but can generally melee attack as many players as touch it. There's a lot of rebalancing/rework coming in the near future that will alter how enemy projectiles work in terms of being able to hit multiple players or being multiplied by the number of players present, etc. Right now the game's probably just easier in MP if you're fighting together, but we figured that would be less frustrating for players than it being buggily-harder.

Minor Notes About Loot

• Whenever there's a drop from an enemy (shards, health drops, etc) all players who are in the chunk at the time can collect the above. Players who enter the chunk later won't see that stuff. (This is the "whitelist" model).

• Whenever there's a permanent drop from something like gems from a gem vein, or just dust or health potions you find in a stash, every player can collect those things once, even if they come to the game later or that room much later. (This is the "blacklist" model).

• The Civilization Level, as in solo play, is global to the world, not specific to a player. Just as a reminder. EXP is also global.

Chat!

To chat to other players, hit the T key. You'll also see other players noted on the world map and in the dungeon/region maps. Open the tooltip for the region/dungeon/room in question to see who, specifically, is there.

Usernames, And License Key Usage Restrictions

• When you connect to a server, it will show a username. At the moment this can be configured in the Networking tab of the Settings screen. If you change your username and connect back to the server, it will create a whole new character and set of inventory and all that for you.
  • Note: you can try to change your username while connected to a server, but it won't work.

• So if you and a family member (or whoever) want to share a single server on a single computer at different times of the day, just change back and forth between your two usernames and you can do so. Two players with the same license key can't connect to the same server at the same time, but they can both play in one world as long as it's one at a time.

• Note that the server will also need to have a license key so that it doesn't limit the world to civ level 6, but that license key by default will just be your main license key from your client. And the server's license key won't block players with the same key or anything like that, unlike if two clients with the same key as each other try to connect to a server.
  • You probably won't even have to think about this unless you set up your server on a dedicated box, but we thought we'd mention it just in case!

Begin Technical/Historical Explanation That May Or May Not Interest You

Mostly due to the shmup-like nature of the game we've not been able to find a single multiplayer model that accomplishes all our goals. Thankfully, we can just use different models for different parts of the game, but this is how we got here:

We started with a single model that was very nothing-happens-until-the-server-says-it-does (except movement/position, which was actually not very relevant to the simulation at the time). It worked, but we found that it wasn't really acceptable for the player to press the "launch fireball" button while at the top of a jump but the fireball not actually emit from them until (say) 100ms later after the server had gotten the message, processed it, and told the client "ok, there's a fireball there now". It was even worse with stuff like the double-jump ability and the massive-speed-buff ability. Basically: when you press the button, the thing needs to happen. Now.

Also, we didn't like that even if the fireball showed up when you thought it should, if the monster you were shooting at was moving fairly rapidly then the fireball might look like it touched them on your client but the server might have the monster in a slightly different place and not detect that collision and thus the fireball misses (and maybe hits something else). Similar with monster shots flying at you: you could get hit by those (or even melee attacks) because reality according to the server just wasn't quite the same as what you were seeing. Close, but not close enough, because "close enough" in a game like this is quite near "exact". Internet latency doesn't permit that.

Fixing both those problems was very tricky. Making fireballs initially process and spawn locally instead of on the server was a fairly straightforward solution to the first problem. Having the fireball collision checking also be done locally solved part of the second problem but not all of it: the monster could still jump around on the client as it received updates from the server on where the monster actually was, and thus you could still miss shots you would have hit in singleplayer, and still get hit by monsters that would have missed you in singleplayer. We really didn't like that.

In the end we found that we could get everything else we wanted if we just broke one common MP assumption: that the enemies are in the same place on all the clients at the same time. That way the clients could be entirely authoritative over monster position (for themselves) and the game would really play a whole lot like singleplayer. We were pretty happy with it, so after several rounds of testing and fixing to get things ready for a public-alpha, we made that available to players on an opt-in-basis.

The players were not happy with it.

The response to "monsters can be different places on different clients" was (remarkably) polite, but very firm: No. Not anger or hysterics or drama or whatever, Just No.

So we thought about it for a while, and realized that if this was the response of our core community we'd really get roasted by audiences that didn't know us. Since that dog wouldn't hunt, we considered several alternatives:

• 1) Just completely cut multiplayer from the feature list. This was very tempting, as we didn't want to mangle the singleplayer game to fit within a viable networking model.
• 2) Fundamentally rework the combat model such that it would be naturally compatible with networking and also allow us to make it really fun. We had some ideas that would have worked well on both counts but really would have been a different project.
• 3) Only have local co-op. Would have been better than nothing.
• 4) Stick with our existing model but change which assumptions we were breaking. Specifically, restore monster-location synchronization but break "monsters always move like they do in singleplayer".

We heard from player feedback that while they didn't like monsters that jumped around or shots that missed due to lag, they were far more willing to deal with that than monster locations not being in sync. So in the end we went with that last option.

The end result (thus far) is a blend of quite a few models; here's an example:

• 1) I move my character around, shoot a fireball, and that fireball hits a monster and does damage: all that happens on my local client and is played back on the server and then on the remote clients.
• 2) Another monster spawns on the server and shoots a fireball at me: that happens on the server and is played back on all clients.
• 3) I run into the fireball and take damage and then run through the monster and get hit by its melee attack: that happens on my local client (so I don't get hit by something that I had literally no chance to react to because it wasn't actually where I was told it was). So monster melee attacks and monster projectile attacks are processed quite differently.
• 4) The monster decides to run away: this happens on the server, and the server sends my client an update on the monster's movement.
• 5) My client receives that update, and if the new position is sufficiently different the monster "jumps" to the new correct location on my client. So if I had fired a fireball at where I thought it was I might miss that shot, or the monster chose to run through me I might get hit by a melee attack (due to my client detecting the collision, not the server doing so). This isn't ideal, but it's the least of the available evils that we're aware of. And it's pretty common for multiplayer games to accept "jumps" due to lag, so there it is.
• 6) A bit later, I hit the monster (which is a boss) with a giant meteor that reduces it to zero health. My client begins the "shrink monster" animation so it looks instantaneous, but the monster is not actually officially "dead" until the server receives the meteor-hit-boss-in-the-face message from my client and it then does two things:
  • First, since the monster is a boss and its death can have "macrogame" consequences (that can affect players outside the room), the server computes those consequences and tells all clients (including me) about them.
  • Second, the server computes the "in-chunk" consequences and tells all clients (including me) that are actually in the room about them. Clients elsewhere never see that message.

Post-Technical Explanation

The end result of all of the above is pretty much that things tend to happen very fast, almost like you are playing solo, and that most things happen in exactly the way that you would expect.

FAQ

How Do I Opt In To The Multiplayer Alpha?

Right now we don't want anyone playing this multiplayer alpha who hasn't at least skimmed this post. So if you just fire up your game like usual, you won't see anything about multiplayer at all.

To opt in during the alpha, go into your RuntimeData folder inside your game folder and put a new file called IAmOptingIntoMultiplayerTestingEvenThoughItMayDestroyAVWWStuff.txt. You don't need anything in that file, the game just checks to see if it exists.

Next time you start the game, you'll see a Multiplayer button on the main menu. If you don't, then your file is probably named IAmOptingIntoMultiplayerTestingEvenThoughItMayDestroyAVWWStuff.txt.txt (which windows tends to do if you have file extensions hidden, which is the windows default).

How Do I Host An AVWW Server?

Once you've opted into multiplayer, just go into the Multiplayer section of the main menu, and hit Launch Server Of Your Own. It will then give you a list of worlds that you have created in solo play. Choose the world you'd like to launch as the server, and another copy of AVWW will launch.

Once this server copy loads, it will simply say "Welcome!" and the name of the world that you launched it with. Just minimize it or otherwise leave it in the background, and you're all done. Later there will be some admin controls on the server, but right now there are not.

If you prefer to launch the server from the command line directly (which is what the game is doing anyhow), then on windows launch it as AVWW.exe -server -world "{name}" On OSX it should work as open -a 'AVWW.app' -n --args -server -world "{name}" We haven't actually tested the OSX server yet, though, to warn you. But it works fine as a client and there shouldn't be any issues with the server that we know of.

Is There A Central List Of Servers Somewhere?

Not yet, no. You'll either have to direct connect by IP, or if you're playing on a LAN the game can search for it for you. This is exactly like AI War.

That said, unlike AI War we'll have a central server list up in the next month or two, because with a server model like this it's very easy compared to AI War.

How Many Players Are Supported On A Server?

You tell us! This is something we really want to have feedback on. How many players are you able to run on one server with acceptable performance? So far we've had three, and the performance was extremely awesome. We're betting you can get at least into the teens, and 30-50 players might be feasible.

There is a definite finite amount of players before the server process is going to start having RAM trouble, though, so hundreds of simultaneous players on one server is very unlikely. That said, if you have hundreds of players who come and go on a server, and only 30 (or whatever number winds up working) are on at a given time, that will work fine.

Once we start working on the admin tools for multiplayer, we'll have an ability for server admins to set what their desired player cap is for their server. If your specific network setup only supports 10 players with the performance you want, then you will be able to set it at 10, etc.

Can A World Be Used In Both Single And Multiplayer?

Oh, you bet. And you can even switch back and forth if you want.

Should I Be Extra Careful With My Worlds In The Multiplayer Alpha?

Yes, definitely! We've been testing this for months, but we've also been developing it out at the same time. There are going to be bugs that we didn't find, and some of them might come at the risk of losing part or all of your world. Back up your worlds accordingly, and don't load your only copy of an awesome single-player world into a multiplayer server. Make a copy of it first, just in case!

What Happens When A New Player Joins A World Belatedly?

This is really, really straightforward. Since the civilization level is global, they automatically have the same level as you, whether that's level 1 or 100. Assuming that you've already reached the first settlement (in other words, passed the intro mission), it will just dump the new player into that first settlement with some reasonable starting gear of whatever tier is considered current for your civ level. They'll still have some things to pick up before a serious mission, but they aren't remotely helpless.

Known Issues

1. The movement of other players is pretty jerky at the moment. This is just a cosmetic thing, though, and not something you'll tend to notice in the heat of battle anyhow, so we're going ahead with multiplayer public alpha while we continue to look at that.

2. Some of the dungeon/region map updates are not immediately propagated to you if another player is doing stuff in the same region as you. When you move to a new chunk yourself (room, cavern, section of surface), any missed updates are synced up, though. We're working on this one, too.

3. Sometimes the chat box doesn't have focus immediately when you hit T, but usually it does. It's really annoying when it does not, but we're working on that.

4. Monster movement can be pretty jerky in some cases. A skelebot chasing you across a surface chunk can be very nearly smooth, but an ice bat currently jumps all over the place when it's close to the player that it is chasing. It's definitely not ideal but this is the alternative to monsters being in different places on different clients. We're working on making it smoother.

Multiplayer Features Yet To Come

List of Players On A Server

Handy for seeing who is even in the world. And potentially a quick way to warp to the location of any other player from anywhere in the world.

Better Handling Of Usernames

Right now it's just that textbox in the Network tab of the Settings screen. We know that's clunky, and it's just a temporary thing we implemented to save time for the moment. Later there will be a more robust screen, with a dropdown list of past-used usernames, through the Multiplayer section of the main menu.

Admin Tools

Kicking users, banning users, setting up access rights and anti-griefing measures, that sort of thing. Also setting user caps.

Server Listing

A way for you to advertise your server if you want to, so that other people can see that in the server list and join. Until the admin tools are in, this may be a bad idea!

PVP Options (May be post-1.0)

We've talked about things like having PVP arenas where you and your opponent can each summon monsters to fight one another, and where there's some Chess-bughouse-style back and forth depending on how successful you each are. Any sort of PVP options would be in this sort of style of play, rather than in direct combat like you have against monsters.