Thursday, December 15, 2011

Impulse Post-Mortem

We presented Impulse to the makers of the Haptic controller yesterday, and it went pretty well. I was a little bummed that I wasn't able to get all of the puzzles in that I wanted, like boxes that you had to push around, and little robots that moved around the level that you had to avoid. Regardless of the lack of these objects, the main feature was there. The consoles and the doors.

This group started off pretty well, and I think that had something to do with the fact that three of us had worked together before in previous projects. I worked with George in prototype 1 and Ashley in prototype 2. Ashley and George worked together in prototype 3. We already had a feel for how we each worked. We had our regular stand up meetings whenever we got together and a sit down meeting at least once a week at see our progress thus far and discuss obstacles if needed. It always helps out when we know what we need from each other and Josh provided a way for us to do so. Another thing that helped was having some filler art from the start that was in the same dimensions as the "final" art would be. With that in hand George and I were able to make the levels and test out the motion and flow of the player. George and I got together and discussed what the game flow would be, and how we could break up the assignments so that we weren't stepping on each others feet too much. This helped a bit at the beginning so that we could get the program moving.

As far as set backs go, there were a few that mostly involved testing the code with the actual Game Controller instead of with our xbox controllers. Some of this was due to the fact that we only had one controller in the lab and we had to wait for it to be available in order to test it out. It's also very apparent that it is a new technology. We also had to compensate for a lot of "noise" that the controller had. For example if you pushed up, left, down, or right, the value of the thumbstick would still fluctuate anywhere from .7 to 2.0. Once one accounted for this variance the program would act appropriately.

I consider this project a success and I am very grateful for my team. We did well.

Tuesday, November 22, 2011

The Next Big Thing

Our new groups have been decided and we have been presented with what we need to do for our next Prototype. Essentially we are going to be making a game using a new type of controller that has Haptic feedback called "flesh stretching technology" or "tactors". There are little nubs on the joy sticks of the controller that move under the thumbs, giving the players a new output from games. We are to utilize this technology. One thing different in this prototype is that there will be a specific person in the group that will be the official game designer. The choice of designer was made by each person pitching a game that would use the "tactors". After each person in our group made a pitch it we decided to use my pitch.

The game we will be making is a puzzle game. A person is trying to breakout of a facility by bypassing several locked doors. The doors can only be opened when the player "inputs" the correct code using the thumbsticks of the controller. The code is found in consoles throughout the level and given to the player through the tactors. So if the player feels the "tactor" under their left thumb go right then up, the code for the door is right then up using the left thumbstick. As the player progresses through the game the codes become more complex and even broken up into different parts in separate consoles. The consoles are color coded and the door has a pattern of colors depicting the order in which the codes need to be displayed.

I'm really excited to work with this group of people. I've worked with our Artist Ashley previously on the Repelzul project and the other Engineer George on the Germinators project. The only person we haven't worked with before is Josh the Producer.

Friday, November 18, 2011

Prototype 3 Post-Mortem

Before I get into the actual Post-Mortem I'll describe a bit more about the work that was done on the project itself. We were scheduled to present the project to our "clients" on Tuesday at 1:00PM. This later changed to be Wednesday, Much to our relief. Before the presentation Felix was able to get music added and I mae a countdown for the game. I also added Sparkles to the main menu so that it wouldn't be so static and lifeless. When we finally presented the game the "client" seemed to be fairly pleased as they realized that we had a pretty difficult IP to work with and they were wondering how we would be able to turn it into a game.

Now for the Post-Mortem
When the group was first put together and we were told that we were going to be making an app on Unity I was very excited. This excitment was stunted a bit when we were given our IP. It was for an audience that we didn't really relate to in any way. The agony in turning the idea into a game was very long, and we went through days of not knowing where we were going. We knew that there were some thing that would be needed regardless of the game and worked on those in the meantime. Felix, and I worked on making the menus, configuring the objects for texture changing, and getting familiar with Unity. Michelle started to make art assets of for the character and the environment. Charlie shot us with his NERF gun. There came a point where we had to know what the game would be before we could go further. We got the "Simon Says " idea and went with it. After that had been decided the game came together pretty smoothly. I had to take the reigns and Lead the design in the end in order to get things really progressing.
If we were to do this over again, I would definitely take the reigns earlier. We were stumbling a bit there. I think that we did extremely well with the obstacles that we had and the game turned out good. I am actually proud of it and I think it's kinda fun.

Thursday, November 10, 2011

The Working Model

We needed to have a working system to show to our EP's this week. This was a bit of a challenge because we had changed the game so many times. From the beginning Felix had been working on the side bar (where clothes are selected) of the game and I had been working on the actual visuals (menus, models and texture changing, randomization of the outfits, etc..).

In preparation both Felix and I got our specific parts of the engineering done, and then we worked a bit on combining them. We both had a working version of the game that we then integrated together. The outcome turned out pretty good. We just need to add music, and some things to make it "sparkle".

Friday, November 4, 2011

The Dynamic Game

So, this week after further discussion with our group and the Executive Producers it has been determined that we will have only one mini-game. At first we were trying to add a "I Spy" type game to the closet so that the player would need to find articles of clothing in order to have it available for the dress up portion of the game. That idea fell through. It is proving difficult to put the game in this toy.

We came up with the idea of having a roulette spin and show an outfit for a few seconds that the player would need to memorize and then match. The time would for matching and seeing the goal outfit would decrease after every level making it harder to complete the task. After talking with our EP's yet again we have changed this to be a "Simon Says" type dress up game.

It sounds good. We'll see how it goes.

Friday, October 28, 2011

Dress up Madness

So our new groups for our next prototype have been made, and our prototype has been selected. This time we are going to be developing a game for Siena Entertainment. They mostly specialize in ebooks (try them out, they're pretty entertaining) in the Apple app store and they want to branch out into gaming. WE are to use one their IP (Intellectual Properties) to develop a game. There are four groups working on this and they have four IP's. This where we hit our first glitch. There was one IP that was targeted for toddlers ( 1 - 5), one for preteen girls (8 - 10), and the other two were pretty open in there age demographic. We ended up being assigned the preteen girl game. Our other constraint is that we need to use Unity to develop the game.

So what we have decided is that we are going to be developing a dress up game using the IP we are working on. There are some other elements we are working into the game, but it is mainly dress up. We'll get more into the other parts later.

The main obstacles I see in this game are that the two programmers involved both have full-time jobs (this wasn't too bad for me before because I was very familiar with Power Game Factory and XNA, which brings us to the next part of that obstacle) and they neither of them have ever used Unity before. The other main obstacle I see being a problem is moral. Some people on the team aren't very excited about the project and it kind of affects the rest of the group. I think this will go away as we get more element worked into the project... minigames!

Yes we are trying to fit in some minigames. Charlie our producer and I sat with one of our Executive Producers and 'brainstormed' some ideas on what we can do to make this app less of a toy and more of a game. Hopefully this will excite the team a bit more.

As for the programmer obstacle, Felix and I are both looking at Unity and implementing things that we know we will be using in the project. That is menus, UI, and tap and move. I've also been making a list of what needs to be done by the Engineers (programmers) and how to divide that work up between us most efficiently. That will be fleshed out by our next meeting.

Our Artist (Michelle) in the meantime is starting to create assets for us.

Well keep your fingers crossed for us.

Friday, October 21, 2011

Post-Mortem

Well, the XNA prototype for Mechanical Engineering has finally been "completed" and presented. I am very pleased with the outcome of our game. I'm especially pleased that we were able to get all our main features in (minus the money collection). I think that the success of this build was rooted in our team work and willingness to work over Fall Break.

When we first got together we effectively planned what the roles of each team member would be along with what each member expected from the others in the group. I believe that this openness and frankness allowed the group to function as a cohesive unit, thus allowing us to get the project together. I feel that Troy did an excellent job on getting us to do this early on. I was very pleased that we were able to get art assets from Ashley early on in the production. This helped the engineer's immensely. From my past experience with XNA I can't help but cringe at the stress and and effort it took to get art assets from our team that we could use in game. Having it early on allowed us to work out those bugs early on and boosted the moral by making the game feel as if it was actually progressing. I mean no matter how much code we had, if we can't show it off with a graphic it just doesn't come across as being done. As far as Engineering the game, it was great that both Kameron and I were familiar with XNA. We were able to quickly hash out what we needed to program and divide the work so that we wouldn't need to depend on the other person's code early in the development. For example, Kameron worked on the level setup and game objects the first week, so I worked on mouse control and the menu, credit, and other screens because they didn't rely on each other. As we got further into the process where single files were in need of editing, we were able to sit together and team program our last minute essentials when

Cheers to our team Repel. I am pleased with the results and I can only hope that the rest the projects in this class go as well.

The Final Crunch and Presentation

When we met again on the Monday after fall break we received more fantastic art from our Artist Ashley. We now had the assets needed to create our Market Place. In the game after the Prince is launched you are taken to the Market place in order to purchase upgrades for your catapult and other items. We only have the catapult upgrades in our market at the moment. There are three. You can purchase an upgrade that allows you to customize the Force at which the Prince is released, on to adjust the Angle at which the catapult releases the Prince, and an object to adjust the Length of the catapult arm. Kameron and I did a team programming session and got this added into the game just in time for us to show our Executive Producers our game so far.

Three of our Four EP were able to give us feed back as to what we should do before our final presentation of this prototype. On the Art side we were told to make the lines of our objects bolder. The details of the objects just weren't shining through. It was also recommended that we make the objects bigger. It was also recommended that we reposition the objects in our game so that they didn't distract from what our main focal point was supposed to be.

For Engineering we were told to have the catapult arm move with the Prince and to make the Obstacles in the air actually move instead of remaining static. We also told that adding in an achievement system would be cool and we could use a help button to show the physics equation so that the player would know how to adjust the separate components of the catapult.

We took these suggestions to heart and tried to implement as many of them before Wednesday. While Ashley went to work on fixing the art I talked with Kameron on what files would need to be edited in order to make the objects move and then I made the adjustment so that all of the objects moved either up and down, or left and right. I then took the new art from Ashley and placed them into the game. By this time we needed to finish for the day.

Before Wednesday came I was able to add the catapult arm to the game. Initially we were thinking of having the catapult movement be based on a sprite sheet, but as we thought about making it adjust both angle and length we realized that we would need to take one image and manipulate it with code so that it would act correctly. I took the image that we had for the catapult arm and implemented the movement and growth into the game. It was very satisfying to see the arm move, lengthen, and shorten in correlation with the Prince as the different values were adjusted on the scrollbars. It definitely gave the game a nicer polish. I even made it so that after you chose the angle at which the arm would release the Prince and pressed the launch button, the arm would then go back and then launch the Prince. Before the Prince would just take off from the release angle. The speed of the catapult launch even reflects the Force at which the Prince is released. If it's a low Force the arm move slowly, the higher the Force the faster the arm movement.

After this I added an achievement system. At this point I didn't have much time, so I was only able to make three achievements. They correspond to hitting the obstacles in front of the Princess' tower. If you hit the Pegasus you get "Pegasus Rider" the Bear gives you "Bear Trainer" and the Dragon "Dragon Flayer".

Title Screen:Main Menu:Game Screen when launched:Market Place:Preparing to Launch again (Notice achievement in top right corner):Win Screen:

Credits Screen:
The presentation went well on the game and we all came away feeling pretty good about it.

Friday, October 14, 2011

Fall Break Fun

Before Fall Break started Troy (the Producer), Kameron (An Engineer), and I (Another Engineer) got together and started to work on putting the actual Physics into the game. Troy had been studying the exact Physics we would need to work the catapult and how the different variable affect the projectile formally known as Prince. We ended that session with the Prince launching and gong the desired distance with a nice looking parabola of travel. We decided that we should meet again during Fall break to get more done and fine tune the Physics.

We met again during Fall break. Kameron had made it so that the Prince would change position when the angle was adjusted. I added a scroll bar for the length of the catapult arm and made the adjustments so that the prince changed position with the arm. At the point the Catapult arm remained static and only the Prince's position was changed. The Physics were also smoothed out so that the Prince traveled in an aesthetically pleasing manner.

Tuesday, October 4, 2011

Scroll to your heart's delite

The game is moving along now. We decided that the game needed scroll bars to adjust the value of needed variables. That is, the prince in our game is going to be launched from a catapult in order to get to the princess. We have it so you can adjust certain attributes of the catapult in in order to land in the right spot. These adjustments are going to be controlled by scroll bars. You adjust the scroll bar until it ready the value that you want to assign to that specific attribute and then you press launch and hope you reach your goal.

I have just completed the code for the scroll bars and added some into the level of our game and it looks pretty good. Once we have all the place holder images completed it will look even nicer.

Monday, October 3, 2011

Mouse Control this is Major Tom

We decided that since this new project is going to be for windows that we would like to use a mouse as a controller. I figured that that would be simple, but it ended up being a big pain. First, you need to make the mouse visible, easy. Now you need to make it so it can detect objects and influence what they do and that they can tell if they have been clicked. Not as simple. You do have a MouseState provided for you, but it just tels you if there is click on one of the buttons. I decided that since I had to write a bunch of code for detecting if the mouse button is being held, and if the click counts as a double click that I would just write a new mouse class or object. so that is what I did. The cool thing about ti is that we can now have a custom cursor for our game, and I understand how it works, because I coded it.

To go with the Mouse object I ended up writing a new object class for clickable objects. That is, this class is for any items on the screen that we want to click and have interact with the mouse. things such as buttons and scroll bars.

I made up our menus and went a ahead and applied the clickable object code to them and it's working pretty good. Now to make scroll bars. Yay!

Friday, September 23, 2011

New Prototype Project

On Monday we were given a new project for us to prototype. Our client is the School of Mechanical Engineering. They would like us to come up with a game that will introduce the principles of Physics to the Freshmen that may not have had Physics before.

So we know that the game needs to actually make the students solve Physics problems in order to progress. We decided that we would start out simple with first levels teaching principles such as cause and effect. The later levels would involve the students solving for missing values in order to get through the level.

This teaching or playing process is going to be manifested in our game "Prince Alarming's Repelzel Rescue" or something like that. This game Features our hero Prince Alarming trying to rescue Repelzel with the aid of his squire Wingman. Prince Alarming tries to reach Repelzel in her tower with the use of a catapult. He, of course, leaves all the work up to Wingman to see that he can reach her. This where the Physics comes in. Different variables have to be manipulated to ensure that the Prince can reach Repelzel.

Repelzel on the other hand does not really want to be rescued by the Prince. In fact she is in the tower to keep him away. She also sets up obstacles to prevent him from reaching her. When he does reach her, sh ends up pushing him off of the tower and retreating to the next level.

On Wednesday we pitched the idea and we divided up tasks to be done in order to get this thing done. This involved the other Engineer and me to get together and figure out how we are going to program this thing. We made up a diagram of game flow and and game states along with a list of classes or objects that we will need for the game to run. We then had to estimate how many working units each task would take. Our Producer then made up charts for us to manage our schedules and figure out how we are doing for the deadline of the prototype.

Friday, September 16, 2011

Crunch Time and Presentation

Our prototype was due for presentation this last Wednesday. In this meant that we needed to finish anything we wanted to get in the game on Tuesday. I may have said before that I thought our game was already good enough as a prototype, but that didn't mean we didn't want to polish it up.

I spent four hours Tuesday morning making a final design for our level and remasking it. After this was involved adding pending art assets into the background image and resetting the game objects once the new background was inserted. I also added many more enemies to the level to give it a bit more of a challenge. Before this, they were pretty much non-existent in the last half of the level.

Once the level was in I polished some of the buggy mechanics that were in the level. this included included the AI for some of the germs and the mechanics for the final boss fight. After this polishing I sent the files I'd worked on to the rest of the team and they polished some more. That is, they added remaining sound effects that needed to be placed, and getting the background music to transition properly from game to boss battle. I met up with them again later on Tuesday and we made some of the images larger so that they could be seen better. (We also did this because our instructors mentioned that it might be a good idea.)

Well Wednesday came around and we presented our prototype along with the rest of the class. I think all of the games pretty cool. I'm biased towards the one my group made, but I wouldn't mind playing the others. As a special treat I'm posting the design for the final Boss. That's right when you fight the last guy he transforms into the uber-boss-guy-man! Rogerm!!!


The next project we will be working on in class will be built using the XNA studio. Stay tuned for more details.

Thursday, September 8, 2011

Art Assets and Sound


So one of the main tasks that I've taken for "Germinators" is that of putting the art assets into the game. Basically, our excellent artist scans his inked drawings and sends them to me. I crop out the inked version of the drawings and set them on a transparent background. After this I scale the images to the size they need to be for the game, and then I give them the texture they need to have for the game. When I took on this responsibility I was not aware of how time consuming it would be. It takes quite a bit more time then I expected. To the left you can see our main character.

I have, however, been able to put quite a few more assets into the game. Our Producer sketched up a level for us and I went ahead and put it into the game and added masking (this is what lets the sprites or characters know where the floor, wall, ceiling, platforms, etc... are) so that we could start testing the placement of platforms and other objects. We also now have four "normal" germs and the "Boss" inside of the level. I also created a "super-form" for our main character. He assumes this form when he hits a power-up. To be honest I created the form using already existing art from our artist. Yep, crop, copy, and paste are my friends. The power-up form is on the left. Our character becomes "Super-soap boy".

We also have some music and sound. I imported the files that our Producer produced and set them to play at the appropriate times. There is the normal level music, the power-up music, and the end-boss fight music. in game so far. I still need to place some of the other sounds we have. These are just general effects like taking damage and collecting items.

I've also been involved in setting up the way the game functions. I'm mainly responsible for the main character and the end-boss. Originally we were going to have our character get "sick" when he touched a germ. At this point his health would steadily decrease until he succumbed to his illness or he washed his hands. Unfortunately we have not been able to find this functionality in PGF. We have decided that the character will just have lives for now as that endeavor was taking up too much time.

Another obstacle that we found was getting the "Super-form" to function properly. The already created power-up in PGF only makes it so that the character isn't harmed while in that form. We wanted it to act more like the "star" in "Super Mario Brothers" where he killed everything by touching them. Unlike other areas of PGF the power-up item cannot have its attributes edited. I was finally able to get the functionality that we wanted by creating a "hotspot" in the game that activated a script that would change the character to the "super-form" for a certain amount of time and then change back. So now we every power-up item in the game is encapsulated in a "hotspot" box. This way when the power-up is collected the script is initiated and the desired effect is seen.

I've also worked out the Boss' characteristics and how it fights. The boss is initially in the form to the left. When enough bars of soap are thrown at it it transforms to another form that also needs to be beaten. I've got all of that working now and the first incarnation of the boss is pretty good. I need to work on the logic for fighting the second form of the boss now. I may put up that image later.

The game is gong quite nicely. I think what we have now would make a pretty decent prototype as is, but as we have more time we are going to continue improving the game.

Wednesday, August 31, 2011

Germinators: Infiltration of Cesspool Elemetary

So in our group project at school my group is creating a platformer prototype game using Power Game Factory. This is an game development kit developed for the creation of Macintosh games. Now this isn't my first time using this product, so I'm somewhat hoping to be able to get some things done technically that I wasn't able to do before. We'll see if time permits.

For our current game we were given only three conditions that had to be met. first, we have to use Power Game Factory. Second, we need to take on a serious topic. Finally, the game is to be a prototype, not a finished product. We are taking on the topic of germs. Specifically, germs in our childrens schools and how our kids can prevent getting sick. That said, we are building a game where an elementary student is fighting of germs at his school using soap. Think of it as "Super Mario Brothers" take on the flu if you will.

So far in our development I have created our title screen, and created the Player character using the art that our very able artist has provided. I have also created the main "weapon" of the Player. I'm also working on some of the special mechanics of our game. In my next post I will get some screen shots up and describe a bit more of our game.