Slashdot Mirror


EA Announces Multi-Title Unreal Engine 3 License

An anonymous reader writes to mention a Gamasutra article about a surprising announcement from EA. They've made the move to license the Unreal 3 Engine for a series of next-generation titles. "The brief announcement states that EA 'employs a variety of engines, tools and technologies to best serve the needs of each game and development team', but raises interesting issues regarding the Criterion-authored Renderware engine, purchased by EA in 2004 alongside the Burnout developer, and its intended global EA rollout."

54 comments

  1. Cool. by Antony.S · · Score: 2, Funny

    (well, someone had to reply eventually)

    1. Re:Cool. by AcidLacedPenguiN · · Score: 1

      I'm starting to wonder about that Unreal 3 engine. I mean, its being made out to be this super engine that can do ANYTHING. We're seeing everything from FPS to RPG to EDUTAINMENT titles popping up all using it.

      I know that if anyone can make a game engine its their engineers, but do you suppose it's really THAT robust?

      --
      disclaimer: I've been known to store numbers in my ass for which to dig out when quantities are required.
    2. Re:Cool. by Antony.S · · Score: 1

      Well UT2004 (UE 2.5) had lots of great mods so its possible, I trust Atari a lot more than id after the disaster that is D3/Q4

  2. Another Boneheaded Move By EA by Anonymous Coward · · Score: 0

    First the RenderWare fiasco and now this boneheaded move.

    The world doesn't need more Bald Space Marines in Bumpy/Shiny Armor games. And what is even worse is that so far the UE3 games that have been shown like Gears of War have miserable framerates and only bogus marketing shots(ultra-high rez with massive AA applied) are being released and no public demo.

    Not a vote of confidence from the engine's own developer.

    Something is seriously wrong at EA if their own internal development teams can't come up with something better than the Doom3ish low poly/overly normal mapped rendering engine from Epic. UE3 is an engine designed for the archaic x86 pc architecture(weak CPU connected to a GPU by a slow bus) and using it for a modern console is a ridiculous waste and assures EAs games using it will look no better than mid-range pc games.

    Bleh.

    1. Re:Another Boneheaded Move By EA by Anonymous Coward · · Score: 0, Flamebait

      "UE3 is an engine designed for the archaic x86 pc architecture(weak CPU connected to a GPU by a slow bus)"

      Can the anti-x86 trolls just move along please? You don't know a damned thing about CPU design, yet you feel qualified to blather on about how poor the x86 is, despite the fact that it still walks all over everything even remotely in it's price range.

    2. Re:Another Boneheaded Move By EA by Durrok · · Score: 1

      "Something is seriously wrong at EA if their own internal development teams can't come up with something better than the Doom3ish low poly/overly normal mapped rendering engine from Epic."

      No, not at all. They know when they release their new "bumpy shiny armor" FPS it will sell x amount of copies for x amount of money making them x amount of profit. As long as X > Development costs, they will keep doing it.

      AC I think you have more problems to worry about then EA though. You seem to have some weird split personality going as your next comment is flaming your original comment. Seek help.

      --
      I keep telling myself I'm not the desperate type.
    3. Re:Another Boneheaded Move By EA by Anonymous Coward · · Score: 0

      Wow! A game console maker switched architectures with the release of a new system! That's NEVER happened in the past! Oh wait... It happens every time with every manufacturer. Guess it's not that much pain to do, huh?

      Now you can go back to jerking off to PPC/MIPS/ARM or whatever underdog-of-the-week you think is getting screwed by Intel. Clown.

    4. Re:Another Boneheaded Move By EA by Anonymous Coward · · Score: 1

      I had nothing to do with previous posts, but Microsoft dropping the x86 (in particular the intel x86) had little to do with performance and much more to do with licencing costs.

      The original XBox was designed much faster than any other console has ever been designed (went from an idea to a full fledged system in 12 or 16 months IIRC); the problem with this was that Microsoft had to stick to (mostly) over the counter components. Microsoft didn't bother to get decent licencing terms from either Intel or nVidia and in the long run this cost them because the licencing they were paying eventually was more then it would cost to buy the processors wholesale, and it prevented a major internal redesign that would cut costs dramatically.

      Contrast this to Nintendo, who spent 4 years working with ArtX and IBM to produce the Gamecube; the licencing terms were so sweet for Nintendo that (even though the system was about as powerful as the XBox) Nintendo charged dramatically less then their competition and still turned a profit on hardware.

      IBM became the default processor for all three consoles this generation because of their willingness to produce a high-quality processor at a reasonable price while maintaining a flexable licence.

      As for the x86 processor, the AMD X2, and Intel Pentium 4 processors have (in practical terms) about the same performance as either the Cell or Xeon processors; the problem with both these companies is that they are not going to allow you to produce their processor for them and are going to be very reluctant to work on incorporating a graphics processor into their CPU's (as Sony did with the slimline PS2).

    5. Re:Another Boneheaded Move By EA by Anonymous Coward · · Score: 0

      The world doesn't need more Bald Space Marines in Bumpy/Shiny Armor games.

      That sounds like the advert for Alias|Wavefront's Maya - End Digital Baldness badges that they were handing out some time ago.

    6. Re:Another Boneheaded Move By EA by DrDitto · · Score: 1

      Parent poster is right. Intel and AMD have proven that the ISA is irrelevant to processor performance. Modern x86 chips implement a RISC superscalar out-of-order pipeline internally. Of the 100+ million transistors on the die, Intel/AMD only have to burn a million or so to implement the x86->RISC conversion (called uOps or micro-ops).

      And no, architectural registers is largely irrelevant also because of techniques like register renaming.

      So yes, the anti-x86 trolls should move along. x86 is here to stay and it doesn't matter.

    7. Re:Another Boneheaded Move By EA by Anonymous Coward · · Score: 1, Interesting

      This is simply not true. The modern x86 is designed for, and great on, general code but if you have a loop and you want to optimize it to the max you cannot obtain the same clock-for-clock performance on an x86 as you can on say the PPC and the factor is somewhere between 20% and 50%. This is partly down to register name shortage (it does matter when you can't express your algorithm without inserting several dozen extra u-ops, and those stack pushes are not optimized away). The other big reason is that PPC has predictability while what's going on inside the x86 is anybody's guess. You can't optimize for x86. Abrash's best work is pure trial-and-error.

      The x86 may be "here to stay" in the desktop or server PC (er, until you want more than 2GB of RAM) but it's dead in the water in every other CPU-based industry. All that x86 to RISC costs a fortune in die size, power consumption and maximum throughput efficiency. The only reason anyone buys an x86-compatible processor today is (duh) to run x86-compatible code. If there is no legacy code to cope with, no-one uses x86. Microsoft made that mistake and lost a lot of money and market placement as a result.

      Anyway the x86 ISA is a 32-bit ISA and it can't survive past the current generation of 32-bit CPUs so your point is about 5 years too late. The death of the x86 ISA is right around the corner. It will live on in software emulation just as the 6809 did.

    8. Re:Another Boneheaded Move By EA by Anonymous Coward · · Score: 0

      Wow. Please go take a graduate-level computer architecture class. You want an example of a "new" ISA that is completely predictable and offers the compiler oogles of opportunity, look no further than IA-64 (e.g. Itanium). Of course it will die at the hands of x86-64 and this isn't because people are yearning to run Office 95. Apple had every opportunity to switch ISA's but they went to x86-32 simply because of performance/power. Core Duo is unbeatable right now. ISA is irrelevant.

    9. Re:Another Boneheaded Move By EA by Anonymous Coward · · Score: 0

      Perhaps you should follow your own advice and take a crash course in Business; your 'Apple chose x86' example doesn't have any validity. Because:
      - they chose PPC before and did so supposedly for the same reasons, so suddenly the 'x86' architecture becomes better?
      - their decision process is obviously based on a lot more factors that just performance/power : how about production capacity, price, market perennity?

      Your 'Itanium' example is of the same caliber: you are dismissing the 'predictability' quality of a good CPU design by using as an example a bad CPU design showing this quality. It's like saying that planes going over mach 1 are bad because the Concorde crashed.

      Finally, you say it yourself : "Core Duo is unbeatable _right now_" (emphasis mine). It's just a temporary quality, so it cannot be linked to the overall x86 architecture.

    10. Re:Another Boneheaded Move By EA by Anonymous Coward · · Score: 0

      Apple started losing money and mindshare because IBM screwed them over on the PPC roadmap by diverting resources to stuff like the Cell. Maybe you should pay attention to history instead of architecture? The decision to go with x86 was not exactly technical. IBM forced them into a corner and Apple jumped.

      I assume from the lack of any technical points in your rebuttal that you don't actually know what you're talking about. You appear to be arguing from the point of view that "out-of-order" is in some sense provably more optimal for every class of program than "in-order". I can assure you that this is by no means the case. (Or maybe you're just saying that because "everyone knows" that IA-64 has "lost" and because Apple changed to x86 then some broad technical point is thereby proved. Er ... not sure how to respond if that's the case.)

      I agree that x86-64 will probably "win" in that it will be the de-facto ISA for Windows machines (even if ISA is irrelevant ... heheh). Programmers like out-of-order processors because it makes their job easier using current compiler technology (which sucks). That doesn't prove that out-of-order is as fast as in-order on the tasks on which in-order excels. And once you start looking at die size and power consumption too then in-order begins to look more attractive for a large group of industries even if the execution speed actually goes down.

      Why do you think people are so interested in the in-order Cell processor? Is it perhaps because you can't get a single die offering 250 GFLOPS of compute power with an out-of-order architecture? (Although it would have been nice if the PU had at least some out-of-order execution ability, the SPUs don't need out-of-order. But now I'm talking about cutting-edge developments in computer architecture rather than what you get in a graduate-level course. Silly me.)

    11. Re:Another Boneheaded Move By EA by Anonymous Coward · · Score: 0
      I agree with much of what you say. My point is that the ISA is, TODAY, a very minor factor in the performance of the CPU. So much, that it is mostly irrelevant. There are research projects that are exploring new ISAs that may very well open different doors (e.g. See UT-Austin's TRIPS project).

      It is possible that IA-32 might not do as well with an in-order core because the lack of register space isn't as easily compensated by OoO techniques.

      I do high-performance computer architecture R&D for a living....silly me.

    12. Re:Another Boneheaded Move By EA by DrDitto · · Score: 1

      If IA-32 was so inferior, a new ISA would be dominant today. Yes, backwards compatibility is a big deal. But if a new ISA delivers 50-100% better performance, you can bet that people would adopt it and MS would offer their products for it (e.g. NT4 was available for DEC Alpha).

    13. Re:Another Boneheaded Move By EA by Anonymous Coward · · Score: 0
      "No, not at all. They know when they release their new "bumpy shiny armor" FPS it will sell x amount of copies for x amount of money making them x amount of profit. As long as X > Development costs, they will keep doing it."

      Solving your equation for x, I guess they must be selling 0 copies for 0 dollars making $0 profit? Let's hope those development costs are negative.

    14. Re:Another Boneheaded Move By EA by Anonymous Coward · · Score: 0

      I think that overall we agree : I don't believe x86 to be very inferior, but still it is inferior.
      However your assumption that people would take the better performance is flawed because it does not take in account the performance/price ratio (e.g. Alpha was way too expensive compared to x86, and the gain was marginal if non-existant for the existing applications at the time, even if tuned and recompiled applications blew away the x86 versions. Also Alpha NT was not properly marketed by MS because of the strong commercial ties they had at the time with Intel).

  3. The engine isn`t that important anymore by Anonymous Coward · · Score: 3, Interesting

    There used to be a time where your engine defined what you could do in a game, and the engine you choose would have a massive impact on the quality of game you could produce; I think these days are long gone. If you discount certain cutting edge graphical techniques, there are few (gameplay modifying) features that are implemented in the Unreal 3/Doom 3 engines that could not be done in an open source engine written in Java.

    Personally, I think that it is time that someone focuses on generating an open source java framework that is designed around splitting a game engine into its smaller components (Graphics, Physics, Scripting and AI); this would allow for smaller (more focused) open source projects to exist which (should) produce higher quality results.

    1. Re:The engine isn`t that important anymore by Tim+C · · Score: 1

      Do you mean something like this?

    2. Re:The engine isn`t that important anymore by LetterRip · · Score: 1

      "Personally, I think that it is time that someone focuses on generating an open source java framework that is designed around splitting a game engine into its smaller components (Graphics, Physics, Scripting and AI); this would allow for smaller (more focused) open source projects to exist which (should) produce higher quality results."

      There are good opensource component C++ frameworks - there is Ogre 3D for graphics (or Crystalspace 3D); Bullet engine for physics (or ODE); Python for Scripting (Or Ruby; Or Lua); there are sound and input libraries; really the only big piece missing is the AI and a good networking library.

      LetterRip

    3. Re:The engine isn`t that important anymore by donscarletti · · Score: 3, Informative
      Ok, component based open souce game infructure, that would be really good. But where the hell did that Java idea come from? Java isn't open source, Java doesn't come by default in many linux distros, Java isn't the speediest thing out there (dispite many people who keep mentioning Java's optimised JIT compiler but completely forget about normal optimizing compilers) and a Java library is almost impossible to bind to other environments and languages. The other thing is, rightly or wrongly, java just isn't that popular with open source types. Java is almost THE WORST language selection one could make.

      Between Sun's marketing department and B-grade university CS programs that work like Java trade schools there is a disturbing number of people out there that think that: Java is comparitively easy to use, Java is flexible/powerful and Java is fast enough to do state of the art techniques on computers that currently exist.

      --
      When Argumentum ad Hominem falls short, try Argumentum ad Matrem
    4. Re:The engine isn`t that important anymore by Anonymous Coward · · Score: 0

      I know there are lots of different solutions, but my thinking is that there should be one (major) system that is being developed, with various sub projects (that could be developed independantly) being built to support it.

      Imagine the OpenGE (game engine) specification where you could take the Graphics engine from Bob's GE and the physics engine from Frank's GE and add it to the rest of Sun's GE.

    5. Re:The engine isn`t that important anymore by Anonymous Coward · · Score: 0

      Yeah, I thought they guy was making an interesting point, but when I saw he was recommending Java I realized he doesn't know what he's talking about. Java can certainly do 3D, but not cutting edge realtime 3D, which is what the commercial game houses are interested in (because their customers willing to shell out $30+ per title are).

      Next.

    6. Re:The engine isn`t that important anymore by perkr · · Score: 2, Interesting

      You are probably right that games will end up being written in an easier language than C++ and with critical and difficult-to-write components such as AI and Graphics as seprate components.

      However, it seems hard to separate AI and for instance physics. For an AI to be smart it has to know how the physics component work or no? I mean is game development going to end up like BizTalk hehe (components "brokering" over XML basically). :)

      Also, for games to have an "edge" creativity in all diverse areas have been needed. If components are open-sourced it would be cool cause then the devs are free to let an expert in the team in and hack the render engine to do whatever they want to introduce to impress the audience. But if we end up with several closed-down or hard-to-change components that might impact the creativity in games. Basically it would be all script-programming.

    7. Re:The engine isn`t that important anymore by Anonymous Coward · · Score: 0

      My suggestion of Java was not because of performance issues (everyone know's java is a pig) but more becase of how much simpler it is to build several components at the same time without any interaction. Java (as compared to C++) is much better at abstracting (and building towards) interfaces.

      Ultimatley, the performance issue (in the long run) is not that major of a problem; if you look at how much performance high-end computer systems have as compared to the minimum requirements of most games you'll notice that hardware's capabilities (for the first time in history) are outpacing the software's requirements. What this means is that eventually (as in, within 5 to 10 years) we will not be worring about whether we will have enough performance from hardware, but whether the system we have built is easy to use and develop for.

    8. Re:The engine isn`t that important anymore by Anonymous Coward · · Score: 0

      The actual quantity of information that is shared between physics, AI, and graphics is pretty small; usually just location, orientation, and direction information (there are other things that could be required on several objects, these are not all that important); most of this information is set in a scene graph. Being that most games are more focused on multiplayer now, it is difficult to share much information between physics, graphics and AI because you're interested in the physics/AI effects of the entire "level" while only interested in the graphics that a particular client has in view; it is far more complicated to determine what should be rendered, or to prevent unexpected AI/Physics results when you share too much between systems.

      I can't say too much about AI/Physics because I haven't done too much that was heavy in AI ... my largest projects have been a mario kart multiplayer clone (for school) and a Puzzle RPG; there was practically no AI in either games.

    9. Re:The engine isn`t that important anymore by Anonymous Coward · · Score: 0

      "If you discount certain cutting edge graphical techniques, there are few (gameplay modifying) features that are implemented in the Unreal 3/Doom 3 engines that could not be done in an open source engine written in Java."

      Yeah, becaust most professional game developers prefer Java as their development language of choice. Why bother yourself with petty concerns such as speed in engine development when you can focus on multiplatform support : /

    10. Re:The engine isn`t that important anymore by Anonymous Coward · · Score: 0

      You can write abstract interfaces using C++, you just have to be more careful not to allow someone on your team break the paradigm through abuse.

      Java and C# will never be suitable for production, real-time 3D games because of their asynchronous garbage collection and runtime argument verification. Sure, the hardware gets faster all the time BUT the expectations of paying customers who own the latest hardware, grows at least as fast, if not faster. They want to see *todays* state of the art. Nobody will shell out $40 to see "Doom I" caliber graphics, even though that knocked us all dead twelve years ago.

    11. Re:The engine isn`t that important anymore by Anonymous Coward · · Score: 0

      Java is still has some issues before it can be used as a game engine. John Carmack had a lot of trouble porting Doom to Java mobile phones. http://www.armadilloaerospace.com/n.x/johnc/recent %20updates/archive?news_id=295. Carmack said he liked BREW better in http://www.armadilloaerospace.com/n.x/johnc/Recent %20Updates. Not to mention Java still is not as powerful at the low level native interface such as C or C++ where you can use assembly or connect to compilied native code much easier. Java needs an efficient method to interface with graphics cards and opengl. It would be impossible for Java to support some advanced 3d rendering which is why Maya hasn't been ported to Java.

    12. Re:The engine isn`t that important anymore by Anonymous Coward · · Score: 0

      One thing to remember though is that John Carmack was trying to port Doom to mobile phones using Java, where the moble phone has similar performance to that of your SNES.

      As I've said already, Java is a pig and will not give you the ultimate performance you would want from a cutting edge game. Now, off of a reasonably modern computer you should be able to get similar performance from a Java to what people were getting from the XBox (or possibly better performance). In the very near future (as in 24 months from today) you will be able to get "Next-Generation" level of graphics off of a Java Virtual Machine on a new system.

      Ultimately, I'm a little disapointed that everyone focused on why Java was a bad choice rather then the merit of a large engine project that was (in fact) a collection of smaller projects that could have multiple competing systems.

    13. Re:The engine isn`t that important anymore by grumbel · · Score: 2, Informative
      Java and C# will never be suitable for production, real-time 3D games because of their asynchronous garbage collection and runtime argument verification.

      Microsoft thinks different and provides XNA. Now I don't expect the next Doom or Halo3 to use Java or C#, but for a lot of games its really a non-issue these days, computers are fast enough and the most grunt work is done by the GPU anyway, which doesn't care if the rest of the programm is written in Java or C# or hand optimized assembler. There is of course still a speed benefit of C++, but its getting smaller and smaller and its certainly at a point where the success of a game will no longer depend on it.

    14. Re:The engine isn`t that important anymore by Anonymous Coward · · Score: 0

      well duh, thats why they chose the U3 engine. It has script level programming called unrealscript and multiple gameplay types written and open sourced with that script (and thus multiple AI goals). It's not great and u2 engine has bloat from U1, but it's better than nothing. or maybe not, it all depends on how innovative your game is--but if it's standard FPS or RPG or adventure, there's a strong base thats already there and free to use.

    15. Re:The engine isn`t that important anymore by Shilkanni · · Score: 1

      Unfortunately I think this is true. The future may come when we can't tell the difference between the graphics & performance of a 10 year old game vs a current game, or we can't tell that a game with the same features written in Java is running slower, but I certainly don't think it's on the horizon.

    16. Re:The engine isn`t that important anymore by Psiven · · Score: 0

      Just a good example of why to keep it simple (stupid).

    17. Re:The engine isn`t that important anymore by Anonymous Coward · · Score: 0

      Unreal Engine 3 is garbage-collected.

    18. Re:The engine isn`t that important anymore by 2megs · · Score: 1

      Python for Scripting (Or Ruby; Or Lua)

      I worked as the lead programmer on a game that used Python for scripting, at a company where another team was also using Python for scripting. From a bugcount and quality-assurance perspective, Python worked out very badly for both games.

      The dynamic nature of the language bit us in the ass over and over and over. Suppose early in the game, based on what someone does, there's a script that states:

      globalFlags.killedRedDragon = true;

      On a quest much later in the game, there's a script that goes something like (loosely paraphrasing Python syntax):

      if (player.characterClass == paladin):
              if (NPC.BobTheBlacksmith.GetDisposition() == friendly):
                      if (globalFlags. killedRedDagron ):
                              # do some special thing where Bob offers to make
                              # you a special paladin-only helmet from the
                              # bones of the red dragon

      You'll note there's a syntax error on that third line. It happens, and it happens especially often with scripters, who are generally among the least experienced coders at a company. You have to build that expectation into your entire development process, and languages with the dynamic flexibility of Python just don't do that.

      The problem is that we won't know about the error until that line is actually executed during gameplay. If the scripter himself is doing it, that's going to take several hours. If not, depending on QA, that might not happen for several months. Or if the hourly grunt whose task was to play through the game as a paladin who likes blacksmiths decided to blow off killing the dragon even though it was in his test script, it might not happen at all and you ship with a few hundred outstanding bugs.

      Sure, better processes and better people could have used Python to great success. But given limited time for processes and limited budgets for recruiting talent, we would have done much better with something that A) doesn't give people enough flexibility to get most things wrong, and B) gives the team the opportunity to catch what's wrong much earlier in the cycle.

    19. Re:The engine isn`t that important anymore by Anonymous Coward · · Score: 0

      Maybe someone should tell that to 3d-realms

    20. Re:The engine isn`t that important anymore by MojoBox · · Score: 1

      Communication between AI and Physics is going to become more and more important as we get more complex environments and physics simulations that NPC's need to interact with. If the old fashion style of laying out a grid of path nodes by hand can be replaced with the NPC's having access to physics information for navigation, that would allow more realistic NPC navigation and save on time manually placing paths (bOOOOring). Mind you, I've only mapped for HL/HL2, so what the hell would I really know? Sounds nice though.

    21. Re:The engine isn`t that important anymore by MojoBox · · Score: 1

      Interesting. Well that explains a few things about that game anyways :\

    22. Re:The engine isn`t that important anymore by PhoenixOne · · Score: 1

      You speak like this is a bad thing. I'm looking forward to the day when almost all of the development time is spent on gameplay and not just trying to squeeze out 10% more polygons than your competitor. Being able to create a game "for the ages", and not one that will be all but forgotten in 3 years because its graphics have become so dated.

      --
      Spell cheek you've failed me four the last thyme!
  4. Game engine consolidation by Dr.+Spork · · Score: 3, Interesting
    I guess if there is anything here to wonder at, it's that this game engine consolidation did not gather steam sooner. Maybe EA, who's been vacuuming up small game companies, whanted their newly-acquired employees to maintain a brief sense of independence. But if you're a game company that cranks out dozens of games a year, with almost all of them being 3D in some way, it makes sense to standardize. I would guess their intention with Renderware is to make it a very modular, clean and optimized game engine, so that its core can be used across all the lines of EA games. This will make redundant lots of the back-end people in EA's recent acquisitions. The people who remain will "generate content" for THE game engine.

    I'm not sure whether this is bad or good. I was thinking it might make future games feel generic, but then I thought... more than now? Let's hope not. But maybe the generic feel of today's FPSes is that the oft-reused game engines are not quite flexible enough, so the player "recognizes" the engine underneath. Maybe in the future they will fix that.

    1. Re:Game engine consolidation by Aadain2001 · · Score: 1
      I'm not sure whether this is bad or good.

      Good for EA as a company (quicker game releases/more game releases), bad for the EA employees (most of the "smart" coder get the axe since they are no longer needed). Still up in the air about how it will be for consumers, but we will just have to wait and see what EA does with this standardized engine.

      --
      Space for rent, inquire within
    2. Re:Game engine consolidation by Quarters · · Score: 1

      EA did standardize. They bought Criterion and Renderware a year or two back. This more to license UE3 is very odd and doesn't say much for EA's attempt to keep Renderware current after they purchased it.

    3. Re:Game engine consolidation by Pharmboy · · Score: 4, Insightful

      Valve has been doing something like this for some time, but differently. By keeping their SDK opened up (and developing TFC soley using the public SDK) they encouraged independent content. DoD was indy at one time, as were most of the titles that now run on the HL1 or Steam/Source engine. The good stuff, they buy up or invest further in, turning "ok free mods" into "really good $10/$20 games".

      I own many of the titles, and the game play is very different. There is a little "sameness" in some titles (CS/TFC/HL) but this is mainly just consistancy, not generic blandness. The content is different as is the overall gameplay. Then again, HL1 itself was a licensed engine from Quake.

      So you can develop some unique games on the same platform. EA will probably do it closed. Valve does it fairly open. The public will decide who does it better.

      --
      Tequila: It's not just for breakfast anymore!
    4. Re:Game engine consolidation by Anonymous Coward · · Score: 0

      Renderware exemplifies everything that was wrong about last-gen engines (especially the convoluted content pipeline), and provides nothing that could be used for next-generation features like streaming open worlds or dynamic content.

      In short, Renderware is a fucking disaster. The EA-wide push to standardize on it probably cost the company a fortune in development nightmares, missed ship dates, and poor sales due to cut features.

    5. Re:Game engine consolidation by pixel_bc · · Score: 2, Funny

      > vacuuming up small game companies

      Aside from the Mythic acquisition, EA hasn't been purchasing companies.......

    6. Re:Game engine consolidation by robson · · Score: 1

      EA did standardize. They bought Criterion and Renderware a year or two back. This more to license UE3 is very odd and doesn't say much for EA's attempt to keep Renderware current after they purchased it.

      Yeah, it seems pretty clear that their acquisition of Renderware was not so they could use the engine, but rather to hinder the ability of other developers to easily create cross-platform titles. In other words, EA probably bought Renderware so they could kill it.

  5. Since you mentioned Ruby... by Anonymous Coward · · Score: 0
    What the gaming world needs is a RAILS for games. A framework that lets you cobble together a cookie-cutter game quickly and then spend the time tweaking for performance visuals and gameplay...

    Wait a minute, aren't games already like that? Hahahahaha!

  6. The ideology isn`t that important anymore by Anonymous Coward · · Score: 0

    "There used to be a time where your engine defined what you could do in a game, and the engine you choose would have a massive impact on the quality of game you could produce; I think these days are long gone."

    Have you ever done any modding?

    "If you discount certain cutting edge graphical techniques, there are few (gameplay modifying) features that are implemented in the Unreal 3/Doom 3 engines that could not be done in an open source engine written in Java."

    I disagree about Java, and I can't imagine why someone in the competitive market that's games, would discount anything.

    Now for your implication that an OSS game engine is the equivalent of it's closed source cousin. Let's test that. Convert the content of a popular modern game over to an open source engine, and see if it plays the same.

  7. As opposed to other developers... by Anonymous Coward · · Score: 0

    ...who are seriously thinking about dropping the Unreal 3 Engine because of the lack of "interactive framerates". I know one developer has taken the plunge and dropped the Unreal 3 Engine in favour of writing their own, writing off the licensing cost. Most other developers who have licensed Unreal 3 Engine for their own projects unfortunately will not have the financial backing to write off the cost of the license in favour of something else.

  8. Re:Game engine consolidation [+Interesting parent] by Dr.+Spork · · Score: 1
    Renderware is a fucking disaster. The EA-wide push to standardize on it probably cost the company a fortune in development nightmares, missed ship dates, and poor sales due to cut features.
    Interesting, I wasn't following these developments. But EA have enough resources to take note of the lessons learned and start from scratch. With all their acquisitions, they certainly have enough smart people on staff... for now.
  9. Unreal 3 by Anonymous Coward · · Score: 0

    ...but Epic is a company and doesn't have a Social Security Number? How could they complete the EULA in order to do business with EA?