Networking Part 3

Well, I've been coding away and trying to get a combined client/server GUI that can act as both a server or a client. When I set myself a goal I always achieve it and this is no exception. Below is a picture of the GUI so far.


The GUI can perform these actions so far:

- Detect Incoming Client Connection
- Detect Client Disconnection
- Simple Chat (between multiple clients)
- Disconnect all clients when the server goes down and provide an appropriate message.
- Trigger an event (This needs to be extended upon to fit in with the actual game engine)

Now, in the picture you might be able to see that when the Server's connection is terminated, the client is terminated afterwards. This is because when a host (player) starts up the server they then join their server as a client at the same time. Why? Because the server is only setup to deal with incoming clients and sending to and receiving data from clients. By trying to implement the client functionalities into the server I came across complications with sending the incoming data back out to the other clients. Hmmm its hard to explain the problem I was having because its very complex when your working with threads. If I think of a good way to break it down and explain it I'll write it up on here.


So far I feel like I have achieved a lot, and learnt a lot more about networking and Java sockets. I'm feeling confident in my ability to pull this off, only time will tell though.

Networking Part 2

Ahhh so I've been putting together a client and server GUI so I can test out my code, below is what I've got so far.

This is the client GUI I have been using to test the server. I can successfully connect to the server and use it to send a message to server, but I've been getting a lot of mixed results. When I send a message across to the server, it can end up printing it out more than one, and it doesn't return anything back to the client either. I am going to have to delve deeper into the code and look a little harder at just exactly what is going on between the server and client, I'll probably end up making a total mess of the code and put in a whole bunch of println and error messages everywhere so I can debug the thing, but hey, thats how I figure out how things work.

Moving on, I had a bit of a revolution about how everything works and just so I made sure I knew what was going on instantly started to put pen to paper and write down what I thought was going on. I really didn't trust myself to remember it if I came back to it later, but as I was writing it down it all seemed to make sense, this can only be a good thing. I tried to draw up a diagram to also better illustrate how it works but I think it needs more work, you can check it out below.



I don't know if its readable on this site (probably not) but what its trying to explain is that each computer, weather it be a player or the host, all have the server interface and three other modules that make it up (Input Handler, Server Connection Manager, Client Connection Manager). The naming of these modules might be a little bit off, but its the best I can come up with at the moment, below ill explain what each one does in a little more detail.

Input Handler - The input handler is designed to retrieve all the incoming packets from clients and redistribute that information back out to the other clients. It keeps a list of all the currently connected clients and stores their information about their connection so the server can communicate with the client. Eventually we would like to have it handle the events that occur during gameplay.

Server Connection Manager - This manager starts the server socket accepting incoming connections and for each connection made a new Input Handler is assigned to that client. The server socket will continue to accept new connections until either the game is started or the host disconnects.

Client Connection Manager - This manager is setup to detect incoming events or chat from the server and deal with it appropriately.

All of these classes run on their own thread, which means that the actual gameplay will be smooth and uninterrupted by the network.

Networking

So I've moved on to the networking side of Java now, I haven't done much with sockets and networking in any language before so this is all pretty new, though I do understand how the internet works. I started reading some information about sockets in one of the many e-books I got recently, what I've read so far is but isn't that helpful most of what I'm reading is about threading and input/output streams for sockets. What I've gathered so far, is if you create a socket that successfully connects to a server it sets up a dedicated link between the computers and any information/packets sent between them use TCP/IP which is a reliable way of communication. TCP was layered on top of IP to give each end of a connection the ability to acknowledge receipt of IP packets and request retransmission of lost or corrupted packets. Furthermore, TCP allows the packets to be put back together on the receiving end in the same order they were sent.

Some of the books I've been looking at include:

Java Network Programming, 3rd Edition - By Elliotte Rusty Harold
Java Network Programming, 2nd Edition - By Elliotte Rusty Harold


I also did some Google searches to get more of a basic tutorial on how to build a client/server network setup, some of the sites I notably bookmarked are below.

Writing Server Side Sockets
Reading and Writing to a Socket
Socket Programming
Multithreaded Chat System

Looking at the article "Mutlithreaded Chat System" it looked to have all of the characteristics I am looking for in developing this network. So I compiled and ran the code to get a better understanding of how it works. I discovered that for each connection made to the server, it starts a new thread that handles all the input coming from a client and then distributes the input back out to the rest of the clients. That example doesn't actually have any client, it gets the user to use telnet instead, so this means I'll have to write up the code for the GUI. Writing the client side is a good thing anyway, it means I get to play with the code and really start to understand it.

I'll post more soon.

Explosions!

Alright, now that I have a vector at least traveling towards the mouse and reaching some sort of relative distance away from the center, ill start writing up the part were the missile explodes. This should be pretty easy, ill just write up a function that draws a circle based on a radius and then every time the explosion is rendered it parses a larger radius in.

Done. As expected it was pretty fast to code up, I added a new explosion object and set it to render when the vector reached its distance. Below is a screenshot of a bunch of vectors moving out to their destination and some explosions already going off.


I've palmed off what I've done so far to Pete now, he is going to fix the vector/laser class so that they travel the correct distance and probably try and work on some collision detection. Pete is the one that has a better understanding of the math behind everything were doing, I'm more or less just coding up the graphics and things to look nice. I don't know were to go from here, so I guess ill look into the networking side of things, I don't want to spend to much time thinking about what I should do next when their is so much to do overall.

I win.

I've been working hard at solving this damned trigonometry problem thats been troubling me so much, just the other day Pete put together a simple 2D Swing Java app that followed the mouse around the screen and output the angle, it is what I was looking for, but the method he used is a LOT different to how I've got it working in OpenGL and the coordinate system. (Below is Pete's Example).



But sure enough, using a combination of both of our code I finally got it working as expect! Now I've got the vector following the mouse around the screen and pointing in the right direction, another hurdle down, I'm sure their will be a lot more hurdles to come, but hey, thats what studio's is all about isn't it? Learning new things and pushing boundaries?

How did I do it? Well it was actually pretty simple, as I suggested it would be in a previous blog. I had been trying this type of algorithm for a while but just wasn't getting anywhere with it until I picked some bits and pieces out of Pete's code (Look below for the code).


public void mouseMoved(MouseEvent e) {
double deltaX = e.getX() - 250.0;
double deltaY = (500 - e.getY()) - 250.0;
v.x = deltaX;
v.y = deltaY;
}

Whats happening is when the mouse is moved across the screen, its retrieving the X and Y position of the mouse and subtracting the start position (250.0) which is in the center of the screen. Then the vectors X and Y is set to the delta X and Y to give it its direction.








zzzzzz

Wednesday....

On Wednesday Pete and I started dissecting the game into classes, so we could possibly start putting together a class diagram, and a get a better picture of the structure the game will take. Because the game is supposed to be extensible, and available for other developers to use the engine to create their own games, we need to modulate everything well enough so the developers can just pick and choose objects they want in the game, with the least amount of actual technical coding like OpenGL (a lot of developers might not be able to understand or use OpenGL, so by having our engine handle all of that is definitely the way to go).

The notes Pete and I took down include:

Indestructible Objects
- Modal Object
- Background
- Moving Objects (Bullets, Lasers, etc)

Types of Physics
- Gravity
- Wind
- etc

A utility class/package | This package will contain a lot of the utilities a developer might make use of to help build their own game.
- Vector class
- Rectangle class
- Sphere class
- etc

Bounding Boxes (for collision detection) | If we have enough time, it would be a good idea to make this up, that way it wont have to be hard coded.
- Editor or Tool to build bounding boxes for different shapes or objects.

Networking
- Player feedback (Doom / Duke Nukem Faces to represent the status/health of your opponent.
- Measure of other players progress
- Winning Conditions
- Events
- Simple chat binds (example: Hello, LOL Take that!, etc)

Profile
- Name
- Statistics | Things like, how many times you have won, what level you reach, averages, etc
- Handicap | This is made up of your statistics and make it a little more even when playing against opponents who might not be very good.
- Chat Bindings

Input
- Keyboard (KeyListener)
- Mouse (MouseListener, MouseMotionListener)
- Joystick ?
- Gamepad ?

Well, most of this information was set in our proposal, but some of these things weren't like in the Networking part having a Player feedback that makes use of a face icon is a pretty cool idea, even though it has been done before, players should be able to instantly recognise this and its purpose, if not we can provide some sort of tutorial in some documentation.

So next week our proposal should have been marked, I hope all the printing problems we had don't effect the overall mark. I'm also a little worried about Pete's grammar and writing since I didn't have enough time to read over it all, and I'm not sure if Pete did a lot of proof reading. But he did write a lot of filler, I think I might have to work on my writing skills more.

I think the progress I've made so far, is pretty good. I am trying to get back into the swing of coding and OpenGL more importantly (which isn't an easy task) after four months of being off and not doing any coding over that time it sure does make it hard. The more coding I do, the more it comes flooding back, so I will just persist.

Grrrr Trigonometry

I did Trigonometry while I was in high school, and I actually did pretty well at it. But its been such a long time since I've used it that I cannot remember anything! I've been trying to get a vector to follow the mouse around the screen, and just keep hitting a brick wall. I've talked to Pete over the past week and he's been trying to help me with the problem providing a few equations and what not, but everything I try just doesn't seem to be working right.

I've tried these equations that Pete gave me:

tanӨ = o / a
Ө = artan( o / a)
Ө = artan( Y2 - Y1 / X2 - X1)

These equations are telling me what the angle is, but I'm not sure if that's exactly what I am trying to achieve here. I keep getting the vector pointing in the wrong direction, when I would move the mouse to different corners of the screen (for example, if i put it in the top right corner the vector would point 90 degrees to the right, and top left corner would result in the vector point 90 degrees to the north). This is getting frustrating now, because I've spent a while trying to solve this problem that is probably really really easy.

The whole point of getting the vector to follow mouse, is so that we can make a start on making our first game (Missile Command), which requires a missle/bullet to move to were the player is pointing.

Now the reason I think I've been getting skewed results is because of the mouse coordinates that Java has been giving me in comparison to the actual coordinate system in OpenGL. I did a test to find out if the coordinate system was actually working as intended (0, 0 at the bottom left), to determine this I set the vector to start at 0,0 and point out at a 45 degree angle towards the center, this proved that coordinates are setup right. Since OpenGL is working as expected, I did a mouse test to determine what sort of values it was giving in relation to how it should be setup. I am confident it is the mouse coordinates that are causing the problem because when I move the mouse to the bottom of the screen it gives me a Y value of 500, which means its reversed. Hmmmmmmmm I should be able to reverse it so it works with the OGL coordinates by using this simple equation.

Y = 500 - mouseY

oo