estimated time : 9 mn
ingredients needed : Unity, Playmaker
(this recipe is part of the footvolley game menu )
Now that our player got all the moves, it’s time to stop training with the magic ball and start playing versus an opponent.
We will add a CPU opponent that will go after the ball and sent it back to the player.
It’s time to add rules too ! Let’s review our needs :
- If the ball touch the ground into the gamefield the point is granted for the player of the opponent field.
- If the ball touch the ground out of the gamefield, the point is granted for the player of this field.
- If the ball touches the net, the point is granted for the player of the opposite field.
Pretty simple, we first need to delemitate our new fields (the gamefield in and out).
00:12 Adjusting gamefield dimensions
Create a “In field” where the ball is considered to be “in”, by duplicate the “TerrainR” game object, and adjust the new created “TerrainRIn” to visually match the gamefield.
Duplicate it and do the exact same thing for the other side of the field.
01:03 Creating new tags
Create tags for the newly created game fields : “TerrainLIn” & “TerrainRIn”. We’ll use them into our FSM actions.
01:38 Changes in Soccerball FSM
First disable our “SentBackBall” method of our “Grounded” state (which was used to sent back the ball as the ball touches the ground).
And replace it with a trigger event that will call a new event “onRside” which will link on a new state:”In R Side” if it collides with the TerrainRIN tag.
Basically it says that when the ball touches the ground, if the collider tag is “TerrainRIn” (so inside the right side of the gamefield) go to the state “onRside”.
02:56 Triggering In & Out Field
As we previously succeed to detect when the ball has touched the inside field, we now update this logic to detect whenever the ball reaches the in or the out side of the field.
So on the “grounded” state, we add another trigger event which detect whenever we collide the gamefield tag, then it send a new created event “onRout” which will be link to a new state “Out R side”.
As we’ve tested that the game logic works by playing a little with the ball sent In & Out of the field.
It’s time to give more coherent names to the “In R side” & “out R Side”.
from our player1 point of view If the ball reaches the “In R side” it means that the point is won by the player, but if it reaches the “Out R side” the point will be granted to the CPU.
So rename the states accordingly , “In R side” as “Player Point” and the other as “CPU Point”.
Same thing for the net : if the ball touches the net, let’s link the “Net” state to “CPU Point” directly.
Our game logic is fine for the moment, let’s add the CPU opponent.
05:12 Copying states for CPU
All the states we modify are in the SoccerBall game object, which is a neutral game object.
Meaning even if we first add some player dependent events (PlayerKick event), it’s not exclusive to the player, and we’re now doing the same thing for the CPU; detecting a CPU kick event, with different states.
First select all the states (Kicked, grounded, net, playerPoint, CPU point), then copy / paste them to duplicate all the states.
05:28 Creating new global event
We have to change the global transition for the CPU, in the Kicked2 state :
Delete the PlayerKick global transition, and create and add a new transition , CPUKick.
This is the entry point for the CPU, when it’ll be kicking the ball.
06:03 Renaming events for CPU
Now for avoiding name conflicts, we have to create new variables for CPU.
Here’s a list :
Grounded2 state :
- Just to clarify, we just rename (for both player and CPU) the “onRout” & “onRSide” Events into “In” & “Out”.
- Now we change the logic for the CPU : in the “IN” event change “On trigger Enter terrainRIin” by “On trigger Enter terrainLin”
06:32 Linking states
Just delete the “CPU Point2” & “Player Point2” states, they’re redundant.
As the final logic is the same, to give a player point or a cpu point; we just link the grounded2 In event to CPUpoint, and the grounded2 Out event to player point.
Same for the net, if the CPU touches the net, so it goes for a Player Point.
Now for later we’ll add to Player Point and CPU point states nearly identical actions :
- Send message action calling a method called “playerPoint” or “CPUPoint” accordingly.
- and a Wait event of 0,5 sec, triggering a FINISHED event.
The finish event linked to a new state : Restart.
Which contains the action :
- Restart Level. which as its name suggests, restart the scene from the beginning to play a new point.
What Now ?
The logic’s implemented, from now on you’ll able to easily put the little final steps to get it done.
Think it as homework 😉
- Create the PlayerPoint & CPUPoint method.
- Use them to increment a player & cpu score.
- Polish time : create a prefab in the ressource folder that displays some text (“POINT !” for example). You’ll instantiate it within the playerPoint & CPUPoint methods.
- Trick part : when the level restart, so does all your values; How can we save our scores ?
Do you remember that we’ve got our Game Manager script that’s contained within our main camera ?
Just store there the values that you don’t want to loose at each start of the scene (player score, cpu score, and who is at service), using this kind of dontdestroy script