Here is what I've accomplished this week:
- MultiTouch has now been fully integrated and implemented
- A Scene Manager class to keep track of, unload, and load assets for whichever scene should be showing. (This is used to create menus and multiple levels.)
- I've gotten my algorithms for platform spawning and removing transferred safely into code (Fully-working as of late last night.)
Take a closer look:
MULTITOUCH:
Unfortunately, it's extremely hard to show this one in a blog post visually. However, I can assure you that I have successfully integrated MultiTouch capabilities into our application. Don't worry, though! Even if you don't have multitouch, you can still use the application, it will just default back to using only single-touch recognition! However, for those of us with MultiTouch-enabled screens, we will probably get a lot less frustrated with the application's performance when the going gets rough in later levels!
SCENE MANAGER:
Using a scene manager, I can now load, unload, reset, run, basically do anything I want with any given scene. This means that I can now actually structure the game application like, well, a game! I can implement a main menu (which I have), pause menus, settings screens, map sequences, you name it! It's all very possible and within grasp, now!
Here is the main menu, for example. (Thank Mike for the awesome title sequence!) Once you hit the play button, the Scene Manager will load up the first level.
This is what the Main Menu looks like after a bit of time. The flower and petal emitter slowly blows the blossoms across the screen.
PLATFORM MANAGEMENT:
This might actually be neck-and-neck for my most accomplished moment thus far, tied up with the cool swipe integration. Here's how it works: The level's "world" is divided up into 64-pixel measurements, kind of like columns. ((Don't worry, it's not visible. It's all code!)) A counter keeps track, through the update loop, of how many pixels the player has moved. As we know, the player doesn't actually move left or right in our game, the main scene stays with us as the world moves by. So, using a method I conjured up, I can easily pass a few numbers dealing with what segment I want my platform to start at, and how many segments I want my platform to have. Then, the module will spawn a left edge, however many center-blocks it takes to get my desired platform length, and then a right platform edge. Throughout the update loop, I can test whether or not the player is within contact of certain parts of these platforms, and act accordingly. For instance, the player can land on top of the platforms, and run right off the edge, and drop back down to the ground level. However, if they smack into the left side of a platform, the level is going to be reset! Yikes!
Are you curious about that counter at the top-left of the screen yet? Alright, I'll tell you! It's for bug-testing. See, platforms won't spawn until they NEED to. Meaning, as the player progresses, the platforms get closer and closer to him. As soon as a platform's position (stored in an array) come near the right edge of the screen, the platform will be spawned, and that many blocks will be added to the counter. Soon after the blocks leave the screen (though not TOO soon, due to timing constraints), they are deleted, and the "Blocks: " counter will reflect that, too. It's just to help bear in mind what kind of strain is being put on, or in this case being taken off, of the processor and phone internals!
SWIPE IS IMPROVING:
If you've been at all curious about how the Swipe implementation is going, see for yourself. I've filled a couple of whiteboards and notebook pages with ideas on how to improve it further and make it look like more of a sword's edge. After looking at a few peoples' theories on how to do this online, I've pretty much narrowed down the type of shape I should use for the implementation, and have derived how I could go about drawing said shape in an appropriate manner.
No comments:
Post a Comment