The demo for Final Fantasy XIII-2 was released today on Xbox Live. Needless to say, it has been downloaded and explored. Here are 3 things I immediately took away from the demo.

 

1. The Paradigm Battle System is back

I know that some hardcore FF fans will disagree with me, but this is a fantastic battle system. They made some tweaks to it that let you specify if your characters should default attack multiple enemies at once or just focus on a single enemy. They also let you put monsters in your party via paradigms (after you’ve captured them). You can even level the monsters in the Crystarium! I’m guessing it’s no accident that a Cait Sith is among the first enemies you face, and the first one I captured (a sign of ff7 goodness?).

2. Enemies drop gil

Thank. Goodness. I don’t know about you, but I was really not looking forward to farming Adamantortoises just to get the elusive 2,000,000 gil catalyst (what was its name?).

3. You can roam cities,  *talk* to people, and buy/sell from them

This was probably the element I missed the most from FF-XIII. As fun as it is to buy from a save sphere – oh wait, it’s not. I also like the concept that you have to spend gil + provide components in order to get certain weapons. Nice touch!

Essentially, they seem to have taken all the things I loved about FF-XIII, kept them, and made tweaks in all the right places. I can’t wait for the full version to arrive at my doorstep. I am hoping this has some of the elements from FF7 and FF10 that I loved. It definitely seems like an improvement on an already amazing game. If only they’d bring back materia… O=]

 

I’ve worked with a company named Think Ministry, Inc. for coming up on a year. We provide enterprise-class church management solutions via a robust database/platform and several other applications. Our main application (MinistryPlatform) comes with its own API as well. Since my main role is Support/QA, I thought it would be good to dabble with our API to understand firsthand how it functions.

I chose to make a “group check-in” application designed for mobile devices. Our churches often ask if we have a mobile check-in application, so I thought it would make some sense to see if I could come up with a good starting point, maybe even an app that would be used by someone. After trying a few mobile frameworks, I landed with jQuery Mobile. It’s basic enough for me to quickly understand, and it did most of what I wanted.

Here were my goals:

  • Authenticate and create a user session based on a MinistryPlatform user ID/password
  • Restrict log-in to a specific security role
  • When a user authenticates successfully, display a list of available events (within x hours of starting, customizable)
  • Display all groups assigned to each event, including people who registered via our public portal but were not a part of an existing group.
  • Display the count of leaders : participants for each group, and how many are currently checked in.
  • Allow the user to tap individual people’s names and check them in to the event immediately.

By the time the application was built, it did all of these (and a few more tweaks/features). It’s now available for download for our current churches, and I’m hoping it will serve as a great example of integrating PHP with our API, and maybe even be useful to some of our churches!

 

I’m still learning how to correctly create/destroy objects using PHP, and I came across something that stumped me for some time. In the application I just built, I interface with a SOAP API. When building my class, I thought I would save myself time to instantiate the __soapClient object in my __construct method. That way I could just call $this->$client->__soapcall(mycall) and be done with it.

The problem, as I discovered, is that creating the SoapClient connection as a part of the construct method means that the API connection is never closed. Eventually, I crashed the IIS server that serves the API. I tried many things first – I unset() the object after processing the data in each method. I considered writing a custom __doRequest() method as some blogs I’d found had mentioned. Ultimately though, I talked to another dev who was using this API and he was kind enough to send me his code. The only difference I could find was that I was creating the SoapClient in my __construct method. I moved the @new SoapClient code to my individual methods and it worked great.

As I’m still new to PHP objects, are there any alternatives I’m missing?

© 2012 kenmulford.com Suffusion theme by Sayontan Sinha