So the Alpha presentation went great! I wasn't as behind as I thought I was. I really feel like I could've used more diagrams and design documentation and I should really work on this over the weekend. Something as simple as a game flow diagram would be very helpful.
Also, after the presentation, a member of the audience who did an iOS app for PennApps said I could use his and his group's Developer license as they had no purpose for it anymore. They were giving the login credentials to "those in need." WOOT! He confirmed that now it is impossible to port an app over to an iDevice sans license (no 5 device rule anymore it seems).
So I worked pretty hard all yesterday and today and I made some good progress for the alpha tomorrow. Having given up on UIKit, I dug into Cocos2D and it was great and easy. Took a little while to figure out how exactly to then tie in Chipmunk, the physics engine, but it was exhilarating when I finally got that damn ball to fall down due to gravity!
However I ran into some major problems, mainly due to lack of any good documentation on both Cocos and Chipmunk but especially the latter (most references I found were for Box2D which is also supported but seems less apt for what I want to do). It's very easy to set a global gravity in Chipmunk but setting gravitational pull independently for multiple objects is a bit more advanced.
To do this I need to create my own "Velocity Function" which the software than uses to do some Euler integration and get the result. However the documentation on this function is small at best. The function is described in the docs as follows:
void cpBodyUpdateVelocity(cpBody *body, cpVect gravity, cpFloat damping, cpFloat dt)
Default rigid body velocity integration function. Updates the velocity of the body using Euler integration.
From looking at the function I derived that it does essentially the following:
where v is the objects current velocity, f is the current force on the object and m is its mass. Now calculating the new gravity is easy enough yet when I use this functino nothing seems to happen. I need to play around with it a bit more. It's possible that it is working and, due to how I'm setting my body masses or initial speeds, it just appears as if nothing's moving.
Anyways excited for the Alpha Presentation today. Little worried about how it'll work out with a video, as opposed to slides. I just gave each slide equal time so hopefully if I run out of time on one slide I can just make up for it later where I have nothing to talk about with a nice segue. My slides are pretty so that's all that really matters, right? Let's hope I can stay awake through it all after pulling an all nighter. But I've been sleeping pretty well recently so I'm not too worried.
Big presentation tomorrow but I'm not too worried. A full night's work and I think I'll have something pretty decent to show. Cocos2D is really intuitive to code in. So I'm confident that if I can just design a planet class that provides the model, fairly simple I think, than coding the iPhone to actually display the model should be pretty easy. Plus I found there's a great section in one of the books I got from the library about puzzle gaming. Hopefully it will further inform the game design I present tomorrow as well. Wish me luck!
So I tried following the UIKit tutorial in my book I bought and the initial step wouldn't even work! I resorted to copying code wholesale from the source code they provide on their site and still nothing. I'm getting a handle for Objective-C now but for some reason the simulator wouldn't even get to my actual code. It just got stuck in the mach_msg loop. I didn't see any differences between my code and theirs. There must be some connection to the main game loop I'm missing but for now I'm abandoning even doing this UIKit tutorial and will begin a Cocos2D one instead which is what I intended on using ultimately anyways. Below see my awesome, motionless, scrapped demo!
Okay so the following list might be a bit ambitious but I'm confident I can get a good bit done since I have minimal other work to cover in the next four days:
1. Complete "Beginning iPhone Programming" first Breakout game tutorial.
2. Generate some other wireframe layouts of my app.
3. Create a mockup of the radar view which will be my initial development goal as its less demanding of user interface than the "real" view.
4. Create an animated version of the radar view (Optional).
5. Read/Skim through all three of my development books, marking sections that apply to my project for later deeper reading.
Its unfortunate that I really only have time to work on my project during the weekends due to my Monday through Wednesday courseload but then again my weekends are practically four days long.
Got the two books that were on reserve for me from the library. Skimmed the intro to one and learned some good stuff. Apparently I need a $99 license to demo my app on an actual device. Don't know if that's changed but it might have...hopefully? I wonder if I had kept my Mindsnacks dev licenses on my iPod touch from the summer if they would've cut it? Doubt it since they were all expiring. Maybe Jesse would be so kind as to share with me their log in credentials? I'll have to email. It's just for a school project right?
UPDATE: Checked the Apple website and its still the same policy as outlined in the book. $99/year to test on a device. I would like to do this eventually. Could the school possibly by a license that I, and future students, could use? Either way need to get on this ASAP since its not an instant process and takes time to get approved. Furthermore, I'd need to add things to my code to make it device compatible (licensing information and the like).
A new week, a new set of challenges. Not too much work this week outside of my Physics midterm Thursday. A iPhone Dev book I requested from the library is finally available, I have to go by after class today. Hopefully it's not gone already. Every useful book the library had was gone, I had to request them all weeks ago and it took this long to get back! I'll definitely be sitting on it awhile. Hooked up my site to my Gmail so I should get all comment notices immediately now.
I've been brainstorming about the game's tool issues I was discussing last post and I came up with another nifty possible too: a black hole device. Obvious, I know! Essentially this would create a second gravitational well in the given puzzle greatly altering all objects therein. The black hole wouldn't be persistent however. It would eventually implode resulting in a shower of space flak. The amount of this flak would be determined by the amount of matter absorbed! Brilliant I know.
So I'm finally done (for now) with my personal website so I can commit more time to my project! Joy! This week I plan on completing the first basic tutorial in my book, a simple Breakout clone, and starting work on my own game. Thankfully I don't think my game will require some of the more sophisticated aspects of the SDK. If I could get as far as incorporating all my libraries, such as the physics library and such previous posted, I'll be on track to present a basic level of my game with dynamics incorporated for the end of the month alpha.
In the meanwhile, did some quick prototyping of what the final game might look like, as far away as that is at the moment. This design was fairly intuitive and off hand. I'd like to explore some alternate layouts with some basic wireframe mockups as the week progresses. I really like the idea of there being a radar view and a "real" view but for now I've restricted my aims to just one. This mockup shows what the "real" view might look like.
The radar view would be accessed through a gesture, probably a two finger swipe across as the design sketch shows. The radar view would essentially be an overall look at the level so the player can see all planets at once in order to set up combos and chain reactions. As seen in this mock-up, the amount of planets that could be on screen a be identifiable is rather limited. Granted, some pinch actions and single finger slides could be implemented to zoom and pan the camera respectively. Again, however, I'm trying to keep it simple for now.
Note, I've included four tools/weapons and I feel this will be the extent of the options in the final game. I'll post a design document later detailing these interactions but for now I've settled on Tether, Frag, Slow and Split. Tether attaches two planets together thus causing them to interact, spin out of control and generally cause havoc on the system. This tool is the one I'm most skeptical of since how it will affect the planets in a dynamic physical system is impossible to know till implementing it. I feel it may just lead to one tethered planet immediately crashing into the central sun, causing the other to spin off into space which would be undesirable. In fact, many elements of the game may ultimately need to be changed as their actual dynamic behavior is unpredictable. Perhaps making a simple dynamic system to simulate these interactions in a environment I can do so quickly in will be called for. Another possible solution would be for tether to slowly draw the two involved planets together, leading to their eventual collision along with any other poor orbiting bodies in the way.
Besides Thether, there are the surer three. Frag fragments a planet into many smaller parts. This tool will only work, however, on the inner solid planets. Obviously a gas planet, such as the outer blue one in the mock-up, could not be fragmented. Slow slows down a planets orbital velocity causing it to careen towards the central system star. And lastly Split splits a planet into two large chunks along its orbital path such that it forms to projectiles with a more eccentric orbit. To solve the mock-up's puzzle above, we could use any one of these tools or multiple if necessary. We could use Slow on the gas planet and with proper timing cause it to crash into the smaller planet. We could tether the two together causing them to spin out of control and eventually crash into the star. We could use Frag on the smaller planet, timing it such that the fragments crashed into the gas planet thus destroying it. Or we could similarly use split in like manner.
This brings me to a primary concern: the tools must be different and unique. Split and Frag are a bit too similar for my tastes. While there are ways of differentiating them, for instance perhaps split causes the two halves to jettison in opposite directions, such efforts seem contrived and unrealistic. Clearly, more time thinking upon the player's tools is demanded. I must simultaneously begin implementing the dynamic orbiting systems.
I'll try and post a radar view mockup this week as well. It would essentially be a neon digital version a la the tools menu on the bottom of the mockup. This pix elated view would allow for greater vision and control while requiring little no additions to the game engine itself as its simply displaying the game state information in a different fashion.
I've also included my initial, though meager, sketch of the game and the working sketches for the above mock-up. Ah how far we've come.
Began reading my iPhone Development book and so far its been very useful. Nice simple introduction to the format of Objective-C. Hope to begin coding this week after my midterm, especially now that my Demoreel's complete and my website's practically there (just need to post some more portfolio stuff, my demoreel and implement the email page, all more a grind than difficult). It's been tough so far keeping up with work and impending graduation. Seems I'll be doing an Independent Study or something of the sort Pass/Fail come graduation time to get my 7th credit. Still can't believe they won't count ASTRO001 as a Free Elective...IT'S FREE!!!! Anyways, wish I had known earlier so I could've dealt with it earlier as a simple 6th credit before going abroad. Still haven't done any job apps to boot, misunderstood the reminders I wrote myself! Doh! Need to get on that. Real life is coming down like a rain of bricks.