Roller Ball Maze Hits A Speedbump
Well, I've spent some time sketching out the idea of my roller ball maze game, and I've got a pretty good outline so far. I've also finished getting my developer account set up so that I can run test apps on my iPhone, or another iOS devices, so that's pretty cool.
What's not as cool is that I have a few distinct unknowns in my game sketch, and I think I may need several days (maybe even a few weeks?) to research them. Phooey! Well, the first one won't be too difficult to work out, but the second one is probably going to require me to read a tutorial or two before I can move on.
Basically, my first problem involves loading the data model underlying the maze. Everything that the user sees is just cosmetics - it needs the actual data to be held and calculated in a structure that controls everything - including what the user sees and feels like they're interacting with. I know of a few ways to build and load this data model, but they're pretty time- and memory- intensive, and I just know there's a much easier way to do it out there. I was going to put this off and just take the long way around for now, until I ran into the second problem...
I've been planning on writing this first app using a 2-D animating model call "Quartz" which is one of two more-or-less built-in animating systems in the iOS frameworks. (Frameworks, by the way, are basically collections of pre-programmed functionality that one can import into a project and then use that functionality with minimal work.) The other major option is a 3-D animating model call OpenGL ES (an open-source graphical library for embedded systems like the iPhone... yeah, I know - blah, blah blah, right?)
The point is that I wasn't planning on learning OpenGL ES yet, because it's a bit more difficult (and also much more powerful than what I need right now). What I've found out, however, is that Quartz really isn't going to do what I need in the long run (it would barely cut the mustard for my sample apps, as it turns out), so it's in my best interest to go ahead and learn OpenGL ES now. Not the end of the world - this is what the practice apps are for, to work out the kinks before I start a major project - but still a bit of a bummer.
So for now, I'm going to keep driving on with my reading - an OpenGL ES tutorial from the apple developer documentation, and the game programming book with the gray cover mentioned below. In the meantime, I'm still going to work on sketching out my sample apps - maybe several of them - while I keep putting together the puzzle on how exactly I will implement them.
What's not as cool is that I have a few distinct unknowns in my game sketch, and I think I may need several days (maybe even a few weeks?) to research them. Phooey! Well, the first one won't be too difficult to work out, but the second one is probably going to require me to read a tutorial or two before I can move on.
Basically, my first problem involves loading the data model underlying the maze. Everything that the user sees is just cosmetics - it needs the actual data to be held and calculated in a structure that controls everything - including what the user sees and feels like they're interacting with. I know of a few ways to build and load this data model, but they're pretty time- and memory- intensive, and I just know there's a much easier way to do it out there. I was going to put this off and just take the long way around for now, until I ran into the second problem...
I've been planning on writing this first app using a 2-D animating model call "Quartz" which is one of two more-or-less built-in animating systems in the iOS frameworks. (Frameworks, by the way, are basically collections of pre-programmed functionality that one can import into a project and then use that functionality with minimal work.) The other major option is a 3-D animating model call OpenGL ES (an open-source graphical library for embedded systems like the iPhone... yeah, I know - blah, blah blah, right?)
The point is that I wasn't planning on learning OpenGL ES yet, because it's a bit more difficult (and also much more powerful than what I need right now). What I've found out, however, is that Quartz really isn't going to do what I need in the long run (it would barely cut the mustard for my sample apps, as it turns out), so it's in my best interest to go ahead and learn OpenGL ES now. Not the end of the world - this is what the practice apps are for, to work out the kinks before I start a major project - but still a bit of a bummer.
So for now, I'm going to keep driving on with my reading - an OpenGL ES tutorial from the apple developer documentation, and the game programming book with the gray cover mentioned below. In the meantime, I'm still going to work on sketching out my sample apps - maybe several of them - while I keep putting together the puzzle on how exactly I will implement them.
Labels: iPhone App Project, Learn It, Sample Apps
0 Comments:
Post a Comment
<< Home