simplegames-blog1

[simplegames-blog1]

5/15/2017-5/19/2017

We are going into the last sprint of our project. I spent the time working on polishing effects and implementing new sounds that we got. A few bugs that I found out about on the  Spear trap that when any thing passed through it triggered so it was changed over to only on Player. For the sounds that were added are for when a weapon hits stone or wood. To stop the player from just sitting on the side of the maps and not engaging in combat Jash and myself created a time that drops a boulder on top of the players that are alive.

[simplegames-blog1]

5/8/2017-5/13/2017

This week was a lot of tuning game play. I added a attack speed to each of the weapons. This week I also started working on a crowd reaction to allow for cheering when a player kills another and boo when killed by traps or them self's. The first problem I ran into with this was that I could not figure out how to blend from a montage into the animation for the reaction that was needed. A way that I fix this was by creating a State Machine for the crowd to allow for a more blended and even distribution of the crowd.

[simplegames-blog1]

5/1/2017-5/6/2017

This week I created a way for the host to start a new round once the current round is over. For when the player has only there fist I created a color change when the player is hit and a regan for after a few seconds. There was a few focus issue with the pause menu that while in the lobby it was causing the player to start the game when they were trying to leave. This was because input was still being passed on both the UI and the Game its self. Since this is the start of our final month I started focusing on finding game breaking bugs and seeing what we needed to do to fix them. A few of them were easy fixes that either something wasn't replicated correctly or a variable was forgotten when pushed to the server.

[simplegames-blog1]

Jeff's Month 4 week 3

For the 3rd week really started having to polished the main menu and build out the rest of the UI. This was harder then people would believe. We didn’t get the assets we were told we were going to get. So I started have to take my extra time and start making the ones that I could do. They came out okay, but they took a decent amount of time. I had to make sure menu parts had to be fully functional with little to no issues. UI has so many test cases, that it just issue after issue, and I had to test, and test, and re-test again.

I ended up building out the splash screens this week. Up to now, we could get by without them. I believe I messed here, and should made them earlier in the project, I was just prioritize the core functions first and then led to not needing the splash screens, but were definitely necessary for the final, deadline, release. Because of this our credits screen and our how to play is not up to the same Quality standard the rest of the game should be at. So hopefully after deadline I will be able to get this up to a standard of the rest of the UI.

This is a really interesting experience, even with all it’s issues, and I’m still drawn to the experience, and I can’t see myself not doing this for a career path.

[simplegames-blog1]

Week 15 Post – By Jashua M.

Remember what I talked about last week? Where I talked about switching to a collider-based hit detection? And I only had two days to do it? I GOT IT TO WORK! It worked good, I had my bugs where some were registering too many hit detections at once, which I solved by applying a buffer where after I detected a hit, I would prevent it from registering a hit again with a few bools here and there. Projectiles were being blocked great by this, cause all they were doing is being stopped by a collider in front of players. Thanks to that collider, our weapon catch was finally able to be done. Blocking also worked great, I just put a trigger box in front of someone when they were blocking with a shield, and whenever someone came inside the trigger box he would always get blocked, but when he left the trigger he could land his attacks. Simple, thanks to a few changes here and there. Our gameplay improved a lot with my changes, which ultimately made me proud.

[simplegames-blog1]

Jeff's Month 4 week 2

This week I finished up the initial hud over the head, I worked on the arrow changing color depending on who you’re facing to attack, added arrow keys, and eventually dynamic changing of the hud based on button set.

I wanted to design this hud element through shaders then just using images. This leads to some advantages, other I get experience learning some stuff, which it is acceptable to small changes without whole asset changes, and takes up less memory. So I used, and made, some basic assets to create the floating hud. I got that up and running. But we were missing arrow keys, and I needed to make that. And I started working on that, it had it own technical hurdles. 

I started working the arrows that point at the opponent, and I bumped into the issue where it wouldn’t replicate properly but I worked on it and I got up and running. It had to do with the pawn on a client’s instance not having access to the the referencing pawn. I ended up working around it, it it took a while. I ended up making a dynamic, hot swapping, system for the hud, for testing reason, that could easily implemented in the game. It allows the user to switch between the possible control schemes.

[simplegames-blog1]

Week 14 Post – By Jashua M.

I got all the combat mechanics to work, and I changed our control scheme to how we wanted it from the beginning. I had a bit of trouble with one of our inputs, because our designer wanted one button on click to perform an action, but when it was held it performed another action instead. I got to get it working based on a timer when button is clicked. The problem was, it really didn’t work based on how we thought it would. It just didn’t feel right. Luckily, I didn’t delete anything that was set previous and I quickly reverted to the way it was. At this point, I’m tweaking our combat system, but I’m still having issues with having the right hit detection happen due to the detection system that our fellow member implemented. I reached out to our mentor in talks to switch everything to a collider-based system, in which he agreed. I had two days to get it done, which seemed crazy but I’ll do my best.

[simplegames-blog1]

Jeff's Month 4 week 1

So by this time we are at a point where we are down a man, and now things that needed to get done, are going to get done in a different manner. I believe I spoke about this in my last blog, but it really hit the fan here in this week. So we had a conversation about what we are going to cut, and what not to cut. So no A.I., no single player, no axe or spear, no different themes for levels, no dynamic levels, basically we can’t work on anything that we haven’t already. Now it was time to clean things up.

So our producers what us to do vertical slices of features, to own a main feature. Up to this point we have been doing horizontal feature, basically we do a few things and we do it for the whole project. That way we can hone our skill and make it really good by the end of the project. Be he wanted us to know how to implement a feature top to bottom. So I got timing windows, and I got the dodge mechanic. Then after that I would handle combat ties. So I was getting down into the nitty gritty. It was interesting for sure. 

The first and main problem this week was dealing with the combat system. It was setup in way that didn’t follow  the intentional agreed upon setup of the agreed engineering, something we talked about in month one. We were going to use c++ classes to characteristics from parented classes, that way when we made changed it would allow for changes to be made the inherited pieces. Also it would allow a certain amount of scalability. So when I got in there it was hard coded blueprints. I was confused, and actually lost half a day because I started working on the c++ side and started implementing features. The throwing system was even disconnected from the horizontal and vertical hit system, it was supposed to be 3 different attack of the same weapon class, and it wasn’t. By the time I figured that out I got the implemented the timing windows.

Then I got off to the transparency, I bumped into a similar problem, the way the system was designed it didn’t allow me to effectively allow me to attach it the systems. I had to modify and start rebuilding the system to account for a feature that was known about for months at this point. Then the reworked animation system wasn’t attached to the attacking systems. This is super frustrating. I eventually I got it working from some directional help from my team.  The third feature I was suppose to implement which was the combat ties, but because the system was designed I didn’t make sense to do, so I talked to our producer and I started working on the floating hud over the players.   

  -Jeff Yanick

[simplegames-blog1]

Week 13 Post – By Jashua M.

Found out that one of our fellow members had to leave our team, which only meant that our workload was going to be even greater now. We took the news well, and quickly planned who’s doing what. I picked up most of his work, which were involved in networking tasks. I was working on our replication issues, where player actions & animations weren’t being displayed to other players. I was also helping Matt with his replication of the traps, just having the ability to show their animations to everyone & telling everyone that such player has died. Most of my time, I was trying to figure out how our fellow member’s hit detection system worked. He made a system that detected when a hit should register based on an angle check, and a distance check. It was good, but it also had its flaws. Deflecting projectiles, and blocking against other attacks was much harder now. I made the best I could with his system, but at this point I’m not a fan of how it works.

[simplegames-blog1]

To The Death - Beta

[simplegames-blog1]

4/10/2017-4/17/2017

This week I began working on create a way to tell visually when the player takes damage from another player when the attacking player is unarmed. I had to look through the combat code for our players and determine where the player takes damage. Once I found where The implementation was needed at I got it to work on Server and client to set the color but when it reset back to there normal color the players on clients side was not updating back. This was fixed by replicating the color that was assigned on hit.

I also updated the collision boxes and added sounds to the traps that we are using in the maps for the game. I then moved onto creating three themed maps for our Roman level.

[simplegames-blog1]

Jeff Week 11

I had to take the character select from a base UI and add networking replication. This created a slight learning curve as well, because I wasn’t very familiar with replication in unreal. So going through the specific parts of the menu I had to figure out what needed to be replicated to the server then back down to the clients, what needed to be sent to the server only, and what needed to be the client only.

  I bumped into a major problem with the UI not responding once I went to intergrate it with the correct scene, and for whatever reason it would respond. I was bashing my head against a wall, because all my test weren’t showing anything fruitful. It wasn’t until I from my highest level of control and then I went down into a member, into another member, into another member until I was hard forcing the visibility to be on a UI element, and it didn’t turn on. I was puzzled, and had to think. With the breakpoints I know the input works. So why is the UI not responding, then it hits me, what if something is covering it. So I check the scene that I implemented, the final one, and I checked it’s personal blueprint, and found I was creating another instance of the UI on top of the one I was using. I fixed that and it worked way it had before. All the work, time, and stress because of something so simple. I was really embarrassed, but that is part of this process.

  The rest of the issues I had was little tweaks and polishes I overlooked or wouldn’t of noticed until pieces were in place. Even though it’s at the 90% mark in terms of completion, it still has little things that still have to be done before it’s where we had envisioned it.

 -Jeff Yanick (UI Designer & Developer)

[simplegames-blog1]

4/13 Blog Post – By Jashua M.

I have two tasks this week. First, I’m going to work on our projectiles, and I’m going to help Jeff on replicating his new character select menu. Basically, even if you had a shield equipped, the projectile would still be a sword. So, I made different projectile versions for the different type of weapons. Also, I’m having issues with adding gravity for the projectiles, for some reason it’s not working for me. I’m going to keep that in the back for now because that’s not uber important right now. Now with Jeff, his menu is working, just that it needs replication. As always, we tell all the clients of the actions what we’re performing. In this case, we had to replicate which player number I am, which is my color, and if I’m ready to play. Those took us a while, but ultimately, we got it done!

[simplegames-blog1]

4/10/2017 - Month 3 Week 3: Timeframe Syncing

Author: Sean Odom

                While the logic for weapons was mostly ready, there weren’t visual elements for all of its effects yet. I continued developing the individual weapon system outcomes and now needed to sync this with visual player elements. The animation system needed some simplification to avoid needing a new duplicate set of RPCs, variables, and event calls and functionality for every new animation added. Access to certain animation elements were necessary as well, to begin influencing them based off weapon logic outcomes. For example, slowing a player based off a certain weapon’s hit. Jash handled the restructure of the animation system and investigated some animation issues, while I worked on accessing what I needed to manipulate animations and extending the weapon outcomes. The goal was to develop a unified server player state (idea, not the actual Unreal API class) that would be used to know the states of players as attacking, idle, or recovering and could feed animations durations based off the weapon stats (their attack speed) and the player state. Unfortunately, our framerate issues had progressively worsened despite the attempts to address some of them the previous week.

                Trying to develop this time syncing between visuals and logic, especially on a networked fighting game, during an animation restructure was difficult. Trying to develop this time syncing to be satisfying, consistent, or even accurate when you are testing at 7 fps is impossible. At this point, frame and animation issues had brought this to a halt. I attempted re-cloning the entire repository, adjusted some logic to be more efficient, and numerous other attempts to address the fps drops, but could not raise them above 12. I do not have these FPS issues in other Unreal projects I have. Other team members were also experiencing frame drops, but they weren’t quite as low. I was being asked to deliver weapon systems that hadn’t been completely designed, worse continually being redesigned, in an environment that couldn’t allow for useful testing, were missing necessary components from existing systems to complete these tasks, and resolve known and continuing to grow issues in the codebase relating to efficiency and networking, all more than a month from when I intended to begin on it. Even so, I had developed this system, but with no way to actually tune or test it without replacing large amounts of existing code with more efficient code (an impossibility in this time span), I couldn’t add it to our build. At this point, I began looking for more final solutions and reached out to leadership again. 

[simplegames-blog1]

4/3/2017-4/11/2017

This week I have worked on implementing the blood particles that was talked about at the end of my last post. Currently the particles for the traps are as followed. The spike pit and spike door pit when a player falls into blood will spurt up like a small fountain, for the delayed spike there is a drip from the spikes that creates the pool of blood, for the raining arrows there is omni-directional spurt that creates at the base a pool of blood. As for when the player dies to a weapon there is a burst of blood from that location. Originally when I was thinking of the initial of creating the blood i wanted to created decals of blood where ever the particles landed. I was able to get this to work on CPU side only but i wanted to have them on GPU side. Currently I am looking in to how to create the decals this way as to not take up unnecessary memory.

I have also started working on a weapon rack that over time will spawn up to two weapons on it at any time and highlights to let the players know that they can pick up from them.

[simplegames-blog1]

3/20/2017-3/3/2017

Over the past three weeks I have been working with our artist Zack Ferry in getting models for the traps and our Roman Themed Arena.

Over this time we have created and implemented  three Spike styled traps two that will kill the player after a set amount of time and one that is a open pit that the players can fall into. We have also created a Trap that will have spears shoot towards a trigger point and kill the player that is standing in the trigger. currently we are working on creating over the next two weeks a trap that drops a boulder onto the player and a Spear launcher that will shoot across the map killing anyone that moves in front of it. There is also planes for a trap that has a tiger claw come out and swipe at the players in the arena.

As for the Themed Arena we have different floor textures, Walls that will surround the play field that will have seating for spectators/ crowd that will react when a player dies by cheering. Currently being worked on is pillars that standing/ destroyed placed around the play field.

Towards the end of this three weeks I began working on adding blood particles to when a player is killed. That be via another player or the player dying to a trap. 

[simplegames-blog1]

Jeff Week 10

This week was weirdly challenging. I thought I would get done with a task much sooner that is was, but do to learning curves and getting certain effects it end up taking longer than it should’ve.

  So I spent half of the week finishing up the network menu I was tasked with completing from the previous week. These last couple of week have been more challenging than before. The school decided to give me another class while taking my final project class. So now on Mondays, Wednesdays, and Fridays, I have to spend my afternoons in this class. That with in depth build breakdowns creates large pockets of days where I am not working on my tasks, but I’m still held up to a 40 week hour standard. So it’s been difficult to get things done in the time frames that I was use to for the last 2 months, because my time tables have changes. It also has made it hard to report my estimated time tables to my team for the completion of these tasks.

  The second half of the week I started working on the new online lobby/character select. I started mocking some stuff and testing it, there wasn’t any real challenge with this, just a lot of experimentation. It thing that really challenged me about this part was to make temporary assets that could display the idea of this menu. I would make something quickly throw it in, and then it wouldn’t work. So I would do it again, it would be off. I would tweek it. Then so on and so on. I’m still not done with the this menu, but the basic idea and outlines are there. I have to start fine tuning, and connect all the networking aspects to it, so it works in a online environment.

  -Jeff Yanick (UI Designer & Developer)