Week 8 – Control groups – Buffing – Beta

Final week is approaching, next week is GGC and last week has been the longest week of my life. I think I’ve put in around 60 – 70 hours this week, so now I’m just exhausted.

The beta that we had earlier this week didn’t go so well, so we had to put in some extra effort to show that we have a game that is a little more polished than what we had when the beta was going on. I have to be honest, we currently have a prototype and not really a beta, however again honestly that is what we were aiming at from the start. Putting together a MOBA and an RTS to make something that works requires a lot of time, effort and planning. I think we have gotten there. Do we have a well polished game, not really, again not what we were aiming for.

Beta

We have a in my opinion a good looking game, it is for us, fun to play, however the problem is that we know how to play it. During the beta we had some people test the game and the overall criticism was that those who had never played a MOBA didn’t know what they were doing or what their goal was. They didn’t know what happened, they didn’t know what they were supposed to do. Those who had played a MOBA before had a little more fun and knew a little bit more what was going on. That said since the beta on Wednesday and up until today a lot has happened. For instance we now have control groups, something I was working on yesterday. Pathing was a big problem. Unfinished graphics, for instance we had building nodes that didn’t look like anything in particular.

In any case, we got a lot of feedback on a lot of features that we had. That pathing for characters didn’t work out so well is more or less because A* that we used had an issue with how we have designed the map. I’ve looked at how we can use the NavMesh system that is in Unity, but the problem stays the same, while the navmesh system seems a bit more intelligent than A*, the navmesh had certain areas it claimed that nobody could walk on because the paths were too narrow. What we ended up doing was to remove the pathing, reason being that if the server started lagging A* started acting really strange and sent creeps away faster for some reason and then sent them back, why I’m not entirely sure, but I’m guessing that it detected that the creeps had travelled too far and sent them back to the position they should be at, however that’s just a guess.

Control groups

One of the things that the commander is doing in our game is to act as the character we call support, but also as an RTS player. The commander has buffs, one that can heal, one that speed up the hero and one that shows the map. The other thing the commander can do is to select units and send them on the way, the problem however has been that when the commander selects the units, and wants to send them one place, that is fine, but the commander lacked the control of saving the selection and bringing it back. So that is one of the things that I’ve now made possible. Unfortunately inside Unity, when using Control + 1, you get to the scene view, so I had to rebind that key into Shift + 1 all the way through 5. So now the player can make 5 different selection groups.

When I made the drag selection box in Unity, what I did was to create a gameobject that could hold the selections and keep track of which units that were selected. So making a control group although it took time to get the logic a 100% right, it made it easier for me in the long run because all I needed to do was to save the selected gameobject list when the player pressed Shift + 1 and store that into an array of gameobject lists. When the player then presses 1, the list is copied over and the objects in it are selected. Getting that to work didn’t take that long, what was the tricky part however is that the lists that you create needed to be newed for some reason. I looked it up and it seems like Unity uses reference instead of copying variables in some cases, lists seemed to be one of them.

Buffing

Another issue that we had was that if you selected some units and the commander wanted to buff those units or other units, because you press the left button to activate that buff, the units were automatically selected, because that’s what I had chosen the game to do. I’m sure there is an easier way to solve this, but after a lot of testing without success, I ended up using the same logic as with the selection group, however instead of that I decided that if the user presses Q, W or E, the next left click won’t register. It does open up for one bug, if the player presses Q, W or E, then cancels that and then want to press left button, the first click should deselect and select the units again. Although it is probably solvable, I don’t think it’ll be worth spending a lot more time figuring out a better solution, simply put, we don’t have the time to do that.

Other

Other than that I’ve done a lot of things, on Thursday I sat down to remove capture nodes and building nodes from the map. I sat out the new base layout which is now divided into 3 places. One of the complaints we had for the beta was that we didn’t have a proper backdoor protection, so I added that to the game as well. So now you can’t base rush eachother, you need to kill the secondary bases in order to proceed through to the middle. Earlier in the week I changed so that there’s a population cap of 10 units, which later on was reduced to 9, so that there will be 3 creeps on each base.

It has been a tough week, but we’ve gotten a lot more done in just a short time this week. Mostly because we’re beginning to be so used to programming in C# and Unity that creating scripts takes less of an effort that it used to do. At least that’s the way it has been for me.

Screenshots

Here are two screenshots from the game as it looks right now. One was a test I did on the minimap so that the selectionbox wouldn’t show when clicking the camera, it now works. Second one is of the boss called snappy, which is meant to give more resources to the commander when he dies. Not that I had anything to do with Snappy, but I think he looks cool 🙂

Weekly update #7 – Unit Selection & Capture Zones

The final weeks of the development process are closing in. Next week is the beta and we have a huge puzzle to put together. We have all the pieces that we want now. Some graphics are still temporary, some of the code has been made but only works in “single player mode”. By that I mean that it hasn’t been added to the multiplayer experience.

Henrik in my group finished programming the capture nodes, by that I mean that he completed what needed to be programmed in order for different zones on the map to be taken over. I continued on the task, but this time I needed to get in the nodes where the commander can raise buildings inside those nodes. Doing that took more time than I anticipated. Simply because there’s a lot of factors you need to take into consideration. When making zones that you can take over and zones, and once you get the zone your side can build on them, you need to take into account several things:

• What happens if there are structures that have been built?
• What happens if the nodes have been spawned already?
• What happens if the structures are destroyed?
• What happens if you destroy one building, is the node still in place or do you have to let the opponent destroy the rest of the buildings so that the new nodes can spawn again?
• Will there be new nodes spawning if buildings have been built and you destroy a building?

Once those questions are answered you can continue, the problem is that you want to be able to test all of these things before deciding which approach to use. So how can we test this in a single player setting when this is a multiplayer only game?

The answer is, you can’t, we have to implement one variation, do some player testing, test out a new way this works and test some more, however we’re not there yet, so right now the best answer I can give is that you need to take a logical stance. If I were in the players shoes what would I expect would happen? How has other games done it?

What we have so far is that you can take over the nodes, so if there’s no nodes there or the enemies nodes are there, the existing nodes are replaced with the side that takes over the nodes. If there’s one or more buildings in the zone the side that had the nodes will still own the building and benefit from that building. Unfortunately the side that lost the zone can still build on it, that’s however a bug that I need to address.

Another challenge we faced was that the capture zones slowed the game down. Physics got overloaded, however there was a quick fix to that, it was just a matter of setting the capture zones on a different physics layer and add so that it doesn’t check for collisions towards anything else than champions and buildings. Reason why I chose buildings is that I’m using the capsule collider method to check if there’s a building in the capture zone, that’s how I figure out if there’s one or more buildngs built in that place.

Other than that it is now working fine, there was a bug that kept me away from testing and getting that detail fixed, but that bug has since been fixed so I can go back and finalize that detail. Here’s a screen capture of the capture nodes, unfortunately it doesn’t really say much. But basically the champion has taken over that node and the commander can then build on the nodes that spawn, because the capture zone didn’t have them already.

Unit Selection

The other feature that I was working on was to create a selection box for the units, so that the commander can send units to a certain location. However in order to test this and to be able to work on this, I needed to create a scene to set up a single player commander. One reason for this is that when you’re making a multiplayer game in order to test you need to build the game, then set up several clients and then try it out. When creating a single player environment you can test what you want with just one client and the process of testing and making sure things work are much faster.

Anyway what I ended up doing with the selection box was to create a visual box which was drawn up by a rectangle that you form through the mouse click and dragging the mouse. The content of the box is filled with a solid which I change the material for to a transparent box. Once the units have been selected they are added to a list and if the user presses the left mouse button, the units are deselected.

At first I made each unit be aware that they were selected and it would have worked, but instead I decided that the units should be added to a list, the list would be cleared once the units are deselected. There were several reasons for making them into a list. One of the reasons was that I wanted to be able to save lists of units into different groups. That feature however will most likely not be implemented. Next week I will get the selection into the game and we’ll see how fast I can get that into the game. Next week is all about getting the stuff together and making a Beta and then it is all about polish.

Here’s a couple of screenshots showing the selection box and some of the units selected

Weekly update #6 – Technical difficulties

This week I wasn’t really sure what to write about, because on Monday everything was working fine. I worked on a buff system. Which I got working on Monday. Then on Tuesday we got a new map, I downloaded the map and after that weird things started happening. First the soldiers (or creeps as they are called in other MOBA games) started warping around the map. I tried to fix that by trying to get the Astar path finding script reset. So I started working on that, but then Unity started crashing. I got the bug report window up and nothing really worked. Everytime I selected Astar in the scene it crashed. So I took a backup of my project, created a new blank project and downloaded the files again. Same thing happened.

I decided to try something else, to revert back to the latest update where I knew it worked, and I still had the same problem. The other programmers however didn’t have this problem, which was really weird. I had the same problem during Wednesday, even tried copying another programmers project to see if that worked. Late on Thursday however I managed to solve the problem, that said, I have no clue what really solved the problem, because we tried so many things. Firstly we had one of the programmers that had a working copy uploading what he had. It solved the problem, what what in that project that he uploaded solved it is what I’m not sure about.

The rest of the week was going into getting what I had done on Monday and Tuesday into the project as well as troubleshooting why the game lags so much when you have multiple players connected. Lagging occurs after more than 2 people connect to the server. So far we’ve disabled physics on the client side, disabled box colliders and the problem we had with the physics engine getting overran has been fixed, but the game is still lagging. One theory we had for why the physics engine went haywire was that the objects have their own physics properties on the client side, so when the server told the client where the bodies should go the client side physics didn’t like that. In any case disabling collision detection on the client side worked well for that particular problem.

We still have the problem for lag on the client side, we don’t yet know what it is, but right now the clients are waiting for the graphics to be presented. I’m not entirely convinced, but we have a theory that it might be related to graphics and missing shader components. That said, since it seems to be working better on the server side and all the assets are the same for both sides, I’m more inclined to think that it might be the networking that is causing the problems for us. We’re not sure though so this is something we need to figure out.

Luckily not everything has been at a standstill though, so the game has been progressing this week as well. Attaching some screenshots from the latest graphics that, although isn’t directly in the game right now, it will be looking like the screenshots below:

 

Weekly update # 5 – Alpha

This week has been long and I believe we’ve come really far with our game. Not so much gameplay wise, but we are starting to get the game more and more together. We also have a direction that the game is going, with that it is also easier to program and get the things that we want into the game to work.

My task for this week has been to work on the commander. I did some work on him last week, but that was to get the commander to work in multiplayer, but this week we decided to change the way the commander builds the buildings and rather have building nodes rather than placing out the buildings in the spots the player wants.

There are several reasons for this. Mainly it is because we wanted to make the commander have nodes and need to choose between the buildings that the commander wants to build rather than being able to build as many buildings as they want. Also since the game we’re making is more of a prototype for the idea that we have, we want to make some of the features a little more light weight so that we have time to complete it, because we realize that we need to cut some of the features now, rather than later, so that we are sure that we have some time for polishing the game in the end.

In any case, programming the building nodes themselves was not hard. What was difficult was getting it to work as we wanted to. The reason for this is once again networking, if you take a network instantiated object, it is no problem for the server to set the building nodes in such a way that they get tagged with a red or blue tag. However network instantiate doesn’t have the tags following it, so you’re left with a couple of options, either make your own way of instantiating, that however means that you need to make a script that keeps track of and can be identified from the server side. The second option is to create RPCs once the object is created and have that RPC call be activated on the client side and setting the tag to the right one.

RPC

Before I continue, might be good to explain what RPCs are. RPC stands for remote procedure call. Basically what it means is that let’s say the server says to the clients that they should create an object. Next the server says that the object you just spawned should have an identifier that corresponds to what you want it to be. In our case it is “Team Red” or “Team Blue”. And to additionally complicate things, RPC is done through something called a network view. Basically that is a sender and a receiver, we can compare it to a phone, you call, someone picks up in the other end and you have a network view (sort of). Those network views are attached to game objects. In principle you can have one network enabled object and have all communication go through that one object. Although I don’t believe that is recommended, so each object have their own sender and receiver with an identifier.

The problem however is that we wanted to create a script that spawns everything in the world. Reason for that is that you want the server to have control of the objects that spawn, so the server tells all the clients connected that this and that object should be spawned. Once they do that, the server and client can sync the objects. In case a creature dies in the game, the server can remove the object and that automatically happens on the client side as well. So going back to the tagging the objects part, the scripts with the network view (sender in this case) was attached to this objectspawner, I was trying to set the tags from that spawner and ended up having the object spawner change tags and not the building nodes. Because the sender and receiver was the object spawner and not the building nodes themselves.

I haven’t found a solution that I’ve been able to test properly yet though, but I suspect it shouldn’t be more difficult than to set the network view on the building node, get that network view component into the spawner and have the script attached to building node catch the RPC call that I’m using through the building node component.

Another problem I had with those nodes was that I was able to build one building, but the other two buildings failed. I figured out what it was in the end, and managed to fix it, which made the whole thing not work at all like I wanted to. Basically I added buttons to the game, which floated around the building node if it was selected. The problem was that the buttons didn’t react when I clicked two of the buttons, but the first one worked. After looking at the problem for a while I figured out that the code worked, but the problem was that the building node that was selected got deselected when I clicked on the button, which made the rest of the code not run. Turned out that the raycast that you can use to select objects was sent before the button code and that made it deselected.

Ray casting is basically a line that originates from I guess it can be wherever, however in this case it was from the camera view, down to the playing field so that everything in it’s way (for the length of the ray) “collides” with it. It is a good way to check for collisions and also selecting items or having the mouse interact with objects in the gaming world. Think of it as a laser pointer that goes in a straight line from one point through another point. As it turns out, raycasting is useful for number of things, but as far as I know most of them are collision based in one way or another. For instance knowing what to target or how far a target is from you and to measure actual collisions, but it all is the same type of checks. If the object that you hit and the origin is within a certain range and also what objects are in the way.

Finally some screenshots of the current build:

Building menu (not final version, but an example of how it could look – currently ingame:)

 

 

 

Built Barracks:

 

Built power generator, which is in progress of being built:

 

 

Finished power generator:

 

Example of Fog of war:

Next week

Next week we will brighten up the fog of war, so that it doesn’t look like it is nighttime, fix the jungle creeps that we had, but have disabled because the physics system went haywire when that was implemented. Add zones so that you can contest zones and hopefully find a good system to keep everything connected. Hopefully we will be able to implement a boss and get that working and randomly spawning.

Then we’re very close to having the beta that we want and then start having sounds in the game, which we’re currently lacking.

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.