Valley 1:Multiplayer

From Arcen Wiki
Jump to navigation Jump to search

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:

VERY Important Notes About Fighting Enemies

  • For reasons you can read about below, the positions of enemies will differ -- often greatly -- between one player and another. So you and I might both be in a server, attacking the same enemy, but I'm on one side of a chunk and you're on the other. Thematically, this is because each of the players in a multiplayer game are actually in subtly different universes of the multiverse, somewhat overlapping with each other and somewhat not. To read about why, see "Why The Multiverse Stuff?" below.
  • 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 attack all the various players individually at once. So if you and I are playing together and fighting a dragon, that dragon could be setting me on fire and slashing you with his claws, or sending fire after you also. However, I won't see the attacks against you, nor will you see those against me. These attacks are thus NOT stat buffed in any way, so the enemies hit with the same force that they would in solo play, just against each player individually.

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!

Why The Multiverse Stuff (First Item from the notes above)?

Because of the shmup-like nature of the game, with lots of enemies and projectiles, we've found it impossible to sync all the enemies and projectiles in a way that was as fun to play as solo play. We could come kind of close, but it was an inferior experience to be sure.

We postulate that this is why there are almost no networked multiplayer schmup games that were are aware of. In any game that needs pixel-precision and sub-second response times, the network jitters just destroy the experience. So, thinking outside the box, the last month of work on multiplayer has been implementing a much more robust and complicated network model that solves the issue in a nontraditional way.

The basic rule here is that for the experience to be satisfyingly precise, all those projectiles and such have to be simulated on your local computer. And they can't be synced-up with the other computers that are also playing in the same room as you, because that would lead to things jumping around and thus you missing your shots or getting hit by something that moments ago was clearly going to miss you. We had it working this way over a month ago, but it was intensely frustrating as a gameplay experience.

Begin Technical Explanation That May Or May Not Interest You

So what we did was make it all local, and we don't even try to sync up certain things. And this is where the network model gets all complex, not that you need to really understand the details to play the game. But given our audience, I figure a few details are probably warranted to sate curiosity. Generally speaking, we actually have something like four simultaneous networking models going here: some stuff happens locally-only; some stuff happens locally and then gets echoed to other clients; other stuff gets requested locally, executed on the server, and then echoed to the appropriate clients; and other stuff gets initiated on the server and then echoed to the clients.

The above sounds really complex, and it is, but it's in no way required to understand or play the game. Let's take a few examples:

A. An ice bat is flying about, and you and I both come upon it. On my computer it flies at me, and on yours it flies at you. No syncing of the enemy position happens between our machines, and all this happens with extremely good precision like in solo play. This is an example of the local-only sim.

B. I want to kill that ice bat, so I shoot a fireball at it. This happens pleasingly immediately and with great precision as well -- same as in solo play -- because it is happening locally. However, it's a lot more fun (and clear) if you can see my spells, so the spell gets echoed to your machine and you see my fireball shot, just as I fired it. You might happen to see it hit the ice bat, or it might miss on your machine. Either way, it's what happens on my machine that matters at all (the echo on your machine is just visual-only not affecting anything whatsoever). This is an example of the local-sim with echoes to other clients.

C. You and I have both been attacking that ice bat, and -- from our testing experience with Josh and Keith and I all playing together -- most likely not even noticing the slight discrepancies like my fireball missing the bat on your machine but hitting it on mine. Now let's say that you land a miasma whip blow that kills that ice bat. The message of your attack hitting the bat gets echoed from your machine to the server, and then the server decides that the bat is really dead and tells all the clients about it, causing the bat to poof away and disappear. This is an example of the server initiating something (the bat's death) based on looking at its state and then telling the clients. This mostly is used for things that really do need to be exactly consistent between clients, and which don't require the same kind of "when did this happen" precision that combat in the game does.

D. Let's say that this ice bat was guarding a wind shelter site. I walk up to it and push the button to erect a shelter. This request emanates from me, and goes to the server for processing. The server then verifies it's okay to put up the wind shelter, and then tells all the clients (including me) about it. This is an example of the client requesting something which the server then executes. This is used for most of the macro-game stuff, and many of the other non-combat type of activities that aren't affected negatively by something like a 400ms delay on a slowish connection.

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. I was really shocked that, playing over a 3G connection from my tethered iPhone, I was getting performance that was almost identical to solo play. This model is extraordinarily latency tolerant for an action game, which is really cool.

The one downside -- which we haven't figured out completely how to mitigate yet -- is the confusion that can result for new players when each of them is seeing something like a boss in different positions over the course of a battle. Depending on the boss and the strategy that the players use, it can actually be so subtly off that you might not notice if I hadn't told you. But it can also just as easily be so off that you're on one side of a large room and I'm way at the other end, and we're each fighting the same boss other in our section.

It's kind of funny, because this style of gameplay is actually really thematically fitting, but we haven't figured out exactly how to present that to players in a way that is succinct and simple to understand, yet. Hence this massive post for those people opting into the initial public alpha for the multiplayer. I think that you'll find in practice that this style of gameplay works really well, but I don't relish the thought of getting daily bug reports from new players about enemies that were in different positions.

FAQ

How Do I Opt In To The Multiplayer Alpha?

Right now, for obvious reasons, 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 with ease thanks to our lag-tolerant networking model, 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. The whole "multiverse thing" with enemies is working entirely as intended, but we are still searching for ways to make that whole process more clear and intuitive to players in the game itself. We have some various ideas in store for this, but plan on putting up a new brainstorming forum thread about it to solicit ideas and feedback on how to make this 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.