Fell behind on the blog again, mostly because there's so much to do this is the last thing on my mind. Our final client ended up canceling out at the last minute so it turned out that we were free to do whatever we wanted. Which despite sounding awesome, really isn't as we were struck pretty hard by paralysis through freedom. This time we were working in Unity, which was a first time experience for everyone except Cody and Damean.
Week 1
We spent the first week (which happened to be Thanksgiving week) brainstorming and trying to come up with ideas. Initially we were really strong on the concept of a game where the player starts out with a very powerful character who slowly loses his powers over the course of the game. While we felt this would be a really cool mechanic to explore, in the end we weren't able to come up with a way to do that wouldn't make the player end up hating the game.
In the end, we settled on pretty much the opposite. We went with a physics based combat/platform-er game with the goal of making the player feel powerful. Our vision was to have hordes of enemies charging the player and he'd blast them all over the place sending them flying with various physics based power moves. Over Thanksgiving everyone prototyped out ideas for what they thought the game should have.
Week 2
When we got back on Monday everyone was pretty shocked to find that Cody had gone far beyond what anyone had expected and prototyped out a version of our prototype. Everyone sat down and played with it and we instantly knew that we were onto something since it was so much fun to play around with. Everyone else shared what they'd come up with over the break and then all the engineers broke off to work on sections of the game.
Since it had worked so well before, Jason and I decided to pair program once again, which was especially helpful since there weren't really enough tasks for the number of engineers we had in this larger than previous group. Together we focused on getting a 3rd person camera into the game, which also gave us the responsibility of character movement since the two are intrinsically linked.
We started off by pulling down as many examples of 3rd person cameras we could find in Unity and checking out their scripts. After that we tried incorporating them into our game to see how they'd work and what we'd need to modify for our purposes. On Friday we took the character control script that Cody had written, and the camera and character scripts that Damean had from a game he was working on, and merged them together as best we could to create our own versions of them.
In the end, we had a camera and control system that functioned pretty much the same as our first ever attempt with a few slight issues. We decided to show them off to the team next week to decide which direction to pursue.
Week 3
Monday we showed everyone what we'd come up with and decided to go with our initial implementation since it was the smoothest and most functional version. We continued to fine tune that and finished up our job and sent out the code to the rest of the group. Additionally, now that we had the core systems down, Jason and I got our main character model into the game and fully implemented his animations, which is done in a pretty interesting way in Unity.
Wednesday disaster struck as Unity version control finally hit back. A bad build rendered the game completely unplayable and Cody and I had to revert to the version I'd submitted with the working camera which was the last stable build we could find. From there we worked through the changes that had been made until we found which one had caused everything to break and resolved the issue. We lost a lot of time, but fortunately the game was far enough along that it didn't hurt us too badly in the end.
All in all Unity is a pretty awesomely powerful tool for prototyping, although the struggle with version controlling it in a large team is pretty frustrating.
Thursday, December 6, 2012
Wednesday, November 14, 2012
Friendly Frogs Post-Mortem
Well, the third prototype is now over and based on the amount of questions we got I think the clients enjoyed what we came up with. And in the end, despite any troubles we may have had over the 4 weeks (and there WERE troubles) I think our end product is actually very similar to the goal we set in the first place.
During the post-mortem the group agreed that the biggest issue for us was not a lack of communication, but there being too much miscommunication. Several time people would talk about or even code up or just simply not know how a section of the game was supposed to behave. Inevitably I have to fault our producer on this as in the end, I felt more like the producer of this project, which was incredibly hard to balance with my engineering duties as well. On the plus side, it was a glimpse into what it's like being a designer/producer. And while I loved the design aspect of shaping the game into what I wanted it to me like, the production role was not enjoyable.
Despite everything that happened though, I'm very happy with our end product and I feel like I learned a ton of things this project.
During the post-mortem the group agreed that the biggest issue for us was not a lack of communication, but there being too much miscommunication. Several time people would talk about or even code up or just simply not know how a section of the game was supposed to behave. Inevitably I have to fault our producer on this as in the end, I felt more like the producer of this project, which was incredibly hard to balance with my engineering duties as well. On the plus side, it was a glimpse into what it's like being a designer/producer. And while I loved the design aspect of shaping the game into what I wanted it to me like, the production role was not enjoyable.
Despite everything that happened though, I'm very happy with our end product and I feel like I learned a ton of things this project.
Monday, November 12, 2012
Week 3 Update
I focused and really cranked out a ton of code this week. I'd learned a lot from the previous week (even if I got hardly any code out) and I finally feel like I at least somewhat understand how to use HTML5, CSS, and Javascript. Javascript in particular really isn't that bad since it feels identical to Java for me, which is easily the language I'm most comfortable with.
In the end, all my work on canvases the previous week was thrown out since they we're being too annoying. I have a background image that's fixed, a character image that sits on top of it, and the arrow for the gauge that I draw in different positions depending on the situation. 6 buttons on the bottom of the screen allow the player to control the conversation, although we don't have any actual dialog. Instead we simply have placeholders indicating if a button is a positive, neutral, or negative response. Depending on which is clicked, the character will smile, look neutral, or frown and the gauge will move in the correct direction (or not move at all in the case of a neutral response).
AB was working on the navigation, which is working, but as of right now still needs the last few touchups to get the days of the week and conditional characters based on those days in. We'll easily be finished by Wednesday for the presentation to the client.
In terms of the game itself, I feel that it does have the potential to be very fun, the issue in us attempting to convince people of that is that it's missing the conversations which are what drive that fun and play. I feel like we've done a good job of setting up the entire framework of the game, however, and hope that it will be apparent how they could create conversations for it since they're much more experienced in the subject.
In the end, all my work on canvases the previous week was thrown out since they we're being too annoying. I have a background image that's fixed, a character image that sits on top of it, and the arrow for the gauge that I draw in different positions depending on the situation. 6 buttons on the bottom of the screen allow the player to control the conversation, although we don't have any actual dialog. Instead we simply have placeholders indicating if a button is a positive, neutral, or negative response. Depending on which is clicked, the character will smile, look neutral, or frown and the gauge will move in the correct direction (or not move at all in the case of a neutral response).
AB was working on the navigation, which is working, but as of right now still needs the last few touchups to get the days of the week and conditional characters based on those days in. We'll easily be finished by Wednesday for the presentation to the client.
In terms of the game itself, I feel that it does have the potential to be very fun, the issue in us attempting to convince people of that is that it's missing the conversations which are what drive that fun and play. I feel like we've done a good job of setting up the entire framework of the game, however, and hope that it will be apparent how they could create conversations for it since they're much more experienced in the subject.
Friday, November 2, 2012
Week 2 of Friendly Frogs
Compared to the previous prototypes, we are nowhere near as finished with this current project. Learning HTML and Javascript wasn't bad at all (ignoring the case where getting a background to show up on a canvas refused to work despite multiple tutorials saying it should) so that's definitely not to blame. It's hard to put my finger on it, but I know it's impacting all the groups and not just us. I think a large part of it has to do with it being hard to work in a lab setting when others around you aren't working.
All that being said though, I'm not concerned about us not finishing on time. I'm planning on really buckling down this coming week and fully expect to have it completed by Thursday. I've read up and understand everything I need to get my section of the code running, I just need to actually get it done. The code behind our game isn't particularly challenging, and I'm most concerned about he conversations since they're really the heart of this game. Worst case scenario the prototype will show what we're aiming at and that it works, and the conversations will really just be filler that the therapists can replace.
And I do feel that this will be a fun and enjoyable game both for people with autism, and those without.
All that being said though, I'm not concerned about us not finishing on time. I'm planning on really buckling down this coming week and fully expect to have it completed by Thursday. I've read up and understand everything I need to get my section of the code running, I just need to actually get it done. The code behind our game isn't particularly challenging, and I'm most concerned about he conversations since they're really the heart of this game. Worst case scenario the prototype will show what we're aiming at and that it works, and the conversations will really just be filler that the therapists can replace.
And I do feel that this will be a fun and enjoyable game both for people with autism, and those without.
Thursday, October 25, 2012
Round Three Begins!
This week we've started our third round of rapid prototyping the the Game Projects class. This time around I'm paired with JJ as the producer, AB as a fellow engineer, and (surprisingly, but awesomely), Alice as an artist once again.
This week we had multiple clients once again* with one of the themes being Autism, and the other Shoshone.
On the negative side, JJ was sick on Monday and thus absent from the clients presentations. Roger filled in for him though, and gave us a bunch of great ideas which helped us flesh out our game. In the end, here's what we came up with (taken from the message I sent out to the group):
Story/Background:
You are a frog living in a huge pond, but you've never seen more of it than your neighborhood. One day you decide that you want to see the "world", but you're too nervous to do it alone so you decide to start making friends to explore with.
Gameplay:
The game will have a week cycle where NPCs are only available on certain days (new thought: if we have sub-locations of the unlock-able locations maybe NPCs would show up in different places depending on the day as well?). Each day the player will be able to converse with anyone who's present that day. They could have anywhere from 1 to 3 "conversations" with the same person, but after the fixed amount the NPC would make it clear they'd like to leave and continued attempts at maintaining a conversation would have a negative impact on your relation with them (to enforce recognition of when a conversation is over). Throughout these conversations, NPCs will reveal likes and dislikes the player will need to remember for use in future conversations (perhaps to move between sub-zones of the gauge you have to remember a like/dislike?). The gauge is the core mechanic to allow the player to see the state of their relationship with the NPC they're currently talking to. It has 3 main sections: positive, neutral, and negative. Positive and negative each have 3 sub-sections: best friend, friend, acquaintance, dislike, hate, and enemy (reading from most positive to most negative. Note: I just came up with these names on the spot, they likely need changing). The negative aspect of the gauge is important as it allows the player to choose if they don't want to be friends with a NPC. (If you can read cues to make someone dislike you, the reverse is possible as well.). This will also tie into the presence of negative NPCs as well who the player may not want to befriend. Finally, each NPC the player reaches maximum friendship with will then join up with the player in exploring the pond, unlocking a new section of the world map and thus new NPCs to interact with.
Additional Notes:
Conversation decisions can impact your relationship with animals other than the one you're currently talking to. Ie: If a bully frog asks if you want to have fun by going around and smashing fish eggs and you go along with it, your relationship with every fish is going to drop. (a destructive example like this may be too extreme, just using it as an example)
NPCs can have relationships as well. Maybe if you've made friends with a turtle and you're trying to make friends with one of its friends your gauge starts a bit higher. (can work in reverse as well). I'm really happy with our end result and I think it's actually going to be a pretty sweet game. I will fully admit a large portion of it is drawn from the social side of Persona, although we'll have more player options per conversation and there's the option to choose to make enemies instead of friends. Which thinking about it, could make for a pretty awesome mechanic in Persona 5 (Hint Hint ATLUS).
Oh right, and we have to program in HTML5 for this project. It's certainly going to be interesting.
* I have to admit I am not a fan of this. Since we need people to work for every client, people end up being forced to work for a project they have little initial interest in. In my case, I've already done work with autism, but I've never worked on Shoshone and I loved reading (actually having my parent's read to me) their mythology as a child. At the same time, I suppose we're not always going to be working on a project we're thrilled about, so it's good to get used to that.
My Shoshone game idea (Cause I like it so much):
Genre: 2-D platformer.
Twist/Question: The character would be a Shoshone word (with multiple unlock-able and selectable characters) Different characters could have various special abilities depending on the word selected. Power-ups would transform the word into a more powerful version i.e. Pup to Wolf. Enemies would be themed to the level and would be the dominant languages of the world that are responsible for killing off these smaller languages. So the French level, for example, would have a bunch of french words as enemies.
Meets the clients goals by showing Shoshone as powerful, fighting off these other languages from their attempts to quash it. On top of that, from an educational standpoint, you're learning words from a TON of different languages.
This week we had multiple clients once again* with one of the themes being Autism, and the other Shoshone.
On the negative side, JJ was sick on Monday and thus absent from the clients presentations. Roger filled in for him though, and gave us a bunch of great ideas which helped us flesh out our game. In the end, here's what we came up with (taken from the message I sent out to the group):
Story/Background:
You are a frog living in a huge pond, but you've never seen more of it than your neighborhood. One day you decide that you want to see the "world", but you're too nervous to do it alone so you decide to start making friends to explore with.
Gameplay:
The game will have a week cycle where NPCs are only available on certain days (new thought: if we have sub-locations of the unlock-able locations maybe NPCs would show up in different places depending on the day as well?). Each day the player will be able to converse with anyone who's present that day. They could have anywhere from 1 to 3 "conversations" with the same person, but after the fixed amount the NPC would make it clear they'd like to leave and continued attempts at maintaining a conversation would have a negative impact on your relation with them (to enforce recognition of when a conversation is over). Throughout these conversations, NPCs will reveal likes and dislikes the player will need to remember for use in future conversations (perhaps to move between sub-zones of the gauge you have to remember a like/dislike?). The gauge is the core mechanic to allow the player to see the state of their relationship with the NPC they're currently talking to. It has 3 main sections: positive, neutral, and negative. Positive and negative each have 3 sub-sections: best friend, friend, acquaintance, dislike, hate, and enemy (reading from most positive to most negative. Note: I just came up with these names on the spot, they likely need changing). The negative aspect of the gauge is important as it allows the player to choose if they don't want to be friends with a NPC. (If you can read cues to make someone dislike you, the reverse is possible as well.). This will also tie into the presence of negative NPCs as well who the player may not want to befriend. Finally, each NPC the player reaches maximum friendship with will then join up with the player in exploring the pond, unlocking a new section of the world map and thus new NPCs to interact with.
Additional Notes:
Conversation decisions can impact your relationship with animals other than the one you're currently talking to. Ie: If a bully frog asks if you want to have fun by going around and smashing fish eggs and you go along with it, your relationship with every fish is going to drop. (a destructive example like this may be too extreme, just using it as an example)
NPCs can have relationships as well. Maybe if you've made friends with a turtle and you're trying to make friends with one of its friends your gauge starts a bit higher. (can work in reverse as well). I'm really happy with our end result and I think it's actually going to be a pretty sweet game. I will fully admit a large portion of it is drawn from the social side of Persona, although we'll have more player options per conversation and there's the option to choose to make enemies instead of friends. Which thinking about it, could make for a pretty awesome mechanic in Persona 5 (Hint Hint ATLUS).
Oh right, and we have to program in HTML5 for this project. It's certainly going to be interesting.
* I have to admit I am not a fan of this. Since we need people to work for every client, people end up being forced to work for a project they have little initial interest in. In my case, I've already done work with autism, but I've never worked on Shoshone and I loved reading (actually having my parent's read to me) their mythology as a child. At the same time, I suppose we're not always going to be working on a project we're thrilled about, so it's good to get used to that.
My Shoshone game idea (Cause I like it so much):
Genre: 2-D platformer.
Twist/Question: The character would be a Shoshone word (with multiple unlock-able and selectable characters) Different characters could have various special abilities depending on the word selected. Power-ups would transform the word into a more powerful version i.e. Pup to Wolf. Enemies would be themed to the level and would be the dominant languages of the world that are responsible for killing off these smaller languages. So the French level, for example, would have a bunch of french words as enemies.
Meets the clients goals by showing Shoshone as powerful, fighting off these other languages from their attempts to quash it. On top of that, from an educational standpoint, you're learning words from a TON of different languages.
Thursday, October 18, 2012
Post-Mortem #2
Our post-mortem this time around was trickier than last time since things went so smoothly. I think two main factors contributed to this ease: Scrum, and pair programming. Scrum allowed us to stay more in touch with Alice and her with us so everyone knew how much progress had ben made. Pair programming kept Jason and I on the same page and also allowed us to tear through what we needed to get done resulting in us finish all of our goals and allowing us to work on extra features we initially weren't sure we'd have time to include. As a result of all this, I feel like we got out a really great prototype and the client seemed to confirm this. Getting funding on the project seems pretty likely and the group is definitely interested in continuing to work on it, so that's awesome.
We found out that our project next week will be in HTML5.... That's going to be interesting since the last time I wrote HTML was about 10 years ago. Considering it's still under development it seems like this project is going to be more similar to the first with MOAI, where everyone is going to be learning how to use the language initially.
On Monday we'll get our new clients and find out what type of games we'll be making. I'm looking forward to it.
We found out that our project next week will be in HTML5.... That's going to be interesting since the last time I wrote HTML was about 10 years ago. Considering it's still under development it seems like this project is going to be more similar to the first with MOAI, where everyone is going to be learning how to use the language initially.
On Monday we'll get our new clients and find out what type of games we'll be making. I'm looking forward to it.
Monday, October 15, 2012
Seriously Delayed Update (My Bad!)
So obviously it's been ages since I last blogged. Completely spaced the whole thing for the two weeks before Fall Break. So since the last post, Jason and I have been working on Kinect Gardening in a pair programming manner which has worked out very well. We were able to get the Kinect up and working on the very first day, but while it was easy to set up, getting it to work well has proven to be a huge struggle. In the end, we've given up on trying to get it to work better since all our attempts have failed and it was just sucking up a lot of our time. Other then that, getting the game logic up and running wasn't too bad.
I also feel that we did a really great job with separating out the code into different classes. The vast majority of our code is outside of the core Game class.
Today we implemented the basics of the gopher logic. Gophers will now spawn on an "upgraded" square and if left alone for a length of time will "downgrade" that square. So for example, if you're currently working on turning all the squares from dirt to tilled, gophers will only appear on tilled dirt and will change it back to regular dirt. We don't yet have the downgrading functionality in, and the gophers don't disappear on their own. Not sure if we'll get that in before the final presentation, but the idea is at least given at this point.
I also feel that we did a really great job with separating out the code into different classes. The vast majority of our code is outside of the core Game class.
Today we implemented the basics of the gopher logic. Gophers will now spawn on an "upgraded" square and if left alone for a length of time will "downgrade" that square. So for example, if you're currently working on turning all the squares from dirt to tilled, gophers will only appear on tilled dirt and will change it back to regular dirt. We don't yet have the downgrading functionality in, and the gophers don't disappear on their own. Not sure if we'll get that in before the final presentation, but the idea is at least given at this point.
Sunday, September 23, 2012
New Project!
It's funny how many times I can remember to blog and yet fail to do so. Last week we met with several University professors who requested games for either educational or physical therapy applications. My group (Mike, Jason, Alice, and myself) chose to work on a game involving the Kinect to help stroke patients with physical therapy.
Our game is fairly simple, but should hopefully engage patients and make physical therapy a bit more enjoyable. We're calling it Kinect Gardening for now (which might actually already exist.... nope, apparently not). In it you have a small garden with several tiles of land that you can work with. The game plays out in stages with breaks between each stage since thats how the therapy sessions work. First the player would till the soil, then plant the seeds, then water the seeds, and finally harvest their end products. These can then be sold at a market earning the player money. With their new cash, the player can then buy new seeds from a wide selection and customize their garden.
Other ideas for the full game are to have moles pop up randomly around the garden at any time and if the player clicks on it (wack-a-mole) they'd get a cash bonus. Another interesting idea that came up is to have a helper that would assist patients take care of areas of the garden that they struggle to reach due to their injury. As the patient recovers, they would then become less and less dependent upon this helper which would hopefully make them feel good about the progress they've made.
Working with the Kinect should be interesting. As long as we can get it up and running we should be able to make this game without too much struggling.
Our game is fairly simple, but should hopefully engage patients and make physical therapy a bit more enjoyable. We're calling it Kinect Gardening for now (which might actually already exist.... nope, apparently not). In it you have a small garden with several tiles of land that you can work with. The game plays out in stages with breaks between each stage since thats how the therapy sessions work. First the player would till the soil, then plant the seeds, then water the seeds, and finally harvest their end products. These can then be sold at a market earning the player money. With their new cash, the player can then buy new seeds from a wide selection and customize their garden.
Other ideas for the full game are to have moles pop up randomly around the garden at any time and if the player clicks on it (wack-a-mole) they'd get a cash bonus. Another interesting idea that came up is to have a helper that would assist patients take care of areas of the garden that they struggle to reach due to their injury. As the patient recovers, they would then become less and less dependent upon this helper which would hopefully make them feel good about the progress they've made.
Working with the Kinect should be interesting. As long as we can get it up and running we should be able to make this game without too much struggling.
Wednesday, September 12, 2012
Post-mortem
Our first game has reached it's conclusion. The presentations today were all great, and it was really awesome to see the final state of everyone's games. They all look really impressive. I'm really looking forward to seeing what we all come up with for our future games.
In our post-mortem afterwards one point came up over and over again. Communication. Everyone universally agreed that we could have done a much better job at communicating with each other, especially cross specialization (i.e. producer with engineers, engineers with artist, etc...). Of course, next time with SCRUM in effect and stand up meetings going on every time the group is together this should be resolved, but it's good to keep in mind.
Common key highlights of the game process included getting collision code in, getting actual artwork into the game, and of course, finalizing the game.
The postmortem process itself, I felt, was very useful. It was really nice to sit around with the group and talk about what we'd done, how it had worked out, and what we think we could have done better. And while we definitely feel that there are a few things we could have improved on, all in all we all really seemed to feel that things had gone incredibly well.
Personally, looking back, it's great to see how far we've come since that first week when we were all struggling with Moai and it felt like making a game with it was going to be impossible. I love the game we ended up creating.
In our post-mortem afterwards one point came up over and over again. Communication. Everyone universally agreed that we could have done a much better job at communicating with each other, especially cross specialization (i.e. producer with engineers, engineers with artist, etc...). Of course, next time with SCRUM in effect and stand up meetings going on every time the group is together this should be resolved, but it's good to keep in mind.
Common key highlights of the game process included getting collision code in, getting actual artwork into the game, and of course, finalizing the game.
The postmortem process itself, I felt, was very useful. It was really nice to sit around with the group and talk about what we'd done, how it had worked out, and what we think we could have done better. And while we definitely feel that there are a few things we could have improved on, all in all we all really seemed to feel that things had gone incredibly well.
Personally, looking back, it's great to see how far we've come since that first week when we were all struggling with Moai and it felt like making a game with it was going to be impossible. I love the game we ended up creating.
Saturday, September 8, 2012
Week 3
So I meant to write up two blogs this week, one on Tuesday and another on Friday, but that obviously fell through.
Part 1:
So on Tuesday our group met in the lab since we didn't have class on Monday. Jake and I combined our code fairly easily and the end product was a functioning game that, awesomely, was really fun to play! In addition to this, we continued finishing the game on Wednesday. I added the energy bar to the top of the screen and tied functionality into it. With our resource system working, the game only got even more enjoyable. From here, the final element was our cow bouncing which Jake and I worked on together to get into the game. It functions a little oddly, but works fine so we called it good for the prototype. On top of all of this we finally started replacing our placeholder art with Alice's art. It did SO much for the game, it was really awesome to see the difference it made.
Part 2:
We met again yesterday on Friday to finish everything up for Monday's presentation. Jake and I polished our final issue, that of the game ending. Now when the game ends everything on screen freezes instead of continuing to move, which makes it look much nicer. We also tied in the final art pieces and completed the game. Unfortunately, due to other meetings we weren't able to finish the final step of tying the game into Sherly's code, which would have resulted in an entirely complete game. We did get footage of the gameplay though, and AJ is getting his presentation for Monday ready. Our goal for Wednesday is to have a completely playable game from the title screen for Beehive Cheese to demo (minus sound since that proved too challenging to add).
All in all I'm very happy with our progress. I never really felt stressed (once we figured out how to get started with MOAI) and we finished on time without the need to cram in a bunch of extra time at the end. On top of that our game is awesome and something I think I'd actually play on Kongregate (assuming it was actually finished and not just a prototype).
Part 1:
So on Tuesday our group met in the lab since we didn't have class on Monday. Jake and I combined our code fairly easily and the end product was a functioning game that, awesomely, was really fun to play! In addition to this, we continued finishing the game on Wednesday. I added the energy bar to the top of the screen and tied functionality into it. With our resource system working, the game only got even more enjoyable. From here, the final element was our cow bouncing which Jake and I worked on together to get into the game. It functions a little oddly, but works fine so we called it good for the prototype. On top of all of this we finally started replacing our placeholder art with Alice's art. It did SO much for the game, it was really awesome to see the difference it made.
Part 2:
We met again yesterday on Friday to finish everything up for Monday's presentation. Jake and I polished our final issue, that of the game ending. Now when the game ends everything on screen freezes instead of continuing to move, which makes it look much nicer. We also tied in the final art pieces and completed the game. Unfortunately, due to other meetings we weren't able to finish the final step of tying the game into Sherly's code, which would have resulted in an entirely complete game. We did get footage of the gameplay though, and AJ is getting his presentation for Monday ready. Our goal for Wednesday is to have a completely playable game from the title screen for Beehive Cheese to demo (minus sound since that proved too challenging to add).
All in all I'm very happy with our progress. I never really felt stressed (once we figured out how to get started with MOAI) and we finished on time without the need to cram in a bunch of extra time at the end. On top of that our game is awesome and something I think I'd actually play on Kongregate (assuming it was actually finished and not just a prototype).
Wednesday, August 29, 2012
Week Two
With a basic (VERY basic) understanding of MOAI, programming for the game has begun. My first assignment was to get the ingredients moving across the screen which was relatively easy to accomplish. From there I found that I needed to make the ingredients disappear when they reached the left side of the screen. In the end, a large portion of this initial code was modified to work with the collision code that came afterwords as my next project.
Collision was much more challenging to get up and running. In the end, the tutorials recommended Block thread method was causing issues with getting collision code to work, so I ended up stripping it out and replacing it. From there the process simplified greatly. The game loop has a frame tracker method I built and inside of that (since it's a location of code we know is constantly being updated) is where I placed the collision logic.
With this done combined with the work of the rest of the team we -should- have a working prototype of the game once we combine all of the code. Here's to hoping it works that smoothly!
Collision was much more challenging to get up and running. In the end, the tutorials recommended Block thread method was causing issues with getting collision code to work, so I ended up stripping it out and replacing it. From there the process simplified greatly. The game loop has a frame tracker method I built and inside of that (since it's a location of code we know is constantly being updated) is where I placed the collision logic.
With this done combined with the work of the rest of the team we -should- have a working prototype of the game once we combine all of the code. Here's to hoping it works that smoothly!
Tuesday, August 21, 2012
Day 1
Our first game project is to make a game about, of all things, cheese! While I initially drew a complete blank (Cheese RPG?) I came up with an initial idea I really liked. Thinking of a food based game brought me back to Harvest Moon 64 since it's a game I played a lot of and really enjoyed. Of course, since we're aiming for an iOS device something along the lines of Harvest Moon seems a little too complicated. Besides the farming in HM64 there's also gathering of ingredients in the wild and this seemed like a good approach. Our game could have a randomly generated field of ingredients and the player would have a time limit to run around gathering what they want.
From here we need to do something with our ingredients to actually make the cheese, a crafting system. I instantly thought of the new crafting system of Guild Wars 2. By starting with the base cheese, Promontory, players could try experimenting with the ingredients they'd gathered to figure out the recipes for the other cheeses. For instance adding coffee and lavender would create Barely Buzzed.
The main issue with this plan was that there aren't really that many different types of Beehive Cheese which severely limits this entire idea.
In the end, after a lot of group brainstorming, we came up with a completely different game that I actually like more than my initial game. Our current plan is as follows:
We moved to a launch based game since it's very easy to use on an iOS device. Thanks to our theme we knew we wanted a queen bee ordering a worker bee to fire our "cannon" which in this case is a beehive. Our "cannonball" is a cheese wheel of Promontory. Each launch will have a goal of target ingredients to crash the cheese wheel into such as 10 coffee and 5 lavender to make Barely Buzzed. To offer some amount of control over the cheese wheel we have a bee on top carrying it and by touching the screen he'll lift it up for as long as you touch or until his fatigue bar fills up. Fatigue will slowly regenerate when the screen isn't being touched. To deal with ground collisions hitting a cow (which will randomly be around) will cause the cheese to bounce back up into the air. Hitting the ground, however, gets he cheese dirty and ends the round in failure. If the player manages to collect all the ingredients in the goal they create the target cheese and win the round moving on to the next cheese.
All in all I think things are looking really good and we should be able to get a demo of this up and running in our 4 week time period. At this point we just have to figure out how to get Moai working....
From here we need to do something with our ingredients to actually make the cheese, a crafting system. I instantly thought of the new crafting system of Guild Wars 2. By starting with the base cheese, Promontory, players could try experimenting with the ingredients they'd gathered to figure out the recipes for the other cheeses. For instance adding coffee and lavender would create Barely Buzzed.
The main issue with this plan was that there aren't really that many different types of Beehive Cheese which severely limits this entire idea.
In the end, after a lot of group brainstorming, we came up with a completely different game that I actually like more than my initial game. Our current plan is as follows:
We moved to a launch based game since it's very easy to use on an iOS device. Thanks to our theme we knew we wanted a queen bee ordering a worker bee to fire our "cannon" which in this case is a beehive. Our "cannonball" is a cheese wheel of Promontory. Each launch will have a goal of target ingredients to crash the cheese wheel into such as 10 coffee and 5 lavender to make Barely Buzzed. To offer some amount of control over the cheese wheel we have a bee on top carrying it and by touching the screen he'll lift it up for as long as you touch or until his fatigue bar fills up. Fatigue will slowly regenerate when the screen isn't being touched. To deal with ground collisions hitting a cow (which will randomly be around) will cause the cheese to bounce back up into the air. Hitting the ground, however, gets he cheese dirty and ends the round in failure. If the player manages to collect all the ingredients in the goal they create the target cheese and win the round moving on to the next cheese.
All in all I think things are looking really good and we should be able to get a demo of this up and running in our 4 week time period. At this point we just have to figure out how to get Moai working....
Subscribe to:
Posts (Atom)