I made a multi line writer for outputting stuff to the screen. I tried to copy off God's code, but it unfortunately was pretty rough. God thinks readability is overrated. Anyways, it doesn't actually seem like that hard of a thing, and it isn't, except for one thing..

The friggin newline character! aka: \n

I can't figure out why, but it won't register these buggers. When it parses in the xml files, though, it seems to add in a bunch of \r and \n tags at every carriage return, which is weird that it'd do both… anyways, it sees the \r tags and does a carriage return, but it simply doesn't seem to see the \n character anywhere. I actually added a case statement to alert me if it saw them, but I've gotten nothing.

And yet, because the \n chars are there, they're mucking up the output from the writer. There may be another error (some off by 1 thing) that I can fix, but until I can get rid of these phantom \n chars, it's too hard to figure out. Any ideas?

If you've been in the music lab or the zykatorium (that's my spelling and I'm sticking to it!), you may have noticed that the zyk doesn't really transform correctly. Mostly, it's because the UpdateTransforms method seems to like working with the incremental changes that are handed each game cycle in the lab or zykatorium. However, I'm not sure how to modify the Zyk model from the original attribute input. So, for example, even though I hand a totally maxed out Zyk in, it looks like a pip-squeak in the lab because it doesn't update the model. It does once you enter the level, but I can't seem to figure out how to achieve this transform for the TestZyk. Gordon, can you help me out here? Thanks!

• Main lab console image (for the "computer that you're working at" that everything goes on)
  • Should not take up over 1/4 to 1/3 vertically of screen… sorta like what is used now for temp console
• Keyboard
  • I envisioned a keyboard "computer screen" this fits the glowy hilights on the keys, but the one you have now is more physical. Your call as to what you want.
  • It will probably be easier to hilight in the image itself which keys are "pressable", so can you do a major/minor version, kinda like on the site, at least with two separate images?
  • Hilight "patch" that appears on a key while it is pressed. Again, you call here, but just some thing to put on top of a pressable key when it's down, so you'll have not just the regular pressable hilight, but an actual "'pressed" hilight on top. Does that make sense to you?
• Menu button: again, as you see fit to put it in, whether you want it separate from the console, or integrated somehow
• Menu interface screen/image
  • Back to lab button (Zyk loses traits from lab, so we'll have confirmation box for this too)
  • Actually, that's all I can think of for the menu right now… so maybe the back to lab will just become part of the console? Maybe, unless you can think of more needed menu items needed?
• Start playing button
  • Normal state
  • Mouse hover state
  • Pressed state
  • Disabled state (grayed out/light off/whatever)
• Stop playing button
  • Normal state
  • mouse hover state
  • pressed state
  • disabled state (grayed out/light off/whatever)
• Clear song button (if they want to retry the sequence. we're allowing that, right?). Once they clear input, the start playing button is enabled again. This prevents their accidentally pressing the (probably) larger big green start input button by accident.
  • Normal state
  • mouse hover state
  • pressed state
  • disabled state (grayed out/light off/whatever)
• Button for accepting the song and attributes and moving onto the level
  • right hand side of screen somewhere on the console?
  • i guess maybe "Accept Changes" or something, maybe blue? your call. Whatever seems to make sense to you as "I'm done playing… now let's use those changes and go onto the level"
  • Normal state
  • mouse hover state
  • pressed state
  • disabled state (same as others)
• Change theme button: Brings up a special mini console where player can put in a new theme for the Zyk. remember that playing the theme is now the new patterns, since those didn't really work out… so your Zyk will have his theme that you can change, and playing it in the actual song increases your toughness. The theme input is timed… maybe like 5 seconds long?
• Change theme console
  • Start input button (can be miniversion of main start song)
  • Playback button (to hear the theme after they play it to be sure they like it)
  • Accept new theme button
  • Cancel button (keeps old theme)
  • All buttons with normal, hover, pressed, disabled state like other buttons
• Access to memos button(maybe just like a random tablet lying on console?)
  • normal, hover, pressed, disabled states like other buttons (though maybe this won't have disabled and will be always available)
• Memos: Though I think Melissa is doing this interface…. right?
• Song progress bar: maybe just some sort of transparent glasslike reflection case for going over those green and red progress bars to make them seem less like a growing green rectangle and more like a scientific meter
• Space somewhere to indicate current tonality (major/minor) and key so they can understand why the core traits get a boost and why their zyk is a certain color (maybe this can go in the x-ray bg?).

Ok, that's all I can think of now! Remember to not hesitate to add.

Also, remember that every clickable button can have 4 states: normal for just when it's there, hover for when the mouse is over it, pressed for when the mouse is clicking it, and disabled for when it can't be clicked.

I guess my vision of the lab was not that it would be a game UI, but rather an actually physical lab console, as though you were at the controls looking at this Zyk in the lab… if that's not how you see it, well… I'm at no liberty to stop you, since you're the artist :). Do it as you see it best. Just bear in mind that that was how I see it as I'm giving you the required art pieces.

Do any of you guys know how to draw just a part of an image, like what you would do to draw an animation where you just want to draw a small part of the whole texture?

Seriously, though… I'm finding that the "console" style UI where the keyboard, zyk "growth" image, menu, and other stuff is getting kinda bulky and blah. So… I wanted to ask what ye artists think of this.

Instead of having the zyk's growth picture on the console, it's on a screen BEHIND the zyk himself. If you don't know what it is yet, I'm envisioning it as kind a Zyk x-ray… sorta like the thing you'd see in some athletics lab. It shows the 8 growth areas for your zyk, segmenting the zyk skeleton into 6 parts for most of the traits, then 2 more boxes for size and transparency levels. As you play, the screen displays either "+" or "-" over its part to indicate whether it is growing or shrinking. And, when you reach a level for a trait, it indicates this with the expected pizzaz, then ticks up the level counter for that part of the Zyk.

A picture is worth a thousand words, but unfortunately, I cna't really do that. Instead, you'll see the programmer art version with VERY little detail and most of what I just described missing in the game now.

But I wanted to know if you guys think that works. I personally like it better than the image on the console, which feels "game-y" and not very "lab-y". I think this way is nice also because it keeps your visual focus in the center of the screen… on the zyk, and the attribute rises and falls on the "screen" in back of him.

In any case, who would be up to making that image? :) That's the real question.

This by itself is hilariously fun and awesome, as we've inadvertently forced the player to bang their keyboard very quickly and continously, which makes sense for speed.

However, it leaves the slow style with long notes as not a very smart move. Would we want to modify sneakiness to be based not off the ratio of rests to notes as we have it now, but rather, being the opposite of speedy notes, on the average note length? In other words, speed is based on the inverse note length: short = more speed, but sneakiness would be based on note length itself: long = more sneakiness. Right now, silent = more sneaky.

Or do we think it's fine as it is? Maybe it's not the worst thing to have slow notes be bad. But you'll just basically be choosing between fast and lots of notes, or slow and I guess, of the ones you do have, slow notes. Input?

Kevin/Gordon/Sascha… I'm not sure what you did, but the game game runs just fine on my computer now…probably also Chelsea's too then… silky smooth. Sascha said he thinks that it might have been that darn dice texture, but who knows. Point is, don't try to fix it, because it runs nicely now. Excellent stuff!

ZYK
Walk/Run
Jump/Fly
Attack
Swim
Idle
Fiercify
((((stop here and do 1st three enemies))))
Bouncing/Grooving animation for Music Lab
Irritated animation for Music Lab
Shove (Successful and not)
Fall
Being Attacked
Death

Iyabol
Bouncing
Attacking
Death

Upalok
Idle (just have eyes move back and forth)
Attack
Death

Nurran
Idle
Spinning
Death

Kinsin
Idle
Death

Slohta
Idle (or just you know the model)
Death

Sulger
Idle
Run/Bash
Fall over/dizzy/out of it.

Everytime I press a key in the musiclab I get this LoaderLock error and it hangs. :(

LoaderLock Detected:
Attempting managed execution inside OS Loader lock. Do not attempt to run managed code inside a DllMain or image initialization function since doing so can cause the application to hang.

Since the bug for whatever reason seems to be occurring more often that I can't run the game at all and must just keep trying again and again until it does run with PreferMultiSampling set to true, this is kinda a bit of a problem… is it happening to anybody else?

Basically, I think it might be a good idea if we make the input restricted to ONE note per note spot at this time. This of course does not apply to chords, which would still be three, but both gameplay and code-wise, I think saying that you can play one chord and 1 note at a time seems right… it restricts the user, yes, and I hope to eventually be able to turn off this restriction, but it does so at the benefit of having a more direct interplay between playing and Zyk transformation. When there is only 1 note per spot, then the player knows exactly what is occurring and why. With multiple, she is unsure of what effects are being applied for each note that she inputs. Additionally, pattern recognition might be a bit of a nightmare with more than one, as is interval recognition to a lesser extent.

Additionally, as I observed Chelsea and others play, it seems that we want two pieces: chords and melody. Melody can be a single note at a time. More than that and you're incorporating harmony or other factors in, but what we want to do is analyze their MELODY playing. So if we allow only one note at a time (btw… I'm still not sure if that means one note on at a time or one note starting on at a time), we are forcing the player to create a melody and experiment with the melody and not just pressing keys.

On the other hand, maybe this is just my opinion. I'm interested in letting the average person play, and be able to see how what their playing changes the game. I feel that as you allow more complex music, the relationship between keyboard input and Zyk attributes grows a bit foggy and they may be left wondering what it is that they're doing wrong.

So what exactly do the roman numerals on the chord hotkeys mean? Distance from the tonic? Something else?

This one basically is input related. We have the current keyboard input as just the middle row of keys. The notes they actually play depends on your key and tonality (major/minor). While the actual key doesn't particularly matter here, as any notes can be transposed based on a base note easily, the difficulty for implementing the "out of key" keyboard keys (this is getting confusing…) is that they can work logically for major or minor, but not both. Because the tonality changes the actual steps from one middle row key to the next middle row key, we can't logically place the fierce, out of key keys in the above row (the "qwerty" row). Think about it… we can't have a direct "black key" correspondence if we have minor keys, since minor keys use the black keys… so what does that make the out of key part then? So basically, we've gotta figure how to make major/minor keyboard mapping work nicely with out of key keyboard mapping.

on another note, there has to be a synonym for "key" in the sense of those little plastic things you click on your computer. The word "overloading" driving me nuts :)

If I close VS and start it up again, this often helps, though the problem seems to be coming back more often now.

Would anybody know what changed to cause this?

Question I have is what exactly the note interval is. When we say note interval, are we talking about the difference in pitch between notes in sequence, or notes played at the same time? Aka… are we testing for differences between notes played simultaneously, in the same note spot, or notes played one after the other? I thought it was sequential, notes played one after the other, but I may be wrong.

Additionally, how are we handling multiple notes? It is obvious what to do when there is 1 note played at a time, so that there/ is only one interval. However, what do we do when we have multiple notes? Do we take the largest interval between any two notes? The smallest? An average of the interval between each and every notes (as in, if there are 3 notes per spot, you'll have 9 note intervals to average, with each of the 3 earlier notes paired once with each of the 3 later? Or maybe try our best to pair up the closest notes or farthest notes between each spot and use those averages? Bit of a tizzy, I'll admit.

I think the codebase needs a bit of tweaking with regards to the how Zyk color is handled in the ZykAttributes class. Apart from the fact that there need to be more colors than are listed, I am confused as to the purpose of the "darkColor" flag. As far as I understand it, the Zyk will have a lighter color if a major key is used, and a darker color if the minor key is used, so why is there a flag instead of a more complex system?

-Sascha

If it just stays cosmetic, here's a fun idea… allow the user to change key while playing, and then modify his color in real time as well… rather than just assign beforehand… of course the way I've structured the code now, this would only be able to occur on section boundaries, but hey tell me if you think it's any good.

Does anybody see some sort of encapsulation problem with putting it in util instead of keeping it privately within MusicMonsters?

So what exactly are we going for with the real time transform… will the Zyk be transformed his total amount during the whole song? As in, will he be entirely transformed based on the music that has been input SO FAR, so that even after the very first note, he changes a whole 1/15th from his previous state? Then, he continues morphing while the player keeps on putting in music. This kinda goes back to the whole "let them just sit there and tune it til they like it" method since it's not really about building him up each song… it's about mooshing him around til you like it each song.

That'd be my solution… but again that brings the question of why the minute long song? Why not just divide up into 4 to 10 measure brackets, so that analysis occurs within several measures. Then feedback is faster and more apparent, and avoids possible boredom late in the song (in the 1 minute version, it will become more and more difficult to adjust settings after many notes have been played, since most stats are average based). With so many notes already in one direction, the player simply must bang the keys more and more to get it any other way, and they can just try over anyways if they really wanted to.

In short, I'm once again suggesting that we switch back to a shorter sound input time, to keep the player concentrated on the short music section that they create.

Also, I figured the sort of non-linear progression should work as such

Level …..Amount
1……………1
2……………3
3……………6
4…………..10
5…………..15

Has anyone figured out how to place items in the code that are only compiled in debug mode? It's accomplished via preprocessor directives in C++, but I don't think you can use the same method in C#, and a quick search doesn't reveal too much in the way of help.

I think I have something awful like 2003.

This gives you the basic rundown of how xml commenting works in c#. But mostly what you need to know is to place "///" before a member of a class to get the automatic tags. <summary> and <param> are pretty self explanatory. Use <remarks> at the top of classes instead of <summary>.

That's about all there is to it.

 b = b + 10 //b is a byte 

…doesn't fly. Compiler error. So… I says to myself I says… well I'll just overload the "+" operator for byte and integer args. No such luck. I tried to do it in the util.cs file. It seems that you can't just do that with integral types for both args. One parameter at least must be a class. Is this normally the case with other languages as well? And anybody see a way around this? It's not critical, but I'm looking to avoid massive amounts of explicit casting that will clutter up the code. Here is the failed method.

 //C# doesn't allow implicit byte operations //such as "b = b + 10" where b is a byte. Used in MIDI data public static byte operator+(byte a, int b) { int c = (int)(a) + b; if (c > 255) throw OverflowException("The requested byte addition was over 255"); else if (c < 0) throw OverflowException("The requested byte addition was less than 0"); return (byte) c; } 

The error was "One of the parameters of a binary operator must be the containing type". It would seem that this could work if I could add the overload to the "Byte" class… C# uses actual objects for each integral type… so things like "int" are just shortnames for the actual objects. However, you can't mess with that stuff for obvious reasons.

* corresponds to the average interval between notes
* expressed by size of fangs
"

So the major attribute of the attack corresponds to… how great the rests are? As in… greater rests equals more ferocity… or vice versa? Does this mean note density eseentially?

EDIT: Also…

"
Attitude (determines core statistics for a Zyk)

* corresponds to minor vs. major key
* expressed by the Zyk’s facial expression (major=upbeat, minor=mellow)
"

What exactly are "core statistics". It's a bit vague.

Tiling
Paralaxing
Zooming
Morphing
Textures

http://blogs.msdn.com/garykac/articles/732007.aspx

Go to there to learn how to use it. The code is on the SVN site as well as demos. You may not actually need to make the font yourself (which is fairly easy), but using them is probably something we'll all do, so be sure you know how.

http://www.codeproject.com/cs/media/MIDIToolkit.asp#StateMachineToolkit

It seems to offer what we need, though I'm not sure if it will allow keyboard midi input… in fact midi input in general is still a mystery to me. Another one with less documentation:

http://www.gotdotnet.com/community/usersamples/details.aspx?sampleguid=89cde290-5580-40bf-90d2-5754b2e8137c

Seems more basic, but as I said, not too much doc. I'll ask the creators if they mind our using their work soon if one of these shows promise, or hey maybe we'll use something else entirely, or just use built in c#… tell me what you think.

-Means of taking in MIDI data from a file
-Means of taking in MIDI data from a com-keyboard
-Algorithms for analyzying MIDI data
-GUI for inputing MIDI data/viewing creature
-GUI for field study part of game
-Overworld Maps or "Some Sort Of Navigation Between Levels"
-Menus all over
-State Machine to flip between Menus, Training, Field Study, etc. parts of game
-Concept drawings for setting
-Concept drawings for monsters
-Concept drawings for items
-Wireframe of Zyk
-Models for finalized concepts
Decision on type of art
-Program to warp Zyk wireframe or morph one into another
-Level editor
-Level design
-Setting up faux-3D camera/environment
-Manual
-Website (does this work? This should work…)

Is there some way to make this a sticky? Because it will be fun to strike through these things as we get them finished :D Oh and please add more. This was just things I could come up with real quick like.