Everything is set except for some main menu flair/a few small bugs. I'm going to spend the day in the lab finishing up this game and my other game for another class.
What I got done this week:
*All sounds are in the game!
*Made Joe's stilts animation function in game
*Fixed end-game GUI's (win/lose)
What I'll be doing today
*Adding flair to main menu
*Making How-To-Play/Credits menu
*Making Footage of Levels to put in main menu
*Squashing as many bugs as possible (3 that I'm aware of)
The more time I have the more stuff I'm going to try and add to make the game look great! I'll see everyone for the final presentation tomorrow!
-David
Monday, November 21, 2011
Thursday, November 17, 2011
Programming Update 11-17
Not too much to report- I've started to implement/animate Joe's spritesheets that he got to me this week. I'm just about done fixing the collision bugs involved with the stilts blocks. I fixed the glitchy winscreen GUI buttons and I'm basically gonna finish everything this weekend!
Wooo!
-David
Wooo!
-David
Tuesday, November 15, 2011
Phil Update 11/15/11
I modified lvl1 quite a bit. I think it's still a bit too hard, but what I might do is swap it for lvl 2 or 3.Will continue to work on the level design.
Thursday, November 10, 2011
Programming Update - 11/10/11
So we've made a lot of progress and we're basically polishing the level designs at this point. Nearly all of the sounds are set, with the exception of a few of the music cues bugging out. Here's what's left to do on the programming side of things:
*Fix/Finish implementing sounds
*Fix the collision checking for underneath the Player/Stilts
*Fix GUI/Menu on win screen
*Fix the collision checking for Stilts and Score Trigger Blocks
*Program animation functions for Joe's animations
*Implement saving high scores after quitting game (least of my priorities)
Sound programming has been giving me trouble, but I just need to step back from it for a day or so and not get too frustrated. The losing game condition w/ the curtains closing/sand bag dropping looks and sounds awesome (only thing missing is the music)! Here's what I got done these past few days
*Score blocks flash when they're about to change to normal obstacles
*Losing condition/cut-scene triggers and behaves appropriately
*Implemented new art/textured models
*In game high-scores
I won't lie- I'm burned out at this point. The flames still there, it's just I'm running out of wick to keep burning on. I'll make it through the quarter though, and Casablocka will be a fine piece of gameplay for us to all put our names on and be proud of :D
-David
*Fix/Finish implementing sounds
*Fix the collision checking for underneath the Player/Stilts
*Fix GUI/Menu on win screen
*Fix the collision checking for Stilts and Score Trigger Blocks
*Program animation functions for Joe's animations
*Implement saving high scores after quitting game (least of my priorities)
Sound programming has been giving me trouble, but I just need to step back from it for a day or so and not get too frustrated. The losing game condition w/ the curtains closing/sand bag dropping looks and sounds awesome (only thing missing is the music)! Here's what I got done these past few days
*Score blocks flash when they're about to change to normal obstacles
*Losing condition/cut-scene triggers and behaves appropriately
*Implemented new art/textured models
*In game high-scores
I won't lie- I'm burned out at this point. The flames still there, it's just I'm running out of wick to keep burning on. I'll make it through the quarter though, and Casablocka will be a fine piece of gameplay for us to all put our names on and be proud of :D
-David
Final Playtest Feedback 11/10/11
What went well and/or has improved:
- The game is seen as cheery and tightly controlled. The fact that players feel like they are in complete control is a very good thing.
- There is now a good sense of replayability and players want to become better or perfect levels.
- After playing the game twice or even once players are aware of what all the blocks do. They understand the mechanics and there's minimal confusion if any at all.
- The sounds and music really pull players into our aesthetic making them feel goofy/happy.
- The skill needed in order to get the stacking/jump blocks is something players seem to enjoy. They feel accomplished when they grow.
- They see the game's aesthetics and feel very different from other games. UNIQUE
- People LOVE the block collecting part.
- For the most part people see the game as fair. It isn't too hard and it isn't too easy. Good balance.
- People enjoy short challenging levels they can retry and improve their skills on.
What went wrong or still needs improving:
- Some players still believe that we need to provide them with a reason behind what they're doing. This could be solved with a simple opening cinematic or introduction screen. This isn't necessary for the final in class build, but might be something we want to add later if we decide to release it somewhere.
- Level design feels unfair in some spots and basically just needs to be iterated on much more. Phil: I'm going to spend at least a few hours doing this over the weekend. I haven't had a big chunk of time available, and I still don't, but I'm going to make the time.
- The animations are still rough or missing.
- Environment still isn't completely cohesive due to the screen just floating in the middle of no where. I think this is a problem, but I don't think we should follow all player advice on what to do about it.
- Although players feel in control most of them time there are a few moments when trying to switch lanes that it simply does not work for a single press.
- Should probably add sepia tone to the screen, but leave the rest the way it is.
- The game is seen as cheery and tightly controlled. The fact that players feel like they are in complete control is a very good thing.
- There is now a good sense of replayability and players want to become better or perfect levels.
- After playing the game twice or even once players are aware of what all the blocks do. They understand the mechanics and there's minimal confusion if any at all.
- The sounds and music really pull players into our aesthetic making them feel goofy/happy.
- The skill needed in order to get the stacking/jump blocks is something players seem to enjoy. They feel accomplished when they grow.
- They see the game's aesthetics and feel very different from other games. UNIQUE
- People LOVE the block collecting part.
- For the most part people see the game as fair. It isn't too hard and it isn't too easy. Good balance.
- People enjoy short challenging levels they can retry and improve their skills on.
What went wrong or still needs improving:
- Some players still believe that we need to provide them with a reason behind what they're doing. This could be solved with a simple opening cinematic or introduction screen. This isn't necessary for the final in class build, but might be something we want to add later if we decide to release it somewhere.
- Level design feels unfair in some spots and basically just needs to be iterated on much more. Phil: I'm going to spend at least a few hours doing this over the weekend. I haven't had a big chunk of time available, and I still don't, but I'm going to make the time.
- The animations are still rough or missing.
- Environment still isn't completely cohesive due to the screen just floating in the middle of no where. I think this is a problem, but I don't think we should follow all player advice on what to do about it.
- Although players feel in control most of them time there are a few moments when trying to switch lanes that it simply does not work for a single press.
- Should probably add sepia tone to the screen, but leave the rest the way it is.
Past two weeks update
I know i've slacked off on updating this. Here's what I got done: Updated the sandbag model to have a longer rope and adjusted the shape. Added and textured curtains model. Made a left curtain model, top curtain model, and right curtain model. I modeled and textured a stage model. I textured joe Dean's Reel model.
I've fixed any errors with the models and uploaded both the .ma's and the .fbx If there are any errors let me know so I can try to fix them.
I've fixed any errors with the models and uploaded both the .ma's and the .fbx If there are any errors let me know so I can try to fix them.
Tuesday, November 8, 2011
Phil Update 11/8/11
This past week not much got done on my part. Dealing with a few team communication issues and we've been shuffling some people around in the Octodad camp as well. Dealing with a good amount of drama. I did however iterate on the big long level that we've been working on and I have people lined up to playtest for Thursday's playtest review. I'd like to break up my longer level into three shorter levels.
Logan Update 11-8-11
I maxed all of the sounds outside of Unity and resubmitted them to David in a (hopefully) more organized manner. Other than that, as I'm sure everyone is, my final projects in other classes are really becoming demanding so I didn't get much more done.
I still need to put in a curtain sound and thud for the in game fail if we are implementing that.
Monday, November 7, 2011
Programming Update - The Finish Line in Sight!
Greetings to all-
I'm in a good mood right now, yes it's 8:23 in the morning but I'm feeling GREAT! The game has made a LOT of progress this week, so that's super cool (details below)!
In addition to being happy, I also have this underlying sense of frustration- other classes are starting to require a lot of time for their respective final projects. This is making me have to break up my work for Casablocka and oftentimes break a streak of implementation where instead of hashing out a feature/function in a day it takes the whole week :\
Despite this annoyance, we will prevail- the game is finally looking and feeling like a real game. Most of the features added this week were based on pre-/post-game experience (menus, win conditions, etc.) and wrapping our "play" portion into a nice package. Here's the list:
* Level Start:
The screen in the background does a 3-2-1 countdown before the player gets to run! The film reel begins to tick away and unleash the level upon the player and once the countdown hits zero the music kicks in and the player heads down the path! It feels REALLY nice and gives the player a chance to prepare themselves/build suspense for the experience moments away!
* Finish Line:
The game now possesses a finish line. When the player crosses it the end state is triggered. Speaking of which-
* End State Prototype:
This was a bit tricky but I was able to make it work. Essentially this is an in-game cutscene of sorts. When the player finishes the level, they jump to the middle ground and begin running fairly slow. The camera jumpes to a position facing the cube at a perpendicular angle and having the screen in the background. The screen (this is the only function that is not yet complete) will calculate the players final score as the player continues to run idle down the track. Eventually he hits a block with a girl on it (needs to be drawn, placeholder is...well...in place) and transfers into it- then they will kiss. It feels super great and reminds me of the endings in old platformers! And it's a cute reference to Casablanca, so like...I'd say it's super appropriate.
* Film Reel:
The film reel is in the level now! I also made it so the reel doesn't get too far into the distance because players LOVE seeing the level generate around it! Another layer of artistic cohesion :]
* Basic GUI Elements:
A counter for your time and number of Gold Blocks collected are now in place on the GUI. They really help the player feel immersed in the experience rather than annoyed by the ugly gui-based draw text region. The only thing left to do is decide how to display time remaining for players when they're in score mode (all obstacle blocks turn to gold) and to convert the "time displayed" into frames to feel, as mentioned many times before, cohesive in theme. As of now though I feel the GUI is headed in the right direction :D
* Curtains:
Matt got me the curtains and they look really good! Functionally, they might need some work but visually they are very stunning! Props to Matt :D
* Level Select Menu:
I have the level select menu basically completed. I have placeholders as of now, but there are going to be 3 levels to select from. The menu they see presents them with a short clip of gameplay footage from the level and will look really cool once the placeholder footage is gone (3-2-1 clip again) and we have actually screen cap from the game! :D
So that's everything I've been able to implement this week! The remaining work is just filling in the blanks left in the art and finalizing level design. My goals for this week are as follows:
* Create the death/end game sequence (Player stops running, sad music cues, sandbag drops, curtains close, retry menu pops up)
* Fix the score display to calculate in frames rather than actual seconds
* Add the calculation feature to the screen after the player finishes the level
* Add more functionality to the level select screen (show high scores)
* Add more game-scenes
- Title
- Level Select (DONE)
- Retry
- Levels (DONE)
- Credits
- How to Play (??? Do we need this ???)
* Add more of Logan's sounds
It seems like a lot, but this is essentially everything that's left to do. I'd LOVE to get the game "completed" by next week so we can run one more round of iterative play testing on new/old players to see what they think and make level design/game system tweaks from there. I also have a bug that needs squashing, so I need to get around to that too...sooo
* Squash said bug
There. The list is now complete. I didn't expect to get so much done this week, so I have high hopes for this week considering I have even MORE free time (though still selective free time :P). We seem to have momentum again and I'm using up the rest of my fuel to power through until the day we present our game!
Cheers,
David
I'm in a good mood right now, yes it's 8:23 in the morning but I'm feeling GREAT! The game has made a LOT of progress this week, so that's super cool (details below)!
In addition to being happy, I also have this underlying sense of frustration- other classes are starting to require a lot of time for their respective final projects. This is making me have to break up my work for Casablocka and oftentimes break a streak of implementation where instead of hashing out a feature/function in a day it takes the whole week :\
Despite this annoyance, we will prevail- the game is finally looking and feeling like a real game. Most of the features added this week were based on pre-/post-game experience (menus, win conditions, etc.) and wrapping our "play" portion into a nice package. Here's the list:
* Level Start:
The screen in the background does a 3-2-1 countdown before the player gets to run! The film reel begins to tick away and unleash the level upon the player and once the countdown hits zero the music kicks in and the player heads down the path! It feels REALLY nice and gives the player a chance to prepare themselves/build suspense for the experience moments away!
* Finish Line:
The game now possesses a finish line. When the player crosses it the end state is triggered. Speaking of which-
* End State Prototype:
This was a bit tricky but I was able to make it work. Essentially this is an in-game cutscene of sorts. When the player finishes the level, they jump to the middle ground and begin running fairly slow. The camera jumpes to a position facing the cube at a perpendicular angle and having the screen in the background. The screen (this is the only function that is not yet complete) will calculate the players final score as the player continues to run idle down the track. Eventually he hits a block with a girl on it (needs to be drawn, placeholder is...well...in place) and transfers into it- then they will kiss. It feels super great and reminds me of the endings in old platformers! And it's a cute reference to Casablanca, so like...I'd say it's super appropriate.
* Film Reel:
The film reel is in the level now! I also made it so the reel doesn't get too far into the distance because players LOVE seeing the level generate around it! Another layer of artistic cohesion :]
* Basic GUI Elements:
A counter for your time and number of Gold Blocks collected are now in place on the GUI. They really help the player feel immersed in the experience rather than annoyed by the ugly gui-based draw text region. The only thing left to do is decide how to display time remaining for players when they're in score mode (all obstacle blocks turn to gold) and to convert the "time displayed" into frames to feel, as mentioned many times before, cohesive in theme. As of now though I feel the GUI is headed in the right direction :D
* Curtains:
Matt got me the curtains and they look really good! Functionally, they might need some work but visually they are very stunning! Props to Matt :D
* Level Select Menu:
I have the level select menu basically completed. I have placeholders as of now, but there are going to be 3 levels to select from. The menu they see presents them with a short clip of gameplay footage from the level and will look really cool once the placeholder footage is gone (3-2-1 clip again) and we have actually screen cap from the game! :D
So that's everything I've been able to implement this week! The remaining work is just filling in the blanks left in the art and finalizing level design. My goals for this week are as follows:
* Create the death/end game sequence (Player stops running, sad music cues, sandbag drops, curtains close, retry menu pops up)
* Fix the score display to calculate in frames rather than actual seconds
* Add the calculation feature to the screen after the player finishes the level
* Add more functionality to the level select screen (show high scores)
* Add more game-scenes
- Title
- Level Select (DONE)
- Retry
- Levels (DONE)
- Credits
- How to Play (??? Do we need this ???)
* Add more of Logan's sounds
It seems like a lot, but this is essentially everything that's left to do. I'd LOVE to get the game "completed" by next week so we can run one more round of iterative play testing on new/old players to see what they think and make level design/game system tweaks from there. I also have a bug that needs squashing, so I need to get around to that too...sooo
* Squash said bug
There. The list is now complete. I didn't expect to get so much done this week, so I have high hopes for this week considering I have even MORE free time (though still selective free time :P). We seem to have momentum again and I'm using up the rest of my fuel to power through until the day we present our game!
Cheers,
David
Thursday, November 3, 2011
Phil Update 11/3/11
The past week I've iterated a bit on the level. I think it's getting there, but there's still a good amount of work to be done as far as balancing difficulty.
Tuesday, November 1, 2011
Update - Logan
I submitted the lane shifting noise (to David).
I composed and submitted 'CasaBlocka Rag' (to David) that will more than likely be used for the intro/start screen if everyone accepts it. No hard feelings if you don't like it, just let me know!
To try and have as many game assets our own, I'll see about writing another track for the game play once I've finished everything else (which isn't much more at this point). I really do like the current gameplay music though, so if I don't write another CasaBlocka Rag, I think we'll be fine. (But I'll try to write something similar, although so much ragtime is extremely similar to begin with :P )
Programming Update Part 2 - 11/1
I'm back with Part 2 of the programming update. Since I last posted, I've added the following features:
- Score Block Mode Fixed
It was never really broken...just not fully implemented. Score Blocks now can be collected from the sides and don't cause you to slow down upon collision. Hoorah!
- Tunnel Locking
This was a feature I had in the works a while ago but it didn't work so I ignored it. Well good news folks- I did it. When players enter a speed tunnel they no longer can accidentally break out of them. They now are shot through the tunnel blocks until they have come out the end of the line!
- Cool Track Generation
This feature is pretty sweet- I had been prototyping a new way for track to be generated, and now it seems to be working! An old film reel begins to roll from underneath the player/level and unleashes film (track) for the player to travel on. As of now the film reel is a placeholder for a model in the works, but it works and definitely adds to the aesthetic of the game.
- Sandbag
I added the sandbag to the level and I implemented some physics to make the world feel more alive. Whenever a player hits a block, the sandbag reacts and acts as if it was just hit as well. I think it's pretty cool, nbd.
- Sounds
I added more of Logan's assets to the game. The rolling film reel plays a projector/film tick sound as it rolls, the intro music now plays when the game is started, and the "pop" sound triggers whenever a player changes lanes. I implemented one of the clapping sound effects for whenever a player hits the highest speed, but it's bugging out and not playing out its full length. This will ideally be fixed this week
I'm about to work on a back-end for the game, as well as the front end to make it feel more alive. Placeholders abound, this should hopefully be finished before class starts.
-David
- Score Block Mode Fixed
It was never really broken...just not fully implemented. Score Blocks now can be collected from the sides and don't cause you to slow down upon collision. Hoorah!
- Tunnel Locking
This was a feature I had in the works a while ago but it didn't work so I ignored it. Well good news folks- I did it. When players enter a speed tunnel they no longer can accidentally break out of them. They now are shot through the tunnel blocks until they have come out the end of the line!
- Cool Track Generation
This feature is pretty sweet- I had been prototyping a new way for track to be generated, and now it seems to be working! An old film reel begins to roll from underneath the player/level and unleashes film (track) for the player to travel on. As of now the film reel is a placeholder for a model in the works, but it works and definitely adds to the aesthetic of the game.
- Sandbag
I added the sandbag to the level and I implemented some physics to make the world feel more alive. Whenever a player hits a block, the sandbag reacts and acts as if it was just hit as well. I think it's pretty cool, nbd.
- Sounds
I added more of Logan's assets to the game. The rolling film reel plays a projector/film tick sound as it rolls, the intro music now plays when the game is started, and the "pop" sound triggers whenever a player changes lanes. I implemented one of the clapping sound effects for whenever a player hits the highest speed, but it's bugging out and not playing out its full length. This will ideally be fixed this week
I'm about to work on a back-end for the game, as well as the front end to make it feel more alive. Placeholders abound, this should hopefully be finished before class starts.
-David
Saturday, October 29, 2011
Programming Update Part 1 - 10/29
Howdy y'all. I just needed to make a post because I'm super excited about the following:
The controls/collisions are fixed.
As of now all the game is feeling WAY more fluid- and the solution was literally adding a line of code to the creation of player-related objects. I don't know why I didn't think of it before, but Brian gave me an idea in class that I ran with and figured out the solution:
Essentially it was to change all blocks collision detection regions and scale them. I seriously don't know why I didn't do this before, and I had a dumb system set up where the player tests their position related to the colliding object after they've collided (really stupid...). I guess because I was working with dynamic objects, I didn't see an opportunity/possibility of scaling the collider without scaling the gameObject.
Turns out you can do this...in one line.
So I did it, but I did it slightly differently than Brian suggested:
Instead of doing it to all obstacle blocks, I did it to all player-related blocks: the player, stilts, left/right collider blocks. It seems to be working very well now :D
Team- I'm sorry it took so long for me to finally do this. Stupid David is stupid.
World- Be looking for some great changes come next week! Score blocks are gonna be super fun/tight once I'm done with them this weekend and assets are gonna start pouring into the world making the game really shine!
Goals for Tuesday/Time of Programming Update Part 2 post:
- Score Block fluidity (Add special collision cases due to natural difference in behavior)
- More Assets (Models/Sounds)
- Better Front/Back End Placeholders
Overachiever Goals:
- Transparent blocks when player is not visible
- Dynamic Camera Adjustment
workworkworkworkworkworkworkworkworkwork
-David
The controls/collisions are fixed.
As of now all the game is feeling WAY more fluid- and the solution was literally adding a line of code to the creation of player-related objects. I don't know why I didn't think of it before, but Brian gave me an idea in class that I ran with and figured out the solution:
Essentially it was to change all blocks collision detection regions and scale them. I seriously don't know why I didn't do this before, and I had a dumb system set up where the player tests their position related to the colliding object after they've collided (really stupid...). I guess because I was working with dynamic objects, I didn't see an opportunity/possibility of scaling the collider without scaling the gameObject.
Turns out you can do this...in one line.
So I did it, but I did it slightly differently than Brian suggested:
Instead of doing it to all obstacle blocks, I did it to all player-related blocks: the player, stilts, left/right collider blocks. It seems to be working very well now :D
Team- I'm sorry it took so long for me to finally do this. Stupid David is stupid.
World- Be looking for some great changes come next week! Score blocks are gonna be super fun/tight once I'm done with them this weekend and assets are gonna start pouring into the world making the game really shine!
Goals for Tuesday/Time of Programming Update Part 2 post:
- Score Block fluidity (Add special collision cases due to natural difference in behavior)
- More Assets (Models/Sounds)
- Better Front/Back End Placeholders
Overachiever Goals:
- Transparent blocks when player is not visible
- Dynamic Camera Adjustment
workworkworkworkworkworkworkworkworkwork
-David
Tuesday, October 25, 2011
Updated Schedule 10/25
Week 7 10/31
Overall Goal: Strive for Content Complete
Tech: Continue to crush bugs and refine.
Art: Get the rest of the animations roughed out and begin finalizing the others.
Design: Make final adjustments to movement and finalize some of the level design. Spread things out!
Audio: Make sure all the sounds get in game and finish finding/making the intro music.
Week 8 11/7
Overall Goal: Hopeful content complete still hopeful.
Tech: Bug fixing, but freeze on new features if possible.
Art: Have all the animations at the least roughed out and in the game. Work on finalizing/polishing.
Design: Finish the level(s).
Audio: All placeholder music/sounds replaced with our own.
Week 9 11/14
Overall Goal: Hopefully be able to relax. (Testing in reality.)
Tech: Become bug-less.
Art: Fiddle with positions of objects and make sure that all animation is running the way you'd like it.
Design: Check for level flow and make last minute tweaks.
Audio: Check levels of all the sounds and music to make sure we aren't blowing peoples ear drums or being way too quite.
Week 10 11/22
GAME DUE
Overall Goal: Strive for Content Complete
Tech: Continue to crush bugs and refine.
Art: Get the rest of the animations roughed out and begin finalizing the others.
Design: Make final adjustments to movement and finalize some of the level design. Spread things out!
Audio: Make sure all the sounds get in game and finish finding/making the intro music.
Week 8 11/7
Overall Goal: Hopeful content complete still hopeful.
Tech: Bug fixing, but freeze on new features if possible.
Art: Have all the animations at the least roughed out and in the game. Work on finalizing/polishing.
Design: Finish the level(s).
Audio: All placeholder music/sounds replaced with our own.
Week 9 11/14
Overall Goal: Hopefully be able to relax. (Testing in reality.)
Tech: Become bug-less.
Art: Fiddle with positions of objects and make sure that all animation is running the way you'd like it.
Design: Check for level flow and make last minute tweaks.
Audio: Check levels of all the sounds and music to make sure we aren't blowing peoples ear drums or being way too quite.
Week 10 11/22
GAME DUE
Post Alpha Feedback Analysis
Here's some of the feedback we received from the Alpha presentation.
Mechanic Ideas:
- Extending the track beyond three lanes.
- Inverse of our current gameplay for a certain amount of time. (Just collect as many blocks as you can!)
- Collect blocks to unlock the extended track lane.
- Blocks/Power-Ups that affect your time directly.
- A way to display your track position when you aren't visible?
Things to Fiddle With/Fix:
- The camera is still an issue.
- Don't be afraid to change the visual design of the space as long as it benefits the gameplay.
- Need to make the character visible at all times.
- Transparency on the blocks between you and the camera?
- Limit the use of tall blocks or provide the extended track to avoid them?
- Limit the use of tall blocks or provide the extended track to avoid them?
- Still need transitions for win/loss.
- Better way to represent the time?
- Tweaking for controls still needed a bit.
Phil Update 10/25
Towards the end of last week I started re-tooling our current level and with Brian's feedback I'm trying to start spacing things out a bit more to give leeway for players to sort of roam the track during some sections.
I do think it's a good idea for us to explore the idea of a "collect as many blocks as you can!" section in each track or multiple shorter tracks.
I've been a bit busy with everything else that's been going on. We're preparing Octodad 2 to be shown at MineCon and work has been busy lately. I'm going to try and adjust our schedule today to better reflect where we're at in development.
I do think it's a good idea for us to explore the idea of a "collect as many blocks as you can!" section in each track or multiple shorter tracks.
I've been a bit busy with everything else that's been going on. We're preparing Octodad 2 to be shown at MineCon and work has been busy lately. I'm going to try and adjust our schedule today to better reflect where we're at in development.
Programming Update
A few things got done this week. I had work in other classes that needed attention so I added/fixed some small things in the game.
The main change I made was the style of level generation. The ground looks like it's spinning off of a film reel rather than just appearing in the distance. This gives the game some style and more cohesive of a theme.
That being said, this feature has created a bug that messes with the way stiltblocks work, so I there's a small kink in the system that currently is messing with the performance of stiltblocks (when you're at full power up and you hit a 2-block high section, you don't fall all the way to the ground, but rather you float 1 block high :\ )
This week I'll implement the controls that Brian suggested in class/email to see how it functions/feels as well as work on implementing post-alpha criticism features (camera suggestions, filter suggestions, some more art assets, transparent blocks).
We already have so much done- because of this I've started to lose momentum. I just need to keep in the mindset that a game is never finished and that there still is plenty to go from now until the end of the quarter.
If we don't have the crucial features (stable controls/functionality) by November please feel free to spam me with emails until I've made it happen.
Or hit me.
-David
The main change I made was the style of level generation. The ground looks like it's spinning off of a film reel rather than just appearing in the distance. This gives the game some style and more cohesive of a theme.
That being said, this feature has created a bug that messes with the way stiltblocks work, so I there's a small kink in the system that currently is messing with the performance of stiltblocks (when you're at full power up and you hit a 2-block high section, you don't fall all the way to the ground, but rather you float 1 block high :\ )
This week I'll implement the controls that Brian suggested in class/email to see how it functions/feels as well as work on implementing post-alpha criticism features (camera suggestions, filter suggestions, some more art assets, transparent blocks).
We already have so much done- because of this I've started to lose momentum. I just need to keep in the mindset that a game is never finished and that there still is plenty to go from now until the end of the quarter.
If we don't have the crucial features (stable controls/functionality) by November please feel free to spam me with emails until I've made it happen.
Or hit me.
-David
Monday, October 24, 2011
Logan - Update (10/24)
So this week I didn't get much more done on sound. I'll be adjusting the volumes in Unity of the sounds once they are all set (since they are rather off right now...unless David already did it. But don't worry David if you didn't, just let me know where all the sounds are.)
I thought about splash screens/opening page and whatnot. I think it'd be cool to either do some kind of movie poster as a splash/opening, or have the start screen be a movie screen with the character mid run cycle (or animated) with silouettes of an audience bordering the bottom of the movie screen (either static or as flickering shadows.)
Here are some ideas I drew up real quick in Paint, nothing too fancy as you see, but ideas..
As I'm looking at these though I realize there is no evidence of blocks being part of the game besides the name haha =P well, something to get ideas flowing.
Wednesday, October 19, 2011
CasaBlocka Alpha Vid Preview
HERE IT IS. The video gets a bit choppy at one point, but otherwise I think it gives people a good idea of what the gameplay is like.
Programming Update!
Even though I've been very busy, I've made a good deal of progress since our last update. Here's a list of the things I've added! :D
*More fluid controls
They still aren't perfect, but they're getting closer to a desirable feel! This will probably be the hardest part to nail and will require some dedication in weeks to come
*Score now displayed in Elapsed Time
Very simple change- basically your score means something now. Displayed in seconds on the bottom right corner of the player HUD (GUI is a whole other story...we'll be working on that in the next week or so)
*Stilts glitch is gone!
There was a glitch that would cause you to lose one of your bonus blocks immediately after gaining them! This was frustrating and lessened player experience during play testing. I'm happy to confirm it's gone!
*Aesthetic starting to come together
- Glow added to power blocks
- Placeholders for images on the special blocks!
- Color added to environment/blocks
- Camera filters added for old-timey flare
*Added sounds
- New music
- Power block hit
- Stilts block hit
- Tunnel block hit
*Added screen in background
This screen replicates what the player's image on the cube is doing. This is a really cool effect we talked about implementing before and I through it together in a few minutes. I think it looks good so far, and we're looking on expanding its capabilities for further immersion.
These are all things that have been added and are functioning in our current alpha build. We're really excited to show our video to the class and show off the work from the past weeks!
The following are features I'm working on implementing as I type!
*Snazzy world generation
This is actually working at the moment. It might have caused a small glitch here or there...so I'm not calling it functional at the moment. Basically the world now generates from below and above and comes together in time for the player to interact with it! Think of two snakes slamming into each other and running in unison towards the player (worst analogy ever).
*More sounds implemented
The sounds really add a lot to the feel of the game. I can't wait to put more of Logan's work into the game!
*Front/Back end splashes
These will really make the game feel complete. Front and back end menus will give users the sense of a full game rather than a pieced together build in future playtests
*Implementing the Movie Intro on the back screen
This is just a matter of me sitting down with Unity Pro and making this happen. Shouldn't take more than a few minutes- I have placeholder logics that just needs to be filled with functionality.
*Tighter controls
I doubt this will be done this week, but hey- a man can dream
That's all for now folks! Get pumped for some slick looking videos in the weeks to come. This game is really coming together nicely :D
-David
*More fluid controls
They still aren't perfect, but they're getting closer to a desirable feel! This will probably be the hardest part to nail and will require some dedication in weeks to come
*Score now displayed in Elapsed Time
Very simple change- basically your score means something now. Displayed in seconds on the bottom right corner of the player HUD (GUI is a whole other story...we'll be working on that in the next week or so)
*Stilts glitch is gone!
There was a glitch that would cause you to lose one of your bonus blocks immediately after gaining them! This was frustrating and lessened player experience during play testing. I'm happy to confirm it's gone!
*Aesthetic starting to come together
- Glow added to power blocks
- Placeholders for images on the special blocks!
- Color added to environment/blocks
- Camera filters added for old-timey flare
*Added sounds
- New music
- Power block hit
- Stilts block hit
- Tunnel block hit
*Added screen in background
This screen replicates what the player's image on the cube is doing. This is a really cool effect we talked about implementing before and I through it together in a few minutes. I think it looks good so far, and we're looking on expanding its capabilities for further immersion.
These are all things that have been added and are functioning in our current alpha build. We're really excited to show our video to the class and show off the work from the past weeks!
The following are features I'm working on implementing as I type!
*Snazzy world generation
This is actually working at the moment. It might have caused a small glitch here or there...so I'm not calling it functional at the moment. Basically the world now generates from below and above and comes together in time for the player to interact with it! Think of two snakes slamming into each other and running in unison towards the player (worst analogy ever).
*More sounds implemented
The sounds really add a lot to the feel of the game. I can't wait to put more of Logan's work into the game!
*Front/Back end splashes
These will really make the game feel complete. Front and back end menus will give users the sense of a full game rather than a pieced together build in future playtests
*Implementing the Movie Intro on the back screen
This is just a matter of me sitting down with Unity Pro and making this happen. Shouldn't take more than a few minutes- I have placeholder logics that just needs to be filled with functionality.
*Tighter controls
I doubt this will be done this week, but hey- a man can dream
That's all for now folks! Get pumped for some slick looking videos in the weeks to come. This game is really coming together nicely :D
-David
Tuesday, October 18, 2011
Alpha Video
So I came to realize that all the lab computers don't have registered versions of FRAPS. I recorded two shorter clips and spliced them together last minute because I also thought this was due Thursday. Basically I suck.
This Week 10-18 Logan
This week I submitted more mechanic sounds:
- tunnel block
- power up
- block drop (drop down from power up)
and new game play music.
I'll be tightening the sounds if need be, please let me know if something sounds strange or needs to be tweaked or changed completely, I'm not personally attached to these sounds so I won't be offended ;) I don't want it to suck! Do we need lane shifting sounds, or would that be too much. I think having the lane light up is enough to show a lane change but that's just my opinion.
Update Level Design With Better Spacing
Right now it clocks in at about 40 seconds, but that also obviously depends on how well you play.
0,0,0
0,0,0
0,0,0
0,0,0
0,0,0
0,0,0
0,0,0
0,0,0
0,0,0
0,0,0
0,0,0
0,0,0
0,0,0
0,0,0
0,0,0
0,0,0
0,0,0
0,0,0
0,0,0
0,0,0
0,0,0
0,0,0
0,0,0
0,0,0
0,0,0
0,0,0
Phil Update 10/18
For this update I've put the level together to prepare for our alpha video showcasing the gameplay. Trying to tweak that for Thursday's presentation.
Monday, October 17, 2011
Mharcourt 10/17/11
This week I made the model for the sandbag. I will be texturing it shortly and baking the textures in. After I texture it I will start work on the projector lens.
Tuesday, October 11, 2011
Logan - Update
As far as the weekend, I didn't get much done (as I mentioned in class/meeting I was camping from Fri-Mon in Michigan, needless to say, no internet/limited computer activity). Earlier this week though I acquired replacement music (haven't put it on the server yet) for the gameplay. I have several piano-based 'rags' and tunes that I believe should much better fit the theme (as we discussed changing the current music). I also have some possible powerup and tunnel block sounds we can test out.
Update 10/11 - Phil
I didn't personally get a lot done last week due to being stupidly busy with other stuff, but I did have time to run some playtests and write up our post playtest analysis. This week I'd like to adjust my level ideas to really work with how the collisions have changed.
Monday, October 10, 2011
MRHarcour This week
I will admit that I didn't really get anything done this week. I started on the Countdown timer but haven't finished it yet, I also haven't started the second task of environment sketches yet. Like David I was completely burned out, not by this project but by everything else. After taking the weekend off I feel very refreshed and eager to get back into action and will hopefully get those things to you guys either by tuesday morning or tuesday evening.
Sunday, October 9, 2011
Back in Action! - Programming Update
I will start this post by saying that after this past week, I was burned out. I've been working so much on this project (as well as other things) that I was beginning to not enjoy/appreciate programming this game as well as my other side projects- This caused me to take a small break where I just stepped back from the game and all programming related work and got outside and did non-computer things. This gave me a fresh perspective on my work and I'm re-energized just in time for the back end of the quarter!
As for updates to the game since my last post, here's what's up:
In time for the tissue testing (Wednesday night) I was able to add the following-
1) Collision testing for the stilts/heightened blocks
2) The ability to restart the game for convenience
3) An end-state for the game
4) More intimate variable control for designers to tweak with ease
5) Score keeping/tracking
These features allowed us to have a successful first test of the game with our testers. While I was on a programming high of getting all of these features in and working, they were overshadowed by another problem: The controls.
The controls worked. collisions worked. what was the problem? fluidity
The collision checking system was not only inefficient, but also too constraining. It gave no slack to the player to cut corners and make twitch movements to avoid obstacles. Most of the complaints/feedback we received about the game revolved around the controls being more flexible/forgiving. This was hard for me to hear and watch when having testers play, because it totally took away from the immersion and overall enjoyment of the game. That being said, I took the feedback well and (after my previously mentioned break) got to work on fixing this problem!
So tonight I fixed it, or at least I THINK I did. With the new functionality I was able to get through the two hardest test builds we made without getting hit (not SUPER hard, but it proved to be do-able finally!) I won't truly know until we get more playtesters to give fresh feedback and maybe have the dev team/old testers confirm the better feel. I'm very close to completely covering my tracks for the new collision/control system and I'm excited to show it to everyone on Tuesday!
GOALS FOR THIS WEEK:
1) Dynamic camera shifting based on environment
This is a very important feature we need to add. When we start stacking blocks for a visual & challenging effect, players oftentimes have a hard time telling where they are or where there's an opening for them to maneuver through. I'm going to have the camera adjust appropriately for the player to be able to see his cube and dodge without an accidental hindrance.
2) Visual Flare
I need to make the special blocks more in-tune with the rest of our piece. This will essentially be me toying with lighting to create visual feedback for the player to recognize important objects!
3) Bug Fixin's
Self explanatory. There are a few that are very small (some not even noticed by the player), but present enough to potentially hinder the flow of play. I will exterminate these bugs ASAP
4) Score Conversion
This isn't hard. Instead of displaying the players score in total update calls, display it in time. This gives meaning to the player and will allow them to better identify the goal for the game.
Hopefully I will have these things implemented in time for our next test (as of now I plan on it) so we can achieve the most effect results. Even though some of the feedback we got hit some nerves, it was all based around problems that are bound to be in a pre-alpha build. Most players said the game was fun when it was working as expected which made me VERY HAPPY! :D
This game is coming very well. I can't wait to see it continue to grow and present a fun experience to all who get to try it!
Cheers,
David
As for updates to the game since my last post, here's what's up:
In time for the tissue testing (Wednesday night) I was able to add the following-
1) Collision testing for the stilts/heightened blocks
2) The ability to restart the game for convenience
3) An end-state for the game
4) More intimate variable control for designers to tweak with ease
5) Score keeping/tracking
These features allowed us to have a successful first test of the game with our testers. While I was on a programming high of getting all of these features in and working, they were overshadowed by another problem: The controls.
The controls worked. collisions worked. what was the problem? fluidity
The collision checking system was not only inefficient, but also too constraining. It gave no slack to the player to cut corners and make twitch movements to avoid obstacles. Most of the complaints/feedback we received about the game revolved around the controls being more flexible/forgiving. This was hard for me to hear and watch when having testers play, because it totally took away from the immersion and overall enjoyment of the game. That being said, I took the feedback well and (after my previously mentioned break) got to work on fixing this problem!
So tonight I fixed it, or at least I THINK I did. With the new functionality I was able to get through the two hardest test builds we made without getting hit (not SUPER hard, but it proved to be do-able finally!) I won't truly know until we get more playtesters to give fresh feedback and maybe have the dev team/old testers confirm the better feel. I'm very close to completely covering my tracks for the new collision/control system and I'm excited to show it to everyone on Tuesday!
GOALS FOR THIS WEEK:
1) Dynamic camera shifting based on environment
This is a very important feature we need to add. When we start stacking blocks for a visual & challenging effect, players oftentimes have a hard time telling where they are or where there's an opening for them to maneuver through. I'm going to have the camera adjust appropriately for the player to be able to see his cube and dodge without an accidental hindrance.
2) Visual Flare
I need to make the special blocks more in-tune with the rest of our piece. This will essentially be me toying with lighting to create visual feedback for the player to recognize important objects!
3) Bug Fixin's
Self explanatory. There are a few that are very small (some not even noticed by the player), but present enough to potentially hinder the flow of play. I will exterminate these bugs ASAP
4) Score Conversion
This isn't hard. Instead of displaying the players score in total update calls, display it in time. This gives meaning to the player and will allow them to better identify the goal for the game.
Hopefully I will have these things implemented in time for our next test (as of now I plan on it) so we can achieve the most effect results. Even though some of the feedback we got hit some nerves, it was all based around problems that are bound to be in a pre-alpha build. Most players said the game was fun when it was working as expected which made me VERY HAPPY! :D
This game is coming very well. I can't wait to see it continue to grow and present a fun experience to all who get to try it!
Cheers,
David
Thursday, October 6, 2011
Post Playtest Analysis
- Movement is too jerky and doesn’t feel fluid. There are many times when I wanted to move, but couldn’t due to blocks next to me as I passed by. The window where you can move is too small. There’s not really much room for preemptive movements.
- Level design scale is very different from what it looks like on paper and is easily affected by the movement problem above which doesn't allow for much intricacy. General designs are good to have, but knowing exactly how those will translate to the game is crucial when using something like a text parsing system that isn’t necessarily 1:1 in feeling.
- Player’s don’t seem to care about the game because they don’t get any background information about what they’re trying to achieve. Even though they understand the mechanic they don’t understand what the motivation to be successful is. What we really need is a context to somewhat mask the mechanical objective with.
- People generally want to see more art and are taken back by how rough the game looks.
- UI is currently more of a hindrance to look to because of the general urgency of the gameplay. Make it stand out more and easier to read.
- People really enjoy the speed boosts and height power ups. Especially combined. Utilize these more, but don’t over populate the levels with them.
- A different camera angle is definitely needed for sequences in which there are more than one block high sections in your way because otherwise it completely blocks your field of view.
- A good amount of space should be placed between each power block before you get the “jump”
because you need time in between each to kind of get your bearings. Right now they’re too close to one another and if a player misses them early on and doesn’t learn what they do then they may get screwed over later on when they actually need them.
- Long sections of block may be a bad idea when there’s a complicated section right before because if you screw up that section and hit these blocks then you’ve basically lost. Maybe implement temporary invulnerability after you’ve hit a block?
- Pacing is everything and right now designing for that is a bit of a challenge. This will have to become extremely iterative in order to feel correct.
- Level design scale is very different from what it looks like on paper and is easily affected by the movement problem above which doesn't allow for much intricacy. General designs are good to have, but knowing exactly how those will translate to the game is crucial when using something like a text parsing system that isn’t necessarily 1:1 in feeling.
- Player’s don’t seem to care about the game because they don’t get any background information about what they’re trying to achieve. Even though they understand the mechanic they don’t understand what the motivation to be successful is. What we really need is a context to somewhat mask the mechanical objective with.
- People generally want to see more art and are taken back by how rough the game looks.
- UI is currently more of a hindrance to look to because of the general urgency of the gameplay. Make it stand out more and easier to read.
- People really enjoy the speed boosts and height power ups. Especially combined. Utilize these more, but don’t over populate the levels with them.
- A different camera angle is definitely needed for sequences in which there are more than one block high sections in your way because otherwise it completely blocks your field of view.
- A good amount of space should be placed between each power block before you get the “jump”
because you need time in between each to kind of get your bearings. Right now they’re too close to one another and if a player misses them early on and doesn’t learn what they do then they may get screwed over later on when they actually need them.
- Long sections of block may be a bad idea when there’s a complicated section right before because if you screw up that section and hit these blocks then you’ve basically lost. Maybe implement temporary invulnerability after you’ve hit a block?
- Pacing is everything and right now designing for that is a bit of a challenge. This will have to become extremely iterative in order to feel correct.
Tuesday, October 4, 2011
MRHarcourt Report 10/4/11
This week I resigned the skybox wall textures and did QA testing. I found three bugs with the level.
Floating block bug > get stilts then run into a stack equal to your current height you will then become a floating block.
Under the level bug > Get stilts then run into a row of 1 stack blocks.
Clone Bug > player will have a controllable duplicate by running into multiple blocks while in "stilts mode" I'm still trying to do this on command.
Level edit bug, Not sure what is going on here but for some reason in the section of TEST2 between lines 23 and 24
Weekly Update - Production
This past week I have:
- Continued work on the level.
- Updated the team schedule to include Audio planning and any recent changes to our plan.
- Come up with a set of post playtest questions for players.
Everything seems to be going really well and I think the game is coming along nicely. Programming is completely on track as David's shown in some of his updates. Audio is coming along nicely and Logan seems to have a good plan laid out that fits the aesthetic feel of the game. Animations are complete for the walk cycle animation from the side of the player and I believe Joe started on the behind-view as well. Matt gave us some environment art to make it feel a bit more like a game.
Logan - Sound Update
This week:
-Created a basic sound doc (as posted earlier this week)
-Continued collecting sounds/samples to modify.
-I'm going to be submitting placeholder music and begin working on the mechanic and atmosphere sounds.
If any of the 'placeholders' seem to fit just right then we can use those. I hope to have at least the basic sounds/music available to plug into our game within the next few days (so we can have them for playtesting as seen in the schedule).
Weekly Update - Programming
So while I was able to add some new components to the game, I wasn't nearly as efficient this week as I have been in the past. I was able to implement some temporary/basic assets so our game actually looks and feels somewhat like A GAME. I believe the lower level of efficiency this week was also caused by me having to go back and clean up some functionality methods in order for our game to even work (more will have to be done soon to :\ ), but I still was able to add a few new design capabilities and features! Here's a list of the features I added in the last week:
*Added new options/functionality to the file parser
*Fixed the behavior of the blocks created below the player after the power chain sequence
*Reworked how our game manages recycling resources
*Improved stability of collision checking
*Fixed the functionality of the power chain sequence/block generation!
*Implemented the system of the music speeding up/slowing down alongside the player's speed
*Added the Skybox with temporary assets into the scene
What I'm hoping to have done before Thursday is the following:
*A Game End-State
*Rework behaviors into classes for better variable management
*Allow for more dynamic shifting between speeds
- How much they speed up
- How long it takes for them before they advance to the next speed
*Discuss the appropriate behaviors for all instances of collision with the team and implement them into the game
Once these features have been implemented, all we'll need is a few more assets and we will have an official alpha build. From there it will just be ironing out the level designs and game flow pattern to really let the mechanics of Casablocka shine! I'm really excited for the coming weeks, because we'll finally be able to see our hard work pay off and hopefully get some helpful feedback from playtesting!
Until next time!
-Dave
*Added new options/functionality to the file parser
*Fixed the behavior of the blocks created below the player after the power chain sequence
*Reworked how our game manages recycling resources
*Improved stability of collision checking
*Fixed the functionality of the power chain sequence/block generation!
*Implemented the system of the music speeding up/slowing down alongside the player's speed
*Added the Skybox with temporary assets into the scene
What I'm hoping to have done before Thursday is the following:
*A Game End-State
*Rework behaviors into classes for better variable management
*Allow for more dynamic shifting between speeds
- How much they speed up
- How long it takes for them before they advance to the next speed
*Discuss the appropriate behaviors for all instances of collision with the team and implement them into the game
Once these features have been implemented, all we'll need is a few more assets and we will have an official alpha build. From there it will just be ironing out the level designs and game flow pattern to really let the mechanics of Casablocka shine! I'm really excited for the coming weeks, because we'll finally be able to see our hard work pay off and hopefully get some helpful feedback from playtesting!
Until next time!
-Dave
Thursday, September 29, 2011
Updated Schedule
Week 4 10/10
Overall Goal: Run play tests and evaluate feedback to find what is/isn’t working. (Tissue Tests)
Tech: Hopefully gameplay will mostly be nailed down and most of the focus can now be placed on making the game pretty. Be able to win/lose.
Art: Have the running animations finished without the transition or jump animations.
Design: Read through player feedback and run the play tests to get an outside perspective on the game.
Audio: Get placeholder music in the game for gameplay and Win/Fail sounds/tracks so we can add those in for the playtests.
Continue reading...
Overall Goal: Run play tests and evaluate feedback to find what is/isn’t working. (Tissue Tests)
Tech: Hopefully gameplay will mostly be nailed down and most of the focus can now be placed on making the game pretty. Be able to win/lose.
Art: Have the running animations finished without the transition or jump animations.
Design: Read through player feedback and run the play tests to get an outside perspective on the game.
Audio: Get placeholder music in the game for gameplay and Win/Fail sounds/tracks so we can add those in for the playtests.
Continue reading...
A little music for working.
Hey guys if you like anything electronic or ambient I highly suggest this playlist.
Wednesday, September 28, 2011
Logan Wright - More Comprehensive Soundamation List
Here's a more extensive list of all the things/events I believe we'll be "soundamating," some include linked sample sounds. Let me know if there are mechanics/events I forgot to include in this list, also, if anyone thinks anything I have listed isn't necessary please let me know. (Sorry about the formatting if its difficult to read, I had issues copying/pasting this into the blog).
Bearded Games - CasaBlocka Sound Design:
Table of Contents:
1. Music:
- Intro screen
- Game play
- End screen?
o Win
o Fail
o Credits (with Beard Pics)
2. In-Game Mechanics and Sound Effects:
- Normal block collision
- Lane shifting
- Block stack power-up
o Loss of block stack?
- Block tunnel
- Fail/restart/’cane-pull-back’
- Jump?
3. Other Sounds/Soundmosphere:
- Audience voice commentary
o Applause
o Boo’s
o Dialogue
o Audience ‘noises’
- Projector camera flicker
- Vinyl record player static
- ‘Button’ selection
o Ex: “Start”
-------
Progress (Ideas/May Sound Like):
1. Music
- Intro screen = http://www.soundboard.com/mediafiles/NzEwMzE5MTc3NzEwNDIy_MfVFQpF6uBI.mp3
- Game play = http://www.soundboard.com/mediafiles/NzAzNjE5MTc3NzAzNzMy_ewBzi5g_2bURE.mp3
- End screen?
o Win =
o Fail = http://www.soundboard.com/mediafiles/MzMzNjE5MTc3MzMzNjcx_TkszSDfE6CI.mp3
o Credits (with Beard Pics) = http://www.freesound.org/people/TexasMusicForge/sounds/2684/
http://www.freesound.org/people/TexasMusicForge/sounds/2688/
2. In-Game Mechanics and Sound Effects:
- Normal block collision =
- Lane shifting =
- Block stack power-up =
o Loss of block stack? =
- Block tunnel =
- Fail/restart/’cane-pull-back’ =
- Jump? =
3. Other Sounds/Soundmosphere:
- Audience voice commentary [Most if not all of this section can be recorded by us]
o Applause
Loud short applause = http://www.partnersinrhyme.com/soundfx/applause_sounds/claps3wav.shtml
Small clapping = http://www.partnersinrhyme.com/soundfx/applause_sounds/applause8wav.shtml
o Boos
Long boo’s = http://www.partnersinrhyme.com/soundfx/applause_sounds/sfxboowav.shtml
Long boo’s Crowd = http://www.sound-effect.com/sounds1/human/applause/boos3.wav
o Dialogue = [Recorded by everyone given time]
[Insert Dialogue to be recorded]
o Audience ‘noises’
Ex: Coughs, slurping, sniffling, snoring, etc… = http://www.partnersinrhyme.com/soundfx/human.shtml
- Projector camera flicker = http://www.freesound.org/people/nemoDaedalus/sounds/60453/
- Vinyl record player static = http://www.freesound.org/people/lonemonk/sounds/39711/
- ‘Button’ selection
o Ex: “Start” =
Bearded Games - CasaBlocka Sound Design:
Table of Contents:
1. Music:
- Intro screen
- Game play
- End screen?
o Win
o Fail
o Credits (with Beard Pics)
2. In-Game Mechanics and Sound Effects:
- Normal block collision
- Lane shifting
- Block stack power-up
o Loss of block stack?
- Block tunnel
- Fail/restart/’cane-pull-back’
- Jump?
3. Other Sounds/Soundmosphere:
- Audience voice commentary
o Applause
o Boo’s
o Dialogue
o Audience ‘noises’
- Projector camera flicker
- Vinyl record player static
- ‘Button’ selection
o Ex: “Start”
-------
Progress (Ideas/May Sound Like):
1. Music
- Intro screen = http://www.soundboard.com/mediafiles/NzEwMzE5MTc3NzEwNDIy_MfVFQpF6uBI.mp3
- Game play = http://www.soundboard.com/mediafiles/NzAzNjE5MTc3NzAzNzMy_ewBzi5g_2bURE.mp3
- End screen?
o Win =
o Fail = http://www.soundboard.com/mediafiles/MzMzNjE5MTc3MzMzNjcx_TkszSDfE6CI.mp3
o Credits (with Beard Pics) = http://www.freesound.org/people/TexasMusicForge/sounds/2684/
http://www.freesound.org/people/TexasMusicForge/sounds/2688/
2. In-Game Mechanics and Sound Effects:
- Normal block collision =
- Lane shifting =
- Block stack power-up =
o Loss of block stack? =
- Block tunnel =
- Fail/restart/’cane-pull-back’ =
- Jump? =
3. Other Sounds/Soundmosphere:
- Audience voice commentary [Most if not all of this section can be recorded by us]
o Applause
Loud short applause = http://www.partnersinrhyme.com/soundfx/applause_sounds/claps3wav.shtml
Small clapping = http://www.partnersinrhyme.com/soundfx/applause_sounds/applause8wav.shtml
o Boos
Long boo’s = http://www.partnersinrhyme.com/soundfx/applause_sounds/sfxboowav.shtml
Long boo’s Crowd = http://www.sound-effect.com/sounds1/human/applause/boos3.wav
o Dialogue = [Recorded by everyone given time]
[Insert Dialogue to be recorded]
o Audience ‘noises’
Ex: Coughs, slurping, sniffling, snoring, etc… = http://www.partnersinrhyme.com/soundfx/human.shtml
- Projector camera flicker = http://www.freesound.org/people/nemoDaedalus/sounds/60453/
- Vinyl record player static = http://www.freesound.org/people/lonemonk/sounds/39711/
- ‘Button’ selection
o Ex: “Start” =
Tuesday, September 27, 2011
Current Level Layout - Phil (1/4 projected length of final)
Key
0 - Empty Space
1 - Single Block High
2 - Two Blocks High
etc.
So here's the current level layout:
Intro/Learn Basic Play
0,0,0
0,0,0
0,0,0
0,0,0
1,0,0
1,0,0
0,0,0
0,0,0
0,0,0
0,1,0
0,0,0
Continues after the break...
0 - Empty Space
1 - Single Block High
2 - Two Blocks High
etc.
So here's the current level layout:
Intro/Learn Basic Play
0,0,0
0,0,0
0,0,0
0,0,0
1,0,0
1,0,0
0,0,0
0,0,0
0,0,0
0,1,0
0,0,0
Continues after the break...
Phil 9/20 - 9/25
This week was a bit hectic for me due to Octodad related things outside of class and being in Austin, TX all weekend promoting the game, but I did end up getting some level design work done while I was away. We ran a pretty successful meeting on Wednesday (9/21) as well which resulted in a few new mechanic ideas. We also went over what the focus of the game should be which was solidified by Brian's feedback on Thursday.
As far as the level design work goes I wrote about 200 lines/block sections so far. This is about a fourth of our final level size. I avoided using many of the extra mechanics for now, but did plan out sections in which they might be interesting to use later. I did this so that we can make sure the level will be fun/interesting at its core without all the fluff we'll be adding later on. This week I would like to continue with this level and start to playtest it as well. (internally at first)
I'm also going to be trying to sketch up some drawings of our pitch material so we can post those to the blog for a better visual understanding of what we're doing and so that anyone can look back at it for reference.
I'd like to maybe re-arrange or at least add a few things to the schedule that I missed out on before like environment art and audio. We have actually talked about these things in person and I've written it down in my notebook. I just need to add those notes to the blog which I'll be doing later today. Basically I'm playing catch-up due to my absence, but all seems good. I'll also be adding my level to the blog once it's about half "finished". (first pass)
As far as the level design work goes I wrote about 200 lines/block sections so far. This is about a fourth of our final level size. I avoided using many of the extra mechanics for now, but did plan out sections in which they might be interesting to use later. I did this so that we can make sure the level will be fun/interesting at its core without all the fluff we'll be adding later on. This week I would like to continue with this level and start to playtest it as well. (internally at first)
I'm also going to be trying to sketch up some drawings of our pitch material so we can post those to the blog for a better visual understanding of what we're doing and so that anyone can look back at it for reference.
I'd like to maybe re-arrange or at least add a few things to the schedule that I missed out on before like environment art and audio. We have actually talked about these things in person and I've written it down in my notebook. I just need to add those notes to the blog which I'll be doing later today. Basically I'm playing catch-up due to my absence, but all seems good. I'll also be adding my level to the blog once it's about half "finished". (first pass)
Monday, September 26, 2011
Logan Wright 9/26
Ok, I've begun collecting sounds/ideas for music, etc... Here are some websites/sound effects I'm going to start working with and combining (as Brian suggested to create rich sounds). This is of course not very organized as it is just the beginning of our look towards sound, but its a start.
I haven't begun synthing any sounds yet, or composing (if this still happens) for the main theme music.
--------
Sounds of the 1920's :
http://www.soundboard.com/sb/Sounds_of_the_1920s.aspx
- Fail theme cliip [ "Track 17: Silent Movie Suspense" could be something like this for a end screen fail or sound clip for representing failure ]
- In game theme music [ "Track 4: 20s Bash" is along the lines of a possible theme song choice/inspiration ]
Partners in Rhyme :
http://www.partnersinrhyme.com/soundfx/applause.shtml
- Applause, Booing, Cheering
- Household sounds = Can be modified
- "Gate Close" http://www.sound-effect.com/sounds1/household/Gate/GATECLO.wav Can be modified forprojector/camera flicker (also have projector flicker sounds on the Free Sound website)
- "Ice Crack" http://www.partnersinrhyme.com/soundfx/household_sounds/ICE_CRAC_wav.shtml Can be modified forold record player static (also have record player sounds on the Free Sound website)
Free Sound :
http://www.freesound.org/browse/tags/record/
- Record Scrath
- LP Noise Loop
- Projector Running Sound
--------
I'm going to be considering/searching for sound effects for the block/tunnel (as Brian suggested) along with the other main game mechanics that will 'semi-subconsciously' add to the soundscape.
Matt Harcourt 9/26
This week didn't get as much done, but I set up our file on perforce and submitted both the texture for the skybox that dave asked for and created the player model. (the box.)
Sunday, September 25, 2011
David Laskey (Programmer) - The Last Few Days (9/20 - 9/25)
This week has definitely been productive for the game. That being said I ran into many interesting problems that slowed down my productivity and efficiency in getting a working shell of our game to be filled with juicy assets :P
Progress:
Since last time, I've added the following features
*Dynamic Track Width
As of now this feature isn't really being utilized, but it gives us more flexibility in our design if we need to ever expand beyond a track being three blocks wide
*Global Variable Class
This was something I wanted to make from the start and finally made! This static class allows the team to change similar numbers and change the feel of play (player speed, camera drag, track creation settings, etc.). This will allow the team to test many different circumstances and will come in handy for quick tweaking when it comes time for play-testing and awesomeness-making.
*Block Tunnel Ability
This feature was actually a glitch before it was...well....a feature. When the player would crash into a block that had multiple blocks behind it, they would boost through and create a very visually stunning effect. I showed the team this "bug" and I cleaned up the circumstances around its happening and made it into an ability for the game!
*Power Block
This feature was discussed and fleshed out in our last Wednesday night meeting. If a player hits a sequence of these special "Power Blocks" correctly, on the last sequence block they have two blocks appear from beneath them and have someone of a hit-buffer similar to when Mario gets a mushroom. While I have implemented the blocks logical code and conditional trees, I have yet to add the block-adding portion. I plan on doing this today, or at least in time for class tuesday so we can have working prototypes of all of our mechanics! :D
***PROGRAMMER GEEK OUT TALK START***
So in implementing the new types of blocks, I needed to assign characters in my file parsing system that would represent the other blocks (as of starting this process everything was just 0's and 1's). I chose "*" for the Block Tunnel cubes and "#" for the Power Blocks.
I first changed my Dictionary that holds all of the file-parsed track pieces in integer arrays to character arrays. This worked fine until the final element of the array would always be set to null. This was quite a comical error on my part, because I should have known sooner on (took me around 20 minutes to figure out) that the null character ('\0') was being tacked onto the end of my character array, as it always is. So for simplicity sake I thought "Why not just use strings so we can avoid this problem?"
This caused me three hours of confusion
I would test the values of my pieces and then decide what to do from there. My logic was as such
"If the element does NOT equal 0, then do one of the following:
- Create 1 Block above the track ("1")
- Create a Block Tunnel Piece ("*")
- Create a Power Block ("#")"
This seems like it would work right? Well everything was fine except none of the third elements were behaving correctly (The entire right side of the track would be empty).
So I decide to do some debugging: Inside of that test for != 0 I added an if-else structure for all of the potential circumstances (1, *, or #). At the end I added a final "else" that if triggered a print-value of the currently accessed element. This yielded odd results. The print statement ended up print "0", even though this should not have been possible seeing as that statement could not be reached if the value was "0". This caused so much confusion and running in circles that I thought Unity was pulling a Game-Maker and mishandling certain circumstances. But of course, I was wrong as usual- but it wasn't entirely my fault! The problem ended up being, or at least I believe right now, that there are hidden characters added on to each element that I was unable to see. Maybe this was a '\0', or maybe a '\t', who knows? Either way my solution was to go back to an int[] and make 2 = Block Tunnel and 3 = Power Block. I may go back to the char or string methods later, but this works for now considering we don't need the blocks to go any higher than 1 above the track in our level design.
I'm by no means a programming expert, so in the end it doesn't surprise me I had this problem- But the learning process excites me so I feel as if that time wasted was actually time well-spent. Never underestimate the learning potential of a good-bug. :D
So until then, chars/strings! I will conquer thee in the future!!!
***END PROGRAMMING GEEK OUT TALK***
2 Steps Forward, 1 Step Back
As most of you reading this should know, as the size of a project becomes larger and larger and your environment gains more responsibility in managing certain assets in a multitude of ways, unexpected problems arise. While they aren't large, they're just situations I need to sit down and iron out:
*Cube Recycling
The problem with my recycling system is somewhere in maintaining the cubes' collision detection state. There are some weird things that happen sometimes and I've sifted through the code briefly. I know the cause of the problem- I just need to find all of the holes and patch them up with the right code! As of now I'm back to Destroying/Creating cubes when necessary and the game state doesn't lag because of it. Hooray for simple game design!!! :D
*Collision Detection
Not necessarily a problem, I just need to go back and optimize how they're checked. Not only to I feel like my current methods are inefficient, but they need to be logically restructured as well. I just need to look more into simple, yet effective ways to test collisions than what I currently have
Looking Forward
Our game is coming along very well so far! We have prototypes of main mechanics, and are starting to work on the assets that add to the feel/style of our game! Nonetheless, we can't get cocky in our progress and need to continue to work at maximum efficiency so can have time to apply the layers of polish we oh-so desire to do!
We are also putting a hold on the checkpoint system for our game. We still want it in there, we just want to make sure that the rest of our game feels fun and fresh before we put the checkpoint system in. This decision came after discussing our ideas with Brian on Thursday, and realizing we need to design the checkpoints around the rest of our game instead of the game around our checkpoints!
Goals
By the beginning of October, I'm hoping to have the following progress made:
*Block Tunnel and Power Block mechanics in full, working condition
*Add more Global Variables to give the team more freedom to tweak from outside the code
*Have a spotlight that flickers and creates the film-reel effect we want
*Have temporary animations working as expected with the player cube and associated cubes
If I succed in implementing the previous, prioritized features I plan on working on the following as well:
*Optimize Collision Detection
*Optimize Cube Creation/Deletion/Recycling
*Create a game end-state
*Create a more visually stunning track creation system (more on this later ;D)
Another mouthful, another book written.
Hope those following found this intriguing :]
-Dave
Progress:
Since last time, I've added the following features
*Dynamic Track Width
As of now this feature isn't really being utilized, but it gives us more flexibility in our design if we need to ever expand beyond a track being three blocks wide
*Global Variable Class
This was something I wanted to make from the start and finally made! This static class allows the team to change similar numbers and change the feel of play (player speed, camera drag, track creation settings, etc.). This will allow the team to test many different circumstances and will come in handy for quick tweaking when it comes time for play-testing and awesomeness-making.
*Block Tunnel Ability
This feature was actually a glitch before it was...well....a feature. When the player would crash into a block that had multiple blocks behind it, they would boost through and create a very visually stunning effect. I showed the team this "bug" and I cleaned up the circumstances around its happening and made it into an ability for the game!
*Power Block
This feature was discussed and fleshed out in our last Wednesday night meeting. If a player hits a sequence of these special "Power Blocks" correctly, on the last sequence block they have two blocks appear from beneath them and have someone of a hit-buffer similar to when Mario gets a mushroom. While I have implemented the blocks logical code and conditional trees, I have yet to add the block-adding portion. I plan on doing this today, or at least in time for class tuesday so we can have working prototypes of all of our mechanics! :D
***PROGRAMMER GEEK OUT TALK START***
So in implementing the new types of blocks, I needed to assign characters in my file parsing system that would represent the other blocks (as of starting this process everything was just 0's and 1's). I chose "*" for the Block Tunnel cubes and "#" for the Power Blocks.
I first changed my Dictionary that holds all of the file-parsed track pieces in integer arrays to character arrays. This worked fine until the final element of the array would always be set to null. This was quite a comical error on my part, because I should have known sooner on (took me around 20 minutes to figure out) that the null character ('\0') was being tacked onto the end of my character array, as it always is. So for simplicity sake I thought "Why not just use strings so we can avoid this problem?"
This caused me three hours of confusion
I would test the values of my pieces and then decide what to do from there. My logic was as such
"If the element does NOT equal 0, then do one of the following:
- Create 1 Block above the track ("1")
- Create a Block Tunnel Piece ("*")
- Create a Power Block ("#")"
This seems like it would work right? Well everything was fine except none of the third elements were behaving correctly (The entire right side of the track would be empty).
So I decide to do some debugging: Inside of that test for != 0 I added an if-else structure for all of the potential circumstances (1, *, or #). At the end I added a final "else" that if triggered a print-value of the currently accessed element. This yielded odd results. The print statement ended up print "0", even though this should not have been possible seeing as that statement could not be reached if the value was "0". This caused so much confusion and running in circles that I thought Unity was pulling a Game-Maker and mishandling certain circumstances. But of course, I was wrong as usual- but it wasn't entirely my fault! The problem ended up being, or at least I believe right now, that there are hidden characters added on to each element that I was unable to see. Maybe this was a '\0', or maybe a '\t', who knows? Either way my solution was to go back to an int[] and make 2 = Block Tunnel and 3 = Power Block. I may go back to the char or string methods later, but this works for now considering we don't need the blocks to go any higher than 1 above the track in our level design.
I'm by no means a programming expert, so in the end it doesn't surprise me I had this problem- But the learning process excites me so I feel as if that time wasted was actually time well-spent. Never underestimate the learning potential of a good-bug. :D
So until then, chars/strings! I will conquer thee in the future!!!
***END PROGRAMMING GEEK OUT TALK***
2 Steps Forward, 1 Step Back
As most of you reading this should know, as the size of a project becomes larger and larger and your environment gains more responsibility in managing certain assets in a multitude of ways, unexpected problems arise. While they aren't large, they're just situations I need to sit down and iron out:
*Cube Recycling
The problem with my recycling system is somewhere in maintaining the cubes' collision detection state. There are some weird things that happen sometimes and I've sifted through the code briefly. I know the cause of the problem- I just need to find all of the holes and patch them up with the right code! As of now I'm back to Destroying/Creating cubes when necessary and the game state doesn't lag because of it. Hooray for simple game design!!! :D
*Collision Detection
Not necessarily a problem, I just need to go back and optimize how they're checked. Not only to I feel like my current methods are inefficient, but they need to be logically restructured as well. I just need to look more into simple, yet effective ways to test collisions than what I currently have
Looking Forward
Our game is coming along very well so far! We have prototypes of main mechanics, and are starting to work on the assets that add to the feel/style of our game! Nonetheless, we can't get cocky in our progress and need to continue to work at maximum efficiency so can have time to apply the layers of polish we oh-so desire to do!
We are also putting a hold on the checkpoint system for our game. We still want it in there, we just want to make sure that the rest of our game feels fun and fresh before we put the checkpoint system in. This decision came after discussing our ideas with Brian on Thursday, and realizing we need to design the checkpoints around the rest of our game instead of the game around our checkpoints!
Goals
By the beginning of October, I'm hoping to have the following progress made:
*Block Tunnel and Power Block mechanics in full, working condition
*Add more Global Variables to give the team more freedom to tweak from outside the code
*Have a spotlight that flickers and creates the film-reel effect we want
*Have temporary animations working as expected with the player cube and associated cubes
If I succed in implementing the previous, prioritized features I plan on working on the following as well:
*Optimize Collision Detection
*Optimize Cube Creation/Deletion/Recycling
*Create a game end-state
*Create a more visually stunning track creation system (more on this later ;D)
Another mouthful, another book written.
Hope those following found this intriguing :]
-Dave
Tuesday, September 20, 2011
Phil Week of 9/13 - 9/20 Recap
Most of my work this week was on the schedule for the team and coordinating meeting stuff. I also setup a PBWorks Wiki for the team for any content that we'd like to find quickly and organize in a way we might not be able to with a blog like this.We have a scheduled meeting time each week and everyone's contact info is available via the Wiki. I also helped with some of the design decisions and gave the intro/elevator part of the pitch.
"Final" Schedule
Week 1 9/19
Overall Goal: Get a rough prototype worked out.
Tech: Level editor/parsing is already roughed out. Get basic movement in for the character and begin “enemy” block movement.
Art: Concept character design and any necessary UI.
Design: Maybe create simple physical prototypes to test mechanics. Or simply write them out in detail on the PBWorks.
Week 2 9/26
Overall Goal: Evaluate results of prototype to discern what needs to change in the immediate future with the overall design.
Tech: Work further on gameplay mechanic implementation if it isn’t already done. Otherwise begin researching lighting techniques for the shadows and lighting.
Art: Begin work on the animations. (Walk cycles etc.) Concept any environmental flair we may need or want.
Design: Play around with the initial implementation of the gameplay mechanics and begin to write down any critiques you may have or what you think should be different.
Week 3 10/3
Overall Goal: Have a near definite vision of what the final game will be. Get Alpha video ready for Thursday.
Tech: Refine gameplay and have the “enemy” blocks moving close to the way we would like them to. Recycle using the pooling technique or something similar to ensure best performance. Leave real optimization until the end though.
Art: Continue work on animations and any other needed art. Leave title screen until close to the end of development. This will probably lead to better ideas for it and it isn’t important yet.
Design:Start planning out some questions to ask external players so that we can begin to run play tests ASAP.
Week 4 10/10
Overall Goal: Run play tests and evaluate feedback to find what is/isn’t working. (Tissue Tests)
Tech: Hopefully gameplay will mostly be nailed down and most of the focus can now be placed on making the game pretty. (Jumping if we have it.)
Art: Have the running animations finished without the transition or jump animations.
Design: Read through player feedback and run the play tests to get an outside perspective on the game.
Week 5 10/17
Overall Goal: More playtesting and tweaking! (awesome 30 seconds hopefully achieved!)
Tech: Work out any bugs we may have. Have everyone on the team play test and others as well.
Art: Help play test and also continue to make the game pretty in any way you can. Details as we get closer.
Design: Play test and report any bugs you can find. Tweak gameplay speeds and mess with any new ideas you may have that would be simple to implement.
Week 6 10/24
Overall Goal: Decide on final content/goal.
Tech: Know exactly what needs to be implemented by the end of the project. Pretty up game with a title and credits screen. Should be easy.
Art: Help tech create title and credits screens. Something creative rather than bland. Attract mode like an arcade cabinet? Finalize art and decide what needs to still be done.
Design: Create an interesting design for title/credits screens and finalize what design tweaks must still be implemented.
Week 7 10/31
Overall Goal: Content complete! Start nothing new! (Maybe) Cut the fat!
Tech: Would like to call code complete and only do cleanup/testing. But small tweaks are also ok.
Art: Have all art either done or at the least in progress and close to done.
Design: Start making your final adjustments to how the game plays. Player speed, block speed, jump heights, etc.
Week 8 11/7
Overall Goal: Actual content complete!
Tech: Bug fixing and testing.
Art: Have all art completed.
Design: Have all gameplay final.
Week 9 11/14
Overall Goal: Hopefully be able to relax.
Tech: David stop being awesome.
Art: Joe, Logan, and Matt stop being awesome.
Design: Everyone stop being awesome.
We win.
Overall Goal: Get a rough prototype worked out.
Tech: Level editor/parsing is already roughed out. Get basic movement in for the character and begin “enemy” block movement.
Art: Concept character design and any necessary UI.
Design: Maybe create simple physical prototypes to test mechanics. Or simply write them out in detail on the PBWorks.
Week 2 9/26
Overall Goal: Evaluate results of prototype to discern what needs to change in the immediate future with the overall design.
Tech: Work further on gameplay mechanic implementation if it isn’t already done. Otherwise begin researching lighting techniques for the shadows and lighting.
Art: Begin work on the animations. (Walk cycles etc.) Concept any environmental flair we may need or want.
Design: Play around with the initial implementation of the gameplay mechanics and begin to write down any critiques you may have or what you think should be different.
Week 3 10/3
Overall Goal: Have a near definite vision of what the final game will be. Get Alpha video ready for Thursday.
Tech: Refine gameplay and have the “enemy” blocks moving close to the way we would like them to. Recycle using the pooling technique or something similar to ensure best performance. Leave real optimization until the end though.
Art: Continue work on animations and any other needed art. Leave title screen until close to the end of development. This will probably lead to better ideas for it and it isn’t important yet.
Design:Start planning out some questions to ask external players so that we can begin to run play tests ASAP.
Week 4 10/10
Overall Goal: Run play tests and evaluate feedback to find what is/isn’t working. (Tissue Tests)
Tech: Hopefully gameplay will mostly be nailed down and most of the focus can now be placed on making the game pretty. (Jumping if we have it.)
Art: Have the running animations finished without the transition or jump animations.
Design: Read through player feedback and run the play tests to get an outside perspective on the game.
Week 5 10/17
Overall Goal: More playtesting and tweaking! (awesome 30 seconds hopefully achieved!)
Tech: Work out any bugs we may have. Have everyone on the team play test and others as well.
Art: Help play test and also continue to make the game pretty in any way you can. Details as we get closer.
Design: Play test and report any bugs you can find. Tweak gameplay speeds and mess with any new ideas you may have that would be simple to implement.
Week 6 10/24
Overall Goal: Decide on final content/goal.
Tech: Know exactly what needs to be implemented by the end of the project. Pretty up game with a title and credits screen. Should be easy.
Art: Help tech create title and credits screens. Something creative rather than bland. Attract mode like an arcade cabinet? Finalize art and decide what needs to still be done.
Design: Create an interesting design for title/credits screens and finalize what design tweaks must still be implemented.
Week 7 10/31
Overall Goal: Content complete! Start nothing new! (Maybe) Cut the fat!
Tech: Would like to call code complete and only do cleanup/testing. But small tweaks are also ok.
Art: Have all art either done or at the least in progress and close to done.
Design: Start making your final adjustments to how the game plays. Player speed, block speed, jump heights, etc.
Week 8 11/7
Overall Goal: Actual content complete!
Tech: Bug fixing and testing.
Art: Have all art completed.
Design: Have all gameplay final.
Week 9 11/14
Overall Goal: Hopefully be able to relax.
Tech: David stop being awesome.
Art: Joe, Logan, and Matt stop being awesome.
Design: Everyone stop being awesome.
We win.
Monday, September 19, 2011
David Laskey (Programmer) - Weekly Update/Pitch Recap & Current Implementation
So Casablocka: A Gentleman's Tale is coming along nicely. I previously posted prototypes of the level generation/manager class handling basic assets fairly well and working with a few kinks here and there. This time I'd like to recap the implementation of the level design/practical scope concepts from our pitch as well as update you all on the progress of the game on the coding side. Let's just say I've been hard at work in the lab :D
Recap of Pitch
So when we pitched our game, we mentioned that we needed a game that was within the scope of reason (10 weeks!) as well as easy to execute in a well-polished manner. Seeing as blocks/cubes are our main asset, this already made everyone's life easier in terms of asset creation. The level generation system is based on text files, as mentioned/explained in my previous post, and can be popped in and out of the game in a matter of seconds. Our levels are essentially streams of blocks, either one or two (maybe three if we end up adding a jump feature) blocks high. The player is moving into this stream of blocks looking to dodge and maneuver around these obstacles. When the player collides into a block, they transfer control over to the block that they hit and slow in speed. Dodging obstacles and speed management are our two main mechanics thus far.
Time to Implement
So I already had a level generator that was performing at protoype-level, but there was no gameplay yet. Going into this next step in the project I was a bit intimidated, seeing as I haven't worked with data structures very much before this project (in CSC 393 right now! :P) as well as work on dynamic asset control. Luckily, unity makes both of these very easy to work with, and once I became a little more comfortable with the environment I was able to implement player control, dynamic control passing between colliding objects, a simple collision system, a basic cube recycling system (probably will need to optimize this later), and a much cleaner level generation method
So with my previous level generation system, the blocks would be moving towards the player on a conveyor belt-like system and the player's x-value would be fixed. This was all fine and well until the "player's speed" would change. I put player speed in quotes because technically it was the speed of the ground, not the player, that was being adjusted.
The problem was when the speed would change, the new cubes would sometimes be created with the old speed first and be too far from the other cubes or do the opposite and get the new speed too soon and start too close to the previous row. I also realized that all of the cubes on the screen were having their update methods called when I could do the inverse and instead only have the player's update method called.
tl;dr -> I now made the track's position fixed and the player/camera position dynamic.
The other changes previously mentioned are fairly self explanatory. Player's can only collide with other cubes from the front, not from the side- so if they're between two cubes they aren't able to move side-to-side. Cube recycling is now based on a queue where cubes are enqueued/dequeued when they are out of frame/needing to generate a new row.
Now, for the player control passing- this took some time for me to conceptualize. Luckily, Unity makes this very easy, because essentially you can place/remove code into an object's update method via behavior scripts whenever you want. This is both very handy, and very dangerous. Here's the code for the collision test/control transfer:
void OnTriggerEnter(Collider other){
this.gameObject.AddComponent("GameCube");
Destroy(this.gameObject.GetComponent("Player"));
LevelGenerator.cubes.Add(this.gameObject);
other.rigidbody.collider.isTrigger = false;
other.gameObject.AddComponent("Player");
LevelGenerator.player = other.gameObject;
Destroy(other.gameObject.GetComponent("GameCube"));
other.renderer.material.color = new Color(Random.Range(0.0f,1.0f),Random.Range(0.0f,1.0f), Random.Range(0.0f,1.0f));
LevelGenerator.cubes.Remove(other.gameObject);
Camera.mainCamera.transform.Translate(0, 0, (other.rigidbody.position.z - this.rigidbody.position.z), other.transform);
//Update Player Speed
if(LevelGenerator.tickMod < 17)
{
LevelGenerator.tickMod += 3;
distanceCounter = 0;
}
else
print("You Lose!"); //Will send player back to last checkpoint
}
What's happening here is the passing of behavior scripts from one object to another, as well as triggering a universal system recognition of this occurrence (i.e. LevelGenerator's player object being updated, as well as the camera position). The object material color change looks nice for now, but was my way of creating a visual cue for successful collision detection.
As the comments suggest, once I implement a checkpoint system- if the player collides with an object at minimal speed they will be sent back to checkpoint (or start if they don't have any checkpoints activated). Otherwise they slow down and have to gain momentum in order to get back to full speed.
///////////////////////////////////////////////////////////////////////
Well, that sure was a mouthful. I apologize if this was dull/tedious for you to read, I just get excited about coding. Oh, and I might as well post a new video of the game's progress too! Check it out below, feedback is appreciated!
-David
Game Prototype Update
Recap of Pitch
So when we pitched our game, we mentioned that we needed a game that was within the scope of reason (10 weeks!) as well as easy to execute in a well-polished manner. Seeing as blocks/cubes are our main asset, this already made everyone's life easier in terms of asset creation. The level generation system is based on text files, as mentioned/explained in my previous post, and can be popped in and out of the game in a matter of seconds. Our levels are essentially streams of blocks, either one or two (maybe three if we end up adding a jump feature) blocks high. The player is moving into this stream of blocks looking to dodge and maneuver around these obstacles. When the player collides into a block, they transfer control over to the block that they hit and slow in speed. Dodging obstacles and speed management are our two main mechanics thus far.
Time to Implement
So I already had a level generator that was performing at protoype-level, but there was no gameplay yet. Going into this next step in the project I was a bit intimidated, seeing as I haven't worked with data structures very much before this project (in CSC 393 right now! :P) as well as work on dynamic asset control. Luckily, unity makes both of these very easy to work with, and once I became a little more comfortable with the environment I was able to implement player control, dynamic control passing between colliding objects, a simple collision system, a basic cube recycling system (probably will need to optimize this later), and a much cleaner level generation method
So with my previous level generation system, the blocks would be moving towards the player on a conveyor belt-like system and the player's x-value would be fixed. This was all fine and well until the "player's speed" would change. I put player speed in quotes because technically it was the speed of the ground, not the player, that was being adjusted.
The problem was when the speed would change, the new cubes would sometimes be created with the old speed first and be too far from the other cubes or do the opposite and get the new speed too soon and start too close to the previous row. I also realized that all of the cubes on the screen were having their update methods called when I could do the inverse and instead only have the player's update method called.
tl;dr -> I now made the track's position fixed and the player/camera position dynamic.
The other changes previously mentioned are fairly self explanatory. Player's can only collide with other cubes from the front, not from the side- so if they're between two cubes they aren't able to move side-to-side. Cube recycling is now based on a queue where cubes are enqueued/dequeued when they are out of frame/needing to generate a new row.
Now, for the player control passing- this took some time for me to conceptualize. Luckily, Unity makes this very easy, because essentially you can place/remove code into an object's update method via behavior scripts whenever you want. This is both very handy, and very dangerous. Here's the code for the collision test/control transfer:
void OnTriggerEnter(Collider other){
this.gameObject.AddComponent("GameCube");
Destroy(this.gameObject.GetComponent("Player"));
LevelGenerator.cubes.Add(this.gameObject);
other.rigidbody.collider.isTrigger = false;
other.gameObject.AddComponent("Player");
LevelGenerator.player = other.gameObject;
Destroy(other.gameObject.GetComponent("GameCube"));
other.renderer.material.color = new Color(Random.Range(0.0f,1.0f),Random.Range(0.0f,1.0f), Random.Range(0.0f,1.0f));
LevelGenerator.cubes.Remove(other.gameObject);
Camera.mainCamera.transform.Translate(0, 0, (other.rigidbody.position.z - this.rigidbody.position.z), other.transform);
//Update Player Speed
if(LevelGenerator.tickMod < 17)
{
LevelGenerator.tickMod += 3;
distanceCounter = 0;
}
else
print("You Lose!"); //Will send player back to last checkpoint
}
What's happening here is the passing of behavior scripts from one object to another, as well as triggering a universal system recognition of this occurrence (i.e. LevelGenerator's player object being updated, as well as the camera position). The object material color change looks nice for now, but was my way of creating a visual cue for successful collision detection.
As the comments suggest, once I implement a checkpoint system- if the player collides with an object at minimal speed they will be sent back to checkpoint (or start if they don't have any checkpoints activated). Otherwise they slow down and have to gain momentum in order to get back to full speed.
///////////////////////////////////////////////////////////////////////
Well, that sure was a mouthful. I apologize if this was dull/tedious for you to read, I just get excited about coding. Oh, and I might as well post a new video of the game's progress too! Check it out below, feedback is appreciated!
-David
Game Prototype Update
Sunday, September 18, 2011
Joe Dean - weekly update 9/20
So last week I worked on locking down an art style for the 2D assets in Casablocka: A Gentlemen's Tale.I wanted to keep things simple and block like to go with our theme. This is the design I think most captures what we are going for.
Let me know what you guys think.
This week I am going to work on concepting the UI and over all aesthetic of our levels. I will also be thinking about ways to tighten up our mechanic.
Friday, September 16, 2011
Schedule so far...
So this is the schedule I have worked out so far. I based it off of the speed at which we've finished things so far. Let me know what you think since I don't yet have the best gauge of your time/abilities.
Week 1 9/19
Overall Goal: Get a rough prototype worked out.
Tech: Level editor/parsing is already roughed out. Get basic movement in for the character and begin “enemy” block movement.
Art: Concept character design and any necessary UI.
Design: Maybe create simple physical prototypes to test mechanics. Or simply write them out in detail on the PBWorks.
Week 2 9/26
Overall Goal: Evaluate results of prototype to discern what needs to change in the immediate future with the overall design.
Tech: Work further on gameplay mechanic implementation if it isn’t already done. Otherwise begin researching lighting techniques for the shadows and lighting.
Art: Begin work on the animations. (Walk cycles etc.) Concept any environmental flair we may need or want.
Design: Play around with the initial implementation of the gameplay mechanics and begin to write down any critiques you may have or what you think should be different.
Week 3 10/3
Overall Goal: Have a near definite vision of what the final game will be.
Tech: Refine gameplay and have the “enemy” blocks moving close to the way we would like them to. Recycle using the pooling technique or something similar to ensure best performance. Leave real optimization until the end though.
Art: Continue work on animations and any other needed art. Leave title screen until close to the end of development. This will probably lead to better ideas for it and it isn’t important yet.
Design:Start planning out some questions to ask external players so that we can begin to run play tests ASAP.
Week 4 10/10
Overall Goal: Run play tests and evaluate feedback to find what is/isn’t working.
Tech: Hopefully gameplay will mostly be nailed down and most of the focus can now be placed on making the game pretty. (Jumping if we have it.)
Art: Have the running animations finished without the transition or jump animations.
Design: Read through player feedback and run the play tests to get an outside perspective on the game.
Week 1 9/19
Overall Goal: Get a rough prototype worked out.
Tech: Level editor/parsing is already roughed out. Get basic movement in for the character and begin “enemy” block movement.
Art: Concept character design and any necessary UI.
Design: Maybe create simple physical prototypes to test mechanics. Or simply write them out in detail on the PBWorks.
Week 2 9/26
Overall Goal: Evaluate results of prototype to discern what needs to change in the immediate future with the overall design.
Tech: Work further on gameplay mechanic implementation if it isn’t already done. Otherwise begin researching lighting techniques for the shadows and lighting.
Art: Begin work on the animations. (Walk cycles etc.) Concept any environmental flair we may need or want.
Design: Play around with the initial implementation of the gameplay mechanics and begin to write down any critiques you may have or what you think should be different.
Week 3 10/3
Overall Goal: Have a near definite vision of what the final game will be.
Tech: Refine gameplay and have the “enemy” blocks moving close to the way we would like them to. Recycle using the pooling technique or something similar to ensure best performance. Leave real optimization until the end though.
Art: Continue work on animations and any other needed art. Leave title screen until close to the end of development. This will probably lead to better ideas for it and it isn’t important yet.
Design:Start planning out some questions to ask external players so that we can begin to run play tests ASAP.
Week 4 10/10
Overall Goal: Run play tests and evaluate feedback to find what is/isn’t working.
Tech: Hopefully gameplay will mostly be nailed down and most of the focus can now be placed on making the game pretty. (Jumping if we have it.)
Art: Have the running animations finished without the transition or jump animations.
Design: Read through player feedback and run the play tests to get an outside perspective on the game.
Thursday, September 15, 2011
Level Generator Class - David Laskey
Hey guys! I was very excited to get working on our project, so I went home and immediately got working on the level generator. Not only does it parse text files, but it also generates the appropriate layout of the blocks!
This is a very barebones class so far, but what I plan on doing for the level implementation is having a sort of buffer system (similar to that of texture swapping). There's two dictionaries holding 2 sections: One that's currently being used/made and one that will need to be used/made next.
Based on that system, when the class first initializes it parses the script into one dictionary, then generates the appropriate length of the section based on the parsed file. Finally, it adds the obstacles (blocks above ground level) to the stage and completes the entire layout!.
Here's an example text file:
Test.txt
0,0,0
0,0,0
0,0,0
1,0,0
1,0,0
0,1,0
0,0,0
0,0,1
0,0,0
1,0,1
0,0,0
0,0,0
0,2,1
Now here's what the Level Generator class outputs (red light was used to help distinguish blocks):
The class will later have a system implemented for the treadmill/movement effect as well as testing for when the next section will have to be loaded. It essentially works off of the "InitializePlane" and "InitializeObstacles" methods.
The text-based level generation is a huge part of our game design; allowing use to create levels fast and efficiently for our limited project scope.
Group Members/Anyone Reading, let me know if you have any suggestions/other features you need me to add in coming weeks!
-David
***UPDATE***
Here's a demo of the generator in action! It loads the same script 10 times, but it works nonetheless. Feedback is appreciated.
Level Generator Demo
***UPDATE #2***
Sorry to keep spamming these updates, I just keep implementing new stuff that I want your guys' feedback on. I revamped the level gen system to no longer use the stupid file buffering system, but instead read in all files and then generate/destroy cubes based on player progress. Here's a video demo of the player cube going through a basic level layout. Nothing has physics/collision detection yet, but everything exists and functions properly in physical space. Let me know what you think! :D
Level Generator Demo 2 + Character Movement
This is a very barebones class so far, but what I plan on doing for the level implementation is having a sort of buffer system (similar to that of texture swapping). There's two dictionaries holding 2 sections: One that's currently being used/made and one that will need to be used/made next.
Based on that system, when the class first initializes it parses the script into one dictionary, then generates the appropriate length of the section based on the parsed file. Finally, it adds the obstacles (blocks above ground level) to the stage and completes the entire layout!.
Here's an example text file:
Test.txt
0,0,0
0,0,0
0,0,0
1,0,0
1,0,0
0,1,0
0,0,0
0,0,1
0,0,0
1,0,1
0,0,0
0,0,0
0,2,1
Now here's what the Level Generator class outputs (red light was used to help distinguish blocks):
The class will later have a system implemented for the treadmill/movement effect as well as testing for when the next section will have to be loaded. It essentially works off of the "InitializePlane" and "InitializeObstacles" methods.
The text-based level generation is a huge part of our game design; allowing use to create levels fast and efficiently for our limited project scope.
Group Members/Anyone Reading, let me know if you have any suggestions/other features you need me to add in coming weeks!
-David
***UPDATE***
Here's a demo of the generator in action! It loads the same script 10 times, but it works nonetheless. Feedback is appreciated.
Level Generator Demo
***UPDATE #2***
Sorry to keep spamming these updates, I just keep implementing new stuff that I want your guys' feedback on. I revamped the level gen system to no longer use the stupid file buffering system, but instead read in all files and then generate/destroy cubes based on player progress. Here's a video demo of the player cube going through a basic level layout. Nothing has physics/collision detection yet, but everything exists and functions properly in physical space. Let me know what you think! :D
Level Generator Demo 2 + Character Movement
Wednesday, September 14, 2011
Pitch - Logan Wright
Titles:
-Battle to BeerHalla
-Drunken Vikings
-Death by Axe, Life by Glass
Main goal of the game: Fight your way through the after life to claim the Mighty Horn of Beerhalla and return to living world as a God.
Basic story: You play as a short but stocky viking who wakes in Beerhalla (Valhalla) after he just died from alcohol poisoning along with an axe to the head that he took during a night of wild raiding and pillaging with his viking friends. He awakens to find two large glasses of beer, one a nice light colored beer with an Fire symbol on it, the other a dark frothy brew with a Ice symbol on it, and a note beside them stating something along the lines of:
"The Gods have recognized your unyielding dedication to being drunk off your ass and raiding and pillaging and have granted you the opportunity to become a legend. Choose your brew wisely and begin your quest to claiming the Mighty Horn of BeerHalla! Drink from this horn of legend and you shall return to your world as a God!"
Your choice of beer (similar to light side/dark side), grants you different abilities and kind of acts as you "magic." You refill you glass (magic meter) by defeating enemies or coming across check points with health and 'beer' pools.
Magic:
-Vomit (comes with both light and dark): Used to disorient an enemy for a second, allowing you to pass by them without taking damage. Also allows an enemy to be set on fire or frozen depending on which Glass you chose.
-Fire (Light): If you chose light, you can set enemies running and on fire that have been vomited on.
-Ice (Dark): If you chose dark, you can turn enemies into ice blocks that have been vomited on.
-[others?]
As far as going through levels: You have a basic melee weapon, the axe sticking out of your head, to fight enemies with. However, you may not want to slay every enemy with your axe as you will sometimes need to freeze them and use them as stepping platforms, or set them ablaze as living torches to get through obstacles. For example [Image below]; depending on your choice of brew/magic, you must either freeze the enemy in front of the wooden gate to then proceed to use him as a stepping stone to jump over the gate, or set the enemy on fire and running into the gate, burning it down allowing you to pass.
~~ This is about as far as I got with this idea ~~
Tuesday, September 13, 2011
Globtrotter - Joe Dean
So my idea is more on the artsy side I think.
genre: 3D puzzle game
similar to: WarioWare meets Super Mario Galaxy
The premise of this game is that you are a space ship trapped on a glob. Globs are gooey little planet-like blobs that float in space. They come in clusters and the object of the game is to get from one glob to the next until you get to the end of the cluster. For a glob to release you though you have to please it. Globs are living goo planets with very strange and particular needs. needless to say they are frustrated. So every glob has a short task that the player must figure out and complete on its surface. Doing so pleases the glob and it sends you to that next one.
These tasks start out simple like moving a box from one side of the glob to the the hole on the other side, but quickly ramp up in to more complicated puzzles. They are physics based.
The idea is to figure out and do them as quickly as you can. I'm not sure what the proper motivation for the player should be but that is something we can figure out.
So the ship should have like 3 maybe 4 basic functions its can utilize to complete these tasks such as:
- tractor beam - to carry objects and what not
- a lazer - to destroy stuff or push objects that cant be destroyed
- and like maybe a Drill - to like pop over to the other side of the glob or something
Other than that the ship can just fly around the glob like its a planet.
as the game goes on the player would have to use these simple abilities by themselves at first, but later use them all in different combinations to progress.
It should feel fast pace like the WarioWare mini games, but have the kind of planet hopping aspect of super mario galaxy.
The flow of the game is more or less:
The player is presented with physical puzzle > player solves puzzle > continues to next puzzle > repeat
This is all I got so far, guys. Let me know what you think.
Pitch MR Harcourt
Game title "Down to the top!"
Genre: 3d Platformer
Similar to: Crash Bandicoot/ Jak and Daxter
Idea: a short 3d platformer where the player explores a building being inexplicably turned upside down. The player has to dodge falling hazards such as tiles, plants, urinals, and the paper shredder from down the hall.
The printer is now on the fritz shooting razor sharp rtsreports threatening to sever your head. It's 5:00 pm, you just got back from lunch and must make your way to the 30th (now 1st) floor before 5:30 to deliver that portfolio your boss asked for an hour ago. Armed with nothing but an atomic stapler and wits to make it to the boss's office.
Main enemies will be co-workers trying to distract you with meaningless banter or managers trying to get you to do something else. The royally pissed off janitor trying to clean up this mess.
The levels will be fast paced with a strict time of "30 minutes" which will equate to more of 10 minutes, giving about 1 minute to pass each floor. The end goal for each level is to find the next set of stairs. With each floor having a hilarious obstacle blocking your path for more than one floor.
The use of the atomic stapler will have 3 uses. 1) to defend yourself from your coworkers. 2) to destroy small obstacles like trashcans and desks. 3) To keep objects attached to the ceiling preventing them from falling on you.
Second by Second: Fast past action platforming jumping over desks and cubicles and firing an atomic stapler at people making lots of explosions.
Minute by Minute: Exploring upside down offices and floors while dodging enemies.
Hour by hour: Getting to the bottom of the building before the time ends.
Day by day: Beating the game will create a ghost so that players can race against either their friends or themselves
Year by Year: There is no long term replay-ability
Defeating Co-workers will drop health recovery. Defeating Management will drop stop watches which will stop the clock for a 1/2 a second. Defeating the Janitor will fully restore your Stapler.
Somewhere on each floor will be a supply room where the player can possibly save, restore staples and recover health. These will provide necessary checkpoints for the player.
Getting to the office on time the boss will say good work and tell you he expects the same thing tomorrow. The player player realizing they could have taken the window all along and saved on the entire trip.
Genre: 3d Platformer
Similar to: Crash Bandicoot/ Jak and Daxter
Idea: a short 3d platformer where the player explores a building being inexplicably turned upside down. The player has to dodge falling hazards such as tiles, plants, urinals, and the paper shredder from down the hall.
The printer is now on the fritz shooting razor sharp rtsreports threatening to sever your head. It's 5:00 pm, you just got back from lunch and must make your way to the 30th (now 1st) floor before 5:30 to deliver that portfolio your boss asked for an hour ago. Armed with nothing but an atomic stapler and wits to make it to the boss's office.
Main enemies will be co-workers trying to distract you with meaningless banter or managers trying to get you to do something else. The royally pissed off janitor trying to clean up this mess.
The levels will be fast paced with a strict time of "30 minutes" which will equate to more of 10 minutes, giving about 1 minute to pass each floor. The end goal for each level is to find the next set of stairs. With each floor having a hilarious obstacle blocking your path for more than one floor.
The use of the atomic stapler will have 3 uses. 1) to defend yourself from your coworkers. 2) to destroy small obstacles like trashcans and desks. 3) To keep objects attached to the ceiling preventing them from falling on you.
Second by Second: Fast past action platforming jumping over desks and cubicles and firing an atomic stapler at people making lots of explosions.
Minute by Minute: Exploring upside down offices and floors while dodging enemies.
Hour by hour: Getting to the bottom of the building before the time ends.
Day by day: Beating the game will create a ghost so that players can race against either their friends or themselves
Year by Year: There is no long term replay-ability
Defeating Co-workers will drop health recovery. Defeating Management will drop stop watches which will stop the clock for a 1/2 a second. Defeating the Janitor will fully restore your Stapler.
Somewhere on each floor will be a supply room where the player can possibly save, restore staples and recover health. These will provide necessary checkpoints for the player.
Getting to the office on time the boss will say good work and tell you he expects the same thing tomorrow. The player player realizing they could have taken the window all along and saved on the entire trip.
Fragility - David Laskey
Game Titles:
*Man of Glass
*Glasstastrophe
*Fragility (My Personal Favorite :D)
Genre:
*2D/3D Platforming Sidescroller
Similar Games:
*Bit.Trip Runner
*Mirror's Edge
Narrative Summary:The government placed a mandatory order that all society must
be transparent for the good of homeland security. Feeling guilty
for being part of such an intrusive bill, Winn Dowe, the man of glass,
decided he would rather flee the city than be a part of the
government's new system.
Main Character Description:
Winn Dowe: A nimble foil, made completely of glass
Unique Hook: This game takes the typical sidescrolling adventure
and 3D platformer and makes a fast-paced, pseudo-puzzle experience.
Going back and forth between 2D and 3D perspectives gives the player
different ways to go about completing a level and/or solving a puzzle.
Sketches:
Target Demographic: This game would be for someone
who likes visually stimulating mini-adventure games.
The small differences in the level design are subtle but
enjoyable and those looking for a simple, yet engaging
experience should enjoy this game.
*Man of Glass
*Glasstastrophe
*Fragility (My Personal Favorite :D)
Genre:
*2D/3D Platforming Sidescroller
Similar Games:
*Bit.Trip Runner
*Mirror's Edge
Narrative Summary:The government placed a mandatory order that all society must
be transparent for the good of homeland security. Feeling guilty
for being part of such an intrusive bill, Winn Dowe, the man of glass,
decided he would rather flee the city than be a part of the
government's new system.
Main Character Description:
Winn Dowe: A nimble foil, made completely of glass
Unique Hook: This game takes the typical sidescrolling adventure
and 3D platformer and makes a fast-paced, pseudo-puzzle experience.
Going back and forth between 2D and 3D perspectives gives the player
different ways to go about completing a level and/or solving a puzzle.
Sketches:
Target Demographic: This game would be for someone
who likes visually stimulating mini-adventure games.
The small differences in the level design are subtle but
enjoyable and those looking for a simple, yet engaging
experience should enjoy this game.
Monday, September 12, 2011
Always Use Condiments - Phil Tibitoski
Idea Names:
Always Use Condiments
Burger Time Happy Time
Oh My god Meat is Flying Oh My God or OMG-MF-OMG
Genre: Cooperative Arcade Cooking Tennis/Pong
Similar Games: Pong, Cooking Mama, WarioWare
Summary:
I have an idea for a pong inspired cooperative game about cooking some sort of flippable food. (i.e. Hamburgers, Pancakes) In the game both players work together from either side of the screen(similar layout as pong) to "properly" cook this food. All the while different condiments will be flying up in the air from the center of the screen. Unlike Pong each player will be able to hold onto their patty or pancake for a certain about of time before sending it back. The reason for this is that each "paddle" is actually some sort of handheld stove. So the longer you hold it the more it cooks. (Sort of like Hot Potato) The goal is to cook the food well and send it through the right condiment streams shooting up in the center of the screen. (Ketchup, Mustard, Syrup.) It sounds insane, but I think it could be fun and if we keep scope in control I think it's doable.
I have an idea for a pong inspired cooperative game about cooking some sort of flippable food. (i.e. Hamburgers, Pancakes) In the game both players work together from either side of the screen(similar layout as pong) to "properly" cook this food. All the while different condiments will be flying up in the air from the center of the screen. Unlike Pong each player will be able to hold onto their patty or pancake for a certain about of time before sending it back. The reason for this is that each "paddle" is actually some sort of handheld stove. So the longer you hold it the more it cooks. (Sort of like Hot Potato) The goal is to cook the food well and send it through the right condiment streams shooting up in the center of the screen. (Ketchup, Mustard, Syrup.) It sounds insane, but I think it could be fun and if we keep scope in control I think it's doable.
Key Feature: Cooperative cooking game that isn't meant to be a simulation and instead revels in its own ridiculous nature.
Sketch:
Target Demographic: Everyone. Casual or Hardcore. Young and Old. Men and Women.
Subscribe to:
Posts (Atom)