Don't sweat it! I'll make a call for a group test when we need one next. This us LIVEdev, open for testing all the time!
Sorry I have been busy so I haven't been able to test it either. On the movement though. I would go with both and let the people decide. On the movement (this was one thing that kinda bugs me with ravensword but I still like the game) you should keep it simple with the character always centered. And just allow us to free look and zoom in and out. Only let us straff left and right then move forward or backward, no in between. This is just my opinion though, I know a couple people said they like the ravensword controls, they just made me feel like I was sliding.
Ah ha! Pretty sweet playing beta .. Here are some things you can put on your list for updates Problems: Ability to go uphill, unable to use sword (buggy), unable to use spell, etc. I suppose you're aware of all the problems Suggestions: movement might need something like Dungeon Hunters control scheme
@ShadowsFall: Yep, all known issues, but thanks @Everyone Here is an update on the new WASD style player movement. After prototyping the zone server, I've tried two major approaches this weekend, each with a degree of success: 1) Send move start/end updates. These happen in response to client-side keypresses. The client processes the movements right away, and sends out a notification to the server. The server broadcasts the movement to connected clients. With each broadcast event also is sent the player's absolute position and rotation. The net effect is a decent use of network traffic but some ugly rubber banding when the absolute positions kick in and vary significantly from the client side position predictions. 2) Broadcast absolute position and rotations from the server at specific intervals. This is much more precise as it involves very little client-side movement prediction, but the initial result (aside from quite a bit of network usage) is a lot of tiny start/stops in player movement. I'm not exactly sure which method I am going to use. I really favor 1) as it is much smaller in terms of network use, but 2) is much more precise. In the first case I'll need to create a 'window' of future movement calculations which can be thrown out when an absolute position arrives to smooth out the rubber banding. If an absolute position override comes in which is more recent than the future-predicted moves bases on previous position and velocity, I would throw out the future predictions and use the absolute position. In the second case I'll need to add in some player velocity calculations to smooth out the positions between server updates, measuring the time between each frame. Also impending is a change used to only broadcast the relevant objects. While my tests showed that an iPhone 3GS can handle 300 networked objects, this was using only a barebones amount of object data. I don't want to cause anyone's devices to catch on fire
Looks nice! Of course there are still many issues (wallwalking etc have already been mentioned), but the game itself already looks pretty neat. The world looks nic (for an iPhone game), but there were no other players online so I could not test the sword etc
whatever method you choose to use, its preferable not to send too many small package, since it will increase the overhead, but u propably already know that. Another model you might want to consider is the object- ghost object model(madeup name, not sure its officially called) in which objects are create on the server side, and reflect onto client using ghost object. It helps reduce client-server communication.
Right now I'm grouping objects into batches and sending them out, though I'd further like to optimize update frequency based on proximity to the player. I'm using a server/client ghosting model with a dummy client object which a real player object attaches to. The networking is using TCP so regular and frequent updates help to maintain a consistent behavior. I am leery of the overhead of all the packet headers needed by many small packets, so will look for more ways to pack the messages in without compromising CPU too much.
Last night was a very productive night. I got a lot closer to a functional movement prototype and did some great inroads into optimization too. I have incredible respect for engines like Source which do multiplayer so well. It is incredibly difficult to do this well and involves nothing short of time travel. This is a nice long weekend, so if it so happens that I get something ready to test, it will go up as a new test and we'll announce it.
For the most part yes. There will be a quality slider to eliminate some things like vegetation and to change the draw distance, but overall it will be the same.
When I tried the multiplayer test thing, can you pick up stuff? or go into houses? and is there anything to kill? thanks.
I just checked it out and it's working on all my machines here, perhaps you are behind a tight firewall? You should at least be able to get to the login screen...
My computer isn't strong enough to run this (2001 Compaq FTWi...Loss) but as soon as you get an iPod Touch version up and running... well...
Haven't heard anything for a while? How's the progress going? It any new art to show us? Tried to get on to test but no one is ever on when I get on.
I've been working hard on zone server technology and the network changes necessary to support a new movement style. I've made a lot of progress. I am happy to talk about it, it's sexy stuff to me, though it's not super cool spell effects or horse riding or anything like that. In fact, when it works, you won't even notice it But it's the glue that runs a net game, and an MMO needs special strategies. I'm developing some pretty complex algorithms to streamline client and server network updates. When a scene loads on the server side, it creates an object called SectorManager. This object has an AI on it that calculates the total scene boundaries based on static objects in the scene, and generates logical sectors inside it based on a sectorSize variable. This is the size of each sector inside a scene. These are then created as dummy objects and they each have their own AI on them called SceneSector. Each SceneSector is then told what it's neighbors are. The reason I do this now is to avoid doing any distance calculations for the player later on... the server will know which sectors the player is interested in based on the sector he is in currently. As objects move around, I use math to figure out which sector they are in. When they change sectors, the object signals the new and old sectors, as they maintain a list of all objects that are inside it. Next step: Thanks to this groundwork, I should be able to really streamline server processing by pulling up a sector, and for each user inside the sector, I will send it updates for objects in the current sector and its neighbors. No distance check required, which means a lot less processing in these critical code sections caused by the use of either a raycast or a distance check (usually uses Sqrt which is a very expensive function to use). Super sexy! I can also use this kind of a system to have another override to turn on/off object AIs enmass inside sectors which are far removed from any activity. Here's a screenshot of the SectorManager in action. http://www.screencast.com/users/daveyoung/folders/Jing/media/6823ee93-f5de-41fb-9d9d-45a6b7d98396 As a player moves around, he will only get updates for sectors around him. It's really sweet in theory, and should make MMO possible for us.
