- The big thing for this week was to start writing sections of the paper
- Professor Rosenstock said he would look them over and provide notes and feedback on them
- Dylan worked on importing more animations and cleaning up any bugs that popped up as a result
- He also worked on saving and loading features
- We discussed the possibility of having a separate "Design" section which would detail the process that went into decisions concerning key game features
- Professor Rosenstock also suggested the possibility of including an "Artistic Vision" section
- Kyle mentioned that monster implementation still needs to be completed
- Professor Rosenstock encouraged us to include pictures in the paper as well
- He also mentioned that it might be helpful to make a gameplay video just to have
- Our next meeting will be Monday the 28th at 3:00pm
- The next meeting after that will take place Friday the 4th at 3:00pm
Sunday, February 27, 2011
MQP Meeting 2/24 Notes
Wednesday, February 23, 2011
MQP Meeting 2/17 Notes
- Animations are coming slowly
- Dylan talked about getting animations into the game, there seems to be a minor issue with each animation that need to be taken care of
- We discussed how to solve one of the tech issues involving the position and orientation of instrument models in relation to the animations
- Concerning the map screen we think it's prudent to have around 20 battles and we need to fully flesh out the map background and other art assets, such as an available and unavailable battle icon.
- Icons for the instruments to be seen in the shop are also a priority
- Kyle worked on implementing the store
- He also fixed problems that arose from the store implementation
- Brian's patterns are all in game and functional
- Dylan successfully implemented a proper "end" to battles
- Dylan also tweaked the functionality of the information bar for each instrumentalist (adding tabs to be able to access different information boxes of the instrumentalist)
- Instrument types are also being implemented
- Professor Rosenstock expressed concern over starting the paper
- He thinks we should shift our effort towards writing the paper
- Professor Rosenstock also said that looking at Dylans IQP paper might be useful
- Tech sections can include original code
- Art sections can include concept art and pictures of models
- Each section should have an introduction, paragraphs with topic sentences, and a conclusion
- Professor Rosenstock would like original drafts of some of our sections by 9:00PM Wednesday
Weekly Progress (2/23/11)


The end is fast approaching, and I can't help but feel like we aren't ready yet. This week, more of my efforts have been toward trying to write up sections of the report than modeling. Per request by the outline, I've written some information about the overall monster designs, the individual monster designs, the battlefield, and the Battle HUD elements. I even included some pictures from the blog and others to slip into the paper where appropriate.
That's not to say I've done nothing at all in terms of art. Dylan informed me of some art issues he has been having with my models, so I sought to rectify what I could. In particular, I changed the eyes from Horngoon, Targoon, Bongoon, and Bibibibi from Maya textures to targa files that are attached to the eyes. It gets the same result, but now Unity will be able to stomach them.
I've also been working on the pictures above. The top picture is a sketch of our long-awaited "subterranean" enemy. This eighth-note with drill arms is known as "Undertone". I have not yet finished this model but hope to soon. The bottom picture, though, shows "Goooooob". Goooooob was designed as an antithesis to Bibibibi, and it is the monster that is defeated by long, slow notes. Goooooob controls a ball of slime that it drags while flying. During a long note, however, Goooooob begins to drop. If it plummets too low, the slime engulfs Goooooob and shrinks into non-existence.
Hopefully next week, I can get appropriate feedback on my written parts, and I can finish Undertone.
Monday, February 14, 2011
MQP Meeting 2/10 Notes
- Next Thursday is academic advising day so we will probably have to determine a new time to meet for that week
- We talked about the division of art work between Joey and myself
- We also had a general discussion about the possibility of going into D-Term
- Concerning tech, Dylan worked on the map screen and implementing its functionality, although he would still like to have an actual art backdrop for the map
- The set up for the map screen can also be used for the instrument trees in the shop
- Dylan also redid the battle GUI such as different actions when instrumentalists are clicked
- Kyle worked on cleaning up some bugs in the game
- In terms of sound and Brian, all the compositions are done and all that is left is to get sound effects
- Professor Finkel expressed his concern over the viability of finish the project this term (everything needs to be working very soon)
- In terms of the MQP paper, it typically ranges in size from 50-100 pages.
- Professor Finkel stressed that proofreading would be very important
- As such it would probably be a good idea to have the artists read the tech written parts and vice versa
- The goal of this week is to have the game "working" by our next meeting
In terms of other advice Professor Finkel had about our paper outline, they are as follows:
- Discussed the trade offs between some tech decisions.
- Reasoning behind all decisions tech side.
- Discuss process of testing (right before postmortem)
- Include Conclusions and Future Work
- Summary of work
- Major changes
- What we learned
- If we had another term what would we do
- Suggestions to a future MQP team
- Everyone should see every other section of the paper
- We shouldn't submit a "draft"
Thursday, February 10, 2011
Weekly Proposal (2/9/11)



Whew! About time. I actually added to the city scene I made before. Around the original block, I added eight more for a 3x3 grid of city blocks. Then I had to make stuff to fill it with.
That's where the bongo and trumpet buildings come in. These are more building designs based on musical instruments like the piano buildings I made so long ago. Each of these come in four colors to keep us from staring at the same orange horns or blue drums.
But wait... what is that on the horizon? That sea-green and red castle-like structure in the west side of the city? I decided that this city could use a significant landmark, and so, I created this museum that is meant to look like a giant drum set (yes, dwarfing even the "hornscrapers"). A drum set was the best musical instrument I could conceive that had an interesting design (or interpretation of one), so that became this city's greatest landmark for now. Maybe we'll have an interesting fight here later?
Who knows? Time grows short at this point.
Tuesday, February 8, 2011
Updated MQP Paper Outline
Some sections are still not assigned due to the fact that they further need to be fleshed out.
1. Abstract
1. Abstract
2. Introduction
a. Team Roles
3. Concept Proposal & Design
a. Inspiration - Rob
b. Evolution of Concept Proposal - Rob
c. Concept Art – Rob & Joey
d. Goals Utilizing Sound - Brian
e. Prototype (Iterations) – Dylan & Kyle
4. Game Design
a. Game Features
i. Game Modes – Dylan & Kyle
b. Monsters - Joey
c. Instruments & Instrumentalist - Rob
5. Technical Design
a. Game engine / Unity
i. Advantages / Disadvantages – Dylan & Kyle
b. Composition Mode - Dylan
c. Monster Implementation - Kyle
d. MIDI Implementation - Dylan
e. Map Implementation- Dylan
f. Upgrade Shop Implementation - Kyle
6. Artistic Design
a. Approach / Design
i. Monsters & Animations– Joey
ii. Instruments - Rob
iii. Instrumentalist & Animations - Joey
iv. Level Design - Joey
v. UI Elements – Rob & Joey
7. Sound Design
a. Process of Composing Game Music - Brian
b. Implementation in Unity - Brian
c. Process of creating sound effects - Brian
8. Successes / Failures
a. Postmortem
i. Multiplayer
9. Misc. Appendices
a. Content not implemented in game
Wednesday, February 2, 2011
Weekly Progress (2/2/11)
This week, I managed to submit animations for the Fast Note bee and the tree monster that I displayed here before.
The bee flits around a bit normally, but when a note hits it, the bee leans back and the headphones pop off for a brief moment. When enough quick notes hit the bee, the headphones pop farther off and the bee takes longer to recover (this is when it is vulnerable). Finally, when it dies, the headphones fall back while the bee crashes to the ground.
The tree's animations are a little simpler. He has a standard walking animation, but instead of being totally smooth, he pauses a little before trying to bring the other leg forward. When the fire surrounding him is blown out, the tree takes a little time to recover and rekindle his flames. When he's finally vanquished, the tree falls stiffens up a bit before falling forward.
Over the coming week (provided I have enough time to do it), I'm going to have to expand the city I began to make. This will provide us with a more vibrant landscape to play in. But for now, all I can do is tell about it.
Before the project is over, I should make a video of the animations I made during the project.
The bee flits around a bit normally, but when a note hits it, the bee leans back and the headphones pop off for a brief moment. When enough quick notes hit the bee, the headphones pop farther off and the bee takes longer to recover (this is when it is vulnerable). Finally, when it dies, the headphones fall back while the bee crashes to the ground.
The tree's animations are a little simpler. He has a standard walking animation, but instead of being totally smooth, he pauses a little before trying to bring the other leg forward. When the fire surrounding him is blown out, the tree takes a little time to recover and rekindle his flames. When he's finally vanquished, the tree falls stiffens up a bit before falling forward.
Over the coming week (provided I have enough time to do it), I'm going to have to expand the city I began to make. This will provide us with a more vibrant landscape to play in. But for now, all I can do is tell about it.
Before the project is over, I should make a video of the animations I made during the project.
Subscribe to:
Comments (Atom)