Wednesday, November 16, 2022
HomeIndie GameProject Juicy | Devlog #1: Getting Started

Project Juicy | Devlog #1: Getting Started

Project Juicy
This venture is open supply and might be discovered on GitHub

Programmer: Angel Bowers

Designer:  Taylor Smith

Playtester:  Senju96

The Project
This venture (like all my tasks) is supposed to be a studying alternative.  The unique concept was to make a recreation in 30 days and concentrate on making fight really feel actually good.  In truth, the unique identify was ‘The November Game’ since growth was speculated to happen inside the month of November.  We are actually midway by way of the month of November and positively not midway by way of growth, so I’m taking this chance to actually change the secret

Project Juicy shall be an arena-style combating recreation with a twist.  The participant will acquire the favor of sponsors by performing totally different actions within the ring.  Sponsors will reward the participant with new armor and weapons as the sport progresses.  We simply wished to provide the participant a greater cause to combat and make choices than merely getting extra kills or surviving the spherical.

The Team
Oh, who’s ‘we’?  ‘We’ consists of our Game Designer, Taylor Smith, our devoted Playtester, Senju96, and myself, the Programmer, Angel Bowers.  I will not communicate for the opposite builders on the crew however I’ve been educating myself Unity growth and C# programming since April 2022.  I’ve been in it for about 7 months on the time of penning this devlog.

Getting Started
The first step of any new venture is getting the crew synced on Unity variations, supply management, and venture planning.  We are utilizing Unity 2021.3 (the newest LTS on the time).  For supply management we’re utilizing GitHub and Sourcetree.  We are utilizing Trello for venture planning.  Since I solely get an hour or two a day for growth, setup took up the complete first day.  The last item I did that day was import some property I knew I wished to make use of on the venture.

The Player State Machine
Whenever I begin on a brand new recreation venture, I like to start out with whichever half the participant will be capable of management.  I discover the venture progresses at a smoother tempo if I can begin interacting with the sport straight away.  In this explicit recreation, I’m not making a Player Controller script however slightly a Player State Machine.  Using a finite state machine lets me simply management which items of code are operating on the participant at any given time as a result of just one state might be lively at a time.  The PlayerStateMachine retains monitor of which state is lively and holds references to different elements on the participant.  Each state has an Enter(), Tick(), and Exit() methodology.  Enter() and Exit() solely run as soon as upon coming into or exiting the state respectively and Tick() runs each body whereas the state is lively.  I realized this methodology from a Udemy course by GameDev.TV and I extremely advocate their programs for anybody studying Unity recreation growth.

Free Look State
I began off by making a FreeLookState script and setting it as lively on Start() within the PlayerStateMachine.  This script provides the participant company to stroll round freely.  Since that is going to be the default state for the participant, it appeared like a great place to start out.  The preliminary setup included changing to the ‘new’ enter system package deal, creating an Input Actions map and mapping directional actions, having the mappings transformed to a C# script interface script (an choice supplied within the inspector), creating an InputReader script to intercept the controls, making a reference to the InputReader from the PlayerStateMachine, and at last, making a Move() methodology inside Tick() to maneuver the character round primarily based on the controls.  There was plenty of setup to get this far however I did get the participant strolling in all 4 instructions with out animations as soon as it was all stated and carried out.

The subsequent factor to do was to get the character animated.  I used Mixamo to decide on an idle and operating animation.  I used Unity’s built-in Animator window to arrange a mix tree.  Blend bushes allow you to mix between totally different animations primarily based on sure parameters, which might be set within the Animator.  I created a Free Look Blend Tree and used a pace parameter to mix between them.  When the pace is 0, the idle animation performs.  As the pace will increase to 1, the strolling animation will begin enjoying.

This is an efficient time to notice one thing beneficial that I realized concerning the coding aspect of animating on this approach.  When I created references to the mix tree and the pace parameter, I used the Animator to transform my string reference right into a hash.

  readonly int FreeLookBlendTreeHash = Animator.StringToHash(“FreeLookBlendTree”);
   readonly int FreeLookSpeedHash = Animator.StringToHash(“FreeLookVelocity”);

This is a very helpful trick to maintain from utilizing string references in your code to control the Animator.  Also, ints run sooner than strings, so it is extra performant in addition to neater and extra change-proof.  Then I simply added some logic into the Tick() methodology of the FreeLookState and we have now an animated character!


if (stateMachine.InputReader.MovementValue ==  
           stateMachine.Animator.SetFloat(FreeLookSpeedHash, 0, 0.1f, deltaTime);
       stateMachine.Animator.SetFloat(FreeLookSpeedHash, 1, 0.1f, deltaTime);

Third Person Camera
If you are not utilizing Cinemachine in Unity, you are doing it flawed.  Cinemachine is a godsend of a package deal and it lets you take care of all issues digital camera associated.  I used a Cinemachine digital digital camera to create a Free Look Camera that follows the participant, focuses on a remodel I positioned on the character’s chest, and might be rotated with both the mouse delta or the proper thumbstick on a gamepad.  This is definitely carried out by including a Cinemachine Input Provider element to the digital camera, creating Look controls within the Input Actions map, and referencing these controls within the inspector.

The digital camera has 3 rigs (prime, center, and backside) that allow you to management how far-off the digital camera orbits across the participant primarily based on how excessive or low the digital camera is.  The final element I like to recommend including to provide the digital camera that third individual really feel is the Cinemachine Collider.  This lets the digital camera detect obstacles and means that you can configure the way it ought to behave when it does.  I saved the default settings for now however I did add the Player tag to the Ignore Tag area as urged by the tooltip.  There are a plethora of settings you possibly can configure for the digital camera however the vital factor for now could be simply to get it arrange.  We will certainly come again and tweak this extra later.

Targeting State
Since this can be a combating recreation, I knew I wished to have a focusing on state.  The necessities for this state are:

  • The digital camera should concentrate on each the participant and the present goal
  • The default goal should be the closest enemy
    • The participant ought to be capable of toggle left/proper between enemies

I began by creating the PlayerTargetingState script and including a button to the controls that was scripted to transition between Free Look and Targeting states.  Then I created the Target and Targeter scripts.  Target is a quite simple script that simply invokes an occasion when destroyed.  This is utilized by the Targeter to take away the particular destroyed goal from an inventory of targets within the viewport.

public class Target : MonoBehaviour
   public occasion Action OnDestroyed;

   void OnDestroy()

I used one other Cinemachine digital digital camera however set it to take a look at a Targeting Group as an alternative of the participant.  The Targeting Group is only a recreation object childed to the digital camera with a Cinemachine Target Group element hooked up.  The participant is at all times the primary one listed on the group and the Targeter simply provides the present goal to the group.  Whenever the present goal adjustments, it’ll take away the previous goal and change it with the brand new one so the digital camera at all times focuses on the participant and the right goal whereas ignoring different obtainable targets.  I used a Cinemachine State-Driven Camera to toggle between the 2 cameras I’ve created to this point in addition to any extra that could be created sooner or later.

The Targeter makes use of a sphere collider to maintain a operating record of targets which can be in vary of the participant always.  It calculates the closest goal by looping by way of the record of targets and evaluating their distances from the middle of the viewport.  The closest goal turns into the default when the participant first toggles into focusing on mode.

The Targeter retains two lists of targets.  The first is in no explicit order and contains all targets at the moment seen within the viewport and contained in the sphere collider I discussed above.  The second record is a replica of the primary that has been sorted from left to proper primarily based on their x-positions in relation to the viewport.  This was the second time I’ve ever used a LINQ assertion and it felt nice once I lastly bought it proper!  This makes it attainable to satisfy the ultimate requirement.  I retailer the index of the present goal on the sorted record and added strategies to toggle left/proper utilizing that index.

Attacking State
Now that the participant can run round and goal enemies, it is time to give them one thing to do about these large unhealthy capsules.  Creating the PlayerAttackingState script itself wasn’t troublesome in any respect… to start with.  The first line of code in each state is a constructor for that state.  The extra code I put into the attacking state, the larger my customized constructor needed to be.  Let’s begin with an summary of how assaults work.

The Attack script is a pure C# script that principally simply has plenty of serialized fields to retailer the information for any assault I create.  This knowledge contains issues just like the identify of the corresponding animation, how a lot harm it does (extra on that later), how lengthy it ought to take to transition into the animation, how lengthy the participant has to hit the assault button to maintain the combo going, and the index of the subsequent assault within the combo.  The PlayerStateMachine has a reference to an array of assaults and I can modify all of the values of the assaults within the inspector.  Whenever the state machine transitions into the attacking state, it should use the customized constructor, which requires an enter to specify which assault (by index) it must transition into.  It’s really a fairly neat solution to arrange combo assaults as a result of a Designer may simply swap out assault animations and rapidly modify timings proper there within the inspector.

Eventually, the Designer and I made a decision we wished to have totally different combos obtainable for various weapon varieties.  Suddenly, the constructor must know not solely which assault to transition to, but additionally which array of assaults to get it from.  I will not get into how the weapon system is about up simply but however I ended up making a separate array of assaults for every weapon kind within the PlayerStateMachine.  Then, as an alternative of the constructor requiring an extra enter to specify which combo it’s, I added logic to the constructor to lookup the weapon class of the present weapon and decide for itself which combo array it wanted to get the assault from.

   public PlayerAttackingState(PlayerStateMachine stateMachine, int assaultIndex) : base(stateMachine)
      if (stateMachine.Weapon.PresentWeapon.weaponClass == WeaponClass.Sword)
           assault = stateMachine.SwordCombo[attackIndex];
      else if (stateMachine.Weapon.PresentWeapon.weaponClass == WeaponClass.Spear)
           assault = stateMachine.SpearCombo[attackIndex];
      else if (stateMachine.Weapon.PresentWeapon.weaponClass == WeaponClass.Heavy)
           assault = stateMachine.HeavyCombo[attackIndex];

Weapon System
I used to be debating whether or not or not I wished to cowl this proper now as a result of I plan to return again and refactor it later.  My weapon system at the moment has a cyclical dependency and I have never found out repair that but.  We’re all human right here and we’re all studying, so I made a decision to go forward and canopy it now and I’ll cowl the repair I provide you with when that point comes.  

The weapon system surprisingly has the best variety of scripts in comparison with every part else I’ve constructed to this point.  It is at the moment made up of 5 courses and I’ll discuss every of them.  WeaponConfig is a scriptable object to make it simpler for a Designer to create new weapons and provides them distinctive traits.  Right now it has variables for a weapon class, weapon prefab, and harm modifiers.  I additionally selected to place a public enum on this script outdoors of the category to supply Weapon Class choices.  This is the enum that the attacking state constructor is referencing to find out which combo we have to use assaults from.

I made just a few aesthetically pleasing weapon prefabs and hooked up a Weapon script to them.  It has a reference to a corresponding WeaponConfig and will get the harm modifier figures to make use of within the IDamageModifier interface that it implements.  The harm system on this recreation is one other space in want of enchancment so I’ll discuss that later.  This can also be the purpose the place the cyclical dependency turns into apparent.  WeaponConfig references a Weapon which references a WeaponConfig.  I’ll discover a solution to break this sick cycle….

WeaponHitbox is a element of the participant mannequin as a result of it makes use of animation occasions to allow/disable the hitboxes for every of the weapon varieties and it should be on the identical hierarchical degree because the animator, which is on the participant mannequin childed to the participant.  In retrospect, maybe the hitbox must be a toddler of the weapon and never the participant…. Again, this can be a system I want to revisit.  It works for now so I can get a prototype out nevertheless it’s not as clear because it may very well be but.  This script additionally detects collisions for the weapon hitbox and tells any well being scripts it hits when to deal harm to themselves.

WeaponDamage is a quite simple script that loops by way of all of the elements in all the youngsters on the participant, collect up something that implements the IDamageModifier interface, and calculates the full harm that must be dealt.  I like this script as a result of it is neat and serves a single function on behalf of a complete system, nevertheless it would not fairly work proper.  More on that shortly, I promise.

Lastly, is the WeaponHandler script.  This is supposed to be a type of API between the PlayerStateMachine and the weapon system.  This was my beginner try to make use of the Facade sample.  The PlayerStateMachine holds a reference to this script and that must be the one reference it must get any knowledge associated to the weapon the participant is holding.  The WeaponHandler holds a reference to all the opposite scripts within the weapon system aside from WeaponConfig.  It additionally has references to a remodel for every of the weapon varieties.  I have never fairly found out if the weapons range sufficient to want a number of transforms however I’ve them arrange already and they are often refactored down into only one remodel later if wanted.  This script has the strategy that equips the present weapon and it has public strategies that decision strategies within the different weapon system scripts if they’re wanted by the state machine.  In my opinion, this script could be doing an excessive amount of.  I’m a fan of the one duty precept and I see a number of obligations being dealt with right here.  I’m going to take one other stab on the weapon system within the close to future and I’ll be sure you let you know all of my story so you possibly can study together with me.

Damage System
As promised, let’s discuss my damaged harm system.  It technically works as supposed nevertheless it would not meet all the necessities of the venture.  The Designer and I could not determine upfront what all of the harm elements within the recreation must be.  So I set off to create a modular harm system that may very well be tailored as we transfer ahead within the venture.  I’ve the WeaponDamage class that tallies up all the IDamageModifier interfaces and calculates the full harm.  So I simply must implement IDamageModifier on any script that I need to consider on the harm.  At this stage we wished harm to not less than be affected by the weapon and the final hit of the assault combo.  I carried out the IDamageModifier on each the Weapon script and the Attack script.  It will get harm from the weapon no downside!  Unfortunately, the Attack script is pure C# and cannot be hooked up as a element.  So when WeaponDamage is looping by way of all of the elements, it may possibly’t see the interface on the Attack script.

I have never found out remedy this downside but as a result of it requires rebuilding the assault combo system and that is the one downside I’ve discovered with it.  I must discover one other solution to retailer assault knowledge that may enable the Attack script to sit down on prime of the participant or the weapon.  My buddy urged that it ought to sit on prime of the weapon however I do not need my Designer to must outline a combo set for each weapon within the recreation!  I shall be serious about an answer for this.

What’s Next?
In this subsequent dash (I’m calling it that nevertheless it’s not strictly measured – the dash ends once I come to a great stopping level), I intend to work on creating enemies.  I’ll be establishing an EnemyStateMachine similar to I did for the participant and it’ll reuse lots of the methods I’ve designed already.  Since I’ll be capable of reuse a few of the methods, I need to use the time saved to revamp the weapon system.  I believe there’s a way more easy solution to organize all of the elements and, in fact, KILL THE CYCLICAL DEPENDENCY WITH FIRE!!!!!!  If anybody really reads this devlog, I can not wait to replace you on my progress within the coming weeks  Coffee  Thank you for studying and I hope I helped you to study one thing at the moment.



Please enter your comment!
Please enter your name here

Most Popular

Recent Comments