Use Wordpress as your game's database

Latest updates:

MBSCore

Code (csharp):

1. v2
2. - CML: Deprecated the following functions: ParseFile, DataWithField, AllDataOfType, AllDataOfTypei
3. - CML: Now supports Closer nodes. Example <something> can now have a corresponding </something> node
4. - CML: Reduction of duplicated code
5. - Encoder: Print invalid text if invalid text was passed to Base64Decode
6. - Added new MBSUtilities section
7.  

WordPress Login

Code (csharp):

1. v3.2.1.2
2. - Fixed compatibility issue with Unity2017
3. - Allow for automatic fetching of player's high score during login if the Wordpress Scoring asset is imported
4. - Added a new static variable through which to access the player's high score if the Scoring asset is imported: WULogin.highscore
5. - Added a new prefab that adds Wordpress Login to it's own Canvas instead of you having to make it a child of an existing canvas
6. - Added an option to WPServer to make the Canvas WPServer is on persist between scenes. Ideal use would be during a bootstrap scene

Undocumented feature: The onLoggedIn event passes the response from the server to your functions that it triggers and I have told people to use the variables in there instead of using the global static variable which I may or may not yet have set at the time your code is called. As of this version you can now add WULogin.StoreFetchedInfo at the start of your code to force these variables to get set immediately and thereafter you are free to use those static variables if you prefer.

Wordpress Scoring

Code (csharp):

1. v3.1 - Authoratative server update
2. - Added the ability to set the high scores for other users via:
3.     - player's ID : WUScoring.SubmitScoreForUser( user, score [, game_id, onSubmitted, onSubmissionFailed] )
4.     - username or email : SubmitScoreForUsername( user, score [, game_id, onSubmitted, onSubmissionFailed] )

 

Correct use of CML:

Code (csharp):

1.  
2. Libraries
3.      Lib
4.           Section
5.           Section
6.           Section
7.      Lib
8.           Section
9.      Lib
10.           Section
11.           Section
12.  

This makes life easy since you can get a List of all Libs by simply calling Children(0) and once you know that there is a Lib with id 1 then you can find all of it's sections by simply saying Children(1). Really simple... but there are times when your sections will not be as clearly organised and in that case you don't have a lot of control any more... For example:

Code (csharp):

1. GUILDS
2.      Warriors
3.           Member
4.      Thieves
5.           Member
6.           Member
7.           Member
8.      Mages
9.           Member

This is an example of a bad use of CML but never the less, you might run into such an situation.

In this example calling Children(0) will return ONLY "Warriors". You might now know the ID values of the various guilds (or find out by using FirstNodeOfType("Thieves") )and you are able to access them directly (I.e. the Thieves guild can be accessed by calling data[3] and the mages guild can be accessed using data[7]) (assuming of course your CML variable is called "data").

Unfortunately, this is where this bad use of CML starts to hinder you. Since there is no clear definitions of where a section starts and where it ends like in the previous example where each Lib was seen as a new section, this means that if you call Children(3) you will not receive all the members of the thieves guild but you will instead receive a list of all members of all guilds STARTING from the thieves guild.

As of this latest update of CML, if you insist on storing your data in such a way for whatever reason, at least now I give you a way to clearly say "This is the end of a section" by doing this:

Code (csharp):

1. GUILDS
2.      Warriors
3.           Member
4.      /Warriors
5.      Thieves
6.           Member
7.           Member
8.           Member
9.      /Thieves
10.      Mages
11.           Member
12.      /Mages

Thieves will now have id 4 and calling Children(4) will return only the members of the Thieves guild as you would have expected.

 

Hi MrDude,
Been a long while glad to see you are doing well.

Planning to use your wordpress plugins for some applications for dental practices. I do their websites on a multisite install. I want to give access to the WUSS plugins on each individual website on the multisite. I know your plugins are not set up to do that based on this post:

Is there any way we could easily modify the plugin to show up on the individual sites and to have the separate tables?

Would be fabulous just not sure if that is a quick change or a massive rewrite. Let me know if there are possibilities.

 

Hi mate. Well I have good news and bad news...based on good news

If you want to see the plugins on each site, all you need to do is open the main plugin fine and look at the header comments. In those comments either set Network to false or delete the line. Done. That simple.

Using separate tables per site will require a total rewrite of every single thing as that goes against the very point of the plugins themselves. When you call my plugins you are using WordPress but not logging in to any one particular site on the multisite. The goal of my plugins has always been to install once and then use with all the games you have/are/ will ever make.

Data is stored per game and per user playing that game and as such the plugins all use the same tables. The name of the tables were a moot point and I chose to add the websites table prefix before my own prefix purely for aestetics sake.

So look it at from this way: Data is stored per game, not per sub-site and thus, what would be the point of manually activating each plugin on each sub-site when you can, instead, activate it once and be done with it?

So yeah...showing the plugins on each sub-site is super easy. Creating duplicate tables,though, changes the very nature of the kits at the lowest most root level and would require a complete rewrite.

What was the reason behind needing separate tables, per website, for the same game?

 

Thanks for your quick response. The reason to separate it out is because each dentist/staff will have their own app for their patients - so one app per site on the multisite. They will only be able to login to the dashboard for their site on the multisite. I only want to let them see their/users patients and be able to manipulate data for the app backend for just their patients.

Sounds like ur system would work better on a traditional one site per WordPress install for our use but that creates much more work to manage all of the WordPress installs. Would there be a way to limit which game IDs are available per site on the multisite?

 

Firstly, you do realise of course, that there is one major flaw in your multisite use approach, right? Multisites have different tables for things like posts and site options etc but all the sub-sites on a multisite share a single user table and all people that registered on one of the sites can log in to all the rest using the same login details... Actually, as I understand it, if they log in on one sub-site then they are automatically signed in on all the sub-sites, isn't that the case? You say you want to limit some users from a single user table to only be visible on individual sub-sites? As far as I am aware that isn't possible, is it?

Now, here is the thing you need to explain to me: What tables do you want to duplicate exactly? I don't see any need for duplication of any files...

THEY don't really need to administer my kits from the dashboard, come to think about it. The dashboard is there so you can tell the system what games there are and how many scores to show etc... so once you have it up and running you are done. Then you just focus on the game.

I let people log in with the login details they have on the site and once they are logged in they are playing the game and can do whatever YOU let them do inside the game and that has nothing to do with WordPress's tables that get duplicated per sub-site. Whoever ELSE is registered on the site has nothing to do with whoever is CURRENTLY using the game you built... so no idea why the location of the stored data would be of any concern to you.

Now, you said that every dentist would have "their own game". That makes life even easier since you can have as many games as you want on one website. Just create a new game in the Dashboard, upload the new game to the website, show the game in WebGL using the unique game id generated for each game you uploaded and there you have it... every dentist can have a game as different from one another as Tetris and PacMan and still the location of the data does not matter.

You as the administrator of the multisite would install the games and get them up and running then simply make sure each site loads the correct game and that is it

If you meant to say that each dentist will have their own "copy" of the game but they will all use the same game then I reiterate again, the person who is logged in can do whatever you LET him do and one logged in person has nothing to do with any other person. I use the same user login file that WordPress uses so there is no need for me to duplicate the users table... and all data I save using the WordPress Data package I save to my own table and all data is isolated by user. In the next update I will allow you to see details of other users but for now, the logged in person can only see whatever data he saved.

Thus if he saves data for patient X then he and only he can retrieve the data he saved for patient X. If patient X has his own profile on the website, he can't even see what the dentist saved. With all data being so isolated to only the person who saved it and with me logging in with the same login file WordPress uses I don't see why you need duplicated tables. More to the point, I don't understand WHAT tables you want duplicated.

Email me the exact details of what you want to do and let me see if I can sort this out for you or else I can tell you "This is not gonna work" but I can tell you now, if you want a person to log in and see the details of other people who have accounts on the website, none of my kits allow you to do that so if that is what you want to do then my kits are not for you... if you do NOT intend to log in as one person and pull in WordPress data of OTHER people then my kits will work perfectly just the way they are. If you are still unsure about anything, please, feel free to email me the details and I'll gladly have a look at what you need and give you far better support than I can give you in the forum.

 

Thank you for the long explanation and response!

For multisite, the users can be users of more than one site, but don't have to be. If they are only added as a user on one site, upon login they will only have access to that site and they will only have their specific role level access.

That being said, based on your further explanations it appears your plugins aren't a fit for what we are trying to do at the moment and we are implementing a non-wordpress based solution.

I did also send you a PM.

Thanks again!

 

Sorry to hear you have decided to go another route. Still a bit puzzled by it though... All those sub-sites... the username and password to log in is stored in one table for all sites and my kit uses that table to log in. There IS only one correct username + password combo in that table and my kit checks for that so it doesn't matter what site you want to log on to, the username and password stays the username and password.

One important issue I forgot to address before... Will your app be standalone or WebGL? If it is WebGL based then logging in is even more of a non-issue. WebGL builds only require logging in if the person is not already logged in to the website. If the person is already logged in on the website then my kit doesn't even ask you to log in as it detects that you are logged in and then continues from there.

 

Just to make you aware... CML is getting an upgrade soon also. I have already made the updates and it is ready at this moment. I am currently using it in the TBB Kit update that I am working on and it will most likely only be released with the launch of the TBBK2 but yeah... change is afoot....

"So what has changed in CML?" you might ask. Didn't I just announce that CML now supports closing nodes? What now? Well what now is that CML3 is usable in all .NET environments and no longer limited to Unity only.

Also... CML and cmlData are both now generic classes. This means that no longer are you limited to storing any data you want and converting it to multiple data formats on the fly... no longer can a single CML file act like an entire in-memory database, ready for you to fetch and update any piece of data or search for it with so many options that it might feel as powerful as an SQL driven database... now... now I give you all of that AND let you add your own custom functions to it on a per-object basis as you see fit

No longer does CML only store everything you want, but now you can create a CML file just for player info and have your custom in-memory database manipulate your stats and inventory and whatever else you want to do with that player, all right inside your "database". Have specific needs for your equipment? Cool, build that functionality right in there... CML might very well be the only data type you ever use in your games from now on out...

If your needs are simple...

Code (csharp):

1. CML mydata;

Want a custom system for dealing with player data?

Code (csharp):

1. public class myPlayerSystem : cmlData
2. {//do whatever you want... I.e.
3. public int HP { get { return Int("hp");} set { Seti("hp", value); } }
4. public void TakeDamage(int amt) { HP -= amt; }
5. }
6. UnityCML<myPlayerSystem> Players = new UnityCML<myPlayerSystem>();
7. Players.Load("PlayerData");
8. foreach(myPlayerSystem player in Players)
9.     player.TakeDamage(50);
10. Players.Save("PlayerData");

As i said, based on what the data is that you are using you can create custom functions to manipulate that data (in this case, build a stats system) and CML3 will graciously accept it into itself.

So yeah, that is coming... Contact me via email if you want to get your hands on it sooner but rest assured, it is coming...

 

Updates of MBSCore, WULogin for MBSCore, WULogin, WUData and WUTimers have been released. WUData and WUTimers only contain compatibility adjustments while MBSCore and the two WULogin contain the major changes.... basically an update to CML :rolling eyes: and WPServer that has been updated.

!!!PLEASE NOTE!!!
If you install this version of WULogin then you must make sure to install the WordPress Plugin also. I have made a huge change to how the data is being delivered and while all the other kits are left in tact in terms of your custom code, it does, however, mean that all kits will be broken now unless you update the plugin also.

To put it simply: I know that there are plugins and general errors on your website that might cause additional data to be printed after my data was sent and that that will break everything immediately... and I have been dealing with that for years now. This week I got my first ever notification of someone receiving additional data BEFORE my data was sent.

To combat this new threat I now include markers in front of and after my data and I ONLY parse what I find between those two markers. This means that multiple calls to SendToUnity will be pointless as only the first will be parsed but it also means that errors generated by unexpected data being sent from your website are now virtually guaranteed to be 100% eradicated! Small change, major difference...

 

It seems people are still asking "How do I show a WebGL game on my WordPress site?" Well, if you have the WordPress Login kit installed then all you have to do is follow these 3 simple steps...

#1
Create a folder called BUILDS in the root of your domain. Find the Extras folder in your project and copy the contents of the zip file to the BUILDS folder you just created.
There are only 2 files: noname.png and wuss_index.php

#2
Build your game in Unity, delete the index.html file Unity created for you and upload the entire folder that Unity installed the game into to your BUILDS folder.

#3
Open any POST or any PAGE and just type in the following shortcode wherever you want your game to appear:
[wuss_webgl game=UDEA0 height=500]

Just replace "UDEA0" with the name of your folder. Done. Go to your page and your game will be waiting for you.

THAT SIMPLE!!!!

The code above will display a placeholder graphic until the player clicks on it to load the game. You have the option of making the game load immediately if you prefer, as well as some other options. Feel free to check out www.mybadstudios.com for advanced options.

Here is what my folder structure looks like with 4 projects uploaded...

 

WULogin and MBSCore have just been updated

U2017 seems to have broken the cookie class and thus you are logged out right after your login succeeded. This update introduces a second test for the cookie in case the first test fails.

Also, U2017 changed how the WWW class reports errors and required me to make a change earlier on to get the login kit to work again. Unfortunately I forgot to do that fix for the fetching of Gravatar icons. That oversight has now been fixed also.

MBSCore now introduces a new struct called Int2D. I tend to store my 2D array index inside of Vector2 variables but then I need to do a cast on both x and y every single time I use the index in any what whatsoever. Now I have a replacement that works exactly like Vector2 except it uses int values instead of float values

MBSCore now adds a FromString method to the Vector2, Vector3, Rect, Color and Quaternion classes. These classes all have a ToString() method which is nice and handy for showing values in the console or on screen but it has no means of generating values again from that string, making it useless to store those values. I.e.

Code (csharp):

1. PlayerPrefs.SetString("rotation", transform.rotation.ToString())

was pointless up till now. Now you can simply say:

Code (csharp):

1. transform.rotation = transform.rotation.FromString( PlayerPrefs.GetString("rotation") );

 

WULogin updated again. Credits to Maxime for discovering the Remember me toggle never worked. Nobody, including myself, ever discovered this so that suggests to me that all of us always keep it on In any event, somehow he managed to turn it off and since there was no control over this feature it warranted a fix. And it has gotten it...

ChangeLog:
v3.3.2
- FIXED: Remember me was not working before. Replaced the bool with a property linking directly to the Toggle component
- UPDATE: Encapsulated the masses of public fields that never need changing. This just tidies up the inspector quite a lot

The second change was just something that bugged me for a long time. I need those fields visible in the inspector so I can configure the prefab but you never need to change any of those values so it bothered me that it was always visible. Now the inspector has been tidied up and looks like this:


...now that toggle field bugs me Will hide that under fields in a later update

 

I am currently busy updating one of Unity's demo scenes.See if you can spot what's new

 

Turns out using this kit in VR was a tad more complicated than I originally thought. Before when people asked me "Can you use this in VR?" I replied with "i never tried it so I just don't know, sorry". So when I got my Rift my first quest was to test and make possible the ability to use this in VR...

First step was to make this entire thing work in world space since it would be rather pointless to have this floating in the center of your view no matter where you looked... more so if you are using a Gear VR. That part was super easy. Just changed the Canvas Overlay mode to WordSpace, Scale the entire canvas to (0.008, 0.008, 1) or else Unity is simply unable to display text since 1px size fonts are 1m / 1 world unit in size. Use a normal, full size canvas and scale everything down drastically and you get good looking text. So there you have it, all done and converted for world view in a matter of seconds

Then came the next big hurdle which I didn't think of before. On a mobile device you touch the username field and you get a native keyboard pop up. There is no native keyboard for VR so now what? Simple... I created one. I created a world space keyboard that is 100% skinnable and absolutely customisable. You can add as many different button layouts as you choose and at runtime just say "show me set number 2". By default I have 3 sets: Uppercase, lowercase and symbols (all with numbers and only the first two with a spacebar).

I like using enumin my code so I created an enum which I then convert to int but you don't have to do it that way... it's just my personal preference. Again, you can have as many layouts as you want and have each contain whatever you want. You could go with QWERTY if you like or, as in my case, go with ABCDEF... Entirely up to you.

Code (csharp):

1.            string [] sets = new string [] {
2.                 "1,2,3,4,5,6,7,8,9,0,A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z,.",
3.                 "1,2,3,4,5,6,7,8,9,0,a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z,.",
4.                 "1,2,3,4,5,6,7,8,9,0,`,~,!,@,#,$,%,^,&,*,(,),_,+,-,=,{,},[,],:,|,?,."
5.             };

Code (csharp):

1.         public void ButtonClicked(string button)
2.         {
3.             switch ( button.Trim().ToLower() )
4.             {
5.                 case "case":
6.                     vertical_group.GetChild( (int)current_set ).gameObject.SetActive( false );
7.                     current_set = current_set == vrkbeSet.Uppercase ? vrkbeSet.LowerCase : vrkbeSet.Uppercase;
8.                     vertical_group.GetChild( (int)current_set ).gameObject.SetActive( true );
9.                     break;

Right, so getting the keyboad made was easy as pie also. Added a bunch of features to make it suit a wider variety of needs of more people... and then I hit my first brick wall. When using this keyboard in normal games the keyboard works perfectly but as soon as you go into VR, how do you detect a Unity UI button? Obviously the mouse is of no use in VR so what? How do you cast a ray into a UnityUI element and detect you have now intersected it?

For that part I had some assistance by the guys over at Oculus who eventually gave me a replacement for the GraphicRaycaster element... meaning now the input works ONLY in VR and not in normal games any more. I can live with that since it is the VR thing we are trying to do here, after all...

But then came the final hurdle and the one that would have forced me to answer "No, it doesn't" if anyone had asked me if the login kit works in VR. I couldn't figure out how to pop up the keyboard when you click on a text input field.I tried adding a button inside it and overlaying it on top of but still the cursor blinked in the text field and no keyboard was to be seen anywhere... So I rewrote that entire sample GUI that I've been giving you all to use and now added a VR ready one that replaces the text input fields with a custom input type I created just for the VR kit. As always I make it as simple as possible to use for those who wish to modify and tinker with things but I still give you a fully functioning system non the less.

Final result: Everything now works like a dream The system works in VR like nobody's business. See the following sample and please forgive my super slow internet spoiling things

2 last notes...

1. I am not sure how I am going to deliver this update since the Touch input requires a lot of Oculus scripts and prefabs etc and those will be updated by Oculus themselves on a rather regular basis so I am not very keen on giving you guys loads of unneeded and outdated code in multiple folders all over the show... yet without it the touch input won't work. Considering that I am only dealing with Touch and yet some of you will be working with Vive, Cardboard, the free VRTK kit and who knows what else, though, I am thinking the best thing to do is to give you the keyboard and the new prefab and let you make use of the plethora of sample code in the Asset Store and elsewhere to create your own input system for clicking on buttons. Unity gives you a working example of a gaze input system, for instance... perfect for cardboard...

2. I created this code using C#6. I want to start moving all my code over to C#6 so starting with this next update my kits will only be compatible with projects that use C#6. Thought you should know. If you don't want me to do that then let me know and I will release this VR update as a separate, paid, optional asset that will require C#6 if you want it. The power is yours

 

Skin your keyboards as much as you like then select your preferred keyboard by changing one field in the inspector...

 

Well I must say that the interest in this announcement has been disappointing at best. Will this update be worthwhile or will it just make people angry for having to upgrade to 2017.3 and use C#6? Hmmm...

Well let's do it this way, shall we... Unless there is an overwhelming demand for this update I am going to go ahead and NOT make it an official update. I have it up and running, though, so to gauge the interest in this, I am going to do it this way: If you want this update, send me your invoice number so I can see you have the Wordpress Login kit and then just ask me for this update. I will then send you a link to the 6Mb download.

Looking forward to hearing from you

 

I think making it an alternative option for those who need it is a good idea. What you might actually want to do is make it a specific VR pack and offer an upgrade from the current kit.

I'm not working on this part of a project at the moment so I didn't really pay close attention to the announcement post. In looking back, there are three things of concern to me in updating the pack.

1) I have no interest in VR so I really don't need a VR update. From a quick skim it requires me to get Occulus files? Does that mean it is Occulus specific for those who are developing for VR? If so, that could also be another issue. For me, I would prefer to stick to a non-VR version or a version where the VR stuff can be installed as an addon option.

2) I hate being forced to be bleeding edge. I'd still be using Unity 5.6 if it hadn't been for Vegetation Studio using instancing features that weren't introduced until 2017.1. For that reason I upgraded but am currently remaining with 2017.1. (This is also the point where I removed the WP addons temporarily because at the time, there were problems and since I didn't need atm I figured I would pull the addon and check back when I needed. I've seen in updates you have since resolved.)

3) I have no clue of the impact of forcing C# 6 but if it causes problems with using other assets that weren't developed in C# 6, that could be very problematic as well. My thoughts would be making that kind of decision for your own project is fine, but for an asset it could definitely be an issue if it requires a whole project to be C# 6. As a single person indie development team, I rely on the asset store to give me shortcuts so I don't have to reinvent the entire wheel from scratch. If I can find assets that fit what I need or fit my needs after some modifications, that saves me a lot of work. If I were to have to go back and check through everything to convert to a different C# version, I'm not sure one asset is worth it. It would probably take less time to recode the function of the one asset requiring the change.

Again, not saying the changes are good or bad. I really need to read through a little closer what they were. But those are my thoughts from a quick skim of the last couple of posts.

 

Hi Shawn. I was actually hoping to send you a copy to try out but since moving over to the PC for some odd reason my mail no longer recognises ppl in gmail or iCloud that I had mailed before... and do YOU think for one second that I can remember email addresses off hand? lol Anyway, down to your concerns...

UnfortunatelyUnity doesn't offer upgrade paths to free products so if I make this an optional upgrade then I HAVE to charge ppl for it AND then I have to maintain two versions (well actually 4, to be more accurate) of the same kit. So either I give it away with the kit if ppl want it or I just keep it for myself and my own projects.

Your concern number 1:
In order to work with GearVR or Oculus you are going to need files from them to make things work. Period. Unity includes it out of the box but Oculus keeps releasing updated versions. I think the built in version of the Oculus tools in 2017.2 was v16 or v14. Oculus is already up to 20. I am including the minimum amount of files needed to use this with the Oculus Rift but whatever I give you will be outdated much faster than I can copy paste the updates they give you for free anyway back into this kit and republish.

Nevertheless I am doing so. If you just install their first then mine won't get installed and if you install their later it will overwrite mine so I guess it's fine... just looks ugly because there are a lot of extra stuff in here now so it doesn't feel as clean as before. Note, though that ALL VR platforms will have the same issue: There is no KB. This solves that by giving you a KB. In fact, I am panning on releasing this as an in-game keyboard as a standalone project but NOT for VR. You can then add some form of touch input (gaze, controller, custom, VRTK, whatever...) and MAKE it VR compatible if you want. My intention was to inclue a ready made VR version with this kit also and include it as a free update. How I made the keyboard attach itself to the various input fields means it can be used with anything VR but I tested it using Touch and thus I give Oculus scripts with it.

Concern 2:
Yeah, I am with you on the bleeding edge thing. up till right now all ALL my assets still support 4.x. I hate forcing people to upgrade so I try my best not to do it. In this instance, though, I did about 90% of the work in 2017.2 before I realized "Doh! what have I done!?" and unfortunately, prefabs you can't take backwards in Unity versions so 2017.2 it was gonna have to be. Unfortunately, there was a bug in Unity that resulted in you always getting an error message about invalid image formats no matter what you do (heck, it's not even your images that are the problem!) and that was fixed in 2017.3 so I upgraded to that and went "Doh! I did it again!" So, err... 2017.3 it has to be. My bad.

Having said that, though, I plan on stopping all support for 4.x from today forward. 5.0, maybe, but I am thinking of releasing updates from 2017.3 onward from now on. Just move my minimum support from 4.x to 2017.3 and then support that for the next 2 years like I have supported 4.x up to now.

Concern3:
If you set your project to use C#4 then that is all you can use but when you set it to use C#6 you can use both. C#6 ADDs to C#4 so there really is no reason NOT to upgrade if you ask me. As for the code itself, omg, man, it is frikken lovely. The code for the buttons, everything including the Start function was done in only 4 lines of code. C#6 is the bomb. I am never again coding anything in C#4.

Unity has already said that they are going to make C#6 / .NET4 the default build target for Windows platforms either in this version or 2018.1 so starting next month, C#6 will start to become the default anyway so why run and hide from it now? I agree that it sucks to tell people to upgrade but unfortunately this was coded in C#6 and it would make no sense to go back and ADD more code to the project just to make it backwards compatible with something Unity is already starting to phase out...

Short version: All the C#4 assets still work just fine... C#6 just makes a lot of code mush less code and gives you a bunch of extra syntax you can use. It won't break anything... just make life easier if you have it enabled. If you haven't started playing with C$6 yet, dude, I seriously suggest you do so. You will love it. You can't NOT do!

 

Example...
This is the code for the keyboard's individual buttons:

Code (csharp):

1.      public class vrkbButton : MonoBehaviour, IPointerClickHandler
2.     {
3.         [SerializeField] Text button_text;
4.         public System.Action<string> click_action;
5.  
6.         public void SetText( string text ) => button_text.text = text;
7.         public void Start() => name = $"Button_{transform.parent.name}_{button_text.text}";
8.         public void OnDestroy() => click_action = null; //not really needed but my paranoia dictates I add it
9.         public void OnPointerClick( PointerEventData data ) => click_action?.Invoke( button_text.text );
10.  
11.     }

This is what it would have been otherwise:

Code (csharp):

1.     public class vrButton : MonoBehaviour, IPointerClickHandler
2.     {
3.         [SerializeField] Text button_text;
4.         public System.Action<string> click_action;
5.  
6.         public void SetText( string text )
7.         {
8.             button_text.text = text;
9.         }
10.  
11.         public void Start()
12.         {
13.             name = string.Format( "Button_{0}_{1}", transform.parent.name, button_text.text );
14.         }
15.  
16.         public void OnDestroy()
17.         {
18.             click_action = null; //not really needed but my paranoia dictates I add it
19.         }
20.  
21.         public void OnPointerClick( PointerEventData data )
22.         {
23.             if ( null != click_action )
24.                 click_action( button_text.text );
25.         }
26.     }
27.  

See how much simper C#6 makes even a simple class like this? Now imagine this type of simplicity across your entire project... how can you NOT instantly love the fact that all your old code still works but you can opt to simplify your life this way... all you have to do is type it one way or another... Why would you choose to do things the hard way if you don't have to?

But yeah, this is the reality of the situation... I created this VR add-on because a couple of people asked me for it. Including it will require a Unity Update and that you enable the latest version of .NET so you can use C#6. With this being the case I now leave it up to you guys to decide how badly you want it: Is it only the handful of people who asked me for it or do you all want it?

You decide, I will make it so...

 

lol.. I can definitely relate. Similarly, I didn't remember this asset was free so I didn't catch the free upgrade issue. heheh. If that is the case and you don't plan on charging, maybe you could just provide a free add-on that adds the VR stuff for those who need it.

To be honest, all the VR explanation sounds confusing and sounds like bloat. I think it would probably be better just to document the dependencies and just have the user download the latest third party files prior to installing the package if they need to have VR support. That also takes the bloat out for those of us who have no interest in developing for VR.

Same with the onscreen keyboard. Those of us developing for desktop really don't need it, at least I don't for anything that I have in the pipeline. So this could be another thing that may alienate some of your customers by forcing them to update to a newer Unity version. May be another option for an addon module. If someone needs that specific module, it makes updating to a new version because of its requirements a little easier to swallow. Having to update a Unity version because of a feature you don't actually need so you can keep up to date on the rest of the asset, not so much.

The C# version stuff makes sense. I thought that might be how it worked but wasn't 100% sure if by selecting that new version if there would be code that was deprecated to the point of breaking things or if it would still be functional. As for Unity 2018, I'm a little scared. lol It almost sounds like they are doing a lot of big changes and I almost feel like they've done away with beta and we now beta with all these new versions and releases. From the sounds of it listening to some developers it is almost like they've gone from one extreme to the other, not releasing often enough to new releases too often. I guess that is another reason why I try not to adopt new versions too quickly. Just too much time changing for new releases and not enough time making new stuff. heheh

 

No no... you got it wrong... The login kit costs $30 but I wanted to add this VR update for free. You said "offer an upgrade". Unity doesn't let you "offer an upgrade" that doesn't cost people money. I plan on releasing this kit in a non-VR ready form BUT I wanted to include a VR-ready version for free within the WordPress Login kit. See the problem there? I want to make it free and you suggested I let people "upgrade" which was gonna cost them money.

Actually, reading your comments it has become clear that to address your concerns the path I should follow is to release the Keyboard as a standalone asset in a non-VR capacity (as I intended) and provide the VR update as a separate download from my website. Remove the whole VR support from the Login kit entirely and let those who have an interest in VR pay the extra $5 for the extra stuff they need. Cool. So the vote is currently at 1 for removing the free upgrade and 0 for keeping it in. The tally has started

As for 2018, dude, your fears are warranted. They are changing the entire render system and have sent out emails to authors to make sure their content is compatible before they release it. Far as I can tell, if you use Unity UI or the Unity Standard shader then you have nothing to worry about. If you use anything else then you have some compatibility checking to do... 2018.1 has me scared of the whole bleeding edge thing. Fortunately, my assets are code based and use Unity UI so it doesn't affect me as much... but this conversation is getting drastically off topic.

I will end off with this though... Although 2018.1 has me a little scared after receiving that email, I honestly don't see the difference between releasing a new version every 3 months vs releasing a patch every month. Why are the patches a godsend and every 4th patch being labelled a new version "a problem because they release updates too soon"? The way I see it, the latest public version is just the next patch that came after the last patch... each one improves something that was broken then they move on to fix something else. Rinse repeat.

But that i just me. Like I said, getting way off topic now. Feel free to email me if you wanna discuss this topic any further. (If you can find my email address in your contacts list that is lol Let's see if you are better at that than I am XD )

So, 1/0 for not adding the VR keyboard to the asset. Waiting on people to make the case for otherwise...

 

To my utter horror a customer pointed out a bug and I confirmed it on my end... the WordPress for Unity kits are non-functional in 2017.3!!! :O

If you use GET then you at least stand a chance but for POST users Unity has gone and messed up big time. Apparently, when you make a POST request to a website you need to send along the content length as a header value. All these years Unity has taken care of that for us but as of 2017.3, when you set any custom cookies Unity erases the content length header. When you try and set it yourself you are told "You are not allowed to do that. We do that automatically" ...except they don't.

I have filed a bug report and now wait to see if they fix it in a patch but for the time being 2017.3 and my kits don't play nice together.

 

Good news and bad news, everyone.

First, the good news:
I spoke with someone at Unity and they showed me a workaround so I am happy to announce that so far it looks like the kit is back up and running again.

Now the bad news
The current version of the WordPress Login kits have, unfortunately, reached their end of life effective immediately.

How does that affect you?
The login kit and all the other kits all work perfectly fine on all versions of Unity 4.x up to 2017.2 but does not work in 2017.3 so I am leaving the current version of the login kits on the store and anybody who is using a version of Unity prior to 2017.3 can still download the asset from the store just like normal and they will work just as they always have. Unfortunately, if you try to run the kit in Unity 2017.3 it will compile just fine ... then simply won't work.

I plan on releasing a new version of the kit that uses 2017.3 as the minimum version. This update will not cost you anything and all you need to do to get it is download the WordPress Login kit from within that version of Unity.

For those of you who do not know this, publishers like myself are able to upload different versions of our assets, compatible with different versions of Unity. All those versions lay on Unity's servers and based on which version of Unity you use to download the asset with, Unity will send you one version or the other, based on which version will work for that copy of Unity. This will be the case here.

the asset as it stands now works perfectly fine and will remain available to you. If you have 2017.3 or later you will need to download the asset again before use. Any and all future updates and new features added to the kit will be released to this new version only so that is the only catch. The old version will still work 100% fine while the new version might get new features down the line. Only catch.

So why the change
Simply put, the WWW class is broken. Based on what I've read the WWW class is nothing more than a wrapper around the UnityWebRequest nowadays except heaver on dependencies. It also sounds like Unity is urging people to use the UWR class instead of WWW and in this case using a UWR allows me access to a setting that is not available in the WWW class and that setting allows me to bypass the problem that broke this kit in 2017.3

Unfortunately, the UnityWebRequest class was only added somewhere in 5.x and back then it was placed within the "Experimental" namespace, later to be moved to the "Networking" namespace. The current version of the WP Login kit supports Unity 4.x through 2017.2 but since the UWR lass was only introduced somewhere within the 5.x series it means some versions of U5 simply cannot be supported. In addition to this, the various versions that are supported will require additional code to tell it where to go look for the code...

...but, like I said, I already HAVE a fully operational version that supports all versions right up to 2017.2... so I am leaving that version up for anyone using those versions of Unity. Since 2017.3 is the first one to cause the kit to break, it is the first one that NEEDS the new version and thus I am making it the minimum requirement of the new version.

 

Before I go ahead and upload this new version, though, I would like to ask a few people to test the new version on various devices for me. I am particularly interested in Mac users who can verify that the kit works on MacOS and iOS.

If you are interested in beta testing the new version, please contact me @ support @ mybadstudios.com and send me your invoice number showing you own either the WordPress Login for MBSCore or the standalone version and I will then email you the beta.

Thanks in advance to anyone who volunteers to test drive the beta for me

 

The original first draft of a game I was making. This is just a POC to make sure things work and then later I would have gone and prettied things up. This does, however, show a pretty decent example of how you can customise the default prefab I include with WordPress Login.

Here are some useful tips for you when trying to customise the login prefab. This makes life so much easier, trust me... Before you start, make sure to have the prefab in the scene...

Firstly, the font. Thanks to my naming convention used in the prefab, if you just type in "text" in the search box it will bring up all the text used in the prefab so just drag your selected font into the font field in the inspector and all your text fields are updated in one go. How easy was that?

Next, you will notice that each separate screen that you will see is placed in a parent of it's own. Inside each are, again, common elements named using a naming convention that makes it easy to identify. Select all the Cancel and Accept buttons, for example, and modify their sizes and positions in the inspector all in one go. You just have to have one panel open so you can see what you are doing and then all of them will be placed correctly in all panels.

Same with the splash screen and the actual panel background image... Disable all of them or set them to a new image all with one drag of a Sprite to the inspector. Modifying that prefab is such a piece of cake!

The only 2 things to be aware of is how well your new fonts work with the text fields and to manually mod the personal info screen (if you even decide to use it). If the text fields don't work well with the size and spacing... just select all of them and change the inspector values once. Again, the naming convention I used makes it super easy to find them without having to see them or search for them. That easy.

Enjoy

 

I'm waiting to see if the Asset Store accepts my new submission but they seem to be taking rather long after the holidays

Right from the start my goal was to release each piece of functionality on it's own so people can pick and choose what they want and only pay for that, not for everything I do but I am now releasing a combined package also.

This combined kit will always cost $50 more than buying the parts separately but once you have it, all future kits will be added to it also... so the sooner someone buys it the sooner they will start seeing value in it. This kit will be released under the "Complete Projects" section of the store as it will contain a game with all of the kits integrated already. I am using the Unity demo with the sleeping boy killing the teddies and the bunnies and adding extra weapons, limiting your lives and ammo and integrating a store to buy ammo and upgrade your weapons etc. The game will be placed on my website later on for people to play and see it all in action.

Since c#6 comes free with Unity and it makes life so much more simple, I created the game in it and I am releasing the kit with C#6 as a requirement. In future I might upgrade the existing kits to C#6 also but for the time being there is nothing to be gained by changing the "existing working kits" into "still working kits but with a language requirement" so for the time being it will remain unchanged.

So now, let's see if and when Unity accepts the kit...

 

A customer requested I add localisation to the login kit so I did so. Instead of trying to learn a bunch of new languages or relying on Google translate to do a good job I instead opted to let you do your own localisations. I created it using standalone assets so any one of you who speaks a different language can drop a localisation off here or via my email or something and we can create a library of localisations created by native speakers. the kit will be released with English and Afrikaans by default and the customer who requested this said he can add German and Chinese so we are off to a good start. Localisation support is currently limited to 25 languages but you are free to pick and choose which ones you want to use.

 

Unfortunately, I must add that I truly hated working on this update. Being used to C#6 I felt dirty coding this extension using all that unnecessary code and elongated syntax and all and all it just felt horrible to know I could do this so much better but to maintain legacy support I had to do the job in less than optimal code...

The combined version of the assets also includes an updated login kit with additional features not currently available to you. I tried copying them over and once again I just realised how much simpler C#6 makes life. In my previous post I said that I don't see the point in converting a working kit into a still working kit but with a language constraint on it.. but after making the other kit in C#6 and after adding this new feature and looking at how much more effort it takes to write C#4 code, and then factoring in that I will be coding in c#4 for individual kits and and C#6 for the combined kits, the duplicate maintenance doesn't seem worth it. Extra work to deliver code that is less good than what it can be...

Finally I am seeing a justification for upgrading to C#6. As such, be advised that the next update with require than you upgrade your project to run on.NET4.

And just for good measure, some of the changes made to the login kit so far:
1. Localisation (obviously )
2. All kits can now simply pass in an enum when contacting the server instead of having to manually convert the value to a sting first
3. WULogin now scans for the presence of WUMoney and creates a List<string> of the currencies your game uses
4. I overhauled the panels system in the personal details section. Instead of sliding up the contents of a masked sliding region you now just have plain simple game objects that can be turned on or off based on which panel you want to see.
5. Fixed a bug preventing you from creating games on multisites

I am also working on a completely new WUData package... more info on that later. First, let me get this update out the door...

 

Does anyone here speak Japanese? I would GREATLY love to be able to ship this with Japanese localisation included!

Anyone else who wants to contribute a language please feel free to do so. Email it tome when you are done to have it added to WordPress Login or share it here if you like. I am including the localisation script to this post. Just create a folder called Localisation (for organisational purposes only) and then select the Assets->Create->WULLocalisationData to create the asset. Complete the fields (shouldn't take you 5 minutes) and then export just the Localisation folder as a UnityPackage by clicking on Assets->ExportPackage (or just zip the folder) and you are done.

Everyone who speaks your language thanks you for the 5 minutes you took out of your day

 

Hi @MrDude , I'm quite familiar with Wordpress but wanted to ask exactly how some of these assets communicate between Unity and Wordpress. For example one thing I would like to be able to do is take a screenshot in game, and then upload this screenshot as the logged in user's profile picture in Wordpress if that makes sense. Is it possible for me to communicate this from Unity to Wordpress in this way? Also, I plan to use WooCommerce plugin to create a small online store of game items. I would like when a logged in user buys these items on the Wordpress website they then become available ingame. With this asset can I communicate between Wordpress and Unity in this way?

 

Hi Hamesh81

WordPress doesn't have a default Avatar system. It uses Gravatar.com to host the user's avatar or I have heard there are plugins that associate an avatar with your account. Both of these are third party product and while my kit can be easily extended (see the website to see exactly how easily) I do not natively support 3rd party apps, no. I do fetch thee user's saved Gravatar from there, yes, but I do not make provision for you uploading screenshot to their site, no.

Having said all of that, WUData does allow you to store anything that can be turned into a string so if you were to take the screenshot and then convert it to base64, you can save that to your database, no problem. Of course you would have to write a function to convert back from base64 to PNG but at least it is possible natively, yes.

As for the store, I am planning on creating exactly that myself, also. A store that will allow you to sell stuff via WooCommerce on the website and then have the content available in game. The current assets do not yet have that functionality but the good news is that all you have to do is write a hook for WooCommerce that triggers on the transaction being completed and in that action all you have to do is save your purchases to my table and that is all there is to it... those items are now available in the game.

The last person to ask me about this, I sent him some code and his reply was "I thought it would be something easy but I never imagined it would be THIS easy" .

Here is the all-in-one answer: Each of my kits do what they say they do and nothing more. They can be extended incredibly easily to do absolutely anything you have the skill to do but out of the box I don't integrate with 3rd party plugins or websites.

I think that subs it up nice and simply

 

Thanks for that detailed answer. I will try it out and let you know if I have any other questions.

 

More than welcome. On both counts

 

Woocommerce driven cash shop would be awesome! At least I think that is what you are describing. Having some brain/comprehension issues right now but if I read your post right, that might be what you are talking about.

 

That's exactly what I am talking about, yes. You will not believe how easy that actually is! I just have to find that script somewhere in my sea of backups (been looking for one asset I wanted to work on today and spent the entire day looking for it. Sold my Mac and had to split my data across various drives now have duplicates from Mac and PC with some being years older than other versions and some now apparently lost it would seem... it's a mess right now )

...anyway, add that script to your website and you are done. That simple. Now you just have to pick a naming convention for the SKU so you can identify the item as being in-game-content as opposed to whatever else you have on the site and then just write a function to say where to save the content to after it's been identified. That easy. So you add one function to store the items to the wp_wuss_data table and then upload that one script and you are done...

But what I have in mind is a little more complex than that. I want to enable you to define the items in WordPress and specify what games this item can be used in then allow you to buy/unlock/win/receive/whatever an item in one game and use it in another. I.e. Play Mario Kart with Link from Legend of Zelda and win a Golden Sword trophy after 100 1st place wins. Now open up Legend of Zelda and find the Golden Sword in your inventory as a usable weapon. Just a simple example.

Items can be specific to a game or shareable between games you choose. Also, since I am redesigning the WUData asset and planning on releasing a Pro version that completely changes the table structure and name, making the old and new versions completely incompatible it means saving the items to there is going to be problematic at best... So instead, I will be creating an online items database of items you create and then an online inventory that saves your online and in-game purchased items online.

This means I will be creating the SKU for you and taking control over how items are detected and where they are stored. Lots to do, lots to do... but if you want to just store it directly for use via the WUData kit, that is easy as pie to setup...

 

The combined kits are now live ...
Standalone edition
MBSCore Edition

The MBS Core edition requires the MBSCore kit while the Standalone Edition will include the parts of MBSCore that it uses. The combined kit's price will go up with every asset that gets released so those of you who bought the assets separately don't have to feel you got a raw deal. The benefit of this kit is that when you get it, all future assets are included for free so even though it costs you a little more initially, in the long run you end up saving.

Additionally, I am working on a demo game that includes all the assets so you can have a working game that shows all of this in use. The demo is a remake of Unity's 3rd person shooter except in this version you get to shoot your gun, throw hand grenades and drop bombs. Your gun no longer has infinite range but instead shoots a very short distance. Additionally, you now have ammo limitations...

Your score determines your cash earned for the level and the cash can be used in the included shop to:
1. Unlock the other two weapons
2. Extend the range of the three weapons
3. Increase the damage they do
4. Increase your max ammo
5. Buy your grenades and bombs (gun ammo is refilled each round but special weapons need to be purchased)

Your performance determines your points, your points determine how much ammo you can carry and thus your performance. Your play is limited to 5 lives with a 30 minute counter between free lives being awarded.

And of course, there are the leaderboards, needless to say What's the point of all of this if you can't get competitive

I'll be releasing the game for play on my website and including the source in the assets.
Enjoy

 

The feature list for the new WULogin just keep on growing.

I now have optional panels for a shop, high scores and just one extra for good measure. I don't add buttons for them as part of the default login prefab but I do include the functions so all you have to do is add a button to one of the panels and select the relevant function to open up the new panels. Closing it down again, that I support.

The prefab now displays "Please wait" and a rotating spinner while contacting the server. The PleaseWait is done using UnityUI rather than the included OnGUI version.

Also, since I am now showing the spinner while contacting the server but you are able to make multiple calls to the server at once, I added Automatic Reference Counting to the server. Up till now you just contact the server and wait till it is done and do whatever you want when that happens. The server state is changed from Contacting to None as soon as the first server response is received but you never needed to know of that bug since the server state was never of any consequence. Now that it is I have added ARC to make sure the events are triggered only when they should.

Which brings me to the next change, the server now triggers an event when the state changes. Again, this was never really important since you could just check the public ServerState variable at any time but now I offer you a means of starting and stopping stuff without having to constantly check the state in a loop. Those who requested this feature, rejoice, for here it is!

The biggest news, though, is that WULogin now has the added ability to fetch a list of games and their associated IDs. WPServer is now making use of this feature by allowing you to assign your game id by selecting the game from a drop down list. This means that the GameID is now completely hidden from you except for when you want to use it in code. Since this dropdown will only list games that have been created on your website it means that the legacy system where you just suck a random value out of your thumb and having no link between the game and the website is now removed.

 

Looking for 5 people who have the time and is interested in trying out the new WULogin kit for me... Be advised that you will have to be on 2017.3 or later and enable .NET4. If you are interested in taking it for a test drive, please email me and we can take it from there.

The kit is ready (apart from me having to update the documentation for the new WPServer workflow) so I just need you to see if you can find bugs that I have missed. Once I get the go-ahead from you guys the update can go live...

 

Here is the full change log for WordPress Login v5.

Code (csharp):

1. v5
2. - Converted the code to use C#6
3. - Simplified / shortened the code in the demo scene, GUI and WULogin using C#6 syntax
4. - Greatly simplified the personal details tab system making it easier to customise
5. - Fixed a bug which prevented you from creating new games from the multisite admin dashboard screen
6. - Added support for up to 25 languages per game
7. - Now ships with localisation for English, Afrikaans, German* and Chinese*
8.     * Special thanks to Michael Borgers for the translations
9. - Created the WPServerErrorException custom exception
10. - WPServer.cs now throws exceptions rather than using Goto statements and labels
11. - Contacting the server now sends data only via GET or POST, no longer duplicating the data "just in case"
12. - Removed data structure checks when calling the server for platforms that have been removed from Unity's Build Settings screen
13. - Broke up the long and confusing CallServer function into smaller functions to clarify what each part does
14. - Added a ContactServer overload that takes an enum as the action. You are no longer forced to convert the enum to a string first
15. - Renamed the server state enum from WULServerState to WPServerState
16. - Added Automatic Reference Counting to WPServer
17. - WPServer's state now only changes from Contacting to Done when ALL active server requests have completed
18. - WPServer now triggers an event upon server state changes
19. - Game IDs are now set by choosing the game from a drop down list. No need to manually enter the Game ID found in the dashboard any more
20. - Game IDs are now selected from a dropdown box which means support for manually selecting random values have been removed
21. - Modified the WULogin functions to use enums, not strings
22. - Made a number of previously public variables into private variables that cannot be changed at runtime, only set via the inspector
23.     - Examples: the urls to your website, which url to use, the game id, meta data to fetch, the size of your Gravatar etc.
24. - If WordPress Money is installed:
25.     - The names of the currencies you use are now accessed at runtime using the public CurrencyNames property
26.     - Added a static CurrencyString( string currency_name ) function to format the currency name as used in the usermeta table
27.     - Added a public CurrencyString( int index ) overload to call CurrencyString via the currency's array index instead
28.     - Added public Cash( int index ) and Cash(string currency_name) functions to fetch the current balance of specific currencies
29. - Changed previous readonly strings into const strings instead
30. - WUUGLoginGUI now derives from WUUGLoginLocalisation but your own custom GUIs can still derive directly from WULogin as always
31. - Added a bunch of new panels to the demo prefab
32.     - A high scores panel. Optionally trigger the WUScoring.FetchScores if the scoring kit is installed
33.     - A panel to show a store in or, alternatively, use this panel's display function to load a shop scene instead
34.     - A general purpose panel... just in case you have need for one more...
35.     * NOTE: Localisation is not supported in optional panels. You will have to add that yourself if needed
36. - Removed a bunch of "using" includes in files that didn't use them
37. - Force the static data to be set after login before your custom responses are called instead of potentially later that same frame
38. - Force the static data to be cleared on logout before calling your custom actions
39. - Removed the need to call InitLoginSystem in the GUI's Start function
40. - Automatic fetching of your Gravatar image on login is now an optional toggle
41. - Prefab updated to now show a spinning graphic and "Please wait" text while busy contacting the server
42. - WULogin now allows you to fetch game names and their associated id's at runtime
43. - WULogin now allows you to create new games on your website directly from within the Unity editor (logged in site admins only)
44. - Updated the demo scene
45.     - Scans the local list of game definitions for a game called Demo Game
46.     - If required it will fetch the list of games you created on your website
47.     - If "Demo Game" is not found it will create the game on your website
48.  

Note that there are a few big changes in this version and it will require that you update the plugin on your website.
These changes include:
- no longer being able to manually enter the Game ID on WPServer since...
- the kit now fetches a list of your games directly from the website and...
- let's you choose it from a drop down box
- You can also do this during runtime if you need to
- You can now create games on your website directly from within Unity (Design time only. Logged in site admins only)
- Uses C#6 so you need to make sure you have an IDE that supports it
- Support for localised text
- Added a few extra panels to the prefab. Stuff that might come in handy but not directly supported: High Scores, shop and one extra

 

The update has just been submitted and the combined kit now includes the game template with all the assets integrated into it.

I was so looking forward to putting the game on my website so you could all enjoy the many,many, many changes I made to the Unity Third Person Shooter demo project... unfortunately my never ending battle with WebGL is still raging full steam ahead and I am still not able to make a WebGL build without spending days trying to get it to just show up in a browser... ughghgh. Normally I have CORS issues but this time, no this time the web page is unable to find some or other file that I am not telling it to load... Sigh... Well, that is the case in Chrome, at least. Edge tells me everything is fine except it never gets past the opening scene... Why oh why did WebGL have to be invented?

Guess for the time being this will be limited only to those who have the source... Darn it. I was looking forward to getting that high scores list filled up :/ I'll let you know if and when I get a WebGL build working. Watch this space...

 

As expected... all it took was a few days of struggling with WebGL and now, finally, I have a working project again...
Feel free to try out the demo here: http://www.guild.site/bad-dreams/
also, take note that (aaaaalmost) all the content on guild.site was created by the WUSS Login kit...

The list of games, the banners with the text overlays and colour changes on mouse over, that was procedural generated using a shortcode and will continue to display the new games automatically as and when they are created.

The description that it links to is to a layout page that displays the game according to a customised shared layout (game name, then poster then description etc... The shortcodes installed with WULogin displays all of that but you can create anything you want as the actual description. This also means that if you ever decide to sell the game via WooCommerce or whatever, you just need to add a single shortcode as your product description and that will then show your full game description with images, custom AJAX and whatever else you added...

And last but not least, the actual game is being displayed on the WordPress page using a single shortcode also...
[wuss_webgl game=BadDreams height=500 width=650 autoload=true] ...that is all it takes.

The only thing on there at the moment that is NOT made by WULogin is the Shuriken Practice dev log. (EDIT: And the Welcome page I just made! )

Anyway, please feel free to try out the game and fill up those high scores tables for me!

Ganbatte kudasai!

 

Okay, so for those of you who are NOT following me on Facebook I have an announcement today that will seemingly be out of the blue and catch you completely unaware A while back I said I was going to be releasing a kit that will include the ability for you to sell in-game content via your website using WooCommerce but first... first I had to make that asset and that asset was still a way off...

So instead of making that in-app-content WordPress plugin specific to that particular asset I made it generic so that it can be used by any asset that makes sense to sell in-game content. For example, instead of just selling virtual goods, why not sell virtual currency also? And sell your games on your website while you are at it? And so it has come to pass that this WooCommerce integration is now available inside the WUMoney asset and to start the show off I now allow for virtual currency purchases via your website!

Download the latest WUMoney and install the plugin on your website. Done. You are ready for action. Read the documentation for the full low down. More to come ! Follow me on Facebook to stay up to date!

 

I know the first thing people are going to ask me is "Can I sell other things too?"

To answer that real simply: Yes.
Now for the details of that answer. The hardest thing about selling stuff via the website is where to store the data so that Unity knows about it. For now I have created a function that saves currency in the usermeta table where WUMoney knows to go look for it. In future updates of other kits I will add functions to save more items (first on my list is the ability to sell your games from your own website).

Now if you have some php skills and want to create your own functions to do your own thing, that is no problem at all. I intend to be using this new feature a lot in future so I made it super simple but extremely flexible... All is explained in the documentation but here is the cliff notes version:
for a product to be picked up by my code the SKU needs to have a specific format. It needs to start with this:

Code (csharp):

1. WUSKU_{GameID}_{SomeTypeOfIdentifier}[_WhateverElse_You_Want_To_Add]
2. //Exampe SKUs:
3. WUSKU_1_GAME
4. WUSKU_8_Money_Gold_500

As long as you use that format for the SKU and include the first three parts my code will pick it up. Now you just need to add this to a script of your own and then you are golden to do anything you want with that order from there...

Code (csharp):

1. add_action( 'wuss_purchase', 'MyFunctionName' );
2.  
3. function MyFunctionName($args)
4. {
5.     //if the type of this transaction is not "Foo" then this transaction was't meant for us so quit
6.     if( $args['type'] != "Foo")
7.         return;
8.     //your code here...
9. }
10.  

 

For those who have not yet liked my Facebook page, here's another taste of what you are missing out on...

 

WordPress Serials has been released so I can now share the full details of the asset
http://mybadstudios.com/wordpress-systems/wuserials/
https://assetstore.unity.com/packages/tools/integration/wordpress-serials-9265

The short version: (First two features require WordPress Money to be installed also)
1. Sell your games via WooCommerce on your own website
2. When sold from your website the game is automatically registered to the person who bought it meaning they never have to register at all
3. A serial is linked to a person's account, not to a device: i.e. register once and play on all current, future and even borrow devices
4. Licenses are non-transferable so they can't sell your games second hand
5. Games don't work without a license and licenses are limited to one account, thus piracy is pointless
6. Use it as a free download then pay before you play system
7. Use it as a demo system where the first few levels are free and then you require payment
8. Use it as a rewards system to give in-game boosts to people who paid.

For example: In the WordPress for Unity game template people still need to update their max ammo but if they paid for the game then I always keep their inventory at maximum so they never have to buy any ammo.

I removed almost all functionality on the Unity side and kept it as minimal as possible while passing as much control over to the dashboard so the server is in control of everything rather than the game. This way I can keep hacking to a minimum. They can patch the game but they can't hack the server data unless your game is so awesome that they spend a lot of time and energy in figuring out how to exploit WordPress to get to your game...

You can trust the in-game bool HasSerial or simply ask the server to validate it at any time. If you have 20 different places where you contact the server to validate the serial (level start, data being saved, 7th enemy killed, on reload, enter a building, obtaining a frog leg... whatever random place you choose, just ask the server to re-validate that bool and even if they write a patcher for the game they will be spending a lot more time in the patcher than in the game...

Well that is basically it. I already released a new version of WordPress Login that has native support for WordPress serials if and when you install it. The new variables are included inside WULogin so they are already in place. Only the 3 methods to contact the server gets added when you install the kit. Like I said, I kept the unity side super simple with more than half the code already added to WULogin and around 90% of the kit you install is the WordPress plugin.

AS ALWAYS: DON'T FORGET TO UPDATE THE WORDPRESS LOGIN PLUGIN ON YOUR WEBSITE WITH THE LATEST VERSION

 

And today, even more news of updates

WUData has just been updated. The new version also requires 2017.3 and .NET4 but since you have that enabled for WordPress Login anyway I figure that is no big deal.

So, what's new?

1. For a start, it now includes Pro mode. Oh, how I have wanted this for so many years now! I doubt 99.5% of you will use it, though, since it just allows people who are experts on CML to use the servers response as CML was designed to be used, rather than how I was forced to adapt the output for general purpose consumption. Advanced CML users will love it, the rest of the people will completely forget it exists. I for one won't go a day without it.

2. What makes it so different? That is explained in the all new 6 page PDF documentation that explains how the kit works rather than you having to look at the demos to figure it out.

3. I created a new demo scene to help you figure out how the kit works This new demo scene is completely automated. Just drop the login prefab on there and hit play. It will then automatically run through every single last function in the kit, demonstrating how to use every single last one of them. Each function waits for the previous one to complete and for it's output to print before running and at the end of the demo there is nothing left in the database to indicate it even ran. It creates, modifies and then deletes data, printing off the output at every stage and then completely removes all the data it added to the database. How thoughtful

4. And finally, the big news. The reason for the update is because I finally caved and after years of being asked and just telling everybody "No, I won't do it" I finally went ahead and did it. I now allow you to access other player's data. Ever since the kit was created I took great pride in he fact that every user's data was 100% isolated from everybody else and I kept saying that nobody has any business knowing what anybody else's settings or whatever are... and yet it is the one feature that has been requested the most.

Recently a friend of mine tried to created an authoritative network game and wanted to use WUData to save the player's kills and update their rankings an award them prizes etc only... all their data was isolated from the host player... and so I finally realised that giving players access to other player's data CAN be useful so from today forward I entrust the security of the player's data to you, not to my code. Be careful what you wih for and how you use it now that you have it... but yeah, you now have it and WUData can now be used to update player's data during multiplayer / network games

Enjoy

 

New updates released for WULogin and WUData. Please be sure to update the prefabs on your website for both assets. WULogin just got some extra "Getting started" documentation and had some server side code adjustments for compatibility with the new WUData update.

WUData has had a few noteworthy changes:

Firstly, lets get the bad news out of the way
WUData's dashboard no longer supports the legacy system where you could suck a game id out of your thumb and use that when saving data. If your game is doing that at the moment, the good news is that I didn't break compatibility with that function but since it was meant to be abolished over a year ago already (ever since I started creating games on the website to assign game ids to you), starting with version 4.1 the dashboard will only show data created for games created in the dashboard.

Secondly, I finally added that feature I've been promising you
Some of you had asked me how you can edit shared data (i.e. data shared between players, not data belong to specific players) and I told you that you couldn't, yet, because the control pane; simply wasn't designed for that. First off, the control panel was made for editing USER DATA while being able to create game-wide, shared values was a late addition developed due to popular demand. Secondly, the way the code was jumping back and forth in order to support the legacy and new game systems make it a nightmare to now also support global data on top of all of that mess of code going on in the background.

Now that I have removed support for the legacy game Id assigning method and cleaned up the code, I went ahead modified the control panel to now include two distinct sections: One of editing user data and another for editing game wide settings. Simply click on the relevant button to go to the relevant section and there you are. It is easy to distinguish in which section you are by the one section asking you to select a player's account to view while the other simply tells you "You are viewing shared data" and leaving it at that

I promised I will get that feature added as soon as I updated that control panel and I have delivered on my promise.


And the biggest news for last: WUData now supports image uploads
Yup, you read that right. So many people have asked me how they can use custom avatars instead of Gravatar. So many people have asked me just for general purpose image uploads and there were a number of reasons why I couldn't and didn't WANT to support this feature.

First of all, WUData stores it's values inside a table in the database and updating the table to be able to store large fields only for 99% of your actual stored data being high scores or HP or inventory stock that takes up 1 or 2 bytes... that was just a total waste and it made 0 sense. Secondly, to upload the image I would first have to convert it to base64, later fetch it back and then convert it back from base64 to bytes and then from bytes to color... it was just a lot of overhead. But the main issue I had was that storing the images inside the table was a terrible idea and once I create a function to allow for file uploads I open the door for uploading anything at all and thus you can blame me for security breaches on your website. This was an excellent reason NOT to WANT to do it...

So finally I came up with the following solutions to my issues:
1. I would only allow you to upload content from a Texture2D object. At leas that way I can guarantee I am dealing with an actual proper image.
2. Next I would require you to specify if you want to use JPG or PNG and then I would let Unity convert the Texture2D to an image file, thereby removing any malicious content inside the meta or description or whatever.
3. When the image reaches your server I then convert the base64 to an actual image immediately and store the image inside the uploads folder but inside a subfolder created based on your username. This also serves to organise content by user instead of just having all images piling up in one location.
4. I then store the absolute URL to the image inside the WULogin table and return that when you use the FetchField or FetchCategory functions to retrieve data from your website.

This all boils down to 3 things: 1. You can only upload stuff that originated from a Texture2D, 2. Once the images are uploaded to your site it becomes an image you can display on your website like any other image on your website. 3. When you call FetchCategory and receive back the URL of your image you just need to do a WWW call to the specified URL and once the image has been returned you have a texture that is ready to be applied to anything. no further conversions from one thing to anther needed, Unity just gives you a texture right out of the box.

As for deleting the content from the control panel, I still only display the data that is inside of the table but obviously when you see the url to an image you will know there is an accompanying image. When you delete that field from the table I silently and automatically go find the image and delete it right along with the table entry. No extra effort required on your part.

Images can be upload to your personal account for your personal access, uploaded to another person's account should you ever deem the need for such a thing or it can be saved as shared data accessible to all. Options. That's what you have. I tried my best to prevent security exploits but I am no security expert. If you feel this is something you are not comfortable with, just comment out the 3 lines of code in unity_functions that enable these three methods and then every upload attempt will fail and all issues are avoided.

Included in the update is a new demo that shows how to upload and delete images in all three flavors. It displays the texture that it downloaded on screen but deletes all uploaded images and leaves you with a clean website (unless you want t keep the delete functions commented out so you can see for yourself the images got uploaded).

Just one important thing to note: If you want to use images that you added to your project, Unity requires that you turn on the readable option in the inspector before you can use that image.

That's it, enjoy!

 

More big announcements

Anyone who bought the WordPress Login kit can now upgrade to the complete kit and essentially get back the money they spent on the WordPress Login kit. That's right, you read that right! Unfortunately this offer does not cover all my assets, just a refund on the WordPress Login kit.

The MBSCore Edition comes with a $25 discount while the standalone edition comes with a $30 discount when you upgrade

Now the odd news.... There are 2 versions of the asset store you can choose to use (there is a link at the top that lets you either go to "The old store" or "The beta store"). On the beta store they show a possible 20% discount on a range of assets If you have a subscription. On this store they are showing you "This is how much you COULD be paying if you got 20% off" but I don't see any mention of the discounted price I just mentioned.

In contrast, when you go to the old store it shows the assets are on sale and show you the discounted price instead of the 20% possible discount if you have a subscription.

Thus... If you buy on the new store there is a 50/50 chance that you will get the discount or not... but if you have a subscription and you DO get the discount there is a 50/50 chance that you will get 20% off on top of the discount I am offering... Confused? I know this is making my head spin...

So, to recap:

Buying on the beta store:
25% chance you get up to 35% discount when you upgrade
50% chance you only get the discount I mentioned above
50% chance you pay full price - No discount at all
(if you have a subscription, 100% chance you get at least 20% off)

Buying on the old store:
100% chance you get the discount I mentioned above. No more, no less

So if you have the WordPress Login kit and want to make use of this upgrade offer, those are your options and the odds and the rewards. Who knew that buying an asset on the store could be turned into a game in itself? Roll those dice and see where they land... or go with the sure thing. Which road will YOU travel?

Enjoy

 

Last month I gave away free character models, this month free logo rendering services for people who like to make youTube videos or training vids etc. All exclusive to Facebook followers. Drop on by, confess your like of me and see what else the future has in store