Rather than the traditional object-oriented design paradigm, Unity uses what is known as a component-based architecture.  What does that mean?  The common answer is that in object-oriented programming, objects have an X ‘is a’ Y relationship, whereas component-based architecture invokes a X ‘has a’ Y relationship.  It means that instead of each object in Unity being the child of a child of a child, with the root class being the most generic category and each sub-class extending the functionality of it’s parent classes, objects in Unity start out as the most generic class, and then are given specific attributes, or components, which govern how they act.  So where a ‘kitten’ object in an OOP setting might be implemented by this hierarchy:

Animal -> Four Legged -> Cat -> Kitten

that kitten in a component based architecture would be:

Cat : contains Generic Animal behavior, Four Legged behaviour, Cat behaviour, and Young Animal behaviour.

After learning OOP nearly exclusively in college, this can be a little hard to get your head around.  I mean, it lacks a neat structure, and especially in Unity, where each GameObject would naturally map to one OOP object, it’s difficult to start thinking differently.  For instance, it was frustrating to me, having only learned OOP, to try and organize my objects, since implementing GameObjects as a subclass of something else (such as making each zombie a subclass of a more general ‘enemy’ class) isn’t particularly easy to do, especially in UnityScript.  Couple this with the fact that you’re not calling functions from the object, but calling functions from object.GetComponent(Y), and it starts to really look much different from what you learned in college.

However, for game programming especially, the component model makes a TON of sense, once you make the breakthrough and grasp the core abstract concept – instead of your objects behaving based on what they are, they behave based on what functionality they need.  It’s much more a horizontal organization, and therefore harder to organize, but it makes a lot of sense when you have a lot of objects that share some features, but not others.  For instance, imagine a real-time strategy game where you have ‘hero units’, with special powers and abilities.  However, they still share the same base features as the regular units of their type.  With OOP, you might have an entirely separate class structure, with lots of duplication of features, but with components, you take your existing soldier, swap out its weapon with the hero’s weapons, add in some special ability scripts, and boom, you’re there.

Another example: You have a FPS where you can blow stuff up.  You have a zombie enemy that you want to apply damage to when it gets caught in an explosion.  All enemies in your game should take damage, so you put the ApplyDamage function into the parent class ‘Enemies’.  However, you want to implement boxes that get destroyed by explosions – do you move ApplyDamage up the hierarchy?  By the time boxes and zombies have something in common, that’s pretty high up, like maybe a ‘PhysicalObjects’ class?.  Meanwhile, you’ve also got an object, say a health pack you don’t want to be destructible – do you just give it infinite health points? Branch it off, so you have a ‘PhysicalObjects’ class with a ‘DestructibleObjects’ and ‘NondestructibleObjects’ classes?

What a mess.

With components, just have a ‘Destructable’ component, and give that component to any objects that you want to be destructible.  Too easy.

It’s a big change, though.  It means thinking about your objects in a way that seems totally backwards – instead of starting off with a super-general class and winding up with children objects that are super-specific, you start with a completely generic object and add in distinct bits that differentiate this object from every other one out there.   It loses the strict organization that OOP has, but it does have a certain aesthetic – every object is defined exactly by what it needs to do.  If an enemy is invincible, instead of a kludge where it has a million HP, or a special flag, the enemy just doesn’t get a ‘recieve damage’ script.  If some boxes and barrels contain items, just give those ones a ‘contains item’ script.

Of course, I’m just figuring this stuff out, so it’s still fresh and exciting for me.  It’s also something I never really had particularly explained to me with Unity – a lot of that is my fault; since the Unity introduction and tutorials are somewhat written for total beginners, with some programming background I wound up more or less skimming through without really internalizing what the component model meant.  Still, it’s something that took a fair bit of searching on my own, and while object fundamentals are explained, there isn’t really a section that sits you down and says, ‘Hey, Object-Oriented Programmer, this is a significantly different paradigm!”  I hope it helps anyone out there looking at getting into Unity!

www.OpenChord.org/Zombies

That’s just kinda a basic example of fundamental gameplay.  It doesn’t include what I’ve been working on this last week, which is all back-end stuff to increase the functionality of the project.  Namely:

• Transitioning cards to an SQLite database, compatible with flashcards created in the popular Anki program
• Implementing a spaced repetition algorithm, so items you learn get reviewed at longer and longer intervals, and the items you failed at show up more frequently.

It’s somewhat limited in its current state, and based on how the V1 interprets data, it’s never going to be a particularly great MIDI guitar.  In its current state, it only can produce accurate data for individually fretted notes, so using capos and chords isn’t effective for generating music.  However, since the V1 circuitry doesn’t interfere with the circuitry of the underlying instrument, it’s  a great way to provide a secondary data stream from any stringed instrument.

Possible applications include:

• Controlling stage lighting
• Controlling effect pedals
• Experimental music production

Also, remember that this is first-generation code – if there are any bugs or if you notice something acting unexpectedly, please let me know at develop@openchord.org

Of course, with the MIDI firmware, the V1 won’t be able to play with any games – you’ll have to reflash the firmware to the standard V1 code if you want that.

The code for this is in the SVN, under the Guitar Fighting branch – feel free to download it and put it on your V1. In order to update the firmware, plug the V1 into a PC while holding the red/plus button – it should show up in Windows as BootloaderHID. Then grab this program here, hit “Find Device”, then choose the appropriate .hex file, then hit upload. You should be fighting in no time!

On the good news side of things, after some re-jiggering and testing, we’ve merged the Wii and PS3 firmware!  This means that you don’t have to do a firmware update to switch between the systems anymore, and it’s going to be easier to figure out which firmware  you need.  Instead of V1_Wii.hex and V1_USB.hex series’ of binaries, they’re being replaced by the OpenChordV1.hex series.  Most people should need the 12MHz hex file, but there are still some 16 Mhz boards out there – Anyone who bought kits at PAX or since then has the 12 MHz board, but to check, if you see 16.000 on the little silver oval on the PCB, then you’ve got a 16 MHz crystal, so you’ll need the 16 MHz code.  Or send us an e-mail if you’d like a 12 MHz crystal; we’re more than happy to drop one in the mail for you, free of charge.

That said, we’re also looking at getting an oscilloscope to check out and see if we can maybe send the proper signals to the Xbox – we’ll let you know how that one goes, but judging from the seeming lack of 3rd party Chinese controllers, it doesn’t look particularly promising, unfortunately.
As a side note, if anyone is interested in having a PlayStation2 compatible guitar, let us know. It’s something that we were working on, but couldn’t figure out; however, I’m starting up a project with Kellbot, working to integrate our boards with her awesome Katamari Ball, so since I’ll be dusting off that PS2 code, I’m wondering how much effort we should be putting into getting it to work for the guitar as well?

So we changed it!  Since full 3 button chords are relatively rare in-game compared to gap chords, we’ve now made it so that to press those chords, you now have to press down all 6 strings.  Anything less, and the guitar will assume that you want a gap chord and give you that – this means that barre chords across all 6 strings will likely still give you all 3 buttons lit up, but if you make it a bit shorter, you’ll probably wind up with the gap chord you wanted.

Unfortunately, for you expert players out there, this update might make it somewhat harder to hit those 3 button chords, and it doesn’t do anything to help with chords like green/red/blue.  Those ones are a little more complicated in terms of notes being electrically connected by shared frets on the fretboard, so there might not be anything that we can do to make those easier – I’ll have to study it further.

In the meantime, the new code is available in the Binaries folder of the SVN repository on the Google Code site – get the appropriate .hex file for either the USB or the Wii version, depending on what system you’re running your games on.  If you download it, please let us know what you think about the changes, and if they help out or if they’re garbage.

It’s the sort of thing that we’ve been playing with the guitar for a while, and just got used to handling it in certain ways, and, well, just didn’t have the user testing we needed to have had.  Like all developers should know, if you made the product, you’re really in no good position to test it, since you’ve already got these images in your head as to how things are “supposed to be done” – that was like Lesson #1 in the UI design course I took in college (sorry Prof. Alvarado!).  Ironically, that being said, we haven’t really tested out this update, so if you download and play around with the new firmware, let us know how you like it!

Also, if you’re hardcore, the change itself is pretty easy to adjust in the code, so if you’re into messing with source code, grab a snapshot of our SVN and I can tell you where to mess around with this new feature.

Anyhow, thanks to everyone who played at PAX for helping us find this stuff out, and enjoy the new firmware!

The new product requires no drilling, cutting, or otherwise destructive modification to your guitar.  All you need to do is attach a few copper stickers to the fretboard of your guitar and then clip it on with the included guitar capo.

The product then turns your guitar into a video game controller just like the V1, allowing you to practice fingering, notes, and chords with guitar games for the Wii, Playstation 3, and PC.  And since the device isn’t built into a guitar, it will be significantly cheaper.

Also,  if you have any great ideas for the name, we’d love to hear them!  Shoot us a line at contact@openchord.org