I did some small changes in the code and now the prototype is on the ipad. "Only" problem is code registers touches in general on the screen and the specific location of the touch as you can see in the video.
To interact by touch instead of mouse click I changed this
void OnMouseDown()
{
gameObject.tag="smile";
SetCryTime();
}
to this
foreach (iPhoneTouch touch in iPhoneInput.touches)
{
if(touch.phase == iPhoneTouchPhase.Began)
{
gameObject.tag="smile";
SetCryTime();
}
}
and placed the code snippet inside the update function instead of outside. Next up is fixing the touch code so it only works on the object that are actually touched.
// You can use Model-view-controller to make it a bit more meaningful. Just a thought :). Martin
ReplyDelete// View
foreach (iPhoneTouch touch in iPhoneInput.touches)
{
if(touch.phase == iPhoneTouchPhase.Began)
{
// Determine what this touch means in the current context
// if (gamestate in play game mode)
// did player press on gameobject on screen?
// if (player pressed on gameobject on screen)
// then it means we interpret the action as the player wants to interact with the gameobject
// what actions does the game object have?
// Call function which reflects the actual action which the player did.
// gameLogic.playerInteract(gameObject, action);
}
}
// class GameLogic (Controller)
void playerPressedOnGameObject(gameObject, action) {
// Find out what actions the player can do when touching the gameObject
// if (action == something) {
// player.doSmileAndCryAfter();
// }
}
// class Player (Controller)
void doSmileAndCryAfter() {
gameObject.tag="smile";
SetCryTime();
}
// class GameObject (Model)
Wow, thanks for introducing me to the design pattern Model-view-controller. I guess is basic stuff but is new to me:)
ReplyDeleteI should rewrite the code. At the moment most "action" is within in the player class (Kid). Uhhh, think think think...
So would you make a player class, a gamelogic class and a view class?
Yep. Something along that line could maybe simplify your thinking. It is especially helpful when you would like more complex behavior.
ReplyDeleteI would say you can stick with your original programming style which you feel comfortable with. Then if you find out there is something which seems very complex for you, you can try to have a look at this pattern.
I remember starting from scratch again when I was trying to find out how to use this pattern hehe.
----
Some more in depth explanation on the MVC pattern:
The view (ie. the GUI display, which also takes in the responses from the user input device) only needs to take care of redirecting the messages to the controller.
The (logic) controller decides what needs to be done (e.g. update game object models, player state, initiate animation or sound, move coordinates in a model, update the view).
Models are just your game objects, representing location on screen, how they look, what animations and sounds they have. They do not actually do anything, except contain the relevant information.
The view uses information from the models to make the actual displaying on the screen. It does the actual animation. Animation and sound are initiated from the controller (there can be multiple controllers, controlling different parts of the game :D)