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.

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.