Skipping ahead, setting a plan and party movement
So I decided to start writing this blog about 2 weeks into actual development, I'm doing this all in evenings and weekends so progress is slow but it's still incredibly satisfying.
I knew there were certain things I needed to prove before I could get a functioning game working, the first was the grid based movement. Without creating an actual logical grid, I had to make sure I was working with Unity's internal units and go from there. Therefore everything is build with the idea of a single unit, the player party moves one unit at all times, all the dungeon tiles are one unit and all the walls are one unit, just makes everything easier.
I therefore made this test bed for my movement:
The player party encompasses the main game camera, so that it moves when the party does, and the whole room is built from single unit tiles.
With the room setup I had to create a way for the player to move, seeing as this is the first thing I kind of setup, prior to beginning my C# learning, I did this in Playmaker. I also thought it would make it easier to do the collision detection this way, which it would be if I could get it to work properly ;) but that's a different story.
I first used NGUI to set up a bank of controls for the player, in typical fashion the player should be able to move in all four directions, as well as spin 90 degrees on the spot.
This worked pretty well, setting it up in Playmaker was fine too, making the party move single units seemed to keep everything in check. Below is how I set it up, ignore some of the collision checks, they still arent quite working properly.
It was a simple case of then linking the buttons up from NGUI to script, and then kicking off the functions in the playmaker FSM.
I set up a new C# script called party and applied it to the party game object in the unity editor, I could then drag that across into the NGUI button to link the two. The only thing that was needed then was a method for the button to trigger; NGUI has a handy drop down on buttons that will let you simply select the method you want it to trigger on a gameobject.
Now came the process of setting this up in script, there are a number of things I need to do to actually get this working.
(Note, this is me actually learning, there are probably much better ways of doing these things, but i'm following a thought process.)
Firstly, the script needs to know where the playmaker FSM is, I needed to setup a link, so at the top of my party script I set up a public link to the playmaker FSM so that it would display in the editor.
public PlayMakerFSM PlayerParty;
This creates a public entry in the party script on the gameobject in Unity, in which I can drag the object which has a playmakerFSM on it.
I can then reference this within the script by simply using PlayerParty.
Triggering a command from script is simple once you have the FSM link, to send the "MoveForward" command I would write as follows :
public void MoveForward()
{
PlayerParty.Fsm.Event("MoveForward");
And that's it! Once saved I could then go back to the move forward button and should find that the MoveForward even is now available to the button.
Now for each button I simply had to repeat this process and just replace the command with the appropriate one. But I wanted to make this a little easier to use, therefore set up the following.
public void MoveParty(string fsmtrigger)
PlayerParty.Fsm.Event(fsmtrigger);
While this doesnt seem to save me much time now, I later want to add events and checking to movement, and it would be better to control it all from this one place than in 6 separate movement methods. I now had to change the MoveForward event to read as follows :
public void MoveForward()
{
MoveParty("MoveForward");
As you can see it is calling the MoveParty method, but passing through the string "MoveForward" this is the event which eventually gets sent to the fsm, and causes it to trigger.
Once I had set all these up, it was good to test! And thankfully it worked, the player party is able to move a single unit in all directions, as well as being able to rotate 90 degrees on the spot.
Movement, done! (ignoring collision detection for walls of course)
