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...

A little music for working.

Hey guys if you like anything electronic or ambient I highly suggest this playlist.

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” =

Phil - A few sketches to show mechanic logic. (Jumping)

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...

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)

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.)

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

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.

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

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.

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.

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

Pitch - Logan Wright

Titles:

-Battle to BeerHalla

-Drunken Vikings

-Death by Axe, Life by Glass

Genre: 2D Platformer

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 ~~

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.

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.

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.

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.