Green-Ear: Voice for Torque
by Michael Rojas · 10/30/2008 (9:54 pm) · 13 comments
Hello All!
As with Leba (who I see you have met), this is my first blog. You can read her blog here.
My name is Mike Rojas. I am the CEO of Green-Ear, a company looking to make voice easier to incorporate into your games. As CEO, I am in charge of everything, developing, selling, managing, serving, and cleaning the office. We are very hands-on here at Green-Ear.
My background has been in software communication systems for twenty years. I had a software company prior to Green-Ear which I sold to NEC in 1998 and then ran their Advanced Communication Products Division for 4 years. To be honest, business communications was SO BORING that I was going nuts. So in 2002, I left NEC and started Ayalogic (parent company of Green-Ear) in guess what? Developing an all-software communication network and system for business! (Some people never learn).
However, in March of 2008, I got my wish - my team (and our investment group) decided that our software could do some really interesting things for games. So Green-Ear was born. We knew we wanted to serve independent studios (primarily because our competitor, Vivox - was ignoring you guys); so we formed a partnership with GarageGames and voila! - we're here.
I see it is required to include a graphic so here is one (thanks for the heads up Leba!):
Our product is made up of a client SDK (which is compiled into a library we call GearPlatformLib) and a TorqueGear object (derived from a SimObject). Once the library and TorqueGear object are compiled into Torque, everything related to Green-Ear can be controlled from TorqueScript. GarageGames has even been nice enough to allow us to include Pre-Built Green-Ear enabled Torque Engines to be included in the SDK (TGB, TGE, and TGEA). However, source code to the SDK is provided and you are free to modify it as you need.
Here is how you connect to the network in TorqueScript:
Once you connect, you use the "send" method to command the network, like this:
Everything in Green-Ear uses this text-based messaging protocol to drive features on the network. We chose a text-based protocol because this provided maximum flexibility to the developer - any game technology that could manipulate strings could connect and drive features.
The 'rquc' is a command word for ReQuest Unique Channel. The command set is simple to learn and supports the following groups of features:
* Login and User Registration
* Simple Channel Management
* Voice Chat
* Invitations
* Text Chat
* Friend Text Messages
* Channel Groups
We call this protocol G-EAR, an abbreviation for Green-Ear.
Well, that's about it. Leba is holding a demo contest which I think we are going to extend the submission deadline. I am very excited to working in such a great industry, and I love gaming. Of course I am a recovering WoW addict (Level 70 Undead Priest, Akama), but now I can call my game play RESEARCH - how sweet is that?
Look me up on Facebook (Mike Rojas, Akron, Ohio)!
Cheers,
Mike
P.S. Don't worry about the Player Pack stuff - it is causing great confusion and we are in the process of changing (simplifying) it.
As with Leba (who I see you have met), this is my first blog. You can read her blog here.
My name is Mike Rojas. I am the CEO of Green-Ear, a company looking to make voice easier to incorporate into your games. As CEO, I am in charge of everything, developing, selling, managing, serving, and cleaning the office. We are very hands-on here at Green-Ear.
My background has been in software communication systems for twenty years. I had a software company prior to Green-Ear which I sold to NEC in 1998 and then ran their Advanced Communication Products Division for 4 years. To be honest, business communications was SO BORING that I was going nuts. So in 2002, I left NEC and started Ayalogic (parent company of Green-Ear) in guess what? Developing an all-software communication network and system for business! (Some people never learn).
However, in March of 2008, I got my wish - my team (and our investment group) decided that our software could do some really interesting things for games. So Green-Ear was born. We knew we wanted to serve independent studios (primarily because our competitor, Vivox - was ignoring you guys); so we formed a partnership with GarageGames and voila! - we're here.
I see it is required to include a graphic so here is one (thanks for the heads up Leba!):
Our product is made up of a client SDK (which is compiled into a library we call GearPlatformLib) and a TorqueGear object (derived from a SimObject). Once the library and TorqueGear object are compiled into Torque, everything related to Green-Ear can be controlled from TorqueScript. GarageGames has even been nice enough to allow us to include Pre-Built Green-Ear enabled Torque Engines to be included in the SDK (TGB, TGE, and TGEA). However, source code to the SDK is provided and you are free to modify it as you need.
Here is how you connect to the network in TorqueScript:
$gear = new TorqueGear(); $gear.connect( "My Awesome Title", "My Studio Name" );
Once you connect, you use the "send" method to command the network, like this:
echo("A Green-Ear Enabled Game: Requesting a Unique (private) Chat Channel.");
$gear.send( "rquc" );Everything in Green-Ear uses this text-based messaging protocol to drive features on the network. We chose a text-based protocol because this provided maximum flexibility to the developer - any game technology that could manipulate strings could connect and drive features.
The 'rquc' is a command word for ReQuest Unique Channel. The command set is simple to learn and supports the following groups of features:
* Login and User Registration
* Simple Channel Management
* Voice Chat
* Invitations
* Text Chat
* Friend Text Messages
* Channel Groups
We call this protocol G-EAR, an abbreviation for Green-Ear.
Well, that's about it. Leba is holding a demo contest which I think we are going to extend the submission deadline. I am very excited to working in such a great industry, and I love gaming. Of course I am a recovering WoW addict (Level 70 Undead Priest, Akama), but now I can call my game play RESEARCH - how sweet is that?
Look me up on Facebook (Mike Rojas, Akron, Ohio)!
Cheers,
Mike
P.S. Don't worry about the Player Pack stuff - it is causing great confusion and we are in the process of changing (simplifying) it.
#2
Thanks for the additional tech info, too.
10/30/2008 (11:21 pm)
@Mike - Welcome to the community =)Thanks for the additional tech info, too.
#3
10/31/2008 (12:30 am)
An awesome product, and incredible facilitated on the integration aspect. Congrats!
#4
Scott, let me try to answer your questions about bandwidth and network control.
We wanted each developer to have as much control over their own destiny as possible. To that end, we automated just about all network control into a Developers Area that lives at www.green-ear.com. You access that area but clicking the Login/Register button at the top right.
Once you are in and have entered your product key from the Green-Ear SDK, you are presented with a screen that looks like this:
This is your main dashboard and can be used to track your game activity in real-time. You can set the tachometer to a different title using the drop-down. The tach shows the number of concurrent players in your game (using the Green-Ear network). Red-line on the tach indicates the maximum concurrent licenses you have active.
To change the number of concurrent licenses for a title, you buy additional player packs (one-time fee for the life of the title) and obtain new product keys from GarageGames. You then go to the Green-Ear Developer Area and click on Game Titles. That screen looks like this:
Here you can see all the player packs applied to each of your titles. To apply a new pack, click the upgrade button next to the title. This panel is displayed:
Put in your player pack product key and your network capacity is instantly upgraded.
~Mike
10/31/2008 (2:18 am)
Hey everyone thanks for the warm welcome! 8^) 8^)Scott, let me try to answer your questions about bandwidth and network control.
We wanted each developer to have as much control over their own destiny as possible. To that end, we automated just about all network control into a Developers Area that lives at www.green-ear.com. You access that area but clicking the Login/Register button at the top right.
Once you are in and have entered your product key from the Green-Ear SDK, you are presented with a screen that looks like this:
This is your main dashboard and can be used to track your game activity in real-time. You can set the tachometer to a different title using the drop-down. The tach shows the number of concurrent players in your game (using the Green-Ear network). Red-line on the tach indicates the maximum concurrent licenses you have active.
To change the number of concurrent licenses for a title, you buy additional player packs (one-time fee for the life of the title) and obtain new product keys from GarageGames. You then go to the Green-Ear Developer Area and click on Game Titles. That screen looks like this:
Here you can see all the player packs applied to each of your titles. To apply a new pack, click the upgrade button next to the title. This panel is displayed:
Put in your player pack product key and your network capacity is instantly upgraded.
~Mike
#5
....Continued from last post:
Now to answer to your question about what happens if your game exceeds your licensed capacity.
Answer: nothing!
Your game players will not be affected. What will happen is that the developer associated with the title will be notified via email that their game is having a burst of traffic and additional capacity is needed to correct this. We have not set a policy on how long we should have for this grace period, but we think the community will help us figure that out.
The network is currently engineered at a capacity of 860,000 concurrent users with failover and redundancy. We house our servers in Ashburn, VA at the Equinix Data Center. If you have ever been there it is a Sci-Fi experience to get into. Ask me sometime about the man-tubes you go through with biometric scanners. Kinda like Code Lyoko scanners. Our guys love going there.
So we can tolerate bursts of traffic beyond licensed capacity for awhile (days, weeks), but the idea is that the player pack fees help us expand the network for everybody.
Now your final question about the need to buy player packs during the development of your game.
Answer: no player packs are needed during development and testing.
We wanted every developer to be able to test their game on the actual network without the requirement of buying licensed capacity. So in the same Developers Area of the Green-Ear website, you can enter up to five player accounts which have unlimited access to the network for Green-Ear use. That screen looks like this:
You are free to delete and add new players if you have different people testing as long as the number of players is five or less.
Hope that helps answer some of your questions!
Cheers,
Mike
10/31/2008 (2:22 am)
(I guess the forum has a post limit - still learning!)....Continued from last post:
Now to answer to your question about what happens if your game exceeds your licensed capacity.
Answer: nothing!
Your game players will not be affected. What will happen is that the developer associated with the title will be notified via email that their game is having a burst of traffic and additional capacity is needed to correct this. We have not set a policy on how long we should have for this grace period, but we think the community will help us figure that out.
The network is currently engineered at a capacity of 860,000 concurrent users with failover and redundancy. We house our servers in Ashburn, VA at the Equinix Data Center. If you have ever been there it is a Sci-Fi experience to get into. Ask me sometime about the man-tubes you go through with biometric scanners. Kinda like Code Lyoko scanners. Our guys love going there.
So we can tolerate bursts of traffic beyond licensed capacity for awhile (days, weeks), but the idea is that the player pack fees help us expand the network for everybody.
Now your final question about the need to buy player packs during the development of your game.
Answer: no player packs are needed during development and testing.
We wanted every developer to be able to test their game on the actual network without the requirement of buying licensed capacity. So in the same Developers Area of the Green-Ear website, you can enter up to five player accounts which have unlimited access to the network for Green-Ear use. That screen looks like this:
You are free to delete and add new players if you have different people testing as long as the number of players is five or less.
Hope that helps answer some of your questions!
Cheers,
Mike
#6
If one needs to upgrade their slots, is it a new additive purchase ( 10 original slots for $50 plus another 25 slots for another $100 for a total of 35 slots for $150 ) or an upgrade purchase ( 10 original slots for $50 then 25 slots for an additional $50 for a total of 25 slots for $100 )?
10/31/2008 (4:04 am)
Thanks for the patient and thorough answers. Looks to be a great product, just a little different than what some of us are familiar with. You may have to hold our hand for a bit till we get up to speed.If one needs to upgrade their slots, is it a new additive purchase ( 10 original slots for $50 plus another 25 slots for another $100 for a total of 35 slots for $150 ) or an upgrade purchase ( 10 original slots for $50 then 25 slots for an additional $50 for a total of 25 slots for $100 )?
#7
1st purchase: 10 slots at $50 - key #1 applied, Title now has 10 slots.
2nd purchase: 25 slots at $100 - key #2 applied, Title now has 10+25=35 slots.
However, we have a promotion going at the moment that changes things a bit. If you enter AUSTIN08 into the promotion code field of the Power Up Title screen on the Green-Ear website (not the promotion field on the GG site), the number of slots are DOUBLED when they are applied. I checked with Leba and the code is still active.
So you could do this:
1st purchase: 10 slots at $50 - key #1 + AUSTIN08 applied, Title now as 20 slots.
2nd purchase: 10 slots at $50 - key #2 + AUSTIN08 aplpied, Title now as 20+20 = 40 slots.
Of course, if you were going to spend $100, I would get the 25 slot key, use the promo code and end up with 50 slots for $100.
Cheers,
Mike
10/31/2008 (12:51 pm)
Each player pack purchase generates a unique product key that is used for applying the new number of slots to your title. I guess the Upgrade button on the website could cause some confusion. It works like the first way use described.1st purchase: 10 slots at $50 - key #1 applied, Title now has 10 slots.
2nd purchase: 25 slots at $100 - key #2 applied, Title now has 10+25=35 slots.
However, we have a promotion going at the moment that changes things a bit. If you enter AUSTIN08 into the promotion code field of the Power Up Title screen on the Green-Ear website (not the promotion field on the GG site), the number of slots are DOUBLED when they are applied. I checked with Leba and the code is still active.
So you could do this:
1st purchase: 10 slots at $50 - key #1 + AUSTIN08 applied, Title now as 20 slots.
2nd purchase: 10 slots at $50 - key #2 + AUSTIN08 aplpied, Title now as 20+20 = 40 slots.
Of course, if you were going to spend $100, I would get the 25 slot key, use the promo code and end up with 50 slots for $100.
Cheers,
Mike
#8
I think some of my confusion over this seems to come from unfortunate wording in the descriptions, but could you go over what exactly a slot is and how that correlates to players?
10/31/2008 (1:00 pm)
Something I've been a bit confused on is the whole Player Pack thing. Stuff like number of slots vs. number of players. For instance, the 10 slot pack says its for 10 simultaneous users, yet also says it supports 300+ players.I think some of my confusion over this seems to come from unfortunate wording in the descriptions, but could you go over what exactly a slot is and how that correlates to players?
#9
A slot is a transmission time slot on the network. It is a way of measuring traffic on the voice network at any given instant. If a voice packet is a car, a slot would be a toll booth. If we make it a toll both that doesn't require the car to stop, then we are pretty close. Now if we look down on the cars passing through the toll booths from a helicopter and take camera shots every 10 seconds, we could count the number of cars passing through the toll booths. The number of cars that are caught on camera in the toll booths is the number of slots in use.
The same reason why you don't need 50,000 lanes of highway to support 50,000 drivers -- four lanes would be just fine -- is the reason why slots can support a large number of users.
To complicate matters, not all voice transmissions are the same. In other words, we have trucks, and semi-trailers, SUVs, as well as VW Beetles. Some are longer than others and take longer to get through the toll booth, therefore trucks passing through a toll booth are more likely to be counted as "in use" when we snap the camera than let's say a Beetle.
Since we had no idea how developers would use Green-Ear, we thought this would be the fairest way to allocate cost of the network. For example, if your game uses Push-To-Talk and your voice transmissions are short and bursty (Beetle-like) then your game would naturally not need as many slots. Conversely, if your game is using Green-Ear for streaming audio, then more slots would be needed.
However, I think we are going to convert everyone's slots to concurrent player connections and simplify this slot business. We can do this by just averaging the lengths of trucks, semi-trailers, and Beetles and make them all the same.
Then a Player Pack can be just that, the number of connected players.
Mike
10/31/2008 (1:57 pm)
Thanks Scott. It is confusing. And I think we are going to change it. We applied waaaaay toooo much communication engineering to the problem and made it much more complicated than it needed to be.A slot is a transmission time slot on the network. It is a way of measuring traffic on the voice network at any given instant. If a voice packet is a car, a slot would be a toll booth. If we make it a toll both that doesn't require the car to stop, then we are pretty close. Now if we look down on the cars passing through the toll booths from a helicopter and take camera shots every 10 seconds, we could count the number of cars passing through the toll booths. The number of cars that are caught on camera in the toll booths is the number of slots in use.
The same reason why you don't need 50,000 lanes of highway to support 50,000 drivers -- four lanes would be just fine -- is the reason why slots can support a large number of users.
To complicate matters, not all voice transmissions are the same. In other words, we have trucks, and semi-trailers, SUVs, as well as VW Beetles. Some are longer than others and take longer to get through the toll booth, therefore trucks passing through a toll booth are more likely to be counted as "in use" when we snap the camera than let's say a Beetle.
Since we had no idea how developers would use Green-Ear, we thought this would be the fairest way to allocate cost of the network. For example, if your game uses Push-To-Talk and your voice transmissions are short and bursty (Beetle-like) then your game would naturally not need as many slots. Conversely, if your game is using Green-Ear for streaming audio, then more slots would be needed.
However, I think we are going to convert everyone's slots to concurrent player connections and simplify this slot business. We can do this by just averaging the lengths of trucks, semi-trailers, and Beetles and make them all the same.
Then a Player Pack can be just that, the number of connected players.
Mike
#10
10/31/2008 (2:04 pm)
The original plan seams the best value for customers. I would think you would want to keep it.
#11
One question I have regarding the way the slot system works is regards to multiple titles -
1. If purchase say 100 slots can that be split between multiple titles... i.e. 50 slots for one game, 30 for another and 30 for another or do you have to buy slots just for one title and it's fixed.
2. When you bring out a new game it usually (hopefully) gets a lot of attention and for the first few months (perhaps a year) has lots of players, over time the number of players playing tends to die down and therefore would require a lot less slots, and eventually the game dies and is no longer hosted. In the mean time you may release a new game and the cycle begins with that one.
How does this fit with the slots per title setup? Can packs of slots be transferred from title to title so this lifecycle can be managed and balanced or are you fixed once commiting a slot pack to that title.
Thanks - Andy
10/31/2008 (4:11 pm)
Thanks for the information Michael it's really great to see some more details, can I suggest adding the information & screenshots to a "How does it work" page or part of the FAQ on your website that way the information is available to all looking at purchasing the product rather than just us that sumble across your blog.One question I have regarding the way the slot system works is regards to multiple titles -
1. If purchase say 100 slots can that be split between multiple titles... i.e. 50 slots for one game, 30 for another and 30 for another or do you have to buy slots just for one title and it's fixed.
2. When you bring out a new game it usually (hopefully) gets a lot of attention and for the first few months (perhaps a year) has lots of players, over time the number of players playing tends to die down and therefore would require a lot less slots, and eventually the game dies and is no longer hosted. In the mean time you may release a new game and the cycle begins with that one.
How does this fit with the slots per title setup? Can packs of slots be transferred from title to title so this lifecycle can be managed and balanced or are you fixed once commiting a slot pack to that title.
Thanks - Andy
#12
I will check into that.
On question 2 - the reason we are able to offer a one-time fee for the life of the title is because we understand a title has a "life". Obviously, we pay for cage rental, cross connects, upstream carrier bandwidth, power, servers, 24/7 monitoring, and maintenance on a monthly basis. We thought about offering a recurring monthly charge for the packs, but (1) GarageGames couldn't support recurring billing and (2) we thought it would be more of a hassle for the developer.
What I might be able to do is to look into "unused" slots. In other words, if your game was set for a capacity of 500 slots and you never reached more than, say, 400 at peak, then I might able to "free" the extra 100 for use on another title. I will have to run some modeling and figure out how to do that from a network control standpoint.
Cheers - Mike
10/31/2008 (4:44 pm)
Right now the network and website are setup to translate one product key (and its purchased slot amount) into a single title. But I get your point about buying higher slot packs and then splitting them. You get a price break for the higher quantity slots and it would be nice to apply those in a fashion across multiple titles. I could add a "# slots field" to the Power-Up Title screen that would "consume" the purchased slot amount until the key is exhausted.I will check into that.
On question 2 - the reason we are able to offer a one-time fee for the life of the title is because we understand a title has a "life". Obviously, we pay for cage rental, cross connects, upstream carrier bandwidth, power, servers, 24/7 monitoring, and maintenance on a monthly basis. We thought about offering a recurring monthly charge for the packs, but (1) GarageGames couldn't support recurring billing and (2) we thought it would be more of a hassle for the developer.
What I might be able to do is to look into "unused" slots. In other words, if your game was set for a capacity of 500 slots and you never reached more than, say, 400 at peak, then I might able to "free" the extra 100 for use on another title. I will have to run some modeling and figure out how to do that from a network control standpoint.
Cheers - Mike
#13
10/31/2008 (7:00 pm)
Thanks for the response Mike.. both answers make perfect sense, we've just finished a 1.5million refurb of both primary and D/R data centres so I know just how costly things can be, given the requirements of a system like this I think the prices are more than fair... (well I would say they're cheap but you might take that, come to your senses and put the prices up ;) )
Torque Owner Scott Warren
The product looks promising. It definitely changes the way I think about implementing communication for my project and I will surely buy this product.
The Bandwidth Packages your company provides are Per /Title for the life of the Title ( Nice ! )
Lets suppose the next generation of games comes from the GG community and Green Ear is part of that Next Gen. Game.. How quickly can we upgrade a Bandwidth Package to accomodate 35000 players?
Or:
Lets suppose we release a great game with this Green Ear attached and our Bandwidth Package supports up to 300 very chatty players.. Sales increase and we need more Bandwidth Packages to accomodate another 300 or so... How quickly can this swing into action?
Or:
What if I purchase a game from one of these Devs here and I happen to be customer 301 and the Bandwidth Package is at full capacity for this particular game?
It's all the same question... Just depends on what side of the game we sit.. the Company that made the game or the Customer that bought the game. We would want seemless and uninterrupted service to accomodate a fast growing player base.
Lastly, I am curious if a Game Title must be registered at the time of Purchase and without a Bandwidth Package for inhouse testing... Do we register a game Title at the time we purchase a Bandwidth Package?