LandscapeConcept_wip.png

PlayerConcept.png

Shack.png

City concept.png

Tent.png

Shed.png

landscape1.png

landscape2.png

landscape3.png

landscape4.png

Male_Base_Mesh.png

Female_Base_Mesh.png

Male_idle.png

Male_walk.png

Male_run.png

tree1.png

tree2.png

well.png

mailbox.png

messageboard.png

stonehouse.png

Workshop.png

forge.png

tincan.png

book.png

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:

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.

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.

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.

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.