Tuesday, April 17, 2012

Mike Pope - Week 7

Hey guys! This last week has been incredibly productive. First matter of business I attended to was the first enemy. Since this enemy does not have any animations, I decided to just draw a 2D sprite from scratch instead of modeling one. The only part that's animated on him is the "ZzZz" above his head to indicate that they are sleeping, These are animated through the code that Tate has written.

Secondly, I created 6 sushi assets for pickups. I took a lot of ideas for these from the mini-game Lickitung's  Sushi-Go-Round from Pokemon Stadium. It gave me a lot of ideas on the basic types of sushi to draw out. Drawing them out was fairly simple. Once again I used Photoshop. These pieces also animate, dancing back and forth and glowing for the play to easily see them in any environment.

Next week we are presenting our Alpha, and I am extremely confident!

Tate Marske - Week 6-7

It feels like only yesterday we started this whole project off, and now we're about to present the alpha build of "Fat Ninja" to our peers and professors.

Over the course of the past two weeks, I've been working hard to get my team's final Alpha assets put into our game and getting all of the mechanics to work well with one another.  Have a look!


As you can see, we have our main character running and animated, our final backgrounds (which act in a parallax as they run by the screen to give depth), our platforms, and our sushi.  All of our algorithms, sprites, and audio assets are working together perfectly, and we're very excited for our presentation later this afternoon.

I plan on presenting our game itself by running a camera-projector to a television.  Until I get the proper display cable, this will be the most lag-free way of presenting our working game application.

Monday, April 16, 2012

Kyle Windsor - Week 7

This past week I had some of my most satisfying progress yet.  With the coded elements now implemented in game, I was able to transfer the first level into the game.  This proved very beneficial because I now know exactly how long my level was time was/play wise, how much I have to scale up, are jumps too short/long, etc.  So early on I balanced as much as I could out to create a smooth run through level 1.

After I completed level 1, I started revising levels 2-3 so I can start to input and edit the levels to get them into a playable state.  All told, I'm happy where we are at though I have a small concern for the future.  We still have a lot of work to do to meet our end goals and if we progress remotely close to the pace we did this session, our current goal won't be feasible.

Wednesday, April 11, 2012

Andrew Morrison - Week 7

CRUNCH TIME!!!

2 weeks to go! Music is done for this build, just need to work on sound effects.  I've had the chance to tinker around a little while at school, but unfortunately because of issues with FL Studio running off of the external hard drive, most of the writing needs to be done at home due to random chunks of the sound library disappearing.  On tap this week (by Saturday!) are sounds for jumping, tossing shurikens, menu sounds and a sound for Mikes awesome little Sushi grab on the title screen.

I am even more excited for next session, as without the online class, I'll be able to put even more time into crafting awesome music!

See you in a week!

DM

Tuesday, April 10, 2012

Mike Pope - Week 5/6

This post might be a little long because I'm mashing two weeks of progress into one. To make things easier for you guys, I'll try to space out my progress as much as possible!

     First up last week, I worked on the main menu assets. Everything was hand drawn through Photoshop CS5 (arm, chopsticks, sushi, dish). The only thing I didn't personally draw was the font... but I did however change it up to suit our needs. I used several filters, brushes, and blending techniques to achieve each desired  look for every asset. The dish, by far, was the hardest to get looking just right. Overall, the main menu took about 3-4 hours. In the end, there were about 24 layers, and many of those layers were condensed and merged. The ninja hand/arm asset alone was done in 10 layers.






     Secondly, I have most of Chin completed. All that is left for him is texturing and animating the rest of his animations. Right now for animations I have: Idle Run, Idle Run (sword), Attack Run (shuriken). For making the sprites, I found two programs that would help in converting my 3DSMax files into sprite sheets but unfortunately... both of them supported files that were much different then mine (.DTS/.DTQ, .B3D, .X). I spent a good few days trying to research how to convert these to use them, but I had little luck. What really made this very dis-hearting for me is that this influenced how I created, rigged, and animated my model. In the end, I just decided to render them out straight from 3DSMax. I then found another program which took each picture and merged them all into one sprite sheet. This was the one thing that worked in my favor up to this point!



     Last up this week, I created the background and platform assets for our Level 1-1. Once again, I created every single piece in this level, using the same techniques as mentioned before. The only stock images that I used in the actual creation was the sky and the mountains, but they were still heavily modified. Everything else, I used reference pictures to understand how each house was built and how their living areas looked like.

     To start off, I created each piece of the house (base, wood, sidings, trims, windows, roof, etc). From there, I created a different house setup using the same pieces, plus a few more. After that, I copied over each of the different houses I made for the "distant background" and darked them. In order to keep this as a background and not have it interfere with the "gameplay elements", I decided to put a nice small black to transparent gradient over the buildings... which really helped bring out the enemies and platforms the player is jumping on!

     This Photoshop file had a total of about 30 layers. Once again, this number is drastically dropped down due the fact that I duplicated layers and merged them all to create one easy to manage layer. For instance; I have the base pieces of the house I created first. After that, I took all of those and merged them to have a layer called "House merged". I used that to copy over each house in the background. Overall, I had so much fun making this level!

Next week is the alpha presentation for our game. I think we're all really ready for this! BRING IT ON!

Monday, April 9, 2012

Kyle Windsor - Week 6

This week I can finally start implementing the levels into the game.  I spent the first part of the week transferring all the levels over to grid paper to get an initial level down.  From there, I proceeded to tweak and refine some of them to make them work better.  For example, in the original design it would leave it impossible to jump from one platform to another higher up.  This required some tweaking to make it fit.  I have also done some preliminary adjustments to make the level of the appropriate challenge and to make sure there isn't anything unexpected that initial designs didn't account for.

Now, I encountered an issue with loading the project onto my computer, so after Tuesdays meeting, I will be able to quickly input all the levels into the game.  At that point, I will need to actually test to make sure the levels are long enough, and things aren't too challenging for a first level.

Wednesday, April 4, 2012

Andrew Morrison - Week 5

This week, I made huge progress with the music for Fat Ninja, knocking out music for a level as well as the menu music.  Next up on the list is working on the sound effects, which will take the better part of the next week and a half.

http://morrisongaming.weebly.com/projects-and-portfolio.html

The two pieces I've completed are at the bottom, and again, the portfolio will be updated when the new sounds are completed.

See you soon!

DM

Tate Marske - Week 5

This week has been insane.  It's almost as if my team and I finally got the kickstart we needed to start really cranking stuff out!  After finally getting everything all configured and hunky-dory last week with AndEngine and figuring out how and where to implement what I wanted for a given scene, I took the ball and ran with it.

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.

Monday, April 2, 2012

Kyle Windsor - Week 5

This week has been a busy week for me.  I've had a lot of other work and so I've done as much as I can with the levels.  This past week, the final list of what will be included in Fat Ninja as well as confirmation on the rough flow of skill progression was given.  So most of this week was spent going back over my previous designs and modifying them and editing them to work with the finished ideas a lot more.  Mostly, the levels overall design stayed the same with a few needing minor changes to make jumps doable and such.  The biggest changes came with the enemies and some environmental hazards that wouldn't be there.  It was a juggling act to keep the rough feel while still keeping the same challenge and flow.

That said, my main goal going into this next week is to start actually putting the level in game in some form, even if it's nothing but placeholders, so that there is some notable progress on my biggest task this session.