#sharedplaygroundsaut

I made the cursor stick to the ground, not because it added anything to the project. It was just something @marlosanmiguel kept asking for. Are you proud of me now??????? 

*SlowlyCriesRememeberingAllTheWritingLeft

Blocking:

There's now an animation and shield material for blocking. The material begins to fade as the shield decays. The decay is speed up by damage taken. The number is for debugging. 

Roll/Dash: 

Players can roll by tapping R1/RB while moving. It has a 3 second cool down. 

Dash Cancel: 

Pressing block while dashing stops movement.

Flat Cursors:

Harry has changed the cursor to something more flatter.

Before:

After:

Health Pack:

 I have added health packs that recover either 25% or 50% health. As well as a power up manager that procedurally spawns them.

Last night I presented at the game developer meetup and oh boy was it an interesting one. Ben wanted me to present on the projector and gave me a MOA screen. He wanted me to use the projector, because it would allow others to spectate. Little did I know, the projector was connected to 2 other side screens  Hence, I got to present using 4 screens. It was an unexpected honour that just felt a little too good to be true. 

Enough with the gloating, back to the meetup. Throughout the meetup, gameplay bugs became more apparent and I got a better understanding on how they are triggered.

Bugs:

Physics assets spazzing out.

Players being unable to attack.

Players catching thrown objects and having them get destroyed while they are being held.

Unconscious players ricocheting around the environment.

The feedback, I received was also interesting. 

Make one button do multiple actions. E.g. When players strike an object, make that pick it up. This will simplify the complexity that already exists in my project.

Make objects catchable. Something that I will do, if I have time.

Punish players for button mashing. Which already existed, but was removed to compress a bug for the meetup. 

Have a push back, force on the targets struck. 

The general feeling I got from this meetup was that the project had a complex control scheme and system. Something I was actually aiming for, where it can be picked up by people that play fighting games; easily. Nevertheless, I have to find a good balance that has difference (skill) levels of play. Where expert games have an entirely different play from casual games. This has made me want to take a step back and look at what exactly is vital.

Reflection:

At the beginning of the semester, I declared that I was changing my approach entirely to a test driven approach. Where, I would slow down and slowly add little bits to the game; then do a play test. This approach worked wonders, I managed to have a testable demo by week 3. As a result, the progression was very smooth and productivity was high. 

Then the September Game Developer meetup happened...... After receiving a lot of feedback. I got so absorbed and wanted to overhaul the project and build it around ALL the feedback, I found useful. As a consequence, I reverted to old habits and kept developing without testing. Progress was made, but at the meetup more problems were  present than any other part of the project.

Today I started working on my dynamic camera. So far far I still have to pan out a couple values, work on the speed, and fix the bug that teleports the camera away, if player 1 get eliminated. 

The slow weeks have started to hit me, I am working a lot less and my production rate has dropped. This was kind of expected, due to how much work I had gotten done prior and a cross critique session that made me feel as though I would have gotten more from not coming in. The inevitable slope of slack and demotivation was bond to come. However, with this being my 6th semester; I have a better idea on how to deal with this. Hence, I have looked back at the Trello board and had a thought about what really is essential to the final product.

Upon reflection I have spoken to the others and decided to remove:

Weapon system

Object health and smash

Catching thrown objects

Tackling

Air combos

https://trello.com/b/SmoWX2ni/drunken-tavern-brawler

Furthermore, late last week I decided to count up the hours and give myself another 3 weeks to work on development; because I will need that week and a half to work on bug fixing and optimisation. I have assigned a maximum of 30 hours a week, something that is manageable and won’t drive me to the brink of insanity as all the bugs slowly creep up and make me want to cry myself to sleep knowing that it’ll never be anywhere close to what I dreamed and won’t put too much stress on me.

Another Round of Playtests

Playtest 1:

I ran another three rounds of play tests with a total of different 11 people. During these tests, I noticed that combos were not utilised and players were still not sure if they got hit. One piece of feedback that 2 testers recommended were to have characters flash red or a distinct colour when hit.

I made a quick mock up to test this feature and it did its job, but needs a visual improvement to blend in smoother.

Hit React Colour Feedback:

Aside from design improvements these play tests also made more of the bugs obvious.

Players unable to attack.

Players falling out of the map entirely.

The upper body glitching out:

Reflection

Looking back on all this information and what I have learnt. I know that I will have to keep cutting tasks and focusing on proactive and reactive game balancing. Where fine tuning values are going to be a big task.

Also, I tried working on rolling and got this wonder:

Throughout the semester, I worked on “Drunken Tavern Brawler” for Studio 6 and ARDN612. Hence, this was a 45 points project. Harry and Ryan worked alongside me, but only dedicated 15 points each. Yet, I can proudly say this was the best project I have been apart of; the outcome speaks louder than anything else. The project taught me many skill and lessons in game development and team communication. Nevertheless, getting to this outcome was a very interesting journey.

During my last semester break, I spent a significant amount of time playing with and exploring Unreal Engine 4 as a tool. While scouring YouTube, I came across a tutorial on how to make a “Gang Beasts” like fighter (Medel Design, 2017). From here I started experimenting with physics assets. Then made this:

After making that I thought I could make a comedic ragdoll fighter, but while talking to a friend; she mentioned she was drunk and that gave me an idea for a Snapchat caption “Drunken Bar Fighter The Video Game”. This snap got a lot of positive reception, which motivated me to make the project a reality.

Initially, the project started off as a Gang Beasts(Boneloaf, 2014) clone. But, through play testing I realised that I wanted something a bit more original and different. Thus, I began to pivot toward a 3D arena brawler and want to make it emphasise the competitive; yet goofy nature I saw the players exhibit. Hence, I began to looking at mainstream product in this genre like Super Smash Bros(Bandai Namco & Sora Ltd, 2014); as well as hidden gems like Shrek SuperSlam(7 Studios & Shaba Games, 2005). Coincidentally, Sherk SuperSlam ended up being a critical factor in making the decisions and morphing the project, in the early stages.

Through the experience, I gained a lot of conceptual and project management skills. One of the most useful skills I gained from these departments was learning how to listen to and judge feedback. I realised that the most important thing to listen too is “Why are they saying what they are saying?”, understanding why something is being said will help one determine what is the problem and if it is essential. I could share many examples, where players were asking for specific mechanics or animations edits; which would have only been polish. However, upon reflection the best example I can think of was controlling the level of drunkenness or having that “unique aesthetic”. From face value both suggestions look like they will add a lot of value to the project. But, upon evaluation I noticed that they are not essential to the programs functionality and enter the territory of feature creeping. Moreover, controlling the drunken level would require significant programming done to the ragdoll and physics; currently I am using default values. Then will have to break the skeletal meshes into separate models, re-rig and animate all of those limbs. This entire element may take up to 6 weeks to do, with two working on it. The time span includes no research and accounts for code documentation to crystal clear and bugs to be non-existent. Speaking realistically this would strip development time by at least two-thirds, if we are lucky and a single problem is never faced. Then again there may be a way to fake it, but it would require a lot of time to develop. Basically, if we had succeeded in doing this the final product would have been an utter mess and the actually “game” part would have been half-assed.

On the technical side many skills and principals were learnt or underwent significant improvement. Firstly, I became a lot more aware of the system architecture of Unreal Engine 4. Where, it became easy to figure out how to expose certain variables. Secondly, I learnt a lot about Physics Assets, hierarchical rig and layer blends by bones in a skeletal meshes; where I now understand how to animate specific limbs and send messages efficiently down a chain. Thirdly, using a minimum area within a rectangle to control a dynamic camera smoothly (More documentaion: https://www.geometrictools.com/Documentation/MinimumAreaRectangle.pdf) (Eberly, 2015). Lastly, I have a much better understanding on judging task length.

During the project there were many occasions where I lost track of what I wanted to make. There were many occasions where I started turning this into a technical fighter and neglecting the intended audience. The reason for this was that I got more interested in looking at frame data and combo chains. Then again when one is passionate they can easily get carried away and lose themselves in their work. I could blame Tekken 7 (Bandai Namco Studios, 2015) for these issues, however it did assist in teaching me how to chain combos and structure fighting mechanics and make certain actions punishable, which led to me nerfing the jump.

In conclusion, I do feel like I cheated by doing very little research into drunken behaviour. But, at the end of the day; the fighter part had more importance and essential to the game experience. The drunkenness just acts as a selling point. However, focusing on the fighter part allowed for the project to get done; which gave me a project to look forward to working on after graduation.

References:

Medel Design. (2017, June 27). 😝 GANG BEASTS Fight Style - UE4 Tutorial + PROJECT DOWNLOAD [Video file]. Retrieved from https://www.youtube.com/watch?v=VV4kLV8DifI&t=2s&ab_channel=MedelDesign

Boneloaf. (2014). Gang Beasts [Video Game]. Double Fine Presents.

Bandai Namco & Sora Ltd. (2014). Super Smash Bros. for Nintendo Wii U [Video Game]. Nintendo.

7 Studios & Shaba Games. (2005). Shrek SuperSlam [Video Game]. Activision.

Eberly, D. (2015). Minimum-Area Rectangle Containing a Set of Points. Geometric Tools, LLC. Retrieved from https://www.geometrictools.com/Documentation/MinimumAreaRectangle.pdf