Moral Capitalism

23 January 2013

Greed is Good” is the catchphrase for a Canadian TV show on business starring Kevin O’Leary. When did business go so wrong?

First off, I’m a capitalist. I have a company and we employ people who perform valuable work which we bundle up and sell. The goal is to put in X amount of money and pull out more than X, hopefully a lot more than X. I engage in business for a few reasons, the major factor for me is probably for some control over my own destiny. If things are going to go poorly for me I at least want to know I had input all the way down. I also engage in business as an active investment strategy. Instead of putting my money into a faceless mutual fund or some oversea opportunity fund, I choose to take a risk in myself and my co-workers. I think we can outperform the average investment vehicle. I also want to keep my investment local and support my local community.

I’ve been lucky enough to have participated in two acquisitions of my former company, Bioware. We were first purchased by private equity firm, Elevation Partners http://www.elevation.com/ as a two studio deal. Two years later we were sold to Electronic Arts. Both times the acquisition worked out in my favor. Most employees at Bioware saw some return on both acquisitions. My perception of the deals might be a bit skewed, but I believe the thinking behind the initial Elevation deal was to build a new publisher. The first acquisition happened just as we were making a transition from Xbox and PS2 to XBox 360 and PS3. During this period, we saw a rough doubling of the input costs to develop a top quality game. My guess is the Elevation business plan was drafted in an earlier time and the new capital requirements caused them to shift strategies and they sold the company to Electronic Arts as a method to escape from the earlier strategy. Good on them for seeing the problems, making a call and changing plans. As well, hats off to them for ensuring employees saw a share of the proceeds.

I think Elevation is very atypical of many private equity firms. I think they honestly wanted to build a new powerhouse publisher and realized the offer from Electronic Arts for the studios was a better outcome. I’ve seen way too many stories of what I consider morally bankrupt business decisions.  The Bear Stearns real estate fraud comes to mind: http://www.sec.gov/news/press/2012/2012-78.htm

Reading about the practice of the leveraged buyout the private equity firm Mitt Romney participated in it seems again like morally bankrupt business.  http://www.bloomberg.com/news/2011-07-20/romney-as-job-creator-clashes-with-bain-record-of-job-cuts.html

I think the problem comes down to a willing blindness towards the broader impact of business decisions. “We make money for our shareholders” is the rallying cry. Behind this cry many companies make horrible long-term decisions and in my opinion, unethical decisions. “Growth” is the other major driver. In nature, everything reaches a maximum size and balances out. I think this is also true of companies. In my opinion, these companies that demand continual growth at some point are no longer an organism within an ecosystem, they become almost a virus or cancer, instead of living in the ecosystem, destroying it.

This isn’t really a coherent argument and I do not have a clear solution,  I’m just thought dumping at this point. But, I do think there are steps towards a solution. I think we as individuals, as consumers, as investors have a great deal more power than we might believe. I think by changing our behavior we can enforce broader change.

My personal goal is to be a more directed investor,  a more informed and deliberate consumer and to operate my business in a manner to benefit my partner and I, our employees and our community. I think it is high time we  told people like Kevin O’Leary his one liner “Greed is Good” is wrong, juvenile and not good business. I also think we need to call fraud a lot more often than we do. I think more high profile cases of morally bankrupt business decisions turning into criminal cases would go a long way towards cleaning up the world we know.

-Trent

 | Posted by | Categories: Rants |

So, I recently tweeted “Wii is a Toy”.  I clarified my point was around the large sales numbers not really representing the software market on Wii for independent developers.  I also dropped such gems of wisdom as “We don’t do Nintendo development”, ” Our previous experience with Nintendo was enough to ensure there will not be another” This all generated a lot of fun for journalists as each spun my little sound bites.  In reality, it is a poor communication of a business decision based on our development experience.

I feel I did a disservice. My career has been filled with the delivery of hard criticism, I always try to call it as I see it. Sometimes I wax dramatic for effect.  But, I always believe criticizing  without offering a solution is worthless.  In this case I did not offer a solution. So Let’s fix that omission:

How Nintendo can improve digitally (for smaller developers)

  1.  Put online and digital front and center.  When you are on the console, you need to know about new, interesting titles and how to get them.  With the Wii this was not so.  On future systems you need the online experience to anchor the system.
  2.  Positive Exposure. On Xbox live, it was Jonathan Blow with Braid. On Steam, Team Meat with Super Meat boy. Reach out, identify the best indie game on your service, move that game to the store front page and post a story about the developer with the game. Co-market the game as if it was from a big publisher, put some PR muscle behind the title and the developer, set them up for interviews and coach them on promoting their title. From this effort you will get a number of positive outputs: Sales, loyalty for the developer and newfound respect from the development community.  You’ve got some good indie titles for 3DS, so push them hard and create a feeling of indie success on the platform (cough,Renegade Kid, cough)
  3. Open up.  You can’t succeed today by requiring a ton of secrecy around the platform.  Blocking people from talking sales numbers just kills potential interest in developing for the platform.  If the numbers are bad, you need to figure out why they are bad.  The success of the various download services has shown the market is ready for digital distribution, so don’t hide problems, hit them head on and fix them.  Kudos so far on 3DS for mentioning things needed to get better than on the Wii.
  4. Drop the minimum sales limit to a reasonable number.  It costs money to send money (apparently this “wire” thing is expensive)  so set the limit at a reasonable level, say $1000.  For a small developer that might just make the difference.
  5. Call a product out.  If you get a submission for cert and it is a pile, kick it back fast to the developer and suggest they up the QA process.  Don’t treat everyone the same, fast track good, interesting games which are close to ship and be open about what you are doing.   When a product is horrible, send the feedback quick and tell them what they need to address before you’ll look at it again.

Hope this helps.  Not really rocket science I know, but it is free advice.

I really hope Nintendo can succeed in the next generation, a world without a new Zelda game is a sad place.

-Trent

 | Posted by | Categories: Rants | Tagged: , , |

Payment processing

5 March 2012

This is an odd topic and doesn’t have much to do with game development, but it is bothering us over at Beamdog.  Once in a long while we get a customer who has their credit card declined.  We’d like to help them out, we’d like to give them a solution to the credit card problem (we currently send them to Paypal), but we can’t.  The information we get back from our payment provider is “card declined”.  After digging into the lack of a useful message, it appears that is the message our payment gateway gets as well.   So:

CREDIT CARD COMPANIES: You need to improve your shit!  “Declined” is about as useful to a vendor as telling us “selly no worky”.  I want/need to see some more data.  Is this a foreign card, has it expired, did they screw up the securecode or whatever other BS you guys put in place to try and make cards useless on the internet?  In the current era there is no reason why you can’t give us some extra information so we can work with our customers to solve the problem.

Somebody do a start-up that re-imagines the credit card process and have these guys buy you, because the current state of the credit card payment pipeline is pretty sad.

 

-Trent

 | Posted by | Categories: Rants |

This mode is much more familiar to multiplayer gamers everywhere as this is how the vast majority of multiplayer games are run.

By keeping the rendering local, we remove some of the latency.  We also have the advantage of  hosting a local executable, where we can use local processor cycles to aid in hiding latency.  Most multiplayer games use a variety of tricks to cover up latency, the major one I’m familiar with involves running a local simulation of the world physics, with the server arbitrating any conflicts.  This allows the game to feel much more responsive and makes use of our local processing power.

A key point to remember is that in the case of remote-server cloud-gaming a multiplayer game, this entire process is happening on a remote computer, so you get all the latency of the cloud gaming service, plus the latency of a normal multiplayer game.  Not an optimal scenario.

 | Posted by | Categories: Rants |

Cloud Gaming

29 September 2011

I’ve been talking to a few people lately about the future of gaming and the cloud.  There are a few potential models for cloud gaming, so let’s lay them out:

  1. Remote Gaming – This is what services like OnLive and Gakai are offering.  The game is run on remote hardware and the user input is collected, sent , processed, graphics are generated, compressed and sent out as a stream of video.
  2. Local Client, Remote Server – This is what all the MMO games on the planet are.  This segment also covers the majority of Facebook games.  The game graphics and input systems are run on a local application or in a browser.  The game logic is run on remote hardware, passing game events back and forth between the server which runs the game logic and the client which handles and displays the user interface and rendering.
  3. Local Client, Remote Distribution and Storage – This model is closest to the traditional gaming model with the addition of online storage and distribution.  The game input, graphics and logic are all run locally.  The online component is a remote server which supplies the assets, which are then cached locally and a location for save games.
Let’s dig into each model and hit the high points.

Remote Gaming:

Remote gaming sounds great as a concept:

  • You don’t need a high end computer or console to play a game.
  • You can get gaming “instantly”
  • You can game from home, work or on the road
But, the reality is a little less spectacular once you dig into what is actually going on.  At some level, there is a computer running the game you are about to play.  The “instant” gaming part saves you clicking an icon and watching an initial loading screen.  The game will still need to load levels, load all the character models, start the game, etc.
Latency:  To me, latency is the elephant in the room for cloud gaming.  As a game developer I obsess over the user experience, I obsess over the feel of the controls, the responsiveness of the character and the “feel” of the game.  Let’s look at what happens on a game running on your computer.

If you look at the image,  the black lines are what happens when a game loop is run normally (or on a local machine).

The green lines indicate areas where extra work is performed.

The red lines indicate data transmission over the internet.

 

This doesn’t look too bad until you take into account the latency of each step.  The black steps are basically instant.  The stages take varying amounts of time, but for a game running at 60 frames per second, all these stages happen 60 times per second. (So they need to fit into 1000 msec / 60 times/sec = 16.7 msec)

The green lines require extra work, but video compression/decompression is a well resolved problem.

The red lines are where the latency kicks in.  We have latency in collecting the input and sending the video.  Back in the day, I played a lot of Quake.  Anything below 120 msec of ping and you were at a severe disadvantage.  Quake did a lot of smart things to hide and compensate for the latency as well, most multi-player games do.  Single player games however, do not.  What this means is every time you move the mouse, it must be collected, sent to the server then handled and then the game calculates the result and sends back the video.  If you have any form of lag it shows up in everything, mouse movements, clicking, typing, etc.  This is the Achilles heel of remote gaming, you are using a computer miles away using a remote control.  The remote has some lag from your input until you can see results, which causes the experience to degrade in quality

 

 

As a game developer, my first concern is for the consumer of my game.  I want the experience to be the best possible and I want to ensure they get the benefit of the hard work my team has put in.  Loosing control of the “feel”  of the game is to me a sub-optimal solution.

I’ve already spent too much time on this, so I’ll come back later and hit the other modes.

 

-Trent

 | Posted by | Categories: Rants |

I recently was asked a few questions by a fellow who was early in his career and wanted some of my thoughts on topics he was facing.    After I’d answered his questions I thought the answers were worth sharing, so here goes and I hope you think they are worth sharing as well.

 

 

Q: Were there some hard career decisions regarding my career direction and what did I do?

The only major decisions I made were early on I asked to move from pure management (3D department head) to product management (director) I made the same decision twice when I had been moved to more pure management roles.  I realized I loved making things and just managing people didn’t satisfy me at all.

 

 

Q: How would you describe your management style?

My management style kind of grew out of a few core concepts, some of which came from the memoirs of Colin Powell (I’d used the basic concepts before I read about them it just helped to put them into words).
  1. Ask first, talk later. – My best work was always when we encountered a problem and I’d sketch out the problem and then ask my core group for their thoughts.  I already had an idea what I wanted to do, but sometimes they managed to change my mind before I spoke.  It also allowed the person who suggested the concept to take ownership of it.
  2. Know what you are building. – Early on my projects we always did a mockup of what we felt the game should look like at ship.  This allowed everyone to have a common touchpoint of what the game would be and ended a lot of discussion before it even started (“let’s look at the mockup”)
  3. Talk to everybody. – During NWN I spoke with everyone on the team at least once a week.  I’d wander by, ask what they were up to and then casually dig into problems they were having.  I’d list out the more serious issues and do something about them as soon as possible and ensure the person knew the issue was addressed.
  4. Understand your role.  – At the start if the project, the Director has to provide vision.  In the middle it is support and editorial.  At then end it is almost 100% support and enabling people to work.  I really approached problems my team was having with an attitude that the people doing real work were more important than I was.  Anything I could do to free them up to do more work was my top priority.
  5. Presenting a positive outcome. – I screwed this up later in my career and it ended with a cancelled project.  The director is going to know about funding issues or publisher issues.  Some of this information the team needs to make the right decisions, some of it they don’t need to know.  You are a leader an as such you have to make the team feel like they can win, if they don’t feel victory is possible, they’ll go play for a different team.  I support transparency, but until something is certain, you don’t need to pass on uncertainty to your team.
  6. How about now? – By this I mean a complete unwillingness to put off something which could slow down my team.  If we were blocked by a decision, we’d grab the people who needed to be involved and solve it right then.  I didn’t schedule important meetings early in the project, I made them happen when they needed to.  Later on I fell into the lazy trap and started scheduling weekly meetings to deal with issues and these wound up deflating the impact of right now.
Over time I became less rigid in my taking care of people, and resolving issues, mainly as a result of a loss of connection with the leadership.  I had a really hard time feeling our leadership was not listening and my diligence took a huge hit.  I started deferring and handing off way too much and way too important tasks.  As a startup founder, I’m getting a kick in the ass to rediscover my old behaviors.

Q:  you mentioned believing part of BioWare’s success was not understanding how many things could go wrong with a project. It seems common to run into problems that no one else has solved. What is your process for going about finding and developing a solution?

Is there a point in R&D where you say it just isn’t possible to get a feature done, or rather the path solution to a problem your working on isn’t the right one? How do you determine it?

The key with R&D is to figure out the problem you are trying to solve.  Really dig into it, ask why it needs to be solved.  Ask if there is any way to fake it or build another solution.  R&D only makes sense when the user will notice.  If someone will play your game and not notice the results of the R&D, don’t do it.  In the early days of Bioware, we didn’t know much, so we did a great deal of R&D, solving huge problems which probably didn’t need to be solved in hindsight.  I always leaned on my previous programming experience when we talked about R&D, and I could usually tell a rough order of magnitude around the problem.  As a start-up, we avoid R&D like the plague.  If we need a complex solution which doesn’t currently exist, we dig into every possible way to solve it using know technology.  I’m lucky in this respect because my business partner in IdeaSpark Labs / Beamdog is Cameron Tofer.  Cam was a former lead programmer at Bioware and a Tech lead at Namco.  He’s done a ton of R&D and as a result, he fights pretty hard to avoid it.  If we need to solve the problem and it must be done, he’ll get into it hardcore and answer the fundamental questions quickly, without getting fancy.  The big fear is that programmers love to feel smart and solving big, hairy problems makes them feel good.  In some cases, people will pick a problem not because it needs to be solved, but because it will be a challenge and if they succeed, it makes them feel great.
So, with R&D:
  1. Know the problem you are trying to solve
  2. Come up with a few ideas for solutions to the problem
  3. List out a few simple experiments you can perform to validate the potential solutions, ensure they have metrics for judging success
  4. Build a quick and ugly prototype based on the experiments which solves the problem.
  5. If everything works out, junk the prototype and build the real solution using the concepts proven in the prototype.  If you built the prototype correctly, the code shouldn’t be readable.
I had fun answering these questions and it helped me to try and articulate some of my thoughts around management and R&D.  Thanks to M. for asking.
Cheers,
-Trent
 | Posted by | Categories: Rants |

Life in a Startup

15 July 2011

I recently ran across a drawing depicting the early life of a startup.  The image was part of a presentation by  Sarah Prevette on Your first startup.

 

 

 

 

 

 

 

 

 

 

 

Having lived through this exact cycle for the last two years I’m amazed at how succinct the image is in capturing the turmoil of a startup.   I ran across the image on Facebook through my good friend Jason Della Rocca and I started digging through Sarah’s blog.  Some truly great information there.

After slugging it out for the last two years, I’m convinced a big part of our early success at Bioware was a complete lack of perspective on how many things could go wrong.

 

-Trent

 | Posted by | Categories: Rants |

You often hear RPG fans discussing titles and either lauding a title for great depth or deriding another for a lack of depth.  What is depth?  In the terms of rules systems, what the user perceives as “depth” is a level of complexity to the rules which require some effort to understand.  Titles which lack depth typically have simple rules and are easy to understand, but at the same time are very limited in reach and scope.  Titles which have depth exhibit reward for learning the rules and engaging in strategic use of abilities or actions to gain advantage in the game.  I’ve personally been involved in the “interpretation” of a pen and paper rules system into a real-time computer combat rules system.  This was not a trivial exercise, as the rules were complex and inter-related.  The end result was a high degree of perceived depth, but at a very high cost in implementation.  Our approach was to reduce the rules system into as many simple atomic actions as possible and then develop a structure to process those atomic action elements accordingly.  This did force us to “interpret” a few spells in a slightly different manner than described, but as a whole we felt we maintained the integrity of the rules.

 

If you think in game rules as how a computer would treat the interaction of the rules, you can better understand the issues.  Imagine a case where you have fire based spell and it does a 5 hp of damage to the target.  But, if the target has an item which grants protection against fire, the character takes no damage.  This is easy enough to describe, but from a programmatic standpoint it requires more thought.  If there is only ever one fire spell in the game it is easy enough to implement.  If the fire effects are many, it makes sense to order the rules into a logical flow.  In the fire spell example, I would create a spell item which assigns a “fire damage effect” to the target player.  The effect is evaluated at the player object during the rules arbitration.  Given that the player has a protection item, the effect is checked against a list of character effects, such as fire immunity.  As such, the fire damage effect is dismissed and never applied.  This simple effect and modifier stack allows us to model great rules complexity, but allows us to keep the mechanics very simple.  We have a series of simple systems interacting to deliver complex behavior.  The effect evaluation stack was a key component in the design of Neverwinter Nights and other Bioware RPG’s as it allowed us to take somewhat arbitrary rules and classify them and have them behave as part of a system.  This is also the reason we did not implement certain spells and abilities, as they did not fit into a systemic approach and as such would have added greatly to the complexity of the system in unstable ways.

 

The evaluation stack also allowed us to systemically support timed events, temporary effects and a whole host of other complex interactions without going mad.  Consider a temporary fire protection potion, it applies an effect to the player which is set to exhaust in four turns.  When fire is going to be applied, it is evaluated against the protection effects active and is ignored.  When the fire protection expires, it is removed from the stack and the fire effect damage is applied normally.  This schema allows for a great deal of complex interaction modeling without having to go in an custom code each individual spell.

 

If you are creating a rules system from the ground up, I would put forward this atomic element approach as you can engineer a great deal of predictable, yet complex behavior from simple interacting elements.  If you attempt to add complexity from the top down, without a simple underlying system to handle them, you quickly create an unpredictable and very hard to test monster of complexity.

 

-Trent

 | Posted by | Categories: Rants |

Game (and more generally, software) developers are optimistic people.  The act of creating anything requires a certain degree of optimism, as you start from a blank file and lay down code.  The reality of coding is to take pure concept and commit it to a working system.  This never goes as smoothly as planned.  In most cases, only by attempting the work do you find out the initial selected approach is not the correct one.  I’ve seen many experienced and inexperienced developers get caught on a “light” estimate for how long something is going to take.  Often the time quoted is simply development time and does not take into account the extra required time for debugging, performance tuning, documentation and proper testing.  The first major step to taking proper estimating is to agree on what needs to be accomplished.  We often called this “writing the spec”.  I’ve personally erred on both sides of the specification equation, providing too tight of a specification which doesn’t allow the developer to leverage his/her experience and the other side, which is almost a blank ticket to write anything.  The best method I’ve run across is using a “user story” format which details who the user is and what the planned user experience should be.  This method communicates the target without laying our too many hard requirements.  In most cases, even a junior developer (with a little technical oversight) can meet the requirements as laid and and have room for creativity.

A proper “User Story” needs to do a few things:

1) Describe the user

2) Describe the desired outcome

3) Detail any “hard” requirements

4) Outline the expected effort

 

So here’s my example:

As a mainstream game player I can select a character on the screen by clicking on that character.

When selected the the character should:

  • indicate selection by displaying a coloured circle beneath the character.
  • indicate selection by displaying a highlight box around the character portrait.
  • execute all input commands until de-selected

Scope:

This should be a basic selection system based off the existing UI system.

The system must be able to integrate with the existing party system.

Any required input code should be maintained within the Input class.

The code should compile and execute under all specified target operating systems without errors or warnings.

This system is expected for delivery in two weeks time, including testing, documentation and initial performance tuning.

 

The above example is very arbitrary, but I have yet to find two people who write them up the same.  What I feel is important:

  • Be specific on desired outcomes
  • Give detail when it helps solve the problems
  • Be specific on hard requirements.
  • Ensure there is a timeline clearly associated with the work.
  • If the work is taking over a month, break it down into smaller deliverables.

The best work I’ve done in this area has been when I understand well what I’m trying to describe and I use a few descriptive lines to convey the desired user experience.  You will need to adapt your user stories to fit your personal writing style, but always try to keep your eye on the end user experience.

 

Best,

-Trent

 

 

 

 

 | Posted by | Categories: Rants |

Looks like Apple has stepped up and is advising the Lodsys fellows to cease and desist.  http://www.macworld.com/article/160031/2011/05/apple_legal_lodsys_letter_text.html

Nicely Done Apple.  Here’s hoping the patent trolls back off for a while.

I’ll return to your regularly scheduled programming as this is entirely too drama filled for me.

 

-Trent

 | Posted by | Categories: Rants |
Get Adobe Flash player