Category Archives: Uncategorized

Published!

Desura accepted the last build we submitted. We’re getting published!!!!!!!!!!!!!

I couldn’t be happier.  We’ve come a long way. I still remember the initial prototype I created for the game, and the build we submitted to IGF, as well as the many pivots we had throughout our development process. Our final game has evolved so much, its unbelievable.

I am humbled to be a part of this amazing team. We’re almost over the finish line. We’ll be preparing for EAE day now, where we showcase the game to the public. I also need to prepare for our thesis defense. The end of the semester is always crazy…

Systems are good..

I’m really glad that I took the extra effort to clean up and refine our menu system. It helped me crank our new menus for our pause menu, options menu, controller layout screen etc. really easily.

I’ll describe briefly the architecture for the menu system ( big thanks to Ron Romero for his contribution).

The game has a MenuManager which knows about all the menu states that exist. It is the class which loads all your menus at the beginning, and the class you rely on to toggle between menu states. All of these menu states derive from a base MenuState class. The base class has functionality which lets it know about the player controlling the menu, as well as arrays to store the normal, rollover, and pressed textures for all the buttons in the derived classes. It also has an array of delegates ( or function pointers) which point to the callback associated with each button. When you create a new menu state, you derive from this class, and based on the number of buttons in your current menu, you initialize the texture arrays. You do not need to specify each of the locations for the textures for each button. I’ve created functionality which maps a string like “Options” to options_text_normal, options_text_rollover, and options_text_pressed, so that all these textures can be loaded automatically. All you have to do is fill in an array corresponding to these buttons ( Something like array={“Resume”, “ControlsLayout”, “Quit”}). You also have to decide what happens when each button is pressed, but that’s it! You menu is ready 🙂

MainMenu

Menu System

I developed a menu system for our game this week.

Ron already had a MenuManager set up, which had a dictionary which mapped strings to delegates. You could load a menu by calling the LoadMenu(stinr i_menuName) function, and it would call the appropriate delegate based on the string.

I build on this system, and added a Dictionary, which also associated a string with a delegate. Whenever I would load a menu, I would call the corresponding delegate. Each of these delegates would populate an array for Actions. Hence, as I moved through the menu, I would keep track of the action it was pointing to, and when the ‘A’ button was pressed, I would call the Action currently being pointed to. These actions would mostly cause the game to quit, load a different level, show the help menu/options menu, or go back to the previous menu.

We could now press start during the game ( which would pause all user input, and draw the pause menu), and move through the pause menu ( as you moved through the menu, the button being pointed to currently would be shifted to the right, to let the user know his current selection)

Input maps

I worked on inputs this week. Ron already had a basic framework for them, which he called the InputMap. It basically had a number of strings which corresponded to the different buttons and axes we used in our game. We needed this encapsulation so that we could change the strings contents and have them map to a different button or axis, while still retaining the variable name ( and hence not having to change the code anywhere else). So, we could get the righttrigger axis for the first player by the following code

float RTvalue = InputMap.RightTrigger(int i_playerID)

Architecture, and GameModes

We have managed to get a basic architecture for our game in place, which consists of a central object which keeps track of the game’s elements.

This object sets up the controls, the screen division ( did I mention that we’re not doing networking right now? It’s on the backlog, we might get to it if we get the other stuff in place), the input handlers, checks for end states based on the game mode and also draws menus.

All the credit for the architecture goes to Ron, I was very impressed with it. I managed to learn a few new things about C# as well, such as delegates and events ( which we are using right now to handle Health changes and Level transitions).

I came up with the GameMode logic.  Each game mode is represented by an integer, with each bit representing an end condition. For example, if the first bit represents time limit, and the second represents a kill limit, while the third represents a territory control limit, the DeathMatch gamemode would be something like 00000011 ( so time limit and kill limit are enabled), whereas Territory control mode would be represented by something like 00000101 ( so time limit and tile count limit are enabled). Based on these bits, the game would check to see if the end game state had been attained.

We could use the other bits to represent other end states that need to be checked. I really liked what I had coded. It seemed efficient, and clear to the reader.

New Semester- Sprint to IGF begins!

We started off our new semester this week, and made some very important decision.

I had tried to get the basic game architecture for our game in place over the summer, using C++ and Unreal Engine 4, with the help of two more members of my team – Ron Romero and Triston Thorpe. We realised over the course of the summer that coding in Unreal would not be feasible. We ended up breaking the codebase several times ( and had a hard time figuring out why). We had been using Unreals blueprints for the initial builds, but we did not think that was the best solution for our final game.

With those points in mind, we decided to move forward with Unity. This was a massive step, as we had to throw away all our present code, and start afresh. But it was a step we needed to take. Our team was a lot more comfortable with Unity, and would be a lot more productive using it.

We were assigned engineering tasks based on our preferences ( I was tasked with developing the game modes and game states with Ron Romero).

I am both anxious and excited to move forward with the Unity. We need to get an IGF worthy game ready in 2 months… a daunting task indeed….

 

The Final Touches

The last few classes before EAE day were upon us, but we had made good progress. We had met over the weekend and finalized some of our core game elements. We now had UI for the health of the player, and had the projectiles replicating on the client side. I had to struggle a little bit with assigning players a unique ID, but I figured out a way to do it.

The day before EAE day, I added a limit to the ammunition the players started with ( 20 bullets) and added ammunition pickups on the moving platforms around the levels. This encouraged the players to be wise with their bullets, and also to jump around the level to collect ammo packs ( often making forays into enemy territory to do so). I also managed to get double jumps in, so that players could reach those high floating platforms.

All in all, I was satisfied with the game. It had fun elements and was reasonably balanced to engage players, and we were looking forward to hearing from our players on EAE day.

EAE day went smoothly, without any bugs or glitches. We got tons of feedback forms filled by visitors, and will be looking at them in order to make our games a whole lot better.

This post marks the end of another semester. It has been amazing, and I have given my 150% ( all for the sake of games!). I feel exhausted, and need a well deserved break 🙂

Nothing like a good example

After spending a large amount of time searching online for help regarding networking in unreal, I came across the Shooter Example. This was a sample FPS Shooter game released by Epic, free of cost. I downloaded it and messed around with it a little, and found out that if need be, we could simple put our level inside the Shooter Example ( and take out the previously existing stuff) and be able to play on separate PC’s on LAN! This was a huge relief, as it meant that we would be able to play-test the game at the upcoming EAE day on the 22nd.

I also discovered the replication section in blueprints, and after some messing around. I figured out (mostly) how it worked. We were able to have our cylindrical world spawn on the client through the server.

 

Replicate!

So this week, Epic released the Networking tutorials. They were VERY helpful. We didn’t need to resort to the Shooter Example anymore.

The engineering team, having had some time to dabble in Unreal Engine 4,  decided that we should divide tasks among ourselves and get to work on them. I was to make the territory control mechanic, which included separate tiles for the two teams, and a projectile which could change the territory.

I changed the cylinder making code so that it would form two territories, and assigned each Tile a team variable, which was changed on collision with the Territory changing projectile.

The first two weeks are the hardest :(

So this week has been a bit of a struggle. Learning a new engine is never easy

We needed to know how unreal dealt with networking, but the unreal 4 networking tutorials weren’t out yet. I looked into information about replication, the way unreal engine 3 managed networking. I also tried altering the C++ code to enable double jumping, but ended up causing unreal to break horribly.

It was a frustrating week with little visible progress.  For all the engineers on the team.