Its Time For Chat

Well now the networking system is in, the first thing I wanted to turn to my attention to is a chat system.

Before I began creating GUI design for chatting, I started thinking back to some Second Life features. The ability to take a snapshot of the current view, without any interface components cluttering up the shot. The snapshot would have to be taken at the exact moment after the world display had finished rendering, but before any GUI elements had begun rendering.

With this in mind, I decided I needed one main UI manager class to handle all child overlay components, such as menu bar, task bar, chat bar and whatever else comes up in the future, to keep things clean and easy to manage.

I created a design I am happy with for the task bar and chat bar and their relevant classes and I created the UiManager class.

I am currently working on these components. That is my update. :)

Another post to follow ...

The Network Is In ...

I have spent most of the day today working on the Globe servers and client integration.

Due to the need for the simulator server to run over UDP, some changes had to be made to the different servers roles. The login server now returns an asset server address and port as well as a simulator address and port on successful login. The simulator server currently only serves the time at 100ms intervals, but will shortly serve chat and avatar positions. The asset server is now responsible for returning asset keys which the simulator was previously responsible for, as well as the actual assets themselves in binary form.

Basic UDP is now implemented in the simulator and client, and I have added multithreading to the login client implementation for a smoother user experience.

The base of the networking code is now complete, and if I decide a more advanced UDP method is more appropriate in future, the simulator code is nicely separated and shouldn't be a problem to change.

I have changed the Globe system to work from domain names rather than IPs because this is a more flexible approach. I have set up temporary sub domains and configured my router to allow access to the servers from outside my network.

The next steps are slightly more fun, in creating the temporary avatars and chat functionality.

I have had an idea for the avatar design, so if I get time tomorrow I would like to have another go at that. The 3D company I contacted, turned out to be no good.

The client C++ project structure is shown below.

Below are the Simulator and Asset servers running in their console form.

I will post an update of my progress tomorrow ....

UDP is a different animal to TCP

This post is all about how Globe is going to work or is working from a networking perspective.

Firstly I'll explain a bit about TCP and UDP sockets.

TCP

Transmission Control Protocol is a connection based protocol, so the client makes a direct connection with the server, data is sent and received and when everything is complete the socket is disconnected.

UDP

User Datagram Protocol is a connectionless packet based protocol, so no connection between client and server is made, instead packets are created and sent across networks via routers. UDP is an unreliable protocol, as in there is no guarantee the data will arrive at its destination and in the same order it was sent. Because the protocol is connectionless, it has much less overhead and is far more efficient than TCP at transferring data.

UDP also comes with some interesting features that I am still in the process of researching.

Multicasting

A server creates a multicasting group, clients join the group which acts as an end point, the server sends streaming data once to the group and it is automatically duplicated and distributed to client group members as required by the network. There isn't a more efficient way to send data across a network than this, and recently BT has talked of plans to unveil HDTV over this kind of connection, which shows the kind of data transfer possible.

I am not sure of ISP support of multicasting or what is involved yet, so more to come on this when I find out.

Unicasting

Still researching this one.

Broadcasting

I have found with broadcasting, unlike multicasting, everyone in range of the server receives the packet, not just clients subscribed to a group. From what I have read this is only really useful in a LAN environment, so I won't be researching this any further.

As you know, there are 3 types of server to the Globe system.

Login Server

Asset Server

Simulator Server

All 3 servers were originally implemented with TCP sockets. The login and asset server will stay as TCP, but the simulator needs constant fast data transfer, so it is moving to UDP.

What flavour of UDP depends on my research.

The plan is to get the UDP implemented in the simulator server at the same time as the temporary box avatar, so that features can be developed such positioning of other nearby avatars and chat.

I looked at the Enet network library in a bit more detail and it seems they have devised a wrapper for UDP to guarantee delivery of packets in the right order, so this is still a strong contender. Again, needs more research.

I'll keep ya posted.

You could spend years learning that!

I have spent a couple of days working on character modelling in various 3D designers, including Poser 6, MilkShape 3D, Character FX, LithUnwrap and various other tools.

I know how to operate these tools and I can create basic models, but detailed, optimized and animated 3D characters is out of my league right now. I will continue to learn how to do it, but I think it is something that can take years to master, and I need avatars now.

My plan is to stop working with the 3D modellers and go back to the Globe code.

For now, an avatar will be represented by a human sized box, this way the project can still move forward whilst a solution is found to the avatar design problem.

I have contacted a 3D design company to enquire on costs of outsourcing the character design to them. I have a feeling it will be out of my price range, but its worth a try.

I have a couple of other ideas up my sleeve. I'll keep you posted.

Terrain, Bones and Avatars

Here I am again, it has been a few days since my last post and although I have still been working on Globe, not as much code has been written as in previous posts.

After my last update we had a skybox being rendered, some basic UI elements and asset and simulator server connectivity and data transfer.

My next step was to improve some of the the features I had already created, such as the camera controls. I came up with a mouse collision detection algorithm which provided pixel perfect mouse click collision detection with the control buttons. This was harder than it sounds because the buttons are a kind of cone shape. I also improved the camera rotation and positioning based on input from the camera control.

I improved the simulator server process, so it stays connected and constantly pumps data across, but having done a bit more research I will be switching this from TCP to UDP for performance reasons and broadcast features, so the code will need to change again. At this point I am thinking I will do this with native C socket functions, but I am also considering ENet which is a UDP networking library. http://enet.bespin.org/index.html

I added a terrain table to SQL and some data layer classes and wrote the code required for the simulator to serve the terrain data. The terrain requires 3 images to work. The heightmap, which defines the height of each face on the land. The terrain texture which is stretched over the entire landscape. The detail map, which is repeated many times over the landscape to create the effect of surface texture. So now terrain is being rendered.

As really the whole experience of a virtual world is based around the users avatar, I decided this was the next stop, the notorious time consuming character modelling and animation and the reason less code has been written this time around.

The Irrlicht 3D engine I am using for this project can handle 2 types of character animation, Morph Target and Skeletal animation. As we want maximum flexibility in allowing users to upload their own animations, this rules out Morph Target animation, we have to go down the skeletal route, so that animations can be applied to the bones instead of needing to rework the entire model for each individual animation. Irrlicht natively supports 3 skeletal animation file formats, .ms3d (Milkshape 3D), .b3d (Blitz 3D) and .x (DirectX).

I decided to go with Milkshape 3D files as the software is relatively inexpensive and easy to use and is packed with features.

http://chumbalum.swissquake.ch/

So I set off on my mission of learning to model in MilkShape. I created several models to learn the interface and ways of doing things. I have used 3D Studio Max quite a bit, so that helped me pick it up quickly. When I was sure I had got to grips with it, I started creating a male human character. I hit a few problems with disconnected vertices and broken texture mapping, but by version 4 I had a nice looking nearly finished male avatar.

Tonight I plan to do the finishing touches on the male avatar model, and texture him with a default skin. The next steps will be to create a skeleton for him and a basic stand and walk animation.

When I have an avatar model ready, I will concentrate on creating the code necessary to serve it from the servers and render and control it in-world, and then simulator UDP networking support for other avatar positions and chat.

I'll post an update soon ...

We have a world!

I haven't blogged in a few days because of the sickness, but I have made some more progress on the Globe system, so here goes ...

At the end of my last post I had the Simulator server in a state where it could be connected to, it would return information about the skybox, and an IP and port of its primary asset server. The asset server was in a state where it could serve textures across TCP.

No socket code was implemented in the client at that point to support any of this.

Present day ...

The client can now login, display a loading screen whilst it connects to the Simulator, gets the initialization data, checks which assets it already has in its cache, and downloads any missing textures etc. from the asset server. When its happy it has everything it needs to start, the loading screen disappears and it renders the skybox that has just come from the servers and some basic GUI.

But what a journey it was to get there, I have hit some really nasty problems along the way. Read on ...

My first hurdle was threading. My implementation of the sockets code was not asynchronous, so the animation on the loading screen would stop whilst everything loaded. Not good. As a C# developer I would think, no problem, the Thread class can sort that out. But in C++ things are not quite so straight forward.

As I read through forum post upon forum post, it became more obvious that threading is not supported in C++. It is only possible through functionality in old C libraries. ... Gulp.

I eventually came across this great article by Arun N Kumar, which solved the problem.

http://www.codeguru.com/cpp/misc/misc/threadsprocesses/article.php/c3793/

The class he has developed there wraps the C functionality into an inheritable C++ class. Using his code as guidance I successfully created a C++ thread class for use in the Globe client.

Perfect, so now we have threaded sockets in the client application, I could pass a login token into the thread and it would go off and connect to its servers asynchronously allowing the loading animations to carry on doing their thing.

Next I need to get data returned from the servers out of the threads in its object form, which could be a few different class types, but I am already using the thread argument as a pointer to the login token and accessing class members from inside the thread produces access violations.

This was a hard one. After about 12 hours I found a solution.

• I created a 4k (void*) buffer in memory before the thread was called.
• The login token is serialized into that buffer, with a 4 byte DWORD value indicating the size of the class it contains, and then the thread is started.
• The pointer to the buffer is passed into the thread as the argument.
• The thread carries out its tasks, and loads data into the buffer, along with its class size.
• The main thread checks the buffer to see what type of data it has based on its size.
• When the size matching the correct class is found it knows the data is ready and retrieves it.

The next problem I came across was that the textures the asset server was sending were becoming corrupt when they arrived in the client cache. I checked everything I could think of, the files were being written as binary, the data was coming across correctly.

I eventually opened the downloaded JPG in a hex editor, and compared the original. I realized the downloaded one had no zeros in it, they had been stripped at some point in the process. On closer inspection of the code, the client was loading the file into a irr::core::stringc object before it was saved, this was the cause. I loaded it into a standard buffer and it started working fine.

Great free hex editor.

http://www.hhdsoftware.com/Products/home/hex-editor-free.html

These were the main problems I hit, there has been times I have had to walk away from the screen because I find myself getting nowhere. Its always good to take a break when you think you have hit a problem you will never solve. Everything is solvable. Sometimes you can save hours of pain with a 30 minute break.

After getting over the nightmare communicating asynchronously with the servers, I quickly implemented a skybox based on the data we have received and started to render it.

The next thing was to create some way of the user controlling the camera. In Second Life, there is a nice camera control, a small widget that sits usually at the top of the screen allowing you to rotate and move the camera around (known as caming in-world). It's a UI element, that takes a small amount of getting used to, but people become familiar with it, so I decided to create something similar.

I created a nice menu system, similar to the standard Windows one, but of course much better looking. :) The main headers at present are File, Edit, Window. File contains Upload and Exit, Edit contains Preferences and Window contains Camera Control. The system is very scalable to allow new menus and items to easily be added. I plan to add a server authenticated Admin menu in the near future.

You can now move the camera around with the Camera Control, but the positioning algorithm is not yet perfect, I am now working on that.

So .... essentially, Globe's first sim exists, so we have a virtual world!

Solution Architecture

Well, here I am again. I have been diagnosed with swine flu (thought it was bad flu), so in between the need to go and lay down, I have some time on my hands. Constant doses of paracetamol are keeping me going. Don't worry, you can't catch it through the internet, carry on reading ...

Since my last post I have stopped development on the C# XNA Globe client project because I found the Irrlicht 3D engine to be more powerful, faster and equally productive to work with. The client is now a native unmanaged C++ application, capable of running under OpenGL (default), DirectX or a software renderer. With minor development, this solution also allows Linux and Mac versions to be compiled from the same code base.

Although the client application is now C++, this is the only C++ application in the solution, the remaining 13 projects in the solution, which consist of various servers, data layer and windows services and console applications are all managed C# libraries or applications.

The servers all consist of 3 projects each, a class library containing all the functionality, a windows service host application, and a console application host application, the 2 different host applications are a by product of the hardships of debugging deployed windows services.

Below is a view from solution explorer showing the Globe project as it currently stands and an explanation of what each of the projects is responsible for doing.

TheGlobe.AssetServer

This is a C# class library containing all the functionality that the asset server needs, it contains all the threading and TCP code. The asset server is responsible for sending data such as textures and other media to the client.

This namespace also contains Console and Service host application projects. C# console applications are far easier than windows services to debug, but windows services are better in a production environment, so I am mixing the two.

TheGlobe.Client

The famous Globe client! (well here its famous) It is a native unmanaged C++ application using the Irrlicht 3D engine. The code in this project compiles and executes completely independently of any other projects in the solution, but obviously needs those servers to be running remotely in order to operate.

The new C++ version of the client project is now more advanced than the C# XNA version, so that has been removed and dropped into an obsolete folder.

TheGlobe.Data

This is a combined business and data layer project for all the servers, it is a C# class library containing Linq2Sql classes generated from the Globe database. All reads from the data store are carried out using fast compiled queries and contains its own set of strongly typed data objects for consumption by the servers.

TheGlobe.LoginServer

This is another server, following the same architecture as the Asset Server. The Login Server is responsible for the initial client authentication, and on successful login will provide a login token to the client for future interaction with other Globe servers.

TheGlobe.SimulatorServer

The Simulator is responsible for enforcing and tracking user positions, server side collision detection, chat and generally everything except media such as sound, animations, images etc.

The remaining projects in the solution are just setup wizards for deploying the windows service versions of the servers.

I hope that gives you a better understanding of the Globe Project!

I have now got the asset server and simulator to a stage where it can serve a skybox, so my next development stop will be back on the Client to create C++ connection managers, similar to the login one, to communicate with the servers.

When I have Skybox, Terrain and Water - you get a screen shot :)

Globe moves to C++

I spent an hour playing with the Irrlicht 3D engine in C++ and it looks like this is the way I will be going.

In an hour I have recreated most of the login screen, the library handles loading of images and just about everything else you could ever need.

The application will run in OpenGL by default, although it will be switchable to DirectX9 or a software renderer if required. Using the OpenGL renderer, the Globe login screen renders around 50 times faster than using XNA with C#.

This solution will also make the client application cross platform on Windows, Linux and OSX.

Where do we go from here?

The client sockets code I was planning on implementing is now complete and fully working, this just connects to a remote server, authenticates the user and returns their connection token, the name of the region they are currently in, and an IP address and port of the simulator they were last connected to.

I have added validation to the login boxes on the Globe client, so that a name and password has to be entered before the system will attempt login. I improved the text boxes a bit by widening the possible characters it can contain.

At this point I was dying to get my teeth into some 3D programming, so decided to make an XNA content pipeline extension to generate skyboxes. With some tinkering this started working very nicely.

So now, the process as it stands - You execute the client application and are presented with the login screen, you enter your Globe name and password and the system makes an authentication request to a TCP login server. If successful, the login screen disappears and the skybox (only) is shown.

This is all very good, I have made great progress in just a couple of days, but a comment Artiom posted a couple of posts ago would not leave my head. "Why not use OpenGL?"

Is the best solution to use XNA? or DirectX? or OpenGL? I did some research.

OpenGL looks like a great option, many operating systems support it to varying degrees, it is open standards, faster rendering, but it is a low level C library and although several C# wrapper libraries exist for it, Ideally any application written for OpenGL would be C++ or you would be killing the cross platform compatibility.

XNA looked like a great option when I started, but as I go further into it, I find it can be quite restrictive. For example, key states can be checked easily, but there is no easy way to tell which character should appear in a textbox from the key press. It has good networking support.

I originally planned to make the application XBox compatible, through the use of the XNA framework, but I have hit a show stopper there. All XBox game content must be precompiled up front, and this kind of contradicts the concept of content streaming from asset servers. It is not possible to consume user generated content on an Xbox. So XNA in this case will only support Windows.

In an effort to investigate the latest DirectX offering, I downloaded DirectX 11 SDK. I created a couple of small applications both just to initialize a DirectX device. One in managed C# and one in unmanaged C++. The C# application felt like a hack to be honest, trying to render a Direct3D device on a .net form felt wrong. Also all the DirectX code samples all the way back to version 9 are in C++. There are some awesome new effects in DirectX 11, such as deferred particles which give an effect of rubble as a building falls down. Very nice indeed. The problem with that is over half of Windows users still use Windows XP, so the application wouldn't work for them.

My feeling at this point is to investigate OpenGL in C++ further as this will give maximum exposure to a wide range of platforms including Windows, Linux, MacOSX and Wii.

Please comment - I need your help ! :)

.........................

[Edit] 3 Hours later ....

I successfully linked an OpenGL C++ project that creates a window and a device and spins a triangle around on the screen.

OpenGL seems awesome and I would definitely go down this road if I had more experience in using OpenGL, but I have never used it before, so development time would increase while I learned the pit falls, and a lot more work would be needed in other areas. For example loading an image file is no easy task with C++.

Some alternative options would be:

Use DirectX 9 which is a bit older now, but is in Windows XP.

So that would allow basically all Windows users to run the application.

Use the Irrlicht 3D engine with C++, as this can run using DirectX, OpenGL or software drivers.

The engine also contains functionality for loading content and a lot more.

http://irrlicht.sourceforge.net/

For now, I am going to stick with the XNA framework.

.........................

[Edit] 10 Minutes later ....

I once did a project with Irrlicht and it was very easy to use.

The engine is also cross platform, and open source so it deserves investigation.

Next stop Irrlicht 3D engine prototype Globe Client application.

Wish me luck !

Solution Now

Globe Authentication and Networking

This is my 2nd blog post and although not much progress has happened over the last couple of days due to me having some kind of flu, there has been progress since my last post, so heres the story so far.

The initial design for the login system was ready, it consisted of plans to create a Visual Studio 2008 solution containing a client XNA project, a data layer project for communication with SQL, a database relevant to user login, and a web service project for the XNA client to authenicate with.

The first problem I hit which I hadn't considered, was that although I have created some branding design and screen wireframes, I had assumed XNA would contain some kind of standard UI elements. I seemed to remember a long time ago using DirectX libraries for something and was sure that had UI elements built in. XNA does not.

So, first stop we need to create a UI system to enable users to enter text and all the other usual windows things like buttons.

I created a new class library project called TheGlobe.UI, this project contains an interface called IXnaControl which defines a base control that all other controls inherit. In the root namespace there is a class called UIManager which is responsible for rendering and overall control of all UI elements. I then created XnaTextbox and XnaButton classes which inherit from IXnaControl.

The result was a very nice object orientated self contained UI library, which works very well and is very easy to implement in XNA projects.

Ok, so with that huge show stopper out of the way I created a basic login screen in the client XNA project. The screen just shows the logo in the top left and has a sliding glowing panel at the bottom which moves up and down when clicked and contains some textboxes and a button for logging in.

I created the database and the login relevant tables, the data layer methods i needed for the login process and the authentication web service.

Then I hit big problem number 2.
An XNA project cannot reference web services.

The path I chose around this problem, was to scrap the web service, and create a custom multi-threaded TCP server. I decided to implement most of the functionality in a seperate class library, so that it can be consumed easily by a console application or windows service. So I added TheGlobe.LoginServer class library and TheGlobe.LoginServer.Console host application.

We are now up to present time.

My next steps are going to be implementing some basic client socket code into the XNA project, so it can communicate with the new TCP login server. Then test connectivity.

The overall goal of this stage is to keep everything as simple as possible, whilst allowing the user to login to the world. Then I can move onto actually loading terrain and skyboxes etc.

Please leave your comments and thoughts.

Developer Monkey.

Globe is born!

Welcome to the Globe development blog!

Globe is a virtual world system at the beginning of it's project lifecycle, inspired by Linden Labs Second life.

SL has become infamous for bugs and quirks and because there is no other option, these issues have become accepted by the SL community.

The intention of Globe is to remove many of these issues from the user experience as well as improve on features to allow the virtual space to be as useable, flexible, robust and as intuative to use as possible, by leveraging the power of technologies such as the .net framework.

The project is currently in the design phase, no code has yet been written. Development will be exclusively in C Sharp and will employ the XNA framework to simplify much of the 3D programming, as well as allow XBox compatibility. No Linux or Mac OSX versions are presently planned.

Development will be approached in an agile manner with small segmented goals, allowing the project to be developed 'bottom up' to ease the design phase and allow the project to change direction easily if it is required.

The first phase of the project will concentrate on creating the login system. This will involve work on both client and server components of the system, including design, code and branding.

I will be documenting the entire development process right here, follow this blog to keep up to date with progress.

Don't forget to comment! I want to hear your thoughts, good or bad.

Developer Monkey.