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.