So, we’re done. We’re not selling any kits anymore, and we’re shut down. Just lettin’ you know. If you’re still interested in making controllers and stuff, check out UnoJoy! - it’s my newer project that lets you make a controller using just an Arduino, which, since nobody has to buy anything new, makes everyone better off. Yay!
So, this post is as much for the world as it is to give me a chance to write things out to help me visualize things more clearly.
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!
02SepProgress Update Comments Off
So, I’ve put up a new version of the static scene game today, based in my hometown of Spokane, Washington. It’s still just shooting random zombies that come your way, but the scenery is different, and it’s a much better lead into where the game is going graphically – extensive use of free Google Maps assets to create a game where you get to play in actual locations.
You won’t really notice all that much new stuff in the gameplay; unfortunately, much of the work I’ve been doing has been related to the back-end stuff, and most of that work has been put into the database backend of the stand-alone game. However, obviously I’m starting to get new assets in, and starting to work on level design. Hopefully, this weekend will bring about a new test, one that plays much more like a first-person shooter (one that’s also much more fun…).
That said, the most easy thing to notice is the addition of new study options. If you have any lists of things you want to study, please e-mail them to firstname.lastname@example.org!
So, it’s pretty obvious that OpenChord.org is at the end of it’s life. It’s been that way for probably close to a year now, but I haven’t really had anything to update here. However, in the meantime, I’ve been working on a different project – the making of a non-music-related game. Instead, it’s a game designed to assist with memorizing flash-cards. I still don’t have a name for it, but you can try the beginnings of it here:
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:
I’ll be trying to update this blog more frequently, both as a progress report to myself and as a way to keep track of progress. If you have any ideas, please feel free to e-mail them to Alan@OpenChord.org, or leave them in the comments!
- 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.
So, I’ve been busy with non-OpenChord stuff for the last month or two, but I finally cleaned a few things up and took a video of the MIDI update in action. Like the video mentions, if you’ve already got a V1, all you have to do is download the new firmware and flash it onto your kit – instructions on how to do that are in the last post. Basically, in addition to being a kick-ass Guitar Hero controller, the OpenChord V1 is now ALSO the world’s most inexpensive MIDI guitar. Of course, like I mentioned in the last post, there are a number of limitations – only certain chords are supported (although additional chords are easy to add in the firmware, depending on what you need), and the note velocity is constant. Also, you’re not really going to be able to play with a capo. Still, there are a lot of interesting things you can do with it, and really, it’s kinda fun to play a guitar that sounds like bells!
It’s just a start for now, but if you go check out the code page, you can find working code and the binary for adding MIDI over USB functionality to the V1 guitar. All you need to do is download the binary file and then update the firmware with the .hex file, and it will then show up to your computer as V-USB-MIDI.
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 email@example.com
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.
24AugAnnouncements Comments Off
We’re back, or at least back-ish – We’ll be at the Penny Arcade Expo in Seattle, going from September 3rd through the 5th. Due to a number of factors, there’s a good chance that it’s going to be the last convention that we do, so we’re just going there and trying to have a good time.
Going along with the end of conventions, from here on out, we’re going to be donating 100% of our profits to charity – Child’s Play, to be exact.
One other quick thing to mention – we’ve added some new code to the binaries section on the Google Code page, new code that fixes a bug where the controller wasn’t being recognized by Windows Vista or Windows 7.
So I should have posted this about two weeks ago, I guess. Anyhow Maker Faire was a lot of fun, and we even won an editor’s choice ribbon, although we’re one of a number of winners (That’s just the tip of the iceberg – a 30 second Google search will reveal a lot more.. I mean, it’s appreciated and all, but the winners weren’t even mentioned on the Make Magazine blog – the prize seems to consist exclusively of a blue ribbon and a warm fuzzy feeling.)
At any rate, long story short, we were expecting to sell a whole of kits there at Maker Faire. And we didn’t. Now, I’m sure some of it is the market there, some of it is the nature of the event, some of it was our presentation, but in the end, it just didn’t seem like there was enough real interest in actually buying OpenChord guitars and kits to justify continuing with this as a commercial enterprise. There are a few things I’m looking into in terms of getting some funding (like Kickstarter) to get FCC testing and such – it seems like being able to sell full guitars might still be something more people would be interested in – but I’ve got some other stuff I’ve been working on, including other stuff that actually pays money, and so at this point, that stuff is taking priority.
I guess on a certain level, I’m a bit burnt out on the project, too. After stressing about getting a bunch of kits ready for Maker Faire that are now sitting in the basement, it’s a bit discouraging. There are still some loose ends I want to wrap up (specifically MIDI, now that the new board will support an actual MIDI hardware interface), but I’m taking a bit of a break while I do some other stuff and figure out where to go from here, if to go on at all.
I still will be doing support for any kits you’ve bought, and of course the store is still open – I’ll still be shipping out any kits or parts if you order it. In fact, although I should have done this WAY earlier as well, here are some pictures of the new May boards, with all the components in, and with all the wires in:
This is the May circuit board with all the parts in it – there are some extra spaces for things that might come in the future, and the rows of holes by the Frets and Strings ports are so you can snake your wires through them for strain-relief.
Here’s a picture with some of the wires attached. In this photo, I’ve got the wires to the strings attached to a header pin block for ease of detachment/repair (it is one of the prototypes we take to events like Maker Faire, so easy repariability is key!):
Anyhow, as always, if you need any help with your kit, or any questions, e-mail us, comment here, or whatever!
-Alan Chatham, guy behind this all
We’ve arrived at Maker Faire! Today is setup, but we did have a nice time showing off the guitar and the prototype violin this morning for the Young Maker’s day. They’ve got the Singing Tesla Coils here, so it was pretty cool to listen to them, even if the RF emissions they generate knock our guitars out of commission when they run… So while it’s exhausting (we’re staying with friends in Berkeley, and it’s like 2 hours away on the train…), it’ll be a good time!
Also, we’re on Hack-a-Day, Kotaku, and Joystiq, today, along with others – thanks for checking out the Street Fighter video! Hopefully we’ll take some videos of people here in San Francisco with the bass, guitar, and (work-in-progress) violin. Stop by if you’re in the area!
19MayAnnouncements Comments Off