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 28, 2011
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.
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.
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.
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.
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!
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!
Subscribe to:
Comments (Atom)