imVOX/Ayalogic is looking for a .NET/C# developer to help us migrate from .NET 2.0 to .NET 4.0 for our VoIP client. Experience with similar migrations required, as is a strong knowledge of Expression Blend to migrate our UI. Boston-area preferred, but we will consider all candidates. Rate negotiable. Contract may lead to future development opportunities. Please send resume, public code repo (if available on Github or similar) and references to jobs@imvox.com
Archive for the ‘Development’ Category
Seeking .NET Developer
Wednesday, July 7th, 2010
State of imVOX and your feedback
Friday, June 18th, 2010As development on imVOX continues, I have been taking notice of your suggestions and feedback on our forums and elsewhere. I know we haven’t been able to implement every feature requested so far and that progress hasn’t been quite as swift as hoped- yet I still feel that we are building a solid service that will go far beyond where our competition has ever dreamed of being. Keeping the community in the loop is highly important to me.
First, in case you haven’t heard we released an all new Mac client. It is fast, clean and sets us up for success on the Mac platform. As a Mac users myself, I have been using it more and more daily (and I am very happy to no longer boot into VMWare to use imVOX). Download it from our downloads page and give it a shot. Yet, this is only the beginning.
The team has expanded with additional talented developers and we’re moving far faster than ever. The primary server-side voice engine is being replaced completely with an open-source based alternative to the proprietary platform that we’re currently on. This will allow us to use almost any codec we want. It requires us re-writing the audio/network libraries on the Windows side, but once that’s done we will be able to support the higher quality SILK and CELT codecs as well as anything else that comes out in the future. End results: Higher voice quality and better feature like per-user muting and mixing.
Talking is a social activity and is best among friend. For this reason we are very close to adding friends capability to the Mac and Windows clients. This will enable private text and voice messaging, a friend’s list, easy joining of your friends in servers and grouping functionality eventually. Integration with other social gaming services also becomes a possibility with this addition.
Our Windows client is not as fast or stable as I would like. To fix this we are removing the current audio/network layer and replacing it with our own that we can control better. Additionally we are moving to support .NET 4.0. This will allow us to re-write the interface for much faster response time and lower system load. End result: Faster and less CPU usage.
A new Windows client should be hitting the update servers within the next 1-2 weeks and implement many, but not all of these features. Stay tuned for updates.
We need your help. Make your voice heard. Take a quick survey on imVOX so that we can better understand your use and build a better imVOX. One survey will be randomly selected to win a super-secret but awesome prize!
PC to Mac ports- not an easy process
Monday, May 17th, 2010Benchmarks, comments and forum posts have been circulating over past week concerning the quality and speed of Valve’s Mac Steam digital distribution client. Many users seem frustrated, some confused, and others even exclaim the superiority of Windows as an operating system. At the heart of this is the issue that porting an application from Windows to the Mac OS (Snow Leopard) is very difficult.
At imVOX, we’ve been working for several months on such a port of our voice communications platform from Windows to Mac. It hasn’t been as easy as we had hoped. We’re a small company and our expertise is firmly in the Windows platform. While we have very talented individuals I don’t think any of us had fully developed a Mac application prior, and certainly not one of this complexity. I’d like to share a bit of what made this far harder than we anticipated.
A few points first however: I am not the lead PM, nor am I a developer by trade. I’m a Director of Marketing who happens to be able to code in Ruby. Other people at imVOX are writing the code- not me. I’m just writing this blog post. Also, like I said in the prior paragraph, we are n00bs to developing on the Mac. There are likely several things were did wrong that a Mac ninja wouldn’t have run into. These are our experiences. Advice, ideas and offers to help are welcome.
Mono Makes it Easy- Right?
Our Windows client was written in Microsoft’s .NET 2.0 with C#. While .NET exists only on Windows there is an open source technology called Mono that allows for cross-platform .NET development, in theory making it possible to reuse most of our .NET code to create a Mac (and potentially even Linux) client. We put our code through the Mono Migration Analyzer and things looked generally good. This lead us to belief that this process would be smooth sailing, taking no more than a month at most.
The main idea here was to be able to have one set of code that we were using. No major forks/divisions in the code and reusing almost everything. That would make it easier, cheaper and faster right? Right…?
Workflow Woes
Around the same time as we were starting heavy work on the Mac client we made some other changes to our workflow. We moved from Microsoft’s aging Visual Source Safe to Git. We tried using Github at first, but then shortly after moved to our own self-hosted Git server. For Windows-centric developers who were used to having controls in Visual Studio that integrated with VSS, this was a bit of a stumbling block. Git isn’t hard, but if you’ve been building software for 5+ years using a centralized repo it certainly is a change.
Our developers were still using Visual Studio to develop the Mac software, instead of working in XCode. This required us having a Mac and a PC in front of each developer. I’m honestly not sure why we’re doing this, aside from our developers being deeply familiar and comfortable with Visual Studio as their development environment. If I had to write a Windows piece of software, I’d probably be using TextMate and doing the inverse myself so I can’t blame them.
Everyone had lots to learn. New tools, new ways of debugging crashes and just understanding the OS at a reasonably deep level took some time.
Interfaces
Our Windows interface was written using .NET forms. It was highly Windows-like and also was made to look very ‘gamer’ oriented. This had a few problems. First, the interface barely worked on the Mac. We were doing all sorts of things for transparency, collapsable areas, and to draw the screen overall. When they did work, it was slow and buggy. Debugging these was slow and tedious. Things just didn’t seem right.
After much effort, we decided to go with a native Mac interface instead using Interface Builder. We used MonoObjC as an Objective C to .NET/C# bridge. Thankfully Steve Jobs hasn’t gotten around to killing all translation middleware on the Mac itself (yet). This worked well overall and made our workflow much more manageable. Now myself or our graphic designer could easily check the most recent build out of Git, open up the interface in Interface Builder and rearrange things as needed without breaking anything. Overall MonoObjC was a great idea that I wish we had known about from day 1.
Developing an interface for the Mac however presents several interesting problems. Do you try to keep the exact same interface that you had on Windows for consistency? That pisses off Mac owners due to all the Window-isms present. But if you make a totally native UI you now have a lack of consistency between products. For games, this is less of an issue, but for a piece of desktop software your users notice either way.
If we were writing both Windows and Mac software again from day 1, I suppose we could have gone with a cross-platform interface solution like QT (or just used Java), but I still feel as though we would have been missing something on a usability level.
Feature Parity
One of our major goals from the outset has been to achieve complete feature parity between the Windows and Mac applications when possible. This has been a lot harder than we anticipated. We aren’t far off, but this doesn’t happen automatically for sure. Our main competitor Ventrilo does a rather poor job of this and we’d like to do better. With the next (still beta) release we’ll be missing a few things but we will catch up on that soon. I’d rather release early, release often than wait forever.
Audio and Network
Our program is mainly about voice chat, and obviously deals quite heavily on the audio layer. Since we are transmitting over the network it gets a little more complex with various codecs, echo cancelers and other gremlins.
To begin, audio on the Mac is totally different than audio on the PC side to a degree that I won’t even elaborate. We were using a proprietary licensed codec on the Windows side, but the cost for the Mac was prohibitive (and the quality/flexibility wasn’t what we wanted). Temporarily we’re using a PCMU codec until we can implement SILK/CELT on our servers. We had an echo canceler licensed from the same people on the Windows side so we had to rewrite our own on the Mac side. Our still isn’t perfect, but we’ve implemented an Audio Units chain as to get consistent and stable timing across the board (allowing for inverting of waves to cancel echo). That took quite a bit of time.
Push to Talk and Keyboard Access
Steam users have commented on the setup procedure of their Mac client being less than perfectly smooth. It requires you going to Universal Access under your System Preferences and enabling access for assistive devices in order to get the overlay to work. Guess what? We do the same thing. It isn’t because Valve (or our) programmers are lazy, but rather has to do with how Apple has protected the keyboard on a security level. I don’t know if I’d call it great security, but it certainly is a setting that 99% of users don’t toggle or are aware of.
Accessing keystrokes from an application when another application is focused is rather difficult under OS X and requires some trickery. It ended up that we had to write a separate driver (launches when imVOX does) that intercepts all keystrokes and then passes them back out to their original destination. As you’d imagine, this is roughly the same technique that a keyloggerwould do, and we’ve taken precautions to make sure that nothing is being logged, recorded or stored. This is why Apple doesn’t turn on assistive devices automatically. In our estimate, Valve is doing the exact same thing with Steam so this isn’t an uncommon technique. Should anyone have a better idea, please let us know. We’ve been ripping our hair out over this one.
Odds and Ends
We’ve got a bit more to do on the Mac to make it really Mac-like. We need to write help files that are specific to the Mac. More testing is needed overall. We have a TON of conditional statements in our code now checking if we are running the Mac or PC version. Shortcuts need to be polished. Installation process is far different from the PC. The way we built the application is also different (using nant or Xcode).
Final Thoughts
We thought this would be a simple process. Unfortunately we got bit by our lack of expertise, interface issues and the 1-10-100 rule. Anyone critiquing Valve for their results so far on Steam/Portal should remember that they’ve been at this for several years on the Windows side and programming on the Mac is different.
Even using something like Mono does not make for an easy transition unless your application is dead simple. Also using Mono holds you back a bit for your Windows development. Using .NET 4.0 or Expression Studio will force you to split your code even moreso. I think the best way around this is to create a few shared libraries, and build everything else natively on each OS from the beginning. Sounds harder, but it will probably serve you better in the long term.
Native Mac Client Look and Feel Preview
Monday, March 29th, 2010We’ve got a mostly-working fully native mac UI in testing now. Pretty soon Mac users will have a killer, GPU native accelerated client with none of the buggy drawing issues that we had before.
Your Privacy with imVOX
Wednesday, March 24th, 2010Online privacy is a very serious issue. At SXSW danah boyd from Microsoft and fellow at Harvard’s Berkman Center pointed out in her keynote speech some fantastic points to consider.
She rather astutely pointed out that when relinquishing privacy teens generally think about what they can gain, while adults worry about what they can lose. While technologists talk about personally identifiable information, teens often focus on personally embarrassing information- but there is a large gap between the two and more can be done to protect both.
Additionally she pointed out that we don’t all have the same ability to be a public person online. Those of us that can say and do online what they want with relatively little consequence are privileged and are more the exception than the rule. As technologists we often consider only the technical issues at hand and not how privacy issues can effect the life of users.
The content of your communications is highly personal and sensitive, even if it is mainly talking about the next 25-man raid. We will soon be implementing various social network features including profiles, instant messaging, friends and integration with other networks.
imVOX currently has no privacy policy. We would like to change this and we need your input. We want imVOX to be a thriving and active service, but we cannot do that at the expense of our users.
Contact us directly or discuss your thoughts on privacy and what you need from imVOX in the comments.
Weekly Update #3 – Mac Client and PAX East
Wednesday, March 24th, 2010So much can change in a week, and yet it can seem to the outside like there is little progress. Here’s the updated game plan.
Overview
Our prior goal was to stabilize the Windows client and make is a good user experience without rewriting the entire thing. Also in this we created greater stability on our servers. We’ve done this and while we have a laundry list of features that we want integrated- keeping an eye on the greater picture is important too.
The next immediate goal is switching out some of the core technologies we use. Adding many of the advanced features like per-user audio mixing is difficult if not impossible with our current setup. Due to this we are changing the voice engine and server setup dramatically to use Open Source technology that is far more flexible than our current setup.
Both the Mac and Windows clients approach the screen/display in a non-optimal way. We are using various .NET and Mono forms to hack a lot of things into place. Some of the technology we are using (.NET 2.0) is a little bit old and we could benefit from using newer versions.
But we have a problem in upgrading from .NET 2.0 to 3.5 or greater. Mono (which is what the Mac client runs) only supports through version 2.0 of .NET. We are trying to keep as much code synced between the Windows and Mac version as possible. However we’ve found a solution! If we a Mono/Objective C Bridge and use a native interface on the Mac built in Interface Builder, then the Windows side is free to use a newer version of .NET for drawing the user interface. Instead of using Interface Builder as we would on the Mac, we would use Expression Studio for drawing and laying out the interface.
What does this mean for you, the user? imVOX (and your game) will be faster and more responsive. We will be able to use newer UI elements and upgrade and change things faster. Our design team will be much closer to working on the actual interface, so no longer will we have to jump through the hoops of using Photoshop to make things and then remaking them in .NET.
Next Goals
After we get all of this housework done, then the real fun begins. Social Networking functionality will be coming to imVOX. I can’t say too much more about the specifics, but it should give imVOX a clear advantage over anything that Ventrilo or Teamspeak can do.
PAX East
I will be at PAX East along with Brian Costello from imVOX. If you’re around, drop us a line and we can meetup. A free Pro account goes to anyone who mentions this blog post to us at PAX.
Weekly Update #2
Friday, March 19th, 2010Major changes are on the horizon for imVOX along with big news.We are shifting even more of our efforts into expanding our development and engineering capabilities! We want your ideas, dreams and feedback for how we can make the best gaming communication platform possible.
Here’s just a few of the things coming with our next release, which is initially slated for the end of the month.
- Major Mac Client Update- The old one barely worked. This one will be leaps and bounds ahead of it. We have a developer dedicated to getting this working.
- High Definition Voice- Audio quality will go up dramatically with only minor hit to bandwidth and CPU. A new mixing engine will enable expanded future capabilities such individual level control of other users without effecting the overall chat.
- Expanded Text Chat- Clickable URLs, one-to-one chat, and notification of text messages will make text chat more useful than ever
- Bug Fixes- The new imVOX will be faster and more stable. A new testing procedure has been put in place to catch issues before they hit you in the middle of a raid
- And More!- A new MOTD screen, user aliases, user profiles, away channels, and better banning options are all just around the corner
If all of this seems exciting, just wait for what we’ve got in our back pocket. We aren’t just making another voice chat program, we are going to change the way you communicate and interact with your games. Please leave your ideas and feedback in the comments.
Weekly Update #1
Monday, March 8th, 2010This is the first post of many in which I’ll update you as to what is happening with imVOX and things that you can look forward to in the next week.
Upcoming imVOX Software Changes
First up, we’ve been working on the main imVOX client quite a bit. Aside from adding features, one of our goals is to further streaminline the client from a workflow perspective, and also from a memory footprint and performance perspective.
Upcoming imVOX concept preview
The customizable background may be removed so we can take out the transparent sections of the client which cause many of the performance issues that you currently see when the screen draws.
Friends are slated to make a comeback soon and overall we hope that the client will be easier than ever to use.
Overlays have been a frequent topic of discussion here. Some companies like Valve have done a great job with overlays and we rather like the functionality they have built into Steam games. You also see a great deal of this on the Xbox and Playstation 3 and it works rather well. An overlay would allow you to access crucial imVOX UI elements while in game and also see who is talking, see text chat, kick people from the server, etc. It needs to be smooth however and have almost zero impact to the performance of your game. Drawing the interface natively in OpenGL and DirectX will be likely needed.
Another discussion we’ve been having involves forking our codebase slightly to take advantage of the newest version of .NET. The main imVOX client for Windows is build on Microsoft’s .NET 2.0 framework. This provides us a rapid development environment and gives us a lot of great tools to use. Version 2.0 is a bit old a 4.0 is on the horizon. Moving to a newer version would allow us greater performance, greater stability and new features.
Unfortunately there is a downside to this. The Mac client is built in Mono which only supports compatibility with .NET 2.0. We would have to maintain two code branches for most of our .NET components because of this, although our underlying voice engine written in C++ would remain unchanged and could still cross-compile.
Mac Client Development Underway
The Mac client is again being actively developed. We’ve contracted a developer who is hard at work on it and has already fixed several issues. Those changes will hopefully be pushing live this week.
South by Southwest!
I (David) will be attending SXSW and representing imVOX from March 11- 17th in Austin, Texas. If you are attending SXSW please drop me a message so we can meetup. I will be attending sessions on game industry, social media and UI subjects in addition to speaking with hundreds of people and enjoying the far warmer weather.
I’ll blog as much as I can about SXSW and post photos to flickr and videos to YouTube. I’ve got my cameras charged and memory cards ready to go!
New Website Design
The current imVOX site could be better. It is slow, very graphically heavy, doesn’t display well on mobile phones, has coding errors and contains a great deal of non-semantic HTML. Information is hard to find it doesn’t offer the best user experience. Before SXSW, I’ll be working on this and you can see the realtime changes at http://imvox.com/beta All content on the beta site is simply a placeholder and none of it should be assumed to reflect actual features, functionality, pricing or changes to imVOX.
Amazon EC2: Watch your Disk Space!
Wednesday, February 24th, 2010Today at imVOX we suffered a short outage and downtime of our main service and to our embedded widget due to our database going down. We had everything back up within 15 minutes.
The cause of the downtime was that we ran out of disk space on our database server. We found our when our always vigilant Pro user Rev Lazaro (@revlazaro on Twitter) let us know that his group was unable to log into imVOX via Twitter.
We run our Oracle database on Amazon’s EC2 service, using their Elastic Block Storage (EBS) for storage on the database. We use four 100GB EBS units in a RAID configuration, keeping one for parity which gives us 300GB of usable space for our database. This can easily scale up size-wise and is perfect for our database size. They are also monitored by Amazon’s Cloudwatch service, letting us know instantly if something goes wrong or we run out of space.
So how did we run out of space? Log files.
The EC2 instance only had 10GB of storage which is normally enough. Cloudwatch isn’t watching the EC2 instance for space and the log files from the database transactions got rather large and filled the disk. This instantly locked up the database from executing additional transactions- halting the imVOX service completely.
Thankfully we had a user notice quickly and we were able to move the log files and restart the database without issue.
Lessons Learned:
- Database logs can get big
- Just because your database has space, doesn’t mean your db server does
- Cloudwatch might not catch something like your EC2 instance running out of space
What happened to the imVOX Mac client?
Sunday, February 21st, 2010As any imVOX user on a Mac will tell you- the Mac client is really not stable and barely works. Users have posted to the forum and issues have been acknowledged. So why haven’t these bugs been fixed? Does imVOX hate Mac users? When will we see a stable Mac client? Hopefully this will answer some of these questions.
How we almost didn’t go Mac
I (David/tibbon) am a Mac user. Everyone else at imVOX is a Windows/PC user for the most part and historically this is a very Windows oriented shop. We were using Visual Source Safe for our version control and we’ve been using C#/.NET for our development. Many of the servers are running on Windows. Microsoft runs deep through this company.
I knew that we would need a Mac client early on if we wanted to grab some of the larger MMO markets like World of Warcraft. Yet, management wasn’t totally sold on a Mac client. It might be expensive and although it made sense it wasn’t a large marketshare. Couldn’t we just go after other games and markets? I pleaded that we really needed one and at one point we estimated that it would only take a month to get one off the ground. We were slightly wrong on that. Ok- very wrong.
Mono to the Rescue?
Mono is an open-source, cross platform implementation of Microsoft’s .NET 2.0. It appeared at first as the answer to our problems and would save us a ton of time, money and resources.
What we thought would be easy and a time-saver just wasn’t. The long-term concept here was that we didn’t have the resources to maintain two separate code-bases and using Mono would make it so that the code shipped to Windows users was the exact same as to the Mac users. We’d be able to (in theory) have a Linux client too with minimal effort. We didn’t have the expertise as Mac developers and this diverted heavily from the development of our Windows client.
One of the biggest issues is the interface. Aside from the obvious Mac vs Windows design styles, .NET and Mono seem to handle graphics rather differently. The way we draw our display is rather intense compared to most other .NET applications which makes development very difficult vs using a native interface.
Where are we now?
As seen in prior blog posts, we’ve been trying to find Mac developers to work with us to make imVOX work on the Mac, and continue development on the Windows side. When I say work on the Windows side however that isn’t fully true. Since the code is shared things that go into the Windows side help out the Mac side too. If we fix a bug there, it will likely help everyone out. However fixing something on the Mac side likely doesn’t do much for Windows users since the code is probably in a big if statement that is specific to the Mac.
Finding Mac developers isn’t easy however. We’re looking for individuals with very specific skills and talents to work on a unique program that delves off into unknown realms quite often.
We’ve spent the last week patching up version .27 for the Windows side. As soon as we get the updater running properly on the Mac then many of those changes will trickle down to the Mac side as well. Next week we’ve got one Mac guy starting with us. We’ll have to see how it goes really. I can’t honestly say how long it will be to get it up and running fully.
I’ll be blogging here about some of the more technical details of the Mac release soon.
