Different Theoretical Questions

[ibly31]

Okay, so I implemented a few different features into the 2D platformer-style puzzle game I am recreating for the iPhone + iPod Touch. For those of you who helped me with my last problem; a multidimensional array of ints that would hold level data, I ended up going with a single dimensional NSMutableArray that held NSNumbers. It's working great.

My first question: Downloadable Themes.
One of the first features that I wanted the finished product of this game to have is downloadable themes. Playing the 8*8 sprites that are blown up to 32*32 can get kind of boring, and some people probably would like to take advantage of the iPhone+iPod's beautiful color screen. The way I think I will implement it is to create a desktop editor that is distributed via my website, and it will export a folder with the name of the theme as the name of the folder, along with a file that holds data such as what images are linked to what tiletypes. Is this the best way to do it? How would I even get it to the iPhone and iPod touch, let alone loop through all the folders in the documents section of my Application? Would a single file be easier for what I want to do?

My second question: Application Design.
One of the things that always stumps me when it comes to programming games on the iPhone is the whole UIViews concept. I could never understand how to share values and stuff to the OpenGL view so that I can play one level, go back to a menu, select a new one, and there we go it is playing. What I don't understand is that you only have one instance of an EAGLView and you can't just delete it, and create a new one with parameters for a level file, theme file, and stuff. How do designers overcome this? This is probably how I would do it:

Make my AppDelegate hold important variables such as the name of the level file currently being played and theme file and stuff. Then, every time my Menu UIView selects a level, I call a function in the AppDelegate that calls a function in the EAGLView that resets every variable, reloads the level, reloads the themes, and pushes the EAGLView to the top of the UIView structure. Buuut, my MainWindow.xib file has a UIView in it, and its linked to EAGLView. If I want a Menu UIVIew to display first, how would I make that happen, and initialize the EAGLView at the start of my Application's loading?

My third question: Level Editor.
For some reason, my favorite part of programming is making level editors. Suure, sure, I love making the engine that actually uses the files, but I like making things that make my life easier. Here is my dilemma: should I make a level editor inside the game? Or a desktop one? I'm fairly proficient in Windows programming, and making an editor for Mac should be relatively easy with SFML. I just don't feel like dealing with the hassles of distribution with EXEs, Apples .app files are just so much easier in my opinion.

*important info: my levels aren't too complex. Its a tile based game with levels not really exceeding 25*25 tiles. Each tile is 0-5, with there being only one 5 because it is the location of the character at start. this is good because the iPhone's lack of control surfaces won't affect it because its a simple "select tile, place tile, save level" type editor.

I hope it didn't take up too much of your life to read this. :D Thanks for your help if you decide to answer!

Peace, ibly31.

[RyanPridgeon]

0
My second question: Application Design.
One of the things that always stumps me when it comes to programming games on the iPhone is the whole UIViews concept. I could never understand how to share values and stuff to the OpenGL view so that I can play one level, go back to a menu, select a new one, and there we go it is playing. What I don't understand is that you only have one instance of an EAGLView and you can't just delete it, and create a new one with parameters for a level file, theme file, and stuff. How do designers overcome this? This is probably how I would do it:0

The way I tackle this is have some sort of top level manager class. Let's call it ScreenManager, then it would keep track of different "Screen"s. You can call functions in it to switch between different screens. Inside the screens you have your meat. For example, one screen might initialise, run, and clean up a game. Another screen might handle the main menu for your game. Then it's just a matter of ScreenMgr.transitionTo(MENUSCREEN), or something similar.

[ibly31]

You're taking a C++ approach to it, ObjC is (unfortunately) a lot different. I don't need to write that class, UIViews pretty much do it all for you, but I'm just confused on the whole XIB file setup and transitioning. If you've used XCode then you can help me but if not, thanks anyway.