As was foretold, we've added advertisements to the forums! If you have questions, or if you encounter any bugs, please visit this thread: https://forums.penny-arcade.com/discussion/240191/forum-advertisement-faq-and-reports-thread/
Options
A question for those in the know... (Gaming engine question)
ShadowBlade
Registered User regular
Registered User regular
I posted this in the Bitching Thread, but I was hoping to get some specific discussion/Q&A on it.
Why aren't Game engines recycled more. Metroid Prime and Resident Evil 4 are two that I hold dear and would love to see new franchises and stories developed from them. Am I wrong to think this should make game creation immensely easier and cheaper too?
Why does every game have to have it's own engine? For the wii in particular, where these types of games are so rare/rarely done right, why doesn't Nintendo have at least one other franchise running on the Prime engine? Capcom could maybe have half a dozen games in a few franchises running on the RE4 engine.
Why aren't these engines licensed to other developers more often?
My first thread so I hope this is a good one...
Why aren't Game engines recycled more. Metroid Prime and Resident Evil 4 are two that I hold dear and would love to see new franchises and stories developed from them. Am I wrong to think this should make game creation immensely easier and cheaper too?
Why does every game have to have it's own engine? For the wii in particular, where these types of games are so rare/rarely done right, why doesn't Nintendo have at least one other franchise running on the Prime engine? Capcom could maybe have half a dozen games in a few franchises running on the RE4 engine.
Why aren't these engines licensed to other developers more often?
My first thread so I hope this is a good one...
This world needs a new philosophy. No more, "Could be worse..." I say SHOULD BE BETTER!
ShadowBlade on
0
Posts
Yeah, the big-name engines like UE3, Source and Frostbite are built from the ground up to be reusable. Custom engines for specific games tend to have everything thoroughly entangled, making it hard for a third party to make their own game with it. UE3/Source etc have 3D engine, rendering, sound, physics etc well separated.
It sounds like you're asking why they don't just replace all the models in Resident Evil 4 with different looking models and ZAMMO they have a brand new awesome game. This is sort of like asking why they don't just replace all the actors in a movie with different actors and ZAMMO they have a brand new awesome movie.
Not quite what I was thinking. New story, new models, new mechanics* all based on the old, same engine. New game. No ZAMMO... what ever that means. If the Ganados were all replaced with robots and Leon with a cyborg, and the country side/castles/islands with jungles/pyramids/ships at sea, then you obviously create new cut scenes and dialog and ZAMMO(?)
*and by new mechanic, I simply mean, maybe a battery meter. If he is a cyborg now, let's say he runs out of power constently. Certainly nothing outside of the original engine.
Apparently it is not "THAT" simple, but I am still not sure where ZAMMO came from.
All that now said, I guess I am still a touch confused why this is so rarely done. Is it simply because it would be too obvious that it was indeed the same game? Surely the structure of a map is not determined by the engine? The path you follow and the dialog/cut-scenes would all be new to fit with the new "Story". So maybe my question is more clear now? Replace my stupid Cyborg vs Robo-horde in the jungle idea with something actually interesting and cool, and would you not play a "new" game based precisely on RE4's engine? I think I would... Again, maybe it is not that simple. Sounds simple to me, relatively speaking. Simpler than redeveloping a whole engine each time. Or is the "engine" just not that big of a part of the process? Do the models/maps/story combined out weigh the whole engine so that by the time you ahve them all done, you may as well make your own?
So, people actually reuse engines all the time. Unreal Engine 3 powers Alpha Protocol, Mirror's Edge, Mass Effect 2, Gears of War, and countless other games. Source powers Dark Messiah of Might and Magic, Half-Life 2, Portal, Zeno Clash, and other games. The Anvil engine is behind Assassin's Creed and Prince of Persia. The same engine was used for KOTOR and Jade Empire. Lithtech powers all the Monolith games. Gamebroyo is behind, like, a zillion games. DICE has used Frostbite for everything since Bad Company. The Stalker guys use X-Ray for everything. Etc. So I guess I don't understand what you mean when you ask why engines aren't reused. They are reused when it is cost effective and they aren't w hen it isn't. We could get into the technical specifics but it's probably not going to be very edifying.
Besides the contemporary of UE3, perhaps checking out a robust engine like SC2's editor as a starting point to examine how engines like that work?
Generally I find that when people talk about "game engines," they usually refer to either the graphics engine or the engine which handles the objects (i.e. collision, movements, actions, etc). Graphics engines are actually reused a bunch, a great example being Renderware.
As to your specific question about Resident Evil 4, that is a special game which uses a bunch of graphics techniques that are only applicable to certain situations and graphic styles. For example, most of the shader effects in Resident Evil 4 are completely faked. A good example of how intricately these effects are tied into the game that is resident evil 4, and the gcn hardware, has to do with one way the game generates a specific texture. See, most images are made using 24 bit color (i.e. 32-bit color without an alpha channel), but the GCN outputs at 18-bit color (6 bits per channel per pixel vs 8 bits). This reduction in what is being processed internally and what is being shown on screen causes banding in specific ways. Well, if two colors are interlaced using this, you can produce an effect which gives off a very dark, bumpy look as a texture. It works like bump mapping but it's a total trick with no overhead. The downside is it's a specific type of bumpy texture, that only works with 2 specific colors, and thus is only really applicable in a game made to work around this sort of stuff.
Resident Evil 4 is filled to the brim with this sort of shit. Stuff that looks great, but really only works in RE4. Hence why it's graphics engine isn't all over the place, and hence why other games which use it (Dead Rising Chop till you drop) suddenly look very pedestrian.
Ah, and here-in lies my expertise. No, things were not really easier with 2D games. In fact, I'd say they were harder because games were small enough and made by single people that often they'd just rewrite the entire thing from scratch, saying fuck modularity.
It comes down to the inherent ways of handling the shit on screen. 2 engines I'm very familiar with are of course sonic the hedgehog and interestingly enough, Earthworm Jim as of late. Sonic the Hedgehog is built off of an engine that has been dubbed SonED, while Earthworm Jim uses the tUME engine (the Universal Map Editor). There are tons of engine specific differences between the two, but off the top of my head, Sonic has it's basic element chunk defined as a 4x4 tile, which gets arranged into 8x8 chunks, which get arranged into 128x128 (or 256x256 in Sonic 1) level segments. tUME skips all this, with a 4x4 tile being the basic element chunk, and it having no defined chunks bigger (hence allowing near-direct importing from large, non-tiled bitmap files, which explains EWJ's unique art).
Sonic uses the ways its art scales as part of the way to determine Sonic's speed and velocity (it maps to a solidarity chart), while Earthworm jim's tUME lacks this, so it works with collision boxes.
See how 2 simple 2D games can have big engine differences based off of small quirks?
EDIT: That said, there are a ton of big-name engines that WERE used a lot during the 16-bit days. On the sega camp alone, Sega developed a sound driver engine called GEMS which is used in like, every fucking Sega Genesis game since Sonic 3. You can always tell when a game uses the GEMS sound engine because they all sound very similar. Basically if you hear Sonic 3 sound effects in a non-Sonic 3 game, it's using that GEMS driver.
Special thanks to TSR for the Dead Rising note. I rented that one shortly after release, very excited that it was using the RE4 "engine" and when I saw what was done, too say I was disappointed would be the understatement of the year.
So basically, games are often too dependent on their parts working together to be reworked... properly. It's less like replacing the lego blocks to make a new creation, which can work well and more like trying to replace the parts of a car engine to turn a Rabbit into a Ferrari. Not something remotely simple.
For example, Oblivion (and Fallout 3) is based on Gamebryo, also used by tons of other games, for the 3D engine; their own Radiant AI for the game AI; SpeedTree for forests and stuff.
SpeedTree is a very specific middleware engine: it's for making trees and plants. You can make entire forests with every tree being unique by randomly generating them within a set of parameters.
http://www.youtube.com/watch?v=3HO2o4poY0w
Not always. It depends on the game and the purpose which the engine was made. UE3, for example, IS as easy as using Lego blocks. You just plug in the parts of the engine you want to use. But UE3 was made for this purpose. While other games, like Metal Gear Solid 4, are built without reusing anything in mind, so taking chunks of the engine out would literally render the game unplayable.
It's kind of a hard concept to grasp when you're unfamiliar with how games work underneath because it's weird to think how closely tied, say, an engine that plots pixels onto the screen could be to the physics engine for a game.
Great list. I'd add Torque because it's one of the wider available engines to the public.
A 'total conversion' mod wouldn't be outside the realms of possibility, if one doesn't in fact already exist.
It's modding to an extent, but they're not really playing around with the fundamentals of the engine IIRC. They discovered the file format at use, and that allowed them to do model / texture swaps.
Also allowed them to swap in some different shaders, which can look pretty cool (when they work properly).
But they were never able to tweak the actual engine stuff itself and say, get mouse support working properly for example. I don't think Total conversion territory is really possible there.
All in all though, it was an absolutely stellar job they did. Complete texture swap on everything. Made the PC version of RE4 actually playable (the original release didn't even have proper button prompts for the QTE's. Ridiculous), and definitely one of the better version of the game.
Most EULA's cover game modification in them somewhere -- after all, the game isn't yours, you are just purchasing the rights to install/play it. If the company is awesome and cool and supportive of development, they'll include language that lets you use modding tools "as-is" without warranty or support in the EULA. If they aren't, then changing any files can get you in trouble if they decide to pursue things.
I like using Relic's development support. I don't know if this structure still exists, but back a half a decade ago they had a 3-tiered modding community going. The first level was pretty simple: Level design, using the included tools, and a bit of scripting/unit modification. Past that came level 2, where you got access to some of the things the developers used to make the game. The final level was where Relic trusted you enough to let ya actually at the source code.
And therein lies the holy grail of modding: The source. Given how powerful the source code is, not to mention its position as copyrighted material, you either need to buy the source code for an engine or have it made available to work on it. Even with an engine as robust as UE3, many parts are still locked away where you can't touch them. Hell, I am pretty sure I've never heard of anyone releasing the source code on DRM, which would kind of defeat the purpose.
Then.. well, there is the other side of the coin, although I'm not sure of its legality since GOG: The Freespace 2 SCP. After Interplay went belly up, somewhere along the line the Freespace 2 source code was released to the public, sans in-game assets. This is common with cool gaming companies; id released the source for some of their earlier engines, I do believe, without assets as well. This means that people still need legit copies of the game, but after that they can tinker at their heart's content. With Freespace 2, that is exactly what they did. Even to this day the game is being modified, altered, improved.. People have applied modern 9.0 (and even 10.0) shaders, added entirely new campaigns, high-res textures that cripple my system; hell, they even made an auto-downloader to keep all the mods updated! And at some point, the assets were made available legally through the system.. It was glorious, and shows what dedicated fans can do if sufficiently motivated.
Hell, one group even made the only decent Battlestar Galactica game I've ever seen using Freespace 2. So there you go. Unfortunately, I don't know how things stand since Good Old Games got the rights to sell the game, but I do have a legal copy that I bought a few years back, so I don't really care!
Modding, level editing, all that.. It's a good place to get your mind around entering gaming design. Although I only dabble, as I said it goes a long, long way to understanding why games are like they are, what limitations are out there, and so on. Just keep in mind that while great level design is helpful, there's a lot more to making a game than just that!
I've never played the PC port of RE4, but isn't it based off the PS2 port? Granted, I haven't played that either, but I heard the PS2 port lacks almost all the shaders from the GCN version (for the reason I explained above). If this is the case, how are they being added back in for the PC version?
I couldn't really say what was or wasn't in the PS2 version. I know that when the PC version first released it didn't even have a lighting model, and subsequently looked hideous.
They (the port company) patched in lighting later on.
As for the modding here, that was something they discovered elsewhere. They actually made use of a 3rd party mod originally designed by someone to provide lighting for GTA: San Andreas, which was called "ENB Series". It was expanded to cater to other games. Thread here:
http://z6.invisionfree.com/Resident_Evil_4_PC/index.php?showtopic=2890
Amongst other things it also allowed optional motion blur and depth of field effects. Neither of which worked that brilliantly, but they weren't bad either. When it worked it looked pretty awesome.
I just used a green laser pointer for the sake of it. :P
I can't find a working link to the authors website or anything, but PC Gamer did a short news piece on it
http://www.pcgameshardware.com/aid,668456/ENB-Series-Better-graphics-for-free-in-older-and-new-games/News/
Thats pretty cool stuff, I'd be interested in seeing how this works.
Mario World stores the level as a number of 'screens'. 0,1,2,3,etc. This, along with position is used heavily.
1) All the colored pipes you see in the game are colored by which screen they show up on. If you nudge a pipe so that it crosses a screen boundary, it will be colored green on it's left half and yellow on the right (as an example). This saved them from having to store each colored pipe seperately. It's also why you always see certain colors next to each other.
2) Items boxes in Mario World do not know what is in them! The engine does though - it's completely determined by the box's X position in a screen. When the engine loads up the level, it places items into a question box based on it's X position. You can actually exploit this on some levels by making a block be "hit" as it's moved on the X-axis, and you'll get a different item.
There's a shitton of other optimizations that they used like this in Mario World, and it was pretty much single-use. Nintendo didn't really get into their engine re-use until Mario 64.
This is the way objects are loaded and stored in Sonic as well. A lot of games do this because it allows them to take advantage of the vblank while drawing the screen. The vblank is the position where the CRT gun is moving back to the left so nothing is being drawn on screen. So for a few cycles you essentially have free computation going on. To make the most of this, a lot of games handled their object loading during these vblanks and relied on their X position on screen to figure out what should do what. It was efficient.
EDIT: A question about what you wrote before about screens. Are you saying Mario World defines a screen as in, a single screen-sized buffer? i.e. screen 0 is 0,0 to 320,240(or whatever resolution), screen 1 is 320,0 to 640,240, and so forth, apart of a bigger world, or do you mean that every level snippet is a screen (i.e. screen 0 is 1260x240 big, which leads to a pipe which takes you to screen 1 which is 1460x480 big, etc)?
EDIT again: Wait, actually I just got X and Y mixed up, lo. Actually, Sonic does everything the exact opposite of what you described. It handles object loading and handling via Y position, during the vblank. Lots of other games do this too.
thinking about what you said about storing everything as a screen (assuming my first-described screen storing method is correct) and about how the game determines box power ups via their X position, I'm guessing Mario World must do a lot of this stuff during the hblank, which makes sense. Hblank is when the game finishes drawing the bottom of the screen, and the gun moves back to the upper left. It gives more time to do computation than vblank. I guess mario world must be set up to take advantage of this hblank.
They also use the screen system for entrances and exits. To get Mario to spawn in halfway through a level, they simple tell him to start at say, Screen 7. All usable pipes in a screen will use the exit defined for that screen as well. (ie the screen knows that it exits to Level 55, Screen 17. it doesn't care HOW, it just knows WHERE).
This is also why the doors in Bowsers Castle are so far apart when selecting a room - they have to give each door it's own screen.
edit: here we go. This is basically how big screens were:
For someone who's in touch with the industry as much as you are, I'm surprised you said this. Unreal Engine 3 is a "game engine' It contains graphics, object handling, lighting, all that stuff, and it's considered a single engine (and is even named as such.) There's lots of engines like this. UE3, Source, Idtech, CryEngine, etc. etc. Saying it's too vague when it's been commonly used vernacular since the days of id pimping the Quake engine strikes me as odd.
got it, level chunks. That's interesting to hear, it sounds like it works a lot like the engine earthworm jim used.
I assume there is a rule about 1 entrance and 1 exit pipe per screen in order for what you described to work?
Yes, I'm not saying there aren't game engines, I'm saying what he asked for was too vague. Of course there are game engines, but he was referring to a lot of different kind of engines as just "game engines" in the OP.
Yup. Here's a screenshot of the divides:
edit: here we go. This is basically how big screens were:
Sub screens were mostly in play for levels that could scroll up and down - they don't do anything to objects from what I remember.
This is cool shit, wulff. I haven't spoken to you since the old IRC days, I didn't know you got into Mario hacking.
I've been doing a lot of Amiga work lately. I've been fooling around with HAM (hold-and-modify) mode on an actual Amiga 500 and I recently added such a mode to my game engine. I actually read an interview when I was learning how to use HAM mode which talks about how it came to be - it's a layover from when they were developing the graphics chip for the Amiga 500. They had planned a US launch and implemented an NTSC mode where they could hold the luminance of a picture and edit the hue, or vice versa. When plans for this NTSC mode were scrapped late into production, they realized they couldn't remove the feature from the chip or they'd literally have a large hole in their design. So they left it in, and years later clever programmers realized they could pass it RGB data and have it hold two color channels and modify the third, which is how they got all those crazy gradients into amiga games.
Really fun stuff to play with. Since the way I draw colors to the screen with my engine is via a pointer to a table of colors stored in my master palette, it was pretty easy to create a temporary storage color and point to it, and have it reference another value, then modify 2 of the channels on every update cycle. My HAM mode is a bit more advanced than the actual amiga HAM mode since you can hold 1 and modify 2 if you want, and since I also have an alpha channel.
That's what happens when you do not know, but, since much of what I am seeing here now is Greek to me (awesomely cool Greek and I minimally understand), can I steer this back to that definition question? Just for a moment, then please continue with the Greek. I am finding it all incredibly fascinating.
Is a "game engine" not the sum of it's parts? If The prime series, which I am sure has used at least 2(or 3?) engines now, did not have its sound component(s) or its physics component(s), it would be little more than a bunch of pretty CG models. Or is it not looked at that way in the industry unless the "engine" is designed as a whole?
I wrote out a long reply then realized that Wikipedia has all the answers.
Thank you sir.
Designing for re-use is considerably more expensive than just building a system for a single game - it needs to be better documented and it needs to be much more flexible, just for starters - and that's a cost that'll only be recouped if it can be sold off to other companies. Selling it to other companies is competing against some very well-engineered, well-documented, well-established products - to make a commercial engine is a huge undertaking, not a way to get a little extra value out of developed tools.
There's always the possibility of internal reuse, but that depends on a lot of design decisions made: a lot of game architectures are built around the specific gameplay requirements of a given game. If you're going from Metroid Prime 1 to Metroid Prime 2, that's not a problem (and I bet a lot of the code there was reused). If you're going from Metroid Prime to Donkey Kong Country Returns, it kind of is.