MQP Meeting 12/16 Notes

• The last meeting of B Term
• I showed the screenshots of the instrumentalist model, which has been rigged for animation and has a basic playing animation, and the Recorder and Pan Flute instrument models
• Joey worked on splitting up the UI elements and also was able to work on the spring monster model
• In terms of the prototype Kyle worked on some more code refactoring such as data structures, switching instrument classes, and improved some code for the monsters
• Dylan re-did the interface of the composition mode to incorporate importing
• Brian worked on creating more patterns to be implemented such as utilizing arpeggios, major and minor scales, the piano, the bottles, and some sample synth patterns
• The idea of the patterns is to allow players to just play the game instead of focusing so much on compositing if the player so chooses
• Our goal now is to start working on and building the actual game
• We also still have to work towards implementing multiplayer in some form
• Professor Rosenstock suggested putting everything we have made together into a single form after break
• Professor Finkel will be away most of next term, so we will need to figure out how we will be corresponding with him for our weekly meetings (webcam, skype, etc.)

Weekly Progress - Brian

This week I created a bunch of patterns in the sequencer, as well as one more music track; a basic drum beat that can play in the background. It could potentially play at the beginning of a battle when the player is setting up, and then fade as instruments start to play. I am sending all of the patterns and MIDI sound files I have created so far to the email list for the group. If easier, I can also convert them to .wav files, if they are easier to listen to. I will also have all of the MIDI and pattern files at the meeting tomorrow.

Weekly Progress

Unfortunately there's not much for me to talk about this week. It's the end of the term and everybody's finding it difficult to find the time to do things. I've mostly been cleaning up some of the code and getting some things in place that we'll need later on.

I was hoping to take a stab at some of the instrument unlocking stuff, but I haven't yet really figured out Unity GUIs. I'll keep looking at it though.

We also wanted to try to get Rob's animated instrumentalist in place and hopefuly with an instrument, but we haven't yet discussed how in our meetings.

Dylan and I were planning to get together and sort through everything we have to try to create a cleaner build, and I was hoping we could discuss some strategy, but unfortunately we weren't able to find time to.

There are also a lot of other things we still need to do but barely discussed, so hopefully that will become a little clearer during our final meeting of the term.

Weekly Progress - Rob

This week I work on making 2 more instruments, a pan flute and recorder, rigged and painted weights for our instrumentalist model, and put together a modest animation for when it's playing the recorder instrument.

MQP Meeting 12/9 Notes

• Joey showed off his city environment and we discussed the possibility of potentially adding even more features to it, such as having the main street continue on into the distance so it doesn't just abruptly end
• I showed the instrumentalist model which is completed and just needs to be textured, rigged, and animated
• Joey also showed off some of his UI elements which he has made so far, such as the fatigue bar and information sections for the instrumentalists
• As part of this we also discussed our plan of utilizing the information bars to help showcase the instrumentalist models from the front and also the incorporation of three buttons which will correspond to switching the instrumentalist, pattern, and instrument
• We also discussed our two potential options of showing the information boxes for all instrumentalists or only for the currently selected one
• Professor Rosenstock suggested the idea of potentially having the instrumentalists turn around when selected
• He also suggested splitting the already made UI elements into individual elements so they can be more easily be implemented by the tech team
• In terms of the prototype Kyle worked on mostly behind the scenes stuff, making the game more efficient
• Dylan figured out a way to incorporate piano roll elements into the step sequencer to allow for dragging for not durations
• The player can now designate the number of beats and number of subdivisions per beat
• The composition screen now also features a tempo slider
• Dylan is also working towards implemented the rules for each instrument class as part of the sequencer
• Dylan was also able to implement an import/export feature to assist Brian in getting some of patterns into the game
• He also mentioned that there might be a potential issue of lag when the composition is scrolling on playback
• Dylan suggested that perhaps its time to move away from the prototype and start building the actual game
• Brian played for us a couple more of his compositions which could be used for when instruments are unlocked, but he is still working on using string instruments
• Professor Rosenstock also suggested Brian could also work on some sound effects that will be needed and also some potential background tracks for certain sections such as the map screen for example

MOVING FORWARD

• The upgrade system is the last big tech feature
• Professor Rosenstock suggested even just working towards implementing a very simple version
• Other issues include resolving animation issues, getting UI elements into the game, getting the instrumentalist model rigged and animated, as well as working towards creating more monsters and instruments
• We also talked about putting together the progression of the upgrade mode (what things can be upgraded, etc.)
• Perhaps putting together some form of the map is the next most pressing issue

Weekly Progress (12/08/10)

This week, I spent most of my time making a sample environment with streets, piano buildings, and streetlights. The plain green flat we have for the demo's environment right now will get tedious after a while, so I set this up to (hopefully) give something more interesting to look at during the battle.

I also started designing some of the user interface elements. Displayed at the top is a prototype of the life bar for the city. Below that is the basic display for the musicians the player has performing right now. At the top is a bar for that shows how much energy the musician is using right now. Once that runs dry, the musician is unable to perform for a while, and it's time to let him rest. Along the side are three buttons to change options like the musician in that box and the pattern he is playing.

Weekly Progress - Rob

This week I've been working on remaking the instrumentalist model and getting some animations done for it. The model I've been working on so far is a male and it will also have features to make it look like it's wearing a marching band uniform. I plan on putting together a female instrumentalist model to add some visual variety. The idea will be that the color for each individual instrumentalist's marching band uniform will correspond to the class of instrument they are currently playing based on the instrument class/monster weakness color scheme we've decided upon.

Weekly Progress - Brian

This week I created a few more music tracks for the game; I will have them at the meeting tomorrow. Basically, they are sound effects that can be played when a player purchases an instrument: for example if the player purchases a pitch percussion instrument, a tune will play that includes pitch percussion instruments. I hope by tomorrow to have one sound effect for each music class: pitch / regular percussion, the two types of strings , and winds (woodwind and brass).

I was unable to create any patterns for this week, but I am confident that once the sequencer is finalized, I will be able to quickly create simple patterns to use in the game.

MQP Meeting 12/2 Notes

• Joey showed his basic monster models and animations and I showed my animations for the flying monster
• Professor Rosenstock reiterated working towards a full battle level with a complete environment and suggesting to narrow the number of different battlefield locations to around 3
• We also discussed our intention to have a color system between types of monsters and the instrument classes needed to defeat them (also extending to the color scheme for instrumentalists to denote which instrument class they are versed in)
• As an extension of this we also talked about the potential use of different particle effects to denote when monsters are taking damage or being healed
• Dylan also led us through the new added tech features to the prototype including Kyle's implementation of monsters which are weaker to more and fewer notes respectively and a monster which decreases the effectiveness of all instruments on the field
• Kyle demonstrated the newly implemented fatigue system and tempo changing system
• Under the fatigue system each instrumentalist has a "fatigue bar" which is subtracted from each time a note is played; whether an instrumentalist's fatigue bar reaches zero or the slot is turned off, the instrumentalist's fatigue bar will regenerate after five seconds of inactivity
• A sliding bar was added to the battle mode screen to allow variations in tempo during battle
• We talked about the possibility of having different animations to denote different levels of fatigue for each instrumentalist
• Professor Rosenstock suggested the artists try and think of different ways to represent the tempo slider
• We also briefly discussed the possibility of having different difficulty settings rather than just relying on variations of instruments
• Brian then showed the work he has put forth on sound design playing some of the sound effects and MIDI files he's found to correspond to our list of instruments and also played some sound clips he had composed as potential menu tracks and other game condition tracks such as winning or losing a battle
• Professor Rosenstock suggested Brian continue on by putting together some sample patterns to be used in game or potentially serve as unlock-able patterns as part of the upgrade system
• We then discussed potentially having to switch from a step sequencer to a piano roll to accommodate more interesting and complex patterns, most of which revolved around adapting the step sequencer to be able to combine beats into longer, continuous notes, or having some kind of visual indicator (such as connector lines) between beats which, when toggled, would indicate different note durations

WHATS NEXT

• For the artists Professor Rosenstock suggested a potential division of labor in which Joey focuses on putting together more environment assets and I recreate the instrumentalists and some animations for them as well as making more instruments
• Professor Rosenstock also suggest that the group discuss and potentially draw up initial designs of important UI elements which the artists would also then work on
• Part of this also included rethinking the functionality of the instrumentalists themselves and their associated actions (selecting patterns, instruments, instrumentalists) while in battle mode
• Professor Rosenstock re-expressed his desire to showcase the front of the instrumentalist models somehow
• Professor Rosenstock also brought up the point of coming up with a name for our game, suggesting we brainstorm some potential titles
• Professor Rosenstock also expressed that he thought further implementation of the upgrade system (instrument trees) be the tech teams top priority
• This also includes thinking of other potential "player upgrades" that could be implemented as part of the upgrade system (such as patterns, beneficial potions, etc)
• Professor Rosenstock's final point was that we should try and bring all our features and assets into a single version 

Weekly Progress (12/01/10)

Here's what I have to show for this week: my takes on the basic enemies: BonGoon, TarGoon, and HornGoon. These are the common monsters seen throughout the game, mass-produced musical monstrosities that hop, creep, and waddle toward you. The "Goon" enemies are weak to whatever instrument they resemble, so HornGoon is blown away by wind, TarGoon is shaken by strings, and BonGoon is beat by percussion.

This week, I managed to model these guys, and I made walking and death animations for them. I also created two new animations for the Micropus: an idle floating and a death animation where he crashes.

We have also decided on a color scheme that we can use to designate what instruments are characters' specialties or weaknesses. Orange gets associated with wind, green hues match with strings, and purple shades are tuned to percussions.

Weekly Progress - Brian

These past two weeks I have been creating short music tracks for the game. I have sound effects to indicate won or lost battles, as well as two percussive tracks that can be used in various places. I will have my laptop with me at tomorrow's meeting; and I can play them there.

Also, I have the list of all instrument / MIDI sound files. They are as follows:

(Instrument name - General MIDI Number - MIDI Instrument Name)

Wind Tree:

Bottles - 77 - Blown Bottle

Pan Flute - 76 - Pan Flute

Recorder - 75 - Recorder

Clarinet - 72 - Clarinet

Flute - 73 - Piccolo (I think it sounds more a flute, incidentally)

Oboe - 69 - Oboe

Bassoon - 71 - Bassoon

Saxophone - 66 - Alto Sax

Bugle - 61 - French Horn

Cornet - 57 - Trumpet

Trumpet - 57 - Trumpet (same sound as Cornet)

Whistle - 79 - Whistle

Trombone - 58 - Trombone

Tuba - 59 - Tuba

String Tree:

3-String Guitar - 33 - Acoustic Bass

Guqin - 107 - Shamisen

Harp - 47 - Orchestral Harp

Ukulele - 25 - Acoustic Guitar (nylon)

Banjo - 106 - Banjo (same sound as Mandolin)

Acoustic Guitar - 26 - Acoustic Guitar (steel)

Mandolin - 106 - Banjo

Electric Guitar - 28 - Electric Guitar (clean)

Bass Guitar - 35 - Electric Bass (pick)

Erhu - 111 - Fiddle

Viola - 42 - Viola

Contrabass - 44 - Contrabass

Violin - 41 - Violin

Cello - 43 - Cello

The percussion tree is not included at this point because it can be either a mix of MIDI sounds or samples.

Weekly Progress

There's not a whole lot for me to talk about this week, but I am continuing to work on implementing more monsters and tidying up the code from last week. We were all a bit unsure of what to work on after coming back from break, but aside from the new monsters we are planning to try implementing a version of the fatigue system we've been talking about for several weeks now.

Back to the monsters though; I have tested two monsters that take more or less damage based on how rapidly they are hit with notes. One reason for having these monsters is that we want the player to be able to adjust the tempo of their music, which we decided should be independent of the monsters' actions (which would remain based on real time). In theory, the player could raise the tempo to increase their damage output, but they won't be able to sustain this (yet another argument for implementing fatigue) for a long period of time, and similarly they could decrease the tempo to conserve stamina. These monsters also add more strategy to their use of tempo.

In addition to the tempo monsters, I started to implement the monsters that reduce the effect of certain notes on all the monsters. Right now they only have the effect of reducing damage taken, but other attributes can potentially be added, and eventually they should audibly effect the music or do something to indicate what they are doing. I've implemented a only a single monster that reduces all of the notes, but it is possible to create variations that reduce notes of different classes by varying amounts.

I believe that Rob and Joey are also making art assets for some of these monsters this week, so it'd be nice to see them in game with the working functionality.

Weekly Progress - Dylan

In the past 2 weeks, we determined a bunch of milestones that we figured should be our next tasks on our lists. Of said milestones, I was assigned to work on a couple of different things.

The first, and biggest milestone I worked on implementing was the Fatigue and Instrumentalist changes that we've been talking about. I redid a bunch of the code behind the instrumentalist 'slots' during a battle, the instrumentalist, the instruments, and the patterns. The slot is now its own entity into which the player places an "instrumentalist" (or musician). There are three types of instrumentalists - string, wind, and percussion - which can each only play the instruments of their class. They each have their own stamina - starting at 100. Playing a note costs them 1 stamina, and if they don't have any left, the pattern is turned off and they stop playing. After they haven't played any notes for 5 seconds, they start regenerating their stamina. The longer its been since they played, the more stamina they regenerate a second.

I also redid some of the UI elements for the instrumentalists, so there are now three buttons per slot: one to change the instrumentalist, one to change the instrument they are playing, and one to change the pattern they are playing. (Currently the fatigue is shown on the button for the instrumentalist swap, but this will probably be changed to a bar gauge in the future.) Clicking one of them will pop up a menu allowing the user to select a suitable replacement. I reworked these to all look similar and keep a consistent UI, and also to allow us to filter out options - ie, if you have a String instrumentalist, you will only see string instruments in the instrument change list. (Some of the logic for instrument classes was one of Kyle's milestones, so some pieces are awaiting the merge with his stuff).


My next major milestone was to add the tempo option which Prof Rosenstock mentioned in the last meeting. We discussed this during our meetings on our own during the week, and I did some thinking on the balancing of how it would work out. With the way we have the game set up, it seems to balance itself out as a tradeoff between the number of monsters each note will hit, and the time it will take for the players to regenerate their stamina. Stamina cost is based on how many notes are played, so speeding up the tempo will drain their stamina faster, though regenerating is based on real time so they will not regenerate faster. Since the regeneration works faster the longer they haven't been playing, this could still pose an advantage if played correctly.

The tempo logic is mostly implemented, though I'm still currently finishing it up.

Finally, I also wanted to get some work done on the Note Offs and the durations if there was time. We discussed a different UI during our meetings that would allow us to make a more sophisticated step sequencer which would allow for note durations. I have also looked through the code and designed a solution to turning notes off, but have not yet had time to implement it.


Also, as usual, I will be merging my and Kyle's changes to try to have a demo which shows both for the meeting tomorrow, as well as trying to integrate as many of the art assets as I can.

MQP Meeting 11/18 Notes

• We went over the art assets: 3 monsters & 3 instruments

• Talked about putting together a full mockup of the monster information screen in Photoshop

• Dylan ran through the battle prototype which included the flying monster, the 'mim' monster, and the bomb monster which programatically creates monster pools to draw from

• Professor Rosenstock brought up the issue of visual correlation between instruments being played and effects on monsters

• We discussed the potential use of particles to indicate whether damage or health was being given to the monsters, as well as incorporating animations as indicators

• The question was also raised whether or not the game seemed "fun" yet and we came to the consensus that ultimately more monsters would have to be implemented in order to make that kind of determination

• Both Professor Rosenstock and Professor Finkel asked what the player was 'doing' during the battle, meaning what was there level of involvement in terms of having to complete the battle

• We discussed different ways to try and increase player involvement such as implementing a fatigue system, perhaps having patterns not repeat, ultimately making it so we avoid long periods where the player is doing nothing

• Brian also talked about how he went through and picked out some MIDI sounds that we'll be able to use

MOVING FORWQRD

This is just a list of things to keep in mind moving forward as well as things more specific to the art and tech side

• Improvement on the Game Flow (more complete to include map screen and battle selection)
• Potential sequence mock up of single player (what monsters at what battle and when instrument and player upgrades come into play)
• Upgrade system progression
• Hammering out a potential fatigue system and also its other applications (anti-fatigue upgrades, etc.)
• Also think about potentially implementing upgrades that also encourage interactivity
• Fatigue system - if we were to do it how exactly would we design it and implement it

ART

• Keep plugging away at creating monsters
• Also put together more monster and player animations
• Think of ways to try and showcase the instrument players
• Try and incorporate men and women characters
• All building towards completing one area/battle scene/setting

TECH

• Implementing an upgrade feature
• Implementing a map screen
• Hammering out the win condition
• Make the logic to be able to switch between animations
• A potential import/export method for patterns
• Flushing out instrument classes
• Potential implementation of some form of a piano roll to accommodate incorporating durations

Weekly Progress (11/18/10) and Pictures

This week, I managed to make and animate a couple of monster models to use in the game. The top one is our "mime" monster, which has changed to mean a monster that heals all the monsters on the field if a certain instrument is playing. Therefore, I changed it to some kind of flying octopus with a microphone body. The second picture is a bomb that appears at the end of the battle, which blows up anything in its blast radius after a few measures.


We also have to figure out the way to display information about the monsters in-game. My take on it was some kind of bestiary in the spirit of the "Pokedex" pages in the Pokemon games. The name of each monster, its picture, the stats, and some text on the bottom. In Pokemon, the text is almost entirely flavor text that doesn't apply to much in-game. In this case, however, we can use the text to talk about how to fight the monster or what it is capable of, though a little flavor text probably won't hurt if it doesn't interfere with how the monster works.

Weekly Progress - Brian

This week I spent my time browsing through the MIDI sound bank looking for sounds that we could use for all of the instruments. Taking the three tree diagrams we already came up with, I matched each instrument to a MIDI sound, attempting for as little overlap as possible. I'm not able to post the list I have now, but I have a few examples to share for the blog. For example, I did some research, and determined the Guqin sounds similar to the "Shamisen," which is in the library. Also, some sounds were not logical; the sound "Orchestral Strings" sounds exactly like a harp to me, so that is what I put for the harp sound.

I think somebody mentioned there was a "Percussion" sound that comprised most of the drum sounds we need, but I could not find it in the library I was checking; perhaps I just missed it. The non-tonal percussion effects would be possible to find samples for, so I am not worried about that. In fact, we might want to find as many samples as possible, because it will theoretically sound the same on every computer. However, samples would not be practical for any instrument with different pitches, or note duration, if we implement that. I'll have the full list up soon; it has my recommendation for instruments, but also other possible choices if you guys prefer.

Weekly Progress

This week, our main technical milestones were to prototype 3 different monsters and to implement a version of the sequence that we laid out last week. Kyle picked up the monster prototyping milestone, and most of the work needed to be all in line - so it wasn't really possible to split them up. As such, I went to do the sequence from last week, but this is somewhat reliant on having the monsters already implemented.

Because of this, I couldn't really start this work until those monsters were completed - something we overlooked a little when we were laying out the milestones. Instead, I chose to do something as related as possible. I implemented a system for these 'battle sequences' in general. I worked on developing a system that will allow any sequence to easily be programmed into it. It is based off the 'pool' idea that we developed for the last milestone - in which we define groups of monsters to spawn, the weight of each monster, the spawn rate, and when the pool starts and ends. By just filling in these simple variables, a battle is entirely run by the system, allowing us to rapidly prototype many different sequences with very little code - which could even eventually be turned into a scripting or graphical interface to allow users to develop their own battle sequences.

This also provides another abstraction for the spawning system, in which monster spawns are raised as an event with a given monster type. A monster spawner observer is then registered to these events, which then handles spawning the actual monsters. This will allow us easier implementation of the version of multiplayer in which one player spawns the monsters; The user can have a GUI with buttons for each monster type, and clicking one would just raise the same event that the monster spawner is listening to - leaving much of the spawning logic abstracted away and applicable to both the single player and multiplayer versions.

With this system in place, putting the actual sequence from last week should be pretty trivial once the monster prototypes are finished and merged into the build. It'll basically be just translating the sheet we have into a handful of straightforward "scripting" of sorts.


In addition to this milestone, I chose to work on some other things which seemed relevant to the prototype. The next big thing we had questions on was the map system - how the map would look and giving the user information about these. This ties in a lot with one of the milestones we had this week about monster information. Though it wasn't formally defined as a milestone, we believe that this would be another important thing to hammer out and may affect the rest of the game - it's logically the next step to implement and test. As such, I have some work done defining a tree sort of structure to allow us to lay out the maps and some simple GUI work to display these. Similar to the other milestone, this is mostly a back end allowing us to implement the concrete examples more quickly when we get there - though this is a more complex problem and not all the logic can be handled programatically. For example, we can layout a map as a tree and the functional requirements that the player would have to fulfill for each one, but actually laying the map out across the screen is something we want to take more artistically as opposed to having an algorithm to draw it out.

Weekly Progress - Rob

This week for the art side Professor Rosenstock wanted us to create 3 instruments and 3 monsters. The division of work between the artists would be Joey would make one instrument and two monsters and I would make two instruments and one monster.



Snare Drum






Acoustic Guitar (missing fretboard texture)






Flying Monster

Weekly Progress

One of our milestones for this week is to prototype 3 monster types. The monster types we've chosen are:
Teir 2 Flying monster
Bomb monster
Mime monster

I'm current working on implementing these in the prototype. However, because we didn't yet implement the instrument classes, it's a slightly more complicated than I thought it would be. So I've been trying to add some elements of the instrument classes. From a more technical point of view, I've been trying to decide how much of it I wanted to implement and what the best way of doing it is, but because we're working off of older code from the first prototype some things are not set up as best as they could. So for now I've decided just to use a more simple (but less scalable) approach for the sake of just prototyping the concepts.

MQP Meeting 11/11 Notes

• We went over our 3 completed instrument trees

• Discussed the possibility of including even more instruments from different cultures

• discussed how each tree is essentially an instrument class and each class will have a specific overall property or ability

• We discussed the refined monster list, all legitimate options we are strongly considering

• We discussed how the use of the 'mime' monster is to attempt to partially address the potential issue of game balance and possibly being able to use all instrument classes at the same time

• Professor Rosenstock told us to keep in mind the possibility of having monsters which require a combination of instruments to be defeated

• Once again came back to the question of composing vs. gameplay and whether we want more freedom to compose or would we rather have more stringent monster requirements that technically ultimately restrict absolute creativity

• We went through the battle sequence flow, ultimately working towards a prototype of a battle

• Dylan led us through the game flow prototype including logging in/starting the game, composing, viewing the map screen, entering a battle, visiting the upgrade shop, and then doing it all over again

• We discussed the potential use of time as a monster requirement, potentially extending the usability of patterns

• We briefly discussed the use of MIDI since it apparently it might not be usable in the Unity web player

• We discussed the possibility of the player drawing from a pool of 'instrument players' for each instrument class, and they are only allowed to take a certain number, so the player must plan accordingly and allocate enough players of whatever instrument class they think they might need most

• We also reintroduced the idea of fatigue for either instrument players or specific patterns themselves

• We also discussed the potential ability for a player to decide for themselves whether they want to specialize in composing for a certain class of instruments, and therefore we would design the game around being able to adapt to a players compositional preferences

• WHATS NEXT: Art assets for the battle prototype (3 monsters and 3 instruments), a prototype of the monster info panel (programming implementation and visual mock up), as well as going through MIDI sounds to determine which are usable and which aren't
  

Weekly Progress

This week, in addition to attending the weekly meetings for the decisions we've had due this week for the milestones, I've also been working on the flow prototype. It's still just a prototype so it's not as clean as possible, but it's functional. The player starts out with just a few basic instruments and can battle or compose. After winning a battle (for now the player just clicks to end the battle), they receieve points for unlocking instruments as well as money. When they go back to the main menu, they can then go use the points they've earned to unlock more instruments.

I did this version using MIDI to see how it would work, and some of the instruments sound a little funny. I didn't do all the "note offs" so some notes end up hanging. I hadn't originally planned on using MIDI and with the way the prototype has been structured, it's not easy to get the note offs in. Since it wasn't the main focus for the week, I decided to devote my time to getting the actual flow done instead. This is a problem that could be addressed but I didn't want to spend time on it if we weren't even going to use MIDI anyway.

And as such, once I finished the prototype, I remembered one of the reasons that I strayed from it initially - it doesn't seem to work through the web player. This could, again, be because the MIDI implementation I'm using is referencing a .dll. It's possible that I could get around this by adding the actual source code to the project, though that seems like a large task in itself as it is not written to be used as such. This'll be something I look into later.

Weekly Progress - Brian

Most of the progress this week was spent in meetings, discussing and brainstorming ideas. However, I came up with a couple ideas while at the meetings which I don't think I voiced, which might be helpful.

First, I think at the beginning of battles there should be some reason for the player to not be playing every instrument at once. This would give battles a more musical flow; they could start out quietly, with just a couple instruments playing, and then could crescendo until everyone is playing at once. This could be implemented in a couple ways. For one, the mime enemy that we discussed prevents the player from having each slot playing at once; perhaps at the beginning of a battle there are lots of mime enemies to keep the total volume down. Secondly, the fatigue system would also work well to accomplish this goal. Perhaps at the beginning of a battle you have five instruments, but only a couple enemies spawn. The player could turn all the instruments on, but most would become fatigued, and later on in the battle they would be worse off. As an alternative, they could only turn one instrument on, which would still kill all the enemies, but would save their other musicians for later on in the battle. This would also work in the middle of a battle; perhaps at one point in the battle a huge wave of enemies shows up and your musicians have to become very fatigued to fight them off. After that, there could be a lull, which would let you regain energy, but would also work well with cycles of musical tension / release.

Secondly, battles with only one type of instrument would be interesting both from a musical standpoint, and from a game play standpoint. I think we already touched on this in the meetings, so I apologize if I am just restating it. For example, there might be a percussion only battle which has lots of bomb enemies (can't be killed, only held back long enough until they explode). The percussion instruments would slow down the bombs, saving the player. The same effect would also work for brass chorales or string ensembles. This is just a level design concern, but I think it would allow for interesting and varied levels. In summary, I am stating a new use for the fatigue system, and giving an idea for a level design concept.

Weekly Progress and Pictures (OMG!) (11/10/10)

So, this week, we met to clarify what we needed for monster parameters, to discuss game flow, and figure out our instrument trees.

On my own, I started to make models, as you can see above. The top picture is a basic horn model that can be turned into many forms, including a basic enemy or perhaps even some of the horns the players will use. The 2nd picture is a piano-shaped building to be used as some of the scenery in the musical city.

The reason the horn is currently orange is because we were mulling over the idea of using different colors for whatever is weak to the kind of instrument. Some kind of orange for wind instrument vulnerability, green for weakness to strings, and purple (?) for percussion.

Weekly Progress

This week we further refined our list of monsters and defined all of the instrument trees. So far things are looking pretty good. We should be starting to prototype many of these ideas soon, and maybe then we can finally get a good idea of how everything will work once it's all put together.

Weekly Progress - Rob

After working as a group to put together our first instrument tree, i worked this week on putting together the other trees (string & percussion) and presented them to the other group members for tweaking. What follows are our completed 3 instrument trees: Wind, Strings, Percussion from top to bottom respectively. (Note: the dotted lines represent additional potential links between instruments)



We are also still considering implementing a keyboard instrument tree.


During our weekly meetings we also put together a refined list of monsters to better reflect newer notions about the relationship between instruments and their effects, and monsters.

• basic monster for each instrument tree (wind, strings, percussion)
• monster weaker to more notes within a pattern
• monster weaker to fewer notes within a pattern
• bomb monster that is indestructible but must be slowed/kept back a safe distance before it blows up (it's position on the field might be influence)
• monster that reduces the effectiveness of all instruments playing
• fan monster which reduces the effectiveness of wind instruments
• foam monster which reduces the effectiveness of percussion instruments
• spring monster which reduces the effectiveness of string instruments
• mime monster which attaches itself to different instrument slots over time of which when that slot is on/in use the monster turns all damage being done by that slot into health for all monsters; turning the slot off removes the healing effect

Finally, we putting together a mock up of a potential battle (presumable late game) utilizing the revised game mechanics and the refined monster list. While we worked as a group to fill in the details, the overall design of the mock up was envisioned and drawn out by Dylan. What follows is a cleaned up version of his design.

MQP Meeting 11/4 Notes

• First instrument tree has been completed: class based -> each subclass correlates to a set of monsters

• As such the monsters will also be broken up into 3 classes to correspond with our three instrument classes

• Monster parameters: movement speed, damage multipliers, state modifications

• We discussed additional things to keep in mind concerning game flow such as the use of fatigue, the player having a overall health bar, and having multiple instrument slots, some of which have default specific instrument class type designations, and the potential use of 'ammunition' for instruments/instrument players

• We further discussed multiplayer and our top 2 options

• The first is a VS mode where one player controls the instruments being played against a player who controls the spawning rate and variance of monsters

• The second is a co-op mode featuring potentially up to 3 players where each player controls and composes for a specific instrument class and all players work together in defeating waves of monsters

• We discussed the visual aspects of the game flow, such as the title screen, main player screen, map screen, upgrade menu, compositional menu/interface, battle mode, and how the player would move through all these screens when playing the game

• We discussed our ideas for the player earning experience per each battle allowing them to level up and thereby unlocking new instruments as well as a currency system which would allow the player to purchase other ancillary items or upgrades in the shop

• Professor Rosenstock suggested starting to put together some art assets, sounds, etc. and recommended aiming for being able to put together a single test environment

• WHATS NEXT: completing 3 instrument trees, a 'game flow' prototype (main menu -> composing -> battle -> shop -> repeat), a refined monster list, and putting together a mock up of a potential battle
  

Weekly Progress and Asset List (11/03/10)

Hey, guys! Been a while, hasn't it? Anyway, the group actually met twice this week to really hammer down a few concepts that we needed to clarify. We discussed the parameters of the monsters, such as speed, endurance, and states that affect vulnerability. With these in mind, we might be able to actually design and sculpt a few different monsters now.

Speaking of which, Rob and I hammered out a list of Visual Art Assets that we would need to make for the game.

UI/Interface

· Title Screen

· Main “player” screen

o Map icon/button

o Composition mode icon/button

o Upgrade shop icon/button

o Character illustration

· Map screen

o Information tooltips about each battle

· Composition mode

o Icons for all instruments

· Upgrade shop

o Instrument upgrade screen

§ Instrument trees’ progression

§ Unlocked and locked icons for all instruments

o Player power-ups screen

§ Unlocked and locked icons for all upgrades

· Battle recap/rewards screen

· Backdrops for battle levels

Models

· Player avatars

· All instruments

o Wind, string, percussion

· All monsters

o Basic tier 1 monsters for each instrument class

o Evolved tier 2 monsters incorporating additional requirements

o Matured tier 3 monsters which influence/attack the player

· Environment

o Forest

§ Trees

§ Rocks

§ Logs

o City

§ Buildings

§ Cars

§ Lights

§ Hydrants

§ Signs

o Desert

§ Rocks

§ Foliage

§ Rock formations

§ Cactus

o Water

Animations

· Player avatars

o Playing instruments

o Reacting to monsters/damage

· All monsters

o Approaching

o Being defeated

o Influencing/attacking the player

MQP Meeting 10/28 Notes

• First meeting of B-term

• We went over what we have accomplished so far

• We also discussed what questions we still had left, such as multiplayer and the question of note durations

• Dylan mentioned it might be possible to use MIDI with the free version of Unity and we discussed where it potentially would make sense to use MIDI or to use samples

• We talked a bit more about the upgrade system, the binary trees, and also the relationship between upgraded weapons and being able to discern what monsters required what instruments

• We talked a little about possible milestones for the term, chiefly how many levels and monsters we want, and the further development of multiplayer
  

• We further expanded on the relationship between instruments and monsters and discussed how to integrate the communication as to what instruments are for what monsters into the actual game story and other elements (building the challenges into the narrative)
  

• Professor Rosenstock went about setting up a 3 week long schedule of concrete deliverables.

WEEK 1

• Fleshed out list of monster parameters
• One fleshed out instrument tree
• Settle on one to two finals options for multiplayer
• Deciding on the compositional game mode flow
• A complete list of art assets

WEEK 2

• Refined monsters (specific monster designs)
• Three fleshed out instrument & monster trees
• A compositional game mode flow prototype
• Monster battle design/sequence fleshed out

WEEK 3

• Testing up to 3 fully design monsters
• Prototype of monster information mechanism
• A battle mode prototype
• Some completed art assets independent of monster elements, such as general environmental/UI stuff
  

MQP Meeting 10/14 Notes

• the last meeting of A Term

• we discussed and shared all the monster ideas that we all had come up with

• the question of whether we should think of our project more as a composition tool or as a game that utilizes user generated music

• we discussed Brian's idea for the upgrade system and which was well liked by all

• moving forward we should focus on what beginning level game features and assets we want and how the initial upgrade system will look and function in order to establish the nature of the work flow between fighting battles and then unlocking/buying upgrades

• we discussed a little more about the visual style of the game: musically stylized modern society

• we discussed technical concerns over possible duration of notes, the viability different ways of approaching sixteenth notes, and how Unity would handle the sounds

• we discussed multiplayer again, how involved we might want it to be, and what we would want to get out of it

• up until this point we've come up with three possibilities for multiplayer: 1) a boss battle where players would each control and compose for one instrument, 2) players taking turns composing a sequence and then facing a monster, and 3) purely an online community to share user generated sequences

• we also then discussed the multiplayer possibility of players being able to create monsters to influence other player compositions via fighting the monsters, and the viability of this taking place in real-time or creating offline presets

• looking towards B Term a new meeting time has still yet to be determined

• at the end of B Term we should have a fully playable version of the game incorporating as many flushed out elements as possible
  

Updated Monster Idea List

These are just the ideas I listed in our last meeting of the term.

• monster that causes fog, either across the whole battlefield or just in an area around it
• monster that, once defeated, spawns two smaller monsters that rush towards the player
• monster that randomly plugs a wind instrument for a short time
• a microphone (or mime?) monster that requires one of the players instrument slots to have no pattern playing
• monster who's speed depends on how many notes are in a given patter (more notes = faster and vice versa)
• "magician" monster that temporarily melds two of the players instruments together, reducing the effectiveness of both
• a shape shifting monster that the player must determine its true identity in order to defeat it more efficiently
  

Weekly Progress

This is a little late; we've already had our last meeting for the term, so I'll use this opportunity to reflect on what we've accomplished so far.

The original concept for the game was a bit different from where we stand now (see Original Concept Document). We've mostly kept the general ideas and three different "modes", but we've significantly altered the concept for "Battle mode". The original concept for this feature called for a system where players would be matched against eachother, each with a musical composition. The compositions would be scored/judged/voted on by members of a (presumably online) community, which would determine the winner. This concept centered around being more of a composition tool rather than a game.

Before we expanded on/modified our concept of Battle mode, we asked ourselves if there were ways in which to rate "good" music using computer logic so as to have the game determine the player's sucess instead of other people. Unfortunately this is somewhat of a complex field of research, and there doesn't seem to be any feasible solution, which is probably why the original concept used people. From there we weren't entirely sure where to go; and then someone mentioned having the player fighting back hordes of monsters using music, and this idea sort of just became the general concept behind Battle mode. And so, we focused on this aspect of the design for most of the term. I think the appeal of this decision was that it made the project feel like more of an actual game, and not just a musician's tool.

Throughout the rest of the term we came up with a lot of ideas: Monsters approach a line of the player's instrumentalists, the player must compose patterns to defeat the monsters, monsters will have different attributes that determine how the player must respond to them and could possibly be used to guide the player to compose something that sounds good, etc... We were also originally undecided as to whether the gameplay should focus on composition or performance (real-time). It seems we decided on somewhat of a combination of both; composing patterns that the player can turn on and off while the battle plays out, and perhaps the possibility of the monsters interfering with these patterns and forcing the player to make compositional changes during the battle.

With all of these ideas, it seems impossible to try to invision just how all of these ideas would work once in a functional game. So, we decided to push forward the development of a prototype. We started off simple; just a field with line of blocks for instrumentalists and a quickly thrown together GUI to allow the player to select patterns for each of them to play. Next we added monsters that approach the player's instrumentallists from a point far off on the horizon (see Prototype Progress Screenshot). We worked on the prototype for several weeks and ultimately we added different types of monsters (eg. flying monsters, underground monsters) that needed to be defeated using specific instruments, a simple composition mode prototype, and started throwing some early art assets in. The prototype provided a good idea of how the basic gameplay would work, and from there we decided to create a more comprehensive list of monster types, as well as sketch out some ideas for the Upgrade system and to get an idea of the artistic style.

At the end of the term, we are left with lots of great ideas and a prototype that gives us a good idea of how to start creating a functional game. One of the challenges for the next term however will be deciding which of those ideas to actually start implementing, and coming up with a plan for how to do this. Overall, I think we are all pleased with the progress we have made so far, and are looking forward to actually turning our ideas into a playable and fun game.

Weekly Progress - Dylan

This week we planned on elaborating and specifying some of our game ideas. This week we decided on a few of the important issues we still hadn't addressed like the way patterns would switch, part of the way that upgrades would work, and some of the way the game would progress. We still were stuck on monster ideas and what we should do for those, so we each tried to come up with a few different ideas.

These ideas seem to have broken up into two different categories - ones that would be a fun game mechanic to play against, and ones which enforce certain musical ideas that would hopefully produce a good song. This comes down (again) to a question of whether we want the game to be a game that involves music, or an interactive composition tool that has some other unique elements to it.

My ideas mostly fit into the second group - ways we can enforce musical ideas. They are more along the lines of programmatic mechanics we can use to enforce musical ideas which could be programmed into monsters, and less along the lines of monster concepts with a defined character.

You can look at my ideas here.

Weekly Progress - Rob

This week i worked with Joey to put together a better idea of the overall visual style of the game and the world it takes place in. I also worked on coming up with possible ideas for higher level monster types or dynamics as well as possible unlockable upgrades that directly benefit or boost the player. Examples include monsters that become resistant to the most dominantly used instrument over time, monters that, upon death, release smaller monsters that rush towards the player, as well as the player being able to unlock and upgrade a conductor which increases damage.

Weekly Progress and Monster Ideas (10/13/10)

This week, Rob and I finally began to hammer out a more solid idea of what we want this game to look like. We have in mind a world similar to what we see in this day and age, except that the environment is full of musical imagery. Landmarks may include piano buildings, trees that look like organ pipes, trumpet cars, and tuba fire hydrants. This is going to be done in a cartoony style with a lot of bright colors, and the main characters will be humanoid in appearance. Most likely, the players will be young adults, dressed in a style of clothing that represents their instrument (For example, if one were a pianist, he might be dressed in a tuxedo, like a concert pianist.). Rob led me to this game called "Home Run in Berzerk Land" as a possible color reference.

Each of us was also supposed to come up with a few different ideas for monster variations. So, here are some I have thought of.
"Bomb": This enemy cannot be destroyed by your instruments. He sits in the back waiting to be activated by an instrument (possibly guitar). Once activated, he marches forward. After a couple of measures, he is supposed to reach the players and explode, destroying himself and dealing heavy damage to all players. He can be held off, however, by the beat of the drum, which slows him down. He will still explode a few measures after activation, but as long as he isn't near the players, they suffer no damage.
"Flamingo": This enemy normally struts along the ground, so the guitar's lightning that should hurt her is ineffective. You must first shake the ground up with your bass or drum to encourage this beast to fly. Once she is off the ground, lightning shuts her down.
"Flame": We started to discuss putting horns or woodwind instruments into the game that blast out strong winds. Fiery enemies like this could be extinguished or even vanquished. Otherwise, the roaring flames drown out other sound.
"Mini-Golem": This enemy throws rocks at you from a distance to hurt you. They are protected by a shield, usually, but if you smack them with their own rock by deflecting it with wind, then they will be briefly stunned. Then, you can wail on him to destroy him.
"Wizard": A rather difficult foe to beat. This monster throws fireballs at the band from a distance. These fireballs can not only damage you, but they absorb much of the sound you can play. Snuff the flames out quickly with wind to lower his defenses. After casting his magic a few times, he may forget to close his cape and leave himself open to attack. Any instrument can do some damage to him, but he suffers a lot from hearing 4-note chords (1st, 3rd, 5th, and 8th notes of a key) being played. If he isn't vanquished quickly, he'll reseal himself and restart his routine.
"Rising Wedgehead": This enemy takes about equal damage from all instruments, but he is beaten more quickly if the notes being played go up their respective scale. (Do Re Mi...)
"Falling Wedgehead": The opposite of his rising brother, this enemy is driven off when the players play down the scale. (Do Ti La So...)
"Flying Electromagnet": As long as one of this enemies exist, all lightning strikes from the guitars hit this enemy instead, and he takes no damage from the lightning. They usually appear with swarms of flying or aquatic foes. They self-destruct if shaken too much, but since they fly initially, bass lines won't strike them until the wind or drums can knock them down.
"Screamer": Fast-moving flying monsters that let ultrasonic blasts out of their mouths. These blasts do no direct damage, but they can disrupt your song by screwing up a note of any instrument. They are not very tough, but missing them completely may end up trashing your tunes.
"Sidewalk": These crablike foes move quickly toward guitar and bass players in an attempt to cut the strings of their instruments. They attack these ones because they wish to stop the sounds that they make. They can dodge lightning and quakes as long as there is no drum slowing them down.

Just examples we might be able to work with. These don't even have to be the names.

Instrument / Game Design Ideas

After brainstorming about instrument ideas and the upgrade mode, I came up with a couple suggestions. First, instruments could be divided into seven complexity levels, and four different types: woodwind, brass, percussion, and string. As you progress through the game you can upgrade your instruments into higher level forms, which deal more damage or have extra effects. For example, every instrument starts out as a level 1 "Two sticks," which can be banged together but ultimately are not very useful. Once the user completes a certain criteria they will be able to upgrade the instrument, either into a simple drum or a bottle, both level 2. The simple drum can then be upgraded into various string and percussive instruments, and the bottle can be upgraded into woodwind and brass instruments. In this way, the upgrade system for instruments works similarly to a binary tree, although obviously it will need to be contained to prevent the need for 2^7 separate instruments. The way I see it, levels 1-3 will contain simple instruments that are easy to compose for; levels 4-5 will give the player lots of options without giving them full control, and levels 6-7 will theoretically allow the player to compose whatever they want. Higher level instruments will probably have more abilities; possibly level 6 instruments would have 2x capability, meaning they would be able to subdivide 16th notes, and level 7 would be able to subdivide 32nd notes (4x). Also, the way I see it level 6 instruments will represent the highest quality instruments available today, and level 7 will be imaginary / ancient / futuristic instruments that can be brainstormed as a group. Let me know what you guys think of these ideas at the meeting tomorrow.

MQP Meeting 10/7 Notes

Here are the notes from our weekly meeting with Professors Rosenstock and Finkel.


Firstly, the time for our next meeting will again be at 1:00PM on Thursday in the same room (FL 141)

• Dylan worked on putting together the prototype for composition mode

• Unity Pro is definitely going to happen (potentially on all machines in the IMGD lab

• We discussed the issue of switching patterns in real time during battle mode; how they would be handled, limitations on patterns, connections between patterns and specific character avatars

• We discussed how to implement greater monster requirements and other parameters in order to influence how the player mus compose patterns such as fatigue and an overall narrative to a battle

• We discussed potential methods we could show off monster/character models

• We briefly discussed issues such as how to organize a large number of patters, the set up of the composition mode as well as how upgrades work for instruments
  

• Moving forward we should all play the prototype in order to get a sense for the game and figure out what's fun, not fun, and what could be expanded upon

• Figure out a list of monster mechanics and requirements we like

• Art needs to put together a codified art pitch

• Flesh out the upgrade system, it's scope, and how we can get there (what the game will look like in the beginning, middle, and end)

Weekly Progress (10/06/10)

I think we have finally settled on an art style for the game. We do want to do a more cartoony style and implement monsters that have different "musical forms" implemented in their bodies. Rob and I seem to be taking this train of thought a little differently, but it still achieves a similar effect (or at least, it should).

This week, I designed two models and sent them out to the team. One is a mole that the player must pop out of the ground by playing bass. Though the model doesn't bear them yet, my idea for the mole is to give him music-note glasses. The other model is a bird. I don't think we've totally finalized how to beat the birds yet. Either it gets struck by lightning from the guitar, or (and this is just a thought) it gets spun around by air blown by a saxophone or some other woodwind instrument.

Weekly Progress - Rob

In our meeting monday we discussed other monsters and more diverse requirements that could be implemented into the prototype. Joey and myself took on the task of creating 2 monsters each that would have more stringent requirements for death in order to demonstrate a more complex battle mode dynamic. The two monsters i focused on creating this week were a drum monster, which would be more sensitive to the drums instrument, and a keyboard monster would would be sensitive to either keyboard or piano.

Weekly Progress

Work on the prototype continues. As Dylan already mentioned, he is working on the composition mode while I am implementing additiona types of monsters. There are now monsters that tunnel underground and must be forced out of the ground by a bass instrument before they can be dammaged, and flying monsters that must be knocked out of the sky by a guitar. More types should be easier to impliment now too.

Hopefully by Thursday's meeting we will have a combined version with composition mode and more monsters, as well as the additional art.

Weekly Progress

This week I worked on more of the prototyping. This weeks goals were to integrate some composition and new monster types. We met Monday to talk about ideas for monsters and came up with a few different ideas we could try to prototype this week. Kyle and I decided to split up these two sections of programming - he took the monster implementation and I took the composition segment.

I implemented a new control which is a simple sequencer based off of what I had before in earlier prototypes. I entirely rewrote it so it would be usable as a control instead of just a level. This way we can open one at any point during the game and create a pattern. I added the ability to change what instrument it is playing in (and therefore which it gets saved as, though any instrument can play it back with the current implementation anyway).

I added this sequencer control in a new 'composition' level and added the ability for the player to save the pattern they create with a name that they give. This data is stored into a manager that I wrote. There is a button to go to the battle mode, and all the patterns they have saved are added to the available choices for each instrumentalist they have. This way the player can write one, test it out, and go back and write another. (There is a button in battle mode to go back to composition, but I don't have an example of writing it during the battle mode. With the way the new control is written, it'll be very little extra work, but I wanted to discuss how we think that should be done.)

I also added the ability to switch what instrument is being played at each of the spots as a simple implementation of the player changing units during the game. This will be important for the new monster implementations.


Kyle is working on the monster implementations, but since we are working in parallel, this is not in this version. I will try to merge our two versions together Wednesday night or Thursday morning, but I'm busy this evening so I can't get it done by tonights 10 pm blog post deadline. Hopefully that should be there by the meeting Thursday though.

My version is playable here: Composition Prototype

MQP Meeting 9/30 Notes

Here are the notes from our weekly meeting with Professors Rosenstock and Finkel.


Firstly, the time for our next meeting has changed to 1:00PM on Thursday in the same room (FL 141)

• We discussed the game prototype that has so far been put together, specifically what else we might want to test or implement, specific requirements to defeat monsters, as well as visual cues or design styles of the monsters themselves to communicate how to defeat them

• We discussed trying to be more creative in how we might want to remove monsters from the playing field

• We discussed technical concerns, such as the question of dragging notes, tempo (concerning note length), and note limitations

• Professor Rosenstock expressed concern over characters and monsters potentially having to animate to different tempos.

• We also discussed Unity 3; Dylan had looked at it and said it has a real debugging mode, has some different sound effects, and improved web player performance, but other than that nothing else that would dramatically affect our game

• There was a general consensus that we should keep moving forward with building on the prototype (as opposed to working on the tech doc), specifically differentiating monsters, a composition mode, and potential GUI and other interface art

• It was also suggested to put together a list of potential design aspects as well as solutions to implementing them such as how to manage patterns, switching out instruments during battle, transferring compositions across multiple instruments, and reading .wav files to determine pitch and or rhythm to attack monsters

• Professor Rosenstock wanted the artists to develop a consistent art style including visuals, color palettes, visual world, etc., as well as designing monsters that have more complex death requirements

• At the very end we also briefly discussed concerns over using Dropbox, whether we might have to just try it, or whether the Pro version of Unity will eventually become an option

And finally, just as a reminder, the time for our next meeting has changed to 1:00PM on Thursday in the same room (FL 141)

Weekly Progress (Sept. 29)

This week, I started working on some rough 3d models to use in the game. The monster has been implemented into the prototype posted earlier. I'll continue working on other models as needed (and on my own).

For some reason, I cannot post my drawings on this blog. Instead, I have put them up on a website where I put some of my artwork occasionally. Have a look.

www. storm-artists. net/ view/ 98021

www. storm-artists. net/ view/ 98022

Comments?

Weekly Progress - Rob

This week I worked on putting together a low poly model that would represent the players animated, instrument playing avatars or potential zombie monsters as part of our first-playable prototype.

Weekly Progress

Over the weekend, Unity 3 was released. We had been hoping for this to happen before we started working on this project, because of a few advantages that it would bring us. I looked into the new features that Unity 3 brings, and tried to figure out what might help us and where. Among other things, improvements were made to the debugging and the audio engine, both of which are pretty important to our project.

This week we were also tasked with an initial prototype of the game in order to allow us to test out some of our game ideas and aid us in our decision making process. I spent a good deal of time, and managed to come up with a 'first playable version' of sorts. There is placeholder art everywhere, but the simplest mechanics are down.

The player has 5 cubes at the bottom of the screen, which represent his current 5 instrumentalists. Their instruments are labeled below them. Each one has 4 patterns which they can play (which are the same rhythms across all instruments). The one labeled "Pattern 0" is empty, representing the instrument not playing anything. The user can click on each of the patterns and the instrumentalist will start playing it.

As soon as the game starts, monsters (Joey's Chordcat model) spawn at the white cube in the back. They rush towards the player. If a monster touches the white plane in front of the player, that monster dies and the player loses 1 health (shown at the top). If the players health reaches zero they "lose". For now monsters keep coming, mostly for testing purposes. The player can click a button in the top left to reset the monsters and their health.

To stop the monsters, the player must select patterns for their instruments. Whenever one of the Bass Drums play a note, the monsters are slowed to half their movement speed for 1 second. Whenever one of the Snare Drums play a note, all the monsters take 1 damage. Whenever the Synthesizer plays a note, the monsters take 2 damage. Each monster has 10 health, and a new monster is spawned every half second.

The prototype can be played Here

Weekly Progress

As we still haven't been able to really iron out the details of the game, we've decided to go ahead and make a prototype before doing the tech design docs. So far we have a couple of blocks representing the player's instrumentalists aranged on a plane and a spherical monster that moves towards them. A simple UI with buttons under the instrumentalists allows the player to toggle patterns of notes with some simple sound clips. I'm currently working on implementing a system to damage the monsters when a note is played. Unfortunately as we already discussed at the beginning of the term, the issue of the two of us tech guys working on the Unity project individually seems like it could be problematic. However, I'm sure we'll be able to figure it out.

MQP Meeting 9/23 Notes

Here are the notes from our weekly meeting with Professors Rosenstock and Finkel. Sorry for it taking a while for me to put these up.

• We went over both mine and Joey's concept art and discussed what we liked, possibly alterations, and ultimately what art direction/style we would want to take (what feeling we want to get from it)

• Professor Rosenstock brought up the possibility of having to complete other challenges such as creating weather or breaking down walls in addition to fighting monsters

• Kyle brought up some software that is able to analyze a given piece of music and is able to report back on things such as temp, key, but nothing as far as being able to judge creativity (perhaps it doesn't even matter)

• We presented and discussed our most flushed out design concept and focused on what things we might still be missing or hadn't thought of yet; these include potential background tracks, looping, the point of view, and potentially fixing sequences on the fly

• Professor Finkel suggested we try to put together a first playable version so we can judge how everything looks on screen, if we like how it works, and to get a basic sense of the battle mode game mechanic

• We also discussed Brian's idea that a person can compose a song, which is then turned into a monster, and in order to defeat the monster a player must compose something similar to the original composition which created the monster to begin with

• We discussed potential GUI ideas, how to address not durations (MIDI in Unity), possible in game instrument limitations, having preset compositions for instruments, and having specific art assets to correspond with specific musical sequences

• Kyle described his Task Objects & Actions agenda item

• NEXT MILESTONE: creating low-level, placeholder art assets as well as basic GUI elements in order to put together a playable, interactive demo
  

Concept Art

We've come to an agreement that we want to implement monsters attacking from a distance and using music to fight them off. Because of this, I drew up some concept art of the monsters this week. Unfortunately, I've been trying to upload some pictures and failing to do so due to technical difficulties. Somehow, I will get the pictures I scanned up here (and maybe rescan them for better quality) at some point.

The pictures I drew come in two different styles:
A.) Monsters made of symbols you would find in sheet music with odd markings on their bodies. They are supposed to be more monstrous.
B.) Monsters that look like cartoony versions of creatures we see in real life. Their bodies are adorned with various symbols from sheet music.

According to the milestones, it looks like I have to start on models this week. So, which direction do we go in?

Weekly Progress

This week we worked on possible designs for the user interface, while at the same time continuing to flesh out the concept. We came up with a lot of good ideas, and it's prooving difficult to chose which ones to go with. The UI design will depend a lot on certain design decisions; for example, wether we aim for more of a compositional tool or focus on real-time performance aspects. Because we have still not settled on just one idea, figuring out what the UI will look like is tough, so I decided to try a more technical approach. I created a quick list of task objects and task actions which fit to the general ideas that we seem to be leaning towards.

Task Objects:

1. Instrument

• Unit(s)
• ??

2. Pattern

• Notes
• Units/Instruments
• ??

3. Monster

• Type/Weakness
• Spead?
• ??

4. ???

Task Actions:

1. Compose
Objects:

• Instrument(s)
• Pattern(s)

Actions:

• Create patterns by selecting instruments and notes for them to play

2. Perform
Objects:

• Pattern(s)
• Monster(s)

Actions:

• Select patterns to perform to appease/weaken monsters
• Create good sounding music

3. ???

One of the things me and Dylan also looked into was a possible metric or algorithm for scoring "good" music. We came up with some possible ideas for scoring how well the user is able to follow certain criteria, but it is still difficult to score creativity which might break the rules but still sound good. This is something we will certainly have to keep in mind throughout this project.