Good day, MochiLand! In an effort in teach the community about the tools that Mochi Media offers, I’ve decided to start creating a tutorial series spotlighting these tools and how you guys can use them in your games! Hopefully this series of tutorials can eliminate any barriers of entry and get you to making games with even more features!
Before we start, show me how it works.
No problem! Check it out by clicking here!
What is this newfangled device?
With the Mochi API, you are able to have players login into their Mochi account within your game. In addition, you can access their user properties once they’re logged in from anywhere! This means if you utilize this service, a player can save their game at home and use that same data from work. It’s a great way to ensure your game is accessible from anywhere, making longer form games especially alluring since progress is always with the player.
How do I add this into my game?
1. Make sure you have the newest Mochi API. Download it here – v3.8.
2. Read the documentation.
3. That’s it! :)
Please provide a simple example I can understand (AS3 example).
1. After downloading the newest API and unzipping it in the right place, I put all of this code in my first frame to add the appropriate event listeners. There are a number of them available, but these are the ones I figure are the most basic and the ones you should have:
import mochi.as3.*;
MochiSocial.addEventListener(MochiSocial.LOGGED_IN, loggedIn);
MochiSocial.addEventListener(MochiSocial.LOGGED_OUT, loggedOut);
MochiSocial.addEventListener(MochiSocial.PROPERTIES_SAVED, properties_saved);
MochiSocial.addEventListener(MochiSocial.ERROR, handleError);
mochi.as3.MochiServices.connect("xxxxx", root, onConnectError);The “xxxxx” should be your game’s ID, which can be found on the game profile page in your dashboard. I also have placed the listeners before the connect call. If the player previously logged in and has a valid session, this may happen quickly after the MochiServices.connect() and cause the LOGGED_IN event (amongst others) to not be called properly.
You’ll also see that “root” is the default for the MochiServices.connect call. You can specify a dynamic clip here if you’d like. Make sure you understand the implications of having this attach itself to root.
2. You’ll now need the the functions that all those listeners will use. This is how you’ll be able to retrieve information, save information, make sure folks are logged in and so forth.
function loggedIn(event:Object):void {
// Whatever you need to happen when a user is logged in. This may include getting their user name, loading user properties data, etc. The documentation provides examples of what gets stored in this userProperties object. The code you see below is what I used for this tutorial.
loggedInVar = true;
userName = event.name;
var userProperties:Object = event.userProperties // EXAMPLE: Loading data from user properties. Here I am looking for data under the "visits" property.
if (userProperties.visits)
{
visits = userProperties.visits;
} else {
MochiSocial.saveUserProperties({ visits: 0} );
}
}function loggedOut(event:Object):void {
// Whatever you need to happen when a user is logged out. This may include marking that they are logged out, stopping the game, etc. The code you see below is what I used for this tutorial.
loggedInVar = false;
once = false;
}// You can leave this as is.
function onConnectError(status:String):void {
// handle error here...
}// You can leave this as is.
function properties_saved(ev:Object):void {
trace("Properties Saved!");
}// You can leave this as is.
function handleError(ev:Object):void {
switch (ev.type) {
case MochiSocial.PROPERTIES_SIZE:
trace("Properties too large.");
break;
case MochiSocial.NO_USER:
trace("No user logged in.");
break;
case MochiSocial.IO_ERROR:
trace("IO Error with Mochi Services. Not your fault. Our fault. Sorry.");
break;
}
}If you receive the IO_Error in your code, that means something’s amiss here at Mochi. This could mean user properties might not actually work or something else. Bare with us as we try to fix this.
3. Once you have this code, you will then need to show the login widget somewhere. I’ve placed this on my Title Screen. Having this appear is very simple. Notice that you can pass in an x and y coordinate. If you leave that empty, it will default to (0,0).
MochiSocial.showLoginWidget({x:230,y:320});
Now when a user is logged in, it will fire the loggedIn event. If the user is logged out, it will fire the loggedOut event. I have a loop on the Title Screen checking to see if whether “loggedInVar” is true or false. If it’s true, then the start button is active. If it’s false, then the start button is inactive. You can do the same to ensure someone needs to be logged into before being able to play your game.
4. Now to save data, you just use this code (as seen earlier in the loggedIn event):
MochiSocial.saveUserProperties({ visits: newVisits } );
Keep in mind that I have declared “newVisits” prior to this call. It can be a number, string, whatever you need stored for your game. You can also store multiple things at once, so: { visits: newVisits, levels: 20, groceries: false } would have also been valid.
5. (Optional) The last thing to remember is to properly hide the login widget. Having it attach itself to “root” can lead to strange behavior through the rest of your game if it isn’t hidden properly.
MochiSocial.hideLoginWidget();
6. You’re done! This is a simple example of how you integrate the login system and use persistent data! I know it may look complicated to some, but it’s actually quite easy once you get what’s going on. Hopefully I’ve made it a bit simpler to follow and integrate. Remember that the more times that you practice and implement it, the better you will become at using it. It hopefully also provides you with inspiration on how to add features into your game, making it easier for more players to invest their time in it.
Additional Advice
As convenient as it is to have persistent data, it can be a headache for a player if the services are temporarily down. This is why I also recommend that you store the same save data as a local SharedObject as a “just in case”. There are many ways to determine which data is relevant, such as storing a time stamp and using the newest save when both are available or use the data that has the highest rank. It’s all based on how you structure your game.
Also, this would be a good time introduce Universal Data Storage (read about it). This is an AS3 only service that allows you to similarly store and load data for your games. More importantly, it will also be the service that will let you query information stored about your friends, which makes creating a social gaming experience a lot easier. We’re currently building out this functionality and will continue to do so over time. While the standard user properties will always be here, using Universal Data Storage may be a better choice for more complicated, AS3 games.
Comments? Suggestions?
Please let me know if below if you have any comments or suggestions on what you’d like to see next!
Give me the link to the demo again!
Check it out by clicking here!
