Here you will find the professional software projects that I have contributed to while working at Quicksilver Software.

"The Real Deal" Poker

C++, C# application
Supporting Articles/Websites:
Card Player article, Real Deal at the Venetian

"The Real Deal" was a live entertainment stage show in which a number of professional poker players played hands of poker and the audience had the opportunity to play along with them as a phantom 9th hand. Our application consisted of a server app and as many as 300 client applications all talking to one another over network as the show happened in real time.

This was the first project that I had the opportunity to work on at Quicksilver. With the small team I was working with I had the opportunity to really get my hands dirty with the design and authoring of the code base. I worked very closely with our lead in creating the base framework and designing a large portion of the protocol we used for transferring data from our server to client applications over the network.

Sadly, given the collapse of the economy, the stage show did not last very long. But what we were doing with our application and how it seamlessly operated in unison with the live poker game and stage show was truly unique and revolutionary.

Nexus J

C++ application
Supporting Articles/Websites:
Nexus J Website, QSI Website

Nexus J was the brainchild of Team J, the Quicksilver band of programmers that had all worked on "The Real Deal" Poker. Nexus J for some of us was real blood, sweat and tears as we spent a good portion of our time (most of the time unpaid) to work on this application. We had envisioned an application that would allow us to play all our favorite board games while also connecting with some of our best friends online through the app.

Nexus J was borderline chat client and all in one game platform as many cool features were introduced like chat with your opponents and multiplayer networked games. When last we had a chance to really work on it we had 2 pretty popular board games implemented on it; One I can't talk about for licensing reasons and the other is a famous game by game designer Reiner Knizia called Loco. Nexus J is still available for download if you would like to try it out. Here for Windows, and here for Mac.

I can't take a whole lot of credit for Nexus J, as I only spent a small amount of time on it. I worked a little bit on network protocol design and spent a good amount of time developing a computer A.I. for one of the games, Loco, that never actually made it to final product. I may have also spent a bit of time on a few bugs here or there, but I was pulled away from any real amount of development time on the project as our next major project, MCIT, was ramping up.

M.C.I.T. (Mobile Counter-IED Interactive Trainer)

C++ application utilizing VBS2 Engine Technology
Supporting Articles/Websites:
MCIT Project Page, MCIT Project Description, ICT website, New York Times MCIT Article

Myself and a few others from Quicksilver worked in unison with ICT (USC, Institute for Creative Technologies) who led development of 1 out of maybe 4 or 5 stations or training modules that make up the MCIT training simulator as a whole. Our module, specifically, simulated a confrontation between a REDFOR (or OPFOR; opposing terrorist/insurgent team) and a BLUFOR (American; US Soldier) team. The BLUFOR team, which consisted of 6 soldiers (3 per HUMVEE enclosure), had to drive through a war torn middle eastern city checking for, avoiding and reporting IEDs (Improvised Explosive Devices) while the opposition, which consisted of 4 soldiers at game controller operated terminals, tried its hardest to kill them with said IED.

The BLUFOR team operated out of two scale HUMVEE replica enclosures where each of 3 seats per enclosure had access to their own monitor, headset and controls. Each seat had a unique role and unique controls that suited that role; Driver which utilized a steering wheel control; Team Chief which utilized a terminal with limited controls for issuing orders and calling in support; Gunner which used a custom made gun control simulating a real vehicle mounted .50 caliber machine gun.

On the REDFOR team there were 4 distinct roles that supported a typical approach that a group of insurgents might have if attempting to injure or kill US soldiers patrolling their cities. There was a Triggerman who was responsible for detonating the bomb, a Cameraman who needed to film the explosion, a Leader who coordinated the attack, and a Security role that acted as an extra line of defense if things got out of hand. The four worked together to detonate an IED on an unsuspecting group of US Soldiers and get it on camera. This is pretty representative of how typical insurgents might operate in this type of situation.

My role in the project was pretty significant toward the end of our development lifecycle. In the beginning I did what most on our team did which was developing scripts for the VBS2 engine using its proprietary scripting language that supported the scenario as a whole. As development progressed I was tasked with more complex development roles. At one point I had to design an algorithm for laying a particular amount of a wire model across the map segment by segment from the trigger apparatus to the IED. This wasn't very easy as I had to figure out the origin of rotation of the model (had to use trial and error) so that it would be oriented in line with the other segments. I also had to figure out how to draw the segments on the screen in such a way that they did not appear to be segments, but one contiguous line. I also had to write a sort of best fit algorithm which used various lengths of wire segments so that across the largest distances the largest segment was used and as the distance between the trigger and the IED device grew smaller I had to use the smaller segments. The goal was to minimize the possibility of a break anywhere in the segments using only the fixed length segments at our disposal. There wasn't a lot of documentation or much guidance for the very specific nature of what we had hoped to do using this engine. In many ways I think we had to hack and break the original design of the engine, as it was lacking, to get it to do what we wanted it to do. This approach was difficult as we only had access to the scripting functionality and the code base was completely closed.

Toward the last 5 to 6 months of the project we were asked to develop a standalone C++ program that was meant to display the results of the scenario for both squads. This entailed drawing the scenario maps in an orthagraphic fashion and feeding information from the simulation to the standalone app via xml script. We tracked key points of interest throughout the scenario and wrote information about position and orientation to the xml file that we then displayed in the application. I was almost a project lead with the amount of coding I did on this particular part of the project. I designed and implemented a lot of the core UI functionality that was used in displaying the scenario information which included all of the UI labeling and dynamic positioning of the labels, slide navigation from one key slide to the next, zoom functionality, and a psuedo tile map display. We also had the limitation of coding this application as a dll only and had to launch it from the parent application following the end of the scenario using Win32 window handles to set focus to the standalone application, bring it to fullscreen and eventually close it returning focus back to the parent application.

This project was quite a challenge, but I was able to learn a lot of new things.

Longbox

C++ application
Supporting Articles/Websites:
Longbox Website, QSI Website, CBR Article, CNET Article

I can't say any specifics as to my role in the development of Longbox as a lot of what I did has to do with the security of the application. So, with that in mind, let's just say that I had a pretty large role on the server-side development of this product. For my role I had to learn a lot of new things. I had to acclimate myself to developing in a linux/unix environment almost exclusively, which was something new to me as I had only used linux previously in my life while taking a 1 unit course on Unix systems 3 years prior. I also had to learn Bash scripting and a little bit of Python, CGI and Perl scripting as well. These were pretty new languages to me as I had never really used them to such a great extent prior to working on Longbox, but I can now say with confidence that I am Bash scripter.

I didn't contribute to the client side application too much throughout our development of it, but there was a point in the development of the server when I had some down time, so I chose to spend it squashing some bugs on the client. This task I set out to accomplish required very quickly getting myself accustomed to the client code (that I had previously never touched) and then finding the best way to fix the problem. By the end of it I can say that I fixed a legitimate problem with the client application, and that I did it in the best way possible at the time.

Longbox is still currently in development, but is available for download, for free, here.

Interesting Stuff

QSI Projects

"The Real Deal" Poker

Nexus J

MCIT

Longbox