Weekly update week 4

This week I’ve been doing several things, but the most difficult task in my eyes was to do a slight rewrite of another persons class. It’s not that the code that I had to rewrite was bad from the start, it’s just that it was writtenwith singleplayer in mind and we’re doing a multiplayer game where the server is doing all the calculations. This task was about getting the Commander to work, which is the last piece of the puzzle so to speak.

Commander – The missing link

The first thing I did was to look at the code that our other programmer had written, asked him a lot of questions what the different parts did, because in order to change something you need to understand what is going on, where it is doing something and how it is all connected, because if there is one thing I’ve learned when it comes to Unity is that without a proper overview of the code and where you’re going with the code (it is generically so, but in Unity it turns uglier quicker) you get lost very quickly. It’s easy to attach a piece of code to a game object, but if you don’t know that it is attached to a game object or it is attached to a different game object and you need to look into that object in order to know what’s going on.

In any case after some research into that code, looking at the tutorial the other coder was looking at, the picture of what was doing what became clearer. I decided to fix some of the issues that were bothering me however before implementing the multiplayer part, so I added functionality so that you can cancel the building. By that I mean that if you clicked on the key that gave you a tower, you had to place the tower before you could do something else. I fixed that by removing the temporary object that was created and easily enough you could cancel the building by rightclicking. Second thing I fixed was that you couldn’t drag the building outside your building zone. If you wanted to drag it outside it would stop where the border to the “legal” and “illegal” placement location.

Network – instantiate

The last bit of the coding process of the commander was to have it instantiating the building across the network. What is really nice about Unity, and I believe I’ve written this before, is that the networking functionality is really easy to accomplish. However since the server is what controls everything I needed to make it so that the client triggers an RPC call to the server. The server then makes an instance of the prefab on all the other clients. Now technically, thinking about it in retrospect I should have done it a little bit different, however I still need to work on this on Monday, because even though we have a version where the commander works, I need to implement a way for him to toss out healing to the players and also give buffs to the champions. But we do have a playable version now even if it is a bit sketchy and not really working as we want the game to work.

To show some kind of progress here’s some screenshots of how the game looks. The circles were buff circles that I created just to have something that shows on the screen visually so that we know which area is affected.

Next week

Next week is going to be a crunching week. The official Alpha is next Friday, now that is all fine and dandy, but what we need to do is to get the programmers together and get some kind of unity in how we are going about our code. In the beginning we just started coding because we wanted results fairly quickly, which we got after two weeks. Then all of a sudden it’s like the programming tasks have come to almost a full stop. I know we are programming, but it seems to be going so much slower now. I know it is because in the beginning almost everything we did was progress and now we are modifying the code that others have done to fit with future features etc etc. However we have lost some momentum because we are 3 different types of coders, with different ways of working. In the beginning this didn’t seem to be a problem, but now it seems to be a problem because we have code that is meant to be used for something, but are used for other things. We have created the same types of scripts to be used for different things etc. The reason for writing this isn’t to say that we are having major issues, but rather that this is a situation that we should have avoided and since I’m the lead programmer I should have in retrospect taken the time to set up a plan for how it should look. So that’s a tip for those who are interested, even though it is only a 10 week project, take a couple of days to come up with a workable plan, we all know plans change, but at least give some thought into the structure and have people code after that structure. It saves you time in the end, because then everyone knows which classes you have and what they are intended for.

Week 3 – UnityNetwork again

This week I made a revelation when it comes to network programming. Turns out it’s really really easy. Actually the revelation part happened on Saturday, so I had to set myself down and do some programming, so during the weekend I made a starting menu where we can select to start a server or connect as a client. As you can see in the screenshot below:

So the whole idea was that you have one dedicated server and then you have the rest of the players connecting as a player. So when you’re starting a server you’re asked for a name for the server and then ports to listen to. This is all really straight forward, basically the server just listens and once you have a player asking for permission to connect to that particular port, they are let in. Right now there’s no authorization, which is something that we might want to do later, also we might to make the server a standalone version so that you have one that you can start as a server and select port and you’re up and running. That however is something for later, right now we just want to have the game up so we can have an alpha that we can play.

Anyway after you connect you can select a role and if someone has selected that role the server let’s the client know it is taken by deactivating the button on the client side. Like the screenshot below shows (might have to click it to see):

“Coding”

So now down to the nitty gritty of the code and it turns out it’s not too difficult to get the network working as it should. Now there’s a lot of code behind the scenes that you don’t see, even as a programmer, now of course you can go deeper into the material, but right now we have decided not to write our own packets etc. It’s not that it is a problem, it’s just that it is more convenient to just let Unity handle all that stuff itself.

The first thing that you need is a gameobject with an attached networkview. Networkview allows you to call remote procedure calls, which basically are remote methods / functions. How you do it however is a bit weird, especially for me which is more used to c++ than c#. Another thing, we used uLink, but the basics are the same as with the unity’s own networkview. Anyway that networkview is attached to the gameobject you want to modify, but it needs to be on both the server and client, because think of it like a post office, you deliver the packet to the office, but although you have an address you don’t have a name or a box where it belongs to unless you have it attached to a gameobject. So that’s the first “rule”, gameobject with a networkview that resides on both sides, so you have your pitcher and catcher ready.

The next thing is inside the script, now this is what I had problems with, because let’s say you have a script on the server which calculates the movement of the character. In our case we have the server just take input from the clients, the movement then happens on the server, the movement is then sent back to all clients – even the owner. So let’s take that example with some pseudo code:

The client clicks the mousebutton on a coordinate.

The client sends that position to the server via a networkview call. And the weird thing is that you do that via:
Networkview.RPC(“SendMyMouseClick”, RPCMode.Server, somelocation); // somelocation is a Vector3

The server has then a keyword called RPC like this:
[RPC]
void SendMyMouseClick(Vector3 p_ClickedPosition){
vector3OnServerThatYouWantToChange = p_ClickedPosition;
handle the data here or use methods here;
}

The server then has a way to tell the clients where the clients avatar should be going.
networkview.RPC(“YourClientNeedsToMoveHere”, RPCMode.OthersBuffered, arguments to send back (normally vector3 for position and a Quaternion for rotation, maybe even an animation state)

The client then catches that also via a “tag”:
[RPC]
void YourClientNeedsToMoveHere(the arguments needs to match the senders arguments){
change what you want here. Update whatever. Just know that this is the client and not the server.
}

In any case that is in reality all there is to it, now I believe (not been able to test this yet) that you can seperate the code, just that it needs to be attached to the same gameobject. That said we have so far not done this, so we have both server and client code into the same file, but we separate the code with comments, so I don’t know if it will work, something that we want to test at a later point, I see no reason for it not working however.

In any case, hopefully we’ll have the first Alpha ready tomorrow, we have most of the code for it to work done. We’re just missing the network code on the commander, we’re missing a little bit of code to get the commander working right and we also need to make a GUI so that you can actually build stuff.

The rest of the week I’ve actually spent getting the players to update, getting the creeps to update on all clients along with the towers that we have placed out. So we have most of the networking code in the game right now, which has been my focus for this week. Once I figured out how it had to work it wasn’t that hard and I see now that coding in c# which also was a little challenge turns out to be reasonably simple compared to c++.

 

Network – >.<

Network is both fun and frustrating. This week I continued working with the networking code, the problem however is that it is going slow. You need go about coding in a bit different way than you do when  you code otherwise. Because when you code for singleplayer you don’t have to take into consideration what happens to the object when other people see it. In a network however you need to send the location of your player to the others, but at the same time enable the code to be able to get the movement input from the other players as well.

That I can tell you is a pain to get right. I’m not completely there when it comes to wrapping my head around how to fix this, but I’m slowly getting there. Right now we have a way to update the players position on the other clients, the next thing we need to do is to synchronize the creeps which we call soldiers with the other clients, that means we need to implement a way that only one player is setting the positions of the creeps and updates whether or not they are alive. This is however the problem, the code needs to be reachable by all clients, so they need to know that a creep have spawned, where it spawned, what team it belongs to, how much hp it has and what its current action is.

Sounds simple when it is put it like that, however getting all that into a script, that we already have made is not that easy. Firstly I wasn’t the one that wrote the original code, so I need to first look into the code, understand what happens, then rewrite the whole thing so that the script that spawns creep only gets called once, so that the game objects that represents the creeps is spawned locally but are controlled from the host. This needs to be done for every single object on the playing field. Right now that is what happens with the players, so that the players can see each other.

At least I got that to work at last, we had the weirdest bug that made 1 player see the other and see all movements, but when another player connected and selected a different team, they couldn’t see anyone else than the players belonging to their team. The other team could still see everyone. That said, I solved the bug at last, simply just one integer that was different, once I put the integer to the same for both teams, it worked fine.

In anycase, here’s what the client and “server” looks like at the moment, graphics are just placeholders right now, so it doesn’t look good, but at least we have something that is somewhat playable.

 

I say “server” because right now the server actually shows what is on the screen, reason for it being blue is that while connecting the clients the camera scrolled into something that doesn’t contain anything and it gets blue. The little disconnect window is the server window.

In any case, the work goes forward, although slowly, but we’re getting there. Next week I’ll get some help with the networking, which I need, that said, we also need to set up a plan on how we want the game to work. As I see it, we should maybe make connection and server boxes in a different scene, so that we need to load a new scene then wait a little bit before the game starts so that all clients have a chance to load the game before it begins.

First week

This week I’ve been looking at how we can get the networking to work and started working on a start menu so that we can get the different clients to connect to eachother. To test this and to get that to work I started working on a chat room. Right now it’s just a basic chat room so that everyone can talk to each other. It now works, it doesn’t look that good however but it’s just a temporary interface.

 

As you can see I’m able to communicate through a server by sending message and you get a notification that someone has joined the channel. All of this however is more or less based on a pre-existing chat. I have changed that you don’t write in a nickname in the chat window and select that in the start menu instead. Reason is to open up for a login system at some point. The start menu doesn’t have all the functionality as it should have, but for the alpha it’s okay, we just need a way to sort the different users apart and have them select the role they want to play. Then we need to sort some kind of priority out so that if 3 people have selected the same role, the one who have the lowest or highest ID gets the role they have selected. Ideally it should be locked, but for the alpha this is not something we want to do. The main focus right now is to get an alpha in a playable state so that we can test the game and modify scale and the feeling of the game.

Anyway, going back to what I’ve been doing, I’m currently looking into how to send custom packets to the server, so that the client can interpret the package received, handle the package and then say that you’re ready or not. Once 4 players are ready the game should start. After that we need to have a way to communicate with the other computers, knowing if the others have loaded the game or not. I’m not sure how to solve this however, in the beginning however what we want to do is to add a timer for when the game starts, so that each client gets into the playing scene, then the game starts after 2 minutes, or if we have a signal that all clients have joined and are ready to play, the timer is shortened to 30 seconds or so. That’s what I want to look into for next week however, this week I need to find a way to be able to send instructions to the other clients, so that we know when we have 4 players ready and get the right scene loaded.

Other than that the game is moving forward, faster than we thought it would at the start, we hope that by the end of next week we will be able to put something together and have something playable, that resembles a moba. Then we need to add the commander interface and actions. Unity is easy to work with, but it takes a little transition to understand all the concepts and I’m still in the learning stage, so coding takes a bit longer than I’m used to.

Tata for now, and next week I’ll hopefully be able to tell you a success story about how we were able to load a level once 4 players are ready.