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