Middleware - Beware

     A recent news article has sparked something I have been thinking about for a long time. The dependency a developer now has on middleware providers.
The industry over the last 15 years has switch from developing all parts internally for a program to outsourcing pretty much everything not directly related to the core experience of what they are trying to develop. 
    Middleware is probably not the proper term to be using here as middleware in the SE sense refers to software that connects disparate components together to create a working program. It is more correct to talk about licensed components. 
    These components are thinks like the Quake and Unreal graphics engines, PhysX and Havok physics engines, ProFX texture engines and many others. They generally have a fairly defined task at which the component developer has a large body of experience and has built and optimized toolset for. 

    Component purchasing has been a good thing for the industry in many ways. 3rd Party Components ease develop time and costs in that they reduce internal R&D and debugging. The cost savings have been fairly dramatic for most industries and the reduced R&D time has allowed better critical path management  (R&D can't be scheduled) so programs are finished on time more often than not.  

   An issue not considered until recently is - what happens when a Component supplier is purchased by your competitor. It has happened with Ageia (Nvidia), RenderWare (EA), and is likely to happen to Epic (Microsoft). 
   When that happens do you continue to use the technology you have licensed? Do you seek another Component developer (if they exist)? Or the final safest solution but definitely the most costly... back to the drawing boards and develop from scratch.

   Each of the solutions has it's drawbacks and advantages.

1) Stay with your Component Provider:
Good:
    No rebuilding of code
    No retraining on a new engine
    Critical path protection
    Lower risk of potential error
Bad:
    Possibility of your proprietary code/concept being seen by competitor
    Uncertainty about future of engine (can it be used for sequels)
    Will it be available for your Platform?
2) Change Component Supplier.
Good:
    No R&D Costs
    Protect your concept/code from competitor
Bad:
    Recode segments of your program
    Retraining
3) In House:
Good:
    Protect your concept
    Total dependability related to code ownership
    Can specialize the code more
Bad:
    Costs
    Critical Path Management
    R&D - requires specialized programmers and no set time
    Here's one we don't normally think of but - Potential Liability to original component supplier. Companies like EPIC hand over the entire source code to their engine when you license it. That means anyone that has seen the code and may be influenced by it's design can not be allowed to work on your internal engine.

    The balance act that is created by this is: Time. vs Cost. vs Secrecy. vs Longterm Dependability. vs. Liability. A lot to balance and yet it's something that Publishers/Management do all the time at a high level (most of us developer coder types don't really think about it.) I guess it is time that we do. If our product can be controlled by outside factors beyond our control is it  really our project anymore? Yes... and No. And that answer scares me.
    I wonder if these changes will create another change in the industry - back to the way it was - vertical code integration, accept the higher costs, and lower your risks. I suspect that it won't go that far but that we will be more circumspect about the components we buy and what our contracts entail. It's possible to put no acquisitions clauses into contracts and even stricter privacy rules.... so developers follow the lawyer path fully at last.

[JoelR]

- hmm image linking didn't work -

[evilbubble]

I guess it really depends on what kind of game you intend to develop, your core expertise and of course your budget. Unreal Engine is of course far more suitable for FPS type game that let's say RTS game. If you intend to develop RTS game, you may be better of starting from scratch rather than modifying Unreal Engine.

I guess the increasing cost of developing game is one of the reason why Sony has a 10 years plan for their PS3. A console has to stay in the market for at least 5 years, in my opinion, for game developers to put 2-3 games into the market. Of course it really depends how big the developer is. The more games a developer can put in into the market without starting from nil for their engine, the better the possibility of profit for them. Not to mention they can focus more on the game play, story and etc than the engine.

One thing I will argue here is, since HDTV standard will last for at least 10 years. PS3's quality for certain type of games will still "relevant" for at least 10 years from now. Games like 2D fighting, puzzle, turn based games like Fire Emblem series and etc "might" still look pretty enough using engine developed today or at least the modification of it. And most importantly there is a market for those type of games. Therefore backward compatibility for PS4 is absolutely crucial. A game developed for PS3 should work without any issues for PS4. Therefore low to mid-tier developers can still develop games for PS3 cheaply and have access to PS4 market as well.

The same goes with Xbox360. Wii is a bit different though....

[JoelR]

A different engine style should probably be used for entire genre changes but I am still amazed at what the Unreal Engine and it's competitor have be shoved into. A good engine can morph enough to handle things outside of it's expertise but it will be hampered.

And you are Absolutely right about the life span of some engines. An engine in development/use right now could still see use in ten years. See Insomniac Games - their engine has now been used in 3 titles and with each round they have done revisions to make it more effective. Resistance -> Ratchet and Clank Future -> Resistance 2
Their engine I expect to evolve as the platform ages and as long as the CPU paradigms don't change the basic idea of their engine won't have to change much. (more cores won't hurt - an entirely processor design would)
With systems based on the cell I would expect more SPUs and PPUs but no real radical changes in the way the system operates (unlike the previous generational leap - single to multiprocessing)so your observation holds water in my mind.

[Richdad]

Sir, as you state that when you go for Middleware i.e total component provider you cant modify the codes but in Bioshock Irrational game shave seem to done so. It really too colorful to be Unreal, it looks Unreal engine if we see it by some features but its heavily modified.

[JoelR]

Oh you can modify code - but that modified code now belongs to the middleware provider if not directly but by proxy. You have a license to their engine but they have access to all your code.
Middle ware is great for a lot of things but being vertically integrated doesn't hurt either.
Startups should almost all use middleware (cost and development time are paramount)but if you have a decent size nestegg and a good reputation I recommend doing your own thing rather then licensing.