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?

And hey, can we make the Beta Zyk grey? Because White is kinda cool :-D

It sounds like you've got a good plan pretty much figured out, so just trust your gut on that. I know we disagree on things but I think you've got a really good handle on how this should work ;).

On the other hand, do you want me to write the tutorials? Not saying that you can't do it, but did you have in mind what you're doing? The code for it kinda evolves with what you actually need to do in the tutorial, so I'll have to know what you want.

For example, the idea for tutorial levels is that the player will have to max out an attribute (to demonstrate that trait specifically) before going onto the level. The other stuff will be hidden away. This is sorta your "beta Zyk" idea resurrected (actually, it IS your beta Zyk idea, period). There'll be a white Zyk that grows way faster than normal ones, but only in the given feature. Then the player enters a very short level with a single goal that is able to be reached by having that single maxed out trait. Thus we are showing both the way to increase a trait, as well as showing its in game effect.

The tutorial text pages (I guess you've seen them at this point) will pop up on entering the tutorial level, and the user should be able to bring them back up if they want (via a new button that I'll add). The final page for each tutorial will likely be something like "I've added notes on this subject to your memo file!" or suchlike. They then can access the similar info to what's given in the tutorial in their memos, which, as we've figured, will be stuff on how to raise attributes in the lab, what each attribute means, etc.

As far as triggering memos in the game game, I"ll leave that up to the guys who are working on that half of the game.

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!

I've noticed that shifting screen resolution usually clears up this problem, so whenever I get it now I just flick down my resolution, then shift it back up, and it's been fine then every time so far. The PreferMultiSampling property has to be true, apparently, since our game gives a bunch of errors that I have no intention of working through right now if it's false :).

Thanks for the tip, though! My searches for answers online must have been oddly misplaced (wrong forum, I guess….).

Blah.

It was because you had a .png and a .PNG

I love the filler art by the way >:O Haha.

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

1. Open the project in Vis. Studio
2. Click on "Exceptions…" in the Debug menu
3. Under "Managed Debugging Assistants", uncheck Throws for LoaderLock
4. Hit OK, and everything should now work (in theory)

Post replies if this fails for anyone, and we can try something else.

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

I'm not sure what you are talking about with the infinite "Complete" loops. Could you clarify a bit here?

So essentially the chords are set to play "in key" notes that are two "in key" notes apart, am I correct? As in, the three chord notes are not a fixed value of half steps apart, but instead their separation varies with the "base note" (does the word tonic apply here?). Kinda matters as I guess if they're based only on in key notes, the separation in half steps has to be coded for each chord as it will change for each key and tonality (major/minor). Not a huge deal, but just want it right for the prototype. Let me know then.

I'm still wondering about MIDI keyboards… I'm hesitant to throw my energy into them because they will be secondary if mtvU accepts us, and plus I'm sure it'll be lots of fun to figure out how to say "no don't go to the MIDI out or anything… allow my program to read the incoming MIDI port data and I'll say what goes to the MIDI out". I think it will be doable, but it's a lot of effort that takes away from the main game itself…

But if we can interface with a MIDI keyboard, then it will be just the same as interfacing with the computer keyboard… we select what goes out and when, as opposed to just some other MIDI manager doing it for us.

Essentially, for now, since this is "technical prototype", I'm going to be trying to prove that we can have pattern recognition in our music, period, and figuring out how it fits into the MIDI keyboard is… well, can you say "summer work!"? And I'm not just saying that to say it won't happen… if this game turns out nicely I'd love to submit it to IGF as it's definitely a turn for the different, and I want it as feature complete as possible for that.

Whatever it is, iTunes seems to be part of the problem. A lot of trial and error seems to suggest that XNA and iTunes don't play nice with resources somehow or another… so just a suggestion to anybody else who is having this problem is to close itunes and c# express, then reopen just C#. It may solve the problem.

I - SFH
iii - FHK
IV - GJL
V - HK:
vi - JL"
I - L"? <—- the question mark is whatever would come next.

:)

I also think, if we want to go all out, that Z held down should be first inversion and X should be second inversion. But that's sort of a pain.

So if someone held down Z and played C they would get this:

Z+I - FHL (It's the same set of notes, it just changes which one is the base)
X+I - HL"

A first inversion has a "root" (technical term) note that is the middle note of its equivalent regular chord. So instead of SFH it would start on F, hence FHL. Etc. Do you sort of see where that's coming from?

The only issue to keep in mind is how this will work with a MIDI keyboard.

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?

We're NOT doing it so that you select "C" and then decide if you want C major or C minor, we're doing it so that you select "C,D,E,F,G,A,B" and then you decide if you want to start on "C" or if you want to start on "A". What I'd do is just activate or deactivate the subset of keys in the qwerty row you need to and work from that. The qwerty row will always be "C#,D#,F#,G#,A#" and you just put them wherever you have to put them. If they want major, you put them at ERYUI, if they choose minor, you put them at (ugh, thinking), ETYIO.

Did that make _any_ sense?

Okay, so musically the thing I want to do is called tracking voices, I don't know how feasible that is when it comes to code though. Basically the highest note would go to the highest note, the lowest to the lowest, the one in th emiddle to the one in the middle. If you had one note and then two notes, you'd take one interval (to nearest), if you had two notes to three notes, you'd take two intervals (high to high, low to low), if you had three notes, you'd take three intervals, etc. Does that clarify at all?

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

Let me know then… also, I currently have chord notes counting towards the final note count, which is funny since every chord you play contributes 3 notes but only 1 chord :) I can change that then if we don't want chord notes to count towards the note sum.

Average while it switches? I don't think that would be too hard, if by averages you mean that the key change occurs on the section boundary, and it just averages the color between them (as in, per song, you would only average as many colors as you have sections).

As for online stuff, wow… that's kinda a whole new design over what we have! That'd definitely be a major overhaul of both our technology and our game design, so don't count on having that in place, though if the game is relatively complete by May and we have nothing more to add to the core (which is hard to believe :) ), maybe that could be summer work.

Also, the colors _are_ slightly meaningful. They're arranged according to the Circle of Fifths, which is basically a god of music theory. It doesn't have gameplay applications, but it's pretty cool from a musical standpoint. And plus, if we get this thing from MTV, they're going to want more Broadband stuff, so it gives us the opportunity to add some sort of social aspect, where similarly colored Zyks would be friendlier to one another, etc.