Early on we decided that having a procedural world would provide us the best framework for crafting something on an MMO-scale within a year with only three people. Of course, being procedural brings upon many other problems, especially in a network game. Can you trust clients to generate the world for you? If no, then you server has a lot more work on its hands as it not only has to serve new landscape chunks to clients but generate new ones as players expand beyond the boundaries of the pre-generated world. Beyond the generation of the terrain comes the transport layer, or how the information will be passed on to the clients. Simply saving the terrain in a 3D file format, like an .obj, would be fairly expensive due to their relatively large size of such file formats. Even if compressed to "only" 400kb sending those files to a large number of clients would become a bottle neck real quick, requiring the server to have a lot of bandwidth.
Our solution to all these challenges? Images!
Continue reading "A world of images" »
In order to populate our world, the development tools and the client machines have to agree on which objects have which IDs. Additionally, we didn't want Ethan to have to keep bugging us to register objects in some global registry somewhere every time he wanted to add a new model to the game. As such, we came up with an architecture where the development tools can send an object up to the server, and clients can download it from the server when they need it.
Well, this week, I did a lot of work on the dev side of that process. And let me tell you, it was fun. And by fun, I mean it made me want to punch Unity right in the face.
Continue reading "Unity, AssetBundles, the WWW and You!" »
After the all the issues we had getting Unity to read our own dll and properly wrap our c++ code to c# we decided to use a "proven" solution, that of RakNet. RakNet is a library used by many games and other networking applications that comes with everything preconfigured to create a C# dll using a wrapper utility called Swig. There were even instructions for linking up this dll with Unity, so it seemed like the best option.
After several hours of debugging build errors, followed by linker errors, and reading all that Google had to offer on the subject we found one big flaw. No one, it seems, has ever gotten this dll to compile on a mac, which would leave us back where we started having a working dll only on windows. This isn't to fault RakNet; RakNet compiles just fine using the latest version of xcode, but Unity doesn't support dll's or bundle's that are created on current compilers (they're about 9 years behind in that respect).
As we stared at the lines of red which wouldn't go away it finally dawned on us; why not just use Mono's Socket library? After all, we didn't need the majority of RakNet's feature list, and we had originally been doing everything ourselves from the sockets with our original plugin. Three hours later we were able to get the client talking with the server using the correct endianness. Now we just have to make up for wasted time and start transferring images.
Networking is something that's great when it works, but can be really hard to debug. With a server running on a linux VM we've faced several challenges. The first being, how do you connect the VM and the host to the same network? Well, there's a connection mode in the VMware player, called Host-Only mode, which allows the VM to connect directly to the host. This seemed like the ideal option, but on Nate's windows computer the VM failed to ever get a packet through.
Next, when we tried in on my computer, the VM could talk to the host just fine, but since we haven't written the client dll to work on a mac yet, that didn't help us very much. Eventually we managed to connect Nate's computer to my VM, and then the real networking could begin.
Continue reading "The Trials of Networking" »
A lot has changed since my last post about realtime terrain generation, but good news first; It works!
What I had incorrectly blamed on the normals before was actually a problem of having incorrect faces. When you're missing half of your triangles there ends up being a lot of holes in your mesh.
This past week I made a terrain editor so our artist can easily produce nice looking terrain without having to guess and check using photoshop (which would be really hard). Many features have been implemented including multiple brushes, smoothing of terrain, painting onto the terrain, undo/redo history, and texture blending.
Future plans for the editor include connecting to the server so we can edit the generated game world, object loading and placing, and the ability to edit the border between two tiles.
Yesterday it was decided that generating world tiles in realtime based upon heightmaps would be an easier way of transmitting them over the network and would save us from the problems we were having with Unity's terrain objects not being able to rotate. So now, when a client loads a tile they will be loading three 128x128 images; a heightmap, a texture map, and an object map. The heightmap is used both for generating the tiles and as a lookup table used for physics checks to keep players on the ground. The texture map allows for Ethan to paint the terrain using 4 different textures blended together with each texture being represented by a different channel (r,g,b,a). The object map keeps track of the locations of buildings, resources, and environment objects in the tile.
Of course, while this solution in many ways makes the networking easier and provides us with a very expandable framework for adding new features it means a lot more work is required up front on the client. Now that the terrain needs to be generated on demand instead of merely loaded from a preexisting object we have to do a lot more calculation. It also turns out that the tricky part is not calculating the vertices, nor the uv coordinates, but rather calculating the normals for all the faces.
This is what happens when you don't have any normals:
When coming up with the idea for Broken World we wanted to make a big world that players would be able to explore for a very long time. Based upon that and the fact that we don't have the time or resources to make such a large world by hand we thought it a good idea to have a procedural world with the landscape being generated based upon a tile system where each tile takes about 2 minutes to traverse in game time (it actually takes 1 minute 40 seconds, but who's counting?). So, as it's currently coded (mind you we're in the very early stages of development), here's the relative size of our world:
Each tile is 500x500 game units in size.
To walk around the world in a straight line you would traverse 2^32 tiles before reaching your starting point.
That would take approximately 429,496,730,000 seconds to walk.
Which is about 7,158,278,830 minutes;
Which is about 119,304,647 hours;
Which is about 4,971,027 days;
Which is about 710,146 weeks;
Which is about 177,537 months;
Which is about 13,610 years... maybe we should narrow our scope a bit.
|