Been a While

I have been away from this place for too long.  Many things have happened over the last year that have impacted my life in a significant way.  First, and most importantly, the company that I moved from Rhode Island to North Carolina to work for, no longer exists.  This is very sad for me.  I really enjoyed working for Emergent and with all the incredibly smart individuals associated with that organization.

In October of last year, Emergent’s assets were sold at auction.  fortunately, David Brame came to the rescue and with the help of Gamebase in Korea was able to purchase Gamebryo. I have 3 great years with that product so I am glad David was able to keep it moving.  And from everything I have heard over the last few months, Gamebase USA is doing well.  I wish all involved the greatest success. And who knows, maybe I will work with them again in the future.

So what have I been doing since I left Emergent in September?  Well, I have been doing a number of things.  I am in beta testing of the first version of my parental control application called Kidstime.  It will be made publicly available shortly.  I will have a future post that will talk all about it.

I worked with a great company in Cary called RMSource.  Straight Microsoft technology stack; right up my alley. Unfortunately, the commute killed me and I was spending more money on after school care late fees than I really wanted to (which is 0, btw)!

I am now with North Carolina Farm Bureau insurance in Raleigh.  A slightly closer commute (only about 35 to 40 mins.) and back to Insurance which is an industry I am familiar with. 

We bought a new home in Hillsborough last July, which we love!  The kids are enjoying their summer and Holly is still at Stewart PT.

We are well. I will try to post at least once a month now that I am posed with new challenges.

till next time…

Are you Agile?

I recently went to a seminar in Durham on Agile Development Methodologies. This seminar was sponsored by AccuRev and Anithillpro (UrbanCode). I learned a little bit, some of my core beliefs were re-enforced, and I was a bit surprised by the level of Agile development my company was at compared to other companies that were represented at the seminar.

So, first of all, for those not acquainted with the term Agile, here is a link to wikipedia’s description and below is the Agile Manifesto.  I have been told that any presentation on Agile should include the Agile Manifesto. So, while this is not a presentation, I believe it to be valuable to see it in black and white.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

There is also the related “Twelve Principles behind the Agile Manifesto”.

So what did I learn in this brief seminar? One of the main take-aways from the seminar was directly related to the last line of the Manifesto.  This was probably skewed a bit because the seminar was sponsored by a tools company. But, I learned that the items on the right are important so long as they support the items on the left.  That is, if someone tells you that they are doing Agile therefore they do not use tools, write documentation, or plan their design.  They are not doing Agile.  Tools, Documentation and Design are very important, so long as they support the items on the left.

What were some of the things that helped re-enforce my core beliefs? First, Agile requires management and executive by-in and participation.  Too often a team that practices Agile Development falls flat.  One reason for this is that the management and executives either, 1) do not have by-in to the process and do not promote the process. Or, and what I believe to be the worse of the two scenarios, 2) they do not participate in or own the process.  The success of any development methodology hinges on management and executive participation.

Second, and related, is the priorities of the development team need to be clearly represented and talked about daily. The Product Owners are key to making this happen.  If a Product owner is successful at transforming executive Value Story Cards to Story Cards for the development team and move them through the swim lanes, then the project has a great chance for success.  If this is difficult for the Product owner and priorities are not clear, the team is doomed. If the executive wants this specific feature to be a part of this sprint then the Product owner needs to be adept enough to help the executive decide what feature will NOT be a part of that sprint. This is a give and take. I believe this to be one of the most challenging aspects of Agile to overcome.

What surprised me? Well, in short, I was surprised by how much further along my company is in practicing Agile Methodologies than most of those organizations represented at the seminar.  And yet, how far away we are from implementing some of the key principles.  I am excited that we are moving closer to adopting these principles but the realist in me knows that we have a ways to go.  Especially in the area of priority setting.  We continue to learn and move closer, like most teams. And, I am encouraged.

The Agile Manifesto is an important step in the evolution of Software Engineering.  When an organization follows the principles associated with the Manifesto there is no limit to what they can accomplish.

Tell next time…

The Evolution of a Build System Part 2

In my last post I talked about how Continuous Integration was where I started when faced with rebuilding an entire build process from scratch.  I talked about CruiseControl.Net and some of the challenges I faced at a high level.  Today I am going to talk about taking the Continuous Integration system and moving to a nightly Full Build system.

I began here:

Nightly Build and Test

• Only built portion of code base
• Built from the Tip
• VC80 and VC90 would build on alternate nights
• All platforms were built and tested serially
• Packaging was done as a separate process only when deemed necessary
• Close to 24 hour turn around

This is where we are now:

• Builds all solutions and all configurations of entire mainline
• Builds from latest Green CI Change-list #
• Builds all platforms and compilers in same night
• Build takes advantage of multi-core hardware and RAID drives by building concurrently where possible
• Build and Integrated Tests timing is down to 14hrs total
• Have deployable ISOs for all platforms prior to 10am daily

I built a couple of tools along the way and made use of my staff (thanks Scott and David) and our IT infrastructure and staff.  Being the IT Manager helped considerably.  The IT staff (thanks Jean and Luke) was extremely helpful in automating the process and continues to play a part. 

Here are some next steps:

• Automate the deployment to a QA environment
• Automate tests against the QA deployment
• Continue to bring down the build time

All of this was made possible because we were able to reproduce the build environment and standardize on a process.

Till next time…

The Evolution of a Build System Part 1

A couple of weeks ago I began setting up a new set of build servers for our west coast office.  I’ve pretty much got it setup so it is almost a push button operation.  Not quite there with all the DCC tools yet but almost.  We typically stand up one machine with the OS and run a single installation script which installs Visual Studio 2005, 2008 and the SPs.  It also installs Perforce, CruiseControl.Net and the latest console SDKs automatically. There are other minor tools the script installs as well.  I began to think about how far we had come. It wasn’t always like that…

This is a far cry from where we were when I started working at Emergent about a year and a half ago. Then there was a Twiki page that listed all of the various items required for each build machine. Your fingers ached after scrolling through the instructions.  Add this set of environment variables, make sure this path was added to the system path, install this tool at this path.  It was a very manually intensive process to setup a build machine.  Since the first thing I was challenged with was to streamline the build process, I had to have a reproducible build environment.

So, a combination of organic build scripts and manually setup machines made for a very unstable, and in my eyes, unreliable build system.  I had to first address the reproducibility of a build machine.  But where to start?  I knew we would be finishing a release soon.  Then I think it was Gamebryo 2.5. So I would start preparing for the next release cycle.

The build was taking close to 24 hours.  That was just too long.  Don’t get me wrong.  It was doing a lot of stuff.  It was building all console versions (Win32, PS3, Xbox360 and Wii) of the product and every solution configuration for each.  Then it was executing a rigorous automated testing suite.  So I chose to let that be for now.

Continuous Integration was where I started.  I had experience implementing CruiseControl.Net before so it seemed natural that I mentally moved to it.  My budget was not large so I had to make choices.  I reviewed ElectricCloud and AntHillPro. Both would have done what I wanted but where did I want to spend the little money I had?  I decided to forgo the expensive build systems and spend my money else where. 

I started small. I took a piece of the technology, the base framework, and created a CCNet project on my own box just to prove that I could do it with the C++ code. Then I incorporated each compiler, VS2005 using devenv, VS2008 using MSBuild, VSI from Sony for the PS3, and GCC and make for the Wii builds.  It took a while but the POC was working in a week.  I had some issues with MSBuild and C++ which I outline in a previous post so I decided to move to devenv for all the Win32 builds.  I will spare you the details further.

As my team was piecing the CI process and hardware together, we slowly started putting together a script that evolved through the process for build machine setup. I made sure my team knew I wanted there to be as little manual intervention to a new build setup as possible.  We re-factored existing scripts, combined them into a series of standard named configuration scripts in a well-known-location.  The team slowly began to change their way of thinking.  My mantra was as soon as you have to do something twice, evaluate and automate.  I tried to lead by example.  I engineered a lot of the initial setup and brought the team up to speed.

Continuous Integration as a culture was fairly new to Emergent product engineers.  Yes, they understood the concept and new it would help them be more efficient.  They understood the bringing feedback closer to the time of development was crucial to limiting the time it took to fix the issue.  They understood all of the reasons. But, it took a while for them to actually catch on to the whole “Red means dead” culture.  Finally, after a few months of CI in its full operation,  The engineers were on board and even worked with each other to promote the whole methodology. After all, I believe, these engineers to be the smartest people on the planet.

I was, indeed, pleased to see the fruits of my team’s labors playing out and helping the engineering team as a whole be more efficient.

In Part 2 I’ll talk about the transfiguration of a nightly build system “pieced together with duct tape”, to a streamline, reliable, reproducible build system and process.

Till next time…

Emergent Announces 2009 Results

I’m extremely pleased to let everyone know that the company I work for, Emergent Game Technologies, had a better 2009 than 2008 in terms of Revenue year-over-year.  Here is an excerpt from the press release:

CALABASAS, Calif. – February 2, 2010 – Emergent Game Technologies, a worldwide leader in 3D videogame engines, today reported a 35% increase in revenues year over year and a 58% increase in profitability for the year ending 2009.  Strong licensing deals and reduced expenses led the fourth quarter, ending the year with over 120 deals closed. Growth was strongest in North America, Japan and China, with Emergent^™’s Gamebryo LightSpeed gaining rapid adoption and driving the strong 2009 results.

“Emergent has made changes to weather the tough economic climate and is poised to become stronger than ever as a result of those changes,” says Scott M. Johnson, Emergent’s CEO. “While the Asian market and the US visual simulation market never slowed for us, we are now seeing signs that game development is starting to pick up in North America and Europe.  Our core message of reducing redundancies by using Gamebryo LightSpeed is resonating with publishers and developers.”

Based in Calabasas, CA, Emergent creates technologies that are driving professional videogame development. Emergent’s revolutionary game engine, Gamebryo LightSpeed, was released in May 2009 and provides both established and newly emerging studios with a flexible engine that continues to expand and grow with their evolving development needs.  LightSpeed empowers developers to create their games in any genre and continues Emergent’s dedication to providing a one-stop cross-platform toolset for PlayStation^®3 computer entertainment system, Xbox^®360, Wii^™ and PC.

I’d like to think that my organizations had a lot to do with Emergent’s success.  But then doesn’t every manager hope that they have a direct impact on their company’s bottom line. In the last year the Development Technologies Group had some significant accomplishments, not the least of which are outlined below:

• completed a comprehensive Continuous Integration System and process for all platforms (Win32, Xbox360, PS3, and Wii)
• redesigned and implemented new nightly build process
• redesigned and implemented new packaging process
• redesigned SCM depot to better accommodate automation
• significantly expanded build and test infrastructure to accommodate multiple branch builds
• created a new PC Test Farm for expanded platform testing

The IT Group, which I also manage, also had some significant accomplishments this past year as well.

• upgraded IT infrastructure
• implemented comprehensive backup solution using EMC’s Avamar
• upgraded internet bandwidth at our Calabasas offices
• consolidated all our web assets to a single provider
• implemented Inventory Management system
• implemented standard PC and laptop policy
• successfully addressed more than 10,000 internal Help Desk Tickets

So where do we go from here?  Well we don’t stop.  We keep moving towards helping to make our company successful! Some things we are working on in 2010 include:

• a new SVN repository for our clients to download the latest source
• a one-button build for all our products
• consolidating our IT infrastructure
• continue to provide the best service for our engineers as possible!

All-in-all, it was a good 2009 for my groups and for Emergent.  There were bumps along the way, but all organizations hit these bumps.  Its how you deal with the bumps and how you learn from the bumps that set you aside from your competition!

till next time…

Industry Shake-Up?

Some of you know that I work in the Video Game industry.  See my last post.  I do not work for a company that makes games.  I work for a company that makes what is called a “Game Engine”.  If you are not a gamer you have no idea what i am talking about.  If you are a gamer then you are familiar with the term. The company I work for is called Emergent Game Technologies.

Yesterday, another game engine maker Epic (Makers of the Unreal Engine), decided to offer part of their engine to developers for free.  Yes, that’s what i said, for free.  Most around the office here, upon hearing the news, were a little pissed off.  But then most of us started to really look at the announcement to try to understand what it meant to Epic (the makers of Unreal) and to us as a game engine company.
What does this mean to Epic?

1. Sales leads
2. Sales leads
3. Sales leads

When you download the engine from Epic, you supply all the standard info.  Epic then follows your progress. 

Then there is the gotcha.

• No Support - To quote Epic directly "Epic Games, Inc. will not be providing direct support for this product. "
• If you develop an internal application, you pay Epic $2500 per seat, per year.  To quote Epic directly "If you are using UDK internally within your business and the application created using UDK is not distributed to a third party (i.e., someone who is not your employee or subcontractor), you are required to pay Epic an annual license fee of $2,500 (US) per installed UDK developer seat per year."   Did I say free above?
• If you develop a game and that game is sold with revenues greater than $5000, you pay Epic $99 plus 25% of your revenue.  To quote Epic directly "If you are creating a game or commercial application using UDK for sale or distribution to an end-user or client, or if you are providing services in connection with a game or application, the per-seat option does not apply. Instead the license terms for this arrangement are US $99 (Ninety Nine US Dollars) up-front, and a 0% royalty on you or your company's first   $5,000 (US) in UDK related revenue, and a 25% royalty on UDK related revenue above $5,000 (US).  UDK related revenue includes, but is not limited to, monies earned from: sales, services, training, advertisements, sponsorships, endorsements, memberships, subscription fees, rentals and pay-to-play." Did I say free above?
• Only available for PC development.  If you want consoles, you pay Epic their normal price for the engine.  Did I say free above?

So, to my untrained eye, what this means is Epic will get money from you some way or another. This is great for Epic. A smart move. You could basically say that this is just a glorified, extended evaluation of the product. A single AAA license that comes from this move could mean Epic brings in a half million dollars. And that is conservative.

This is not necessarily great for game developers. It limits their choice because they will immediately go for FREE. I equate this to Microsoft offering Internet Explorer for free back in the 90s. I started using it, because it was free. But, the industry paid for it in the long run. Now we have less choice. Sure there is Firefox and Chrome. but those are relatively recent. It took a long time for competition to get were they needed to be to break Microsoft’s hold on the market. They are still trying.

What does this mean for Emergent Game Technologies?  We differentiate ourselves in a couple of ways.

1. Our support to customers and evaluators is second to none.  Does Not Change!
2. Our product, Gamebryo LightSpeed, addresses the rapid proto-typing, rapid iteration areas of game development like no other product. Does Not Change!
3. Sales – This is the change – We now have to address the gap.  Those startups looking to evaluate an engine that will grab the first one they can get their hands on.  I can assure you, our Sales and Marketing Team is already implementing a strategy that addresses this space.

Will Emergent become the Netscape of game engines and fade away into (made with Gamebryo) Oblivion? I wouldn’t count on it.  Will Epic continue to dominate the market and grow market share?  In the short term, yes.  But who knows what tomorrow will bring.

Till next time…