Now, this isn't as bad as I'm making it seem. I am much more comfortable working with Objective-C now than when I started work this morning. It is quite interesting how much you can do with such little code. I've never used a dynamically typed language before, but it does make a lot of tasks simpler. For instance, I'm setting up a big array to save all my high scores in. At the deepest point there is a score entry containing the name of the player and their score. I create an array with these two items. I then create an array to hold ten of these arrays, creating the top ten score list for the level. Last, I create an array to hold one of these arrays for each level. Now, in C++ that might be something like vector< vector< ScoreEntry > >, where ScoreEntry has to be defined as a struct. However, in Objective-C you just pass whatever object you want into the array. It's as easy as defining an array, pushing anything onto it, then just pushing that array onto the next level array, all with no type definitions. Now, the objects need to be formatted as NSObjects, which all other NS* data types are subclasses of (such as NSString and NSArray as I've already mentioned), which adds a bit of complexity, but the simplicity gained in the overall structure is worth it. Also, Objective-C's standard for methods is a bracket system. Where in c++ you would call obj1.foomethod(x), obj-c would be more like [obj1 foomethod:x]. Also, arguments get names, which at first is distracting but once it clicks it is actually quite useful. I'm not sure I'm ready to jump ship just yet, but it's nice to know I have a more solid background as I continue iPhone development.
Now, as to what I actually got accomplished today. I did get high score lists implemented into the engine, however I haven't gotten my NSUserDefaults framework working yet, so the lists aren't valid between play sessions. Also, I've put the level's top score at the bottom of the play screen, a la old arcade games. You can see these down at the bottom in the screenshots.
One thing I need to mention is how much of a slippery slope hard coding values into an engine is. As I said in earlier blog posts, my game is simple enough that I figured having some hard coded values and states would not be that big of a deal. Thankfully I had the foresight to implement a high-level rudimentary state machine, so I'm not working entirely with hard wired conditionals, however as I add small bits that span the menu, level select, and play environments, I am really wishing I had a more general interface builder and state machine. What I hadn't considered was child states, so that I could handle the Pause and Level Completion "states" as true states, and not hard wired conditionals and locks in the application engine. Rather than a smooth, easily manipulated organization I have a decent high-level setup with lots of little conditionals, along with each buttons' position hard-coded in. The plus side of this is that I've learned how not to go about things in the future. I've already got some plans started for the interface and state handler for the next game which should allow for much more rapid and clear development. I only wish I would have seen the light sooner.
No comments:
Post a Comment