Recycling the engine

Started by
27 comments, last by Kest 15 years, 11 months ago
Quote:Original post by Talin
Things like that are best left to the modders.

Best for who? As a player, I would prefer official expansions to a game world or story. Beyound that, fully finished mods that rebuild a game are very few.
Advertisement
Quote:Original post by Kest
Why do developers not reuse game engines, models, textures, etc, to create sequels and seperate games more often? Why do they not just bring in designers to construct new buildings, villages, cities, levels, characters, etc, while mostly using resources that are already made?

...

I'm just wondering why developers aren't leaning a little more in that direction. Taking some of the pain (and money) off of that side to allow developers to put more effort into level design, scripting, interactive maps, character AI and dialog, etc, making the actual game more intense instead of the effects and visuals.

First of all, as noted previously, a lot of developers do this. Generally, an addition of content into the same engine is called an expansion. A new engine is a sequel. This is pretty much market-defined. If you re-use an engine without adding new features, and try to sell it as a new game to the public, both reviewers and players will notice, and in general the reaction is negative.

And adding new features is difficult - an engine is built for a purpose, and once it is optimized it can be quite a lot of work to make additions. It's often better to build a new engine which encompasses those new functions than it is to hack an old one to carry them.

And additionally, content isn't cheap. Decent artwork, dialogue, voice acting etc. is really expensive - the guy who did the voice acting for GTA IV made 100k, and he was a no-name. AND he was somewhat unhappy about his pay.. If you're going to add good dialog and art, you probably want it to go into the best engine that can show it off.

Engines aren't really that expensive. It's getting the content, organising it, and integrating it into the engine that makes up the bulk of the cost. All of which your suggestions do not help with. Believe me - any code that can be easily re-used between engines IS re-used, if there are any good programmers at the helm. You just don't usually see those bits.
I would imagine the customer would be pretty upset to discover that every game was using the same assets. Now imagine you had a zombie, the zombie didnt quite fit what they wanted, its got to be edited, maybe those animations arent how quite they want them, got to edit them, maybe they spent abit too many/few polygons
I dream hard of helping people.
Quote:Original post by Argus2
And adding new features is difficult - an engine is built for a purpose, and once it is optimized it can be quite a lot of work to make additions. It's often better to build a new engine which encompasses those new functions than it is to hack an old one to carry them.

Engines can be designed for easy modifications during development. I've put a lot of emphasis into this with my own engine. Not because I want to build a lot of games with it, but because I come up with unplanned ideas too often (I'm terrible at pre-planning).

Scripting and text parsing is the way to go for this. The programmed engine should handle what you know to be concrete, and scripting should be used to handle specific objects, actions, and events. That allows you to add new specific elements later on without having to expand the engine. Weapon types, projectile behaviors, AI, people, animation maps, particle effects, and many other elements can all be defined this way.

For example, I could add a new type of ranged weapon class to my game (in addition to the current pistol, subgun, rifle, cannon classes), such as a class for a slingshot or bow & arrow, which would require new animations, character behavior triggers, and sound effects. It would only take a day or so to get it fully integrated into the game, and the engine wouldn't need to be touched.
Quote:Original post by Aiursrage
I would imagine the customer would be pretty upset to discover that every game was using the same assets.

They don't seem to be too upset about the Half-Life 2 episodes. I can't say whether they used the same wall and floor textures, but the weapons and enemies are definitely all the same. Seriously, who cares? It's fun, so it works.
Quote:Original post by Kest
Quote:Original post by Aiursrage
I would imagine the customer would be pretty upset to discover that every game was using the same assets.

They don't seem to be too upset about the Half-Life 2 episodes. I can't say whether they used the same wall and floor textures, but the weapons and enemies are definitely all the same. Seriously, who cares? It's fun, so it works.


Its Half-Life 2 Episodes though, people would react very differently if valve released Half-Life 3 using the HL2 engine and assets :D

The name really is that important since it affects the customers expectations, anyone buying "Half-Life 2: Whatever" is pretty much expecting some new levels, possibly an extra weapon or two, a continuation of the story, or similar , Those buying Half-Life 3 (assuming valve makes another sequel) in the future will expect a "new" game.

Meeting the customers expectations is important since disappointed customers will have a negative impact on sales.
[size="1"]I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!
Quote:Original post by SimonForsman
Quote:Original post by Kest
Quote:Original post by Aiursrage
I would imagine the customer would be pretty upset to discover that every game was using the same assets.

They don't seem to be too upset about the Half-Life 2 episodes. I can't say whether they used the same wall and floor textures, but the weapons and enemies are definitely all the same. Seriously, who cares? It's fun, so it works.


Its Half-Life 2 Episodes though, people would react very differently if valve released Half-Life 3 using the HL2 engine and assets :D

The name really is that important since it affects the customers expectations, anyone buying "Half-Life 2: Whatever" is pretty much expecting some new levels, possibly an extra weapon or two, a continuation of the story, or similar , Those buying Half-Life 3 (assuming valve makes another sequel) in the future will expect a "new" game.

Meeting the customers expectations is important since disappointed customers will have a negative impact on sales.

Agreed. Pulling one over on customers was never any part of the strategy. A developer would want them to know exactly what they are buying. Any strategy (like working within title conventions) that furthers that is a good strategy.

I just don't think it makes any difference to them beyound that. Or at least it doesn't make any difference to me. A quality experience is just that. If a development team did me right before, I'll trust them to do so again until they fail.
Quote:Original post by Kest
Engines can be designed for easy modifications during development.
...

Weapon types, projectile behaviors, AI, people, animation maps, particle effects, and many other elements can all be defined this way.

For example, I could add a new type of ranged weapon class to my game (in addition to the current pistol, subgun, rifle, cannon classes), such as a class for a slingshot or bow & arrow, which would require new animations, character behavior triggers, and sound effects. It would only take a day or so to get it fully integrated into the game, and the engine wouldn't need to be touched.

What I said was that engines were comparatively cheap to build. The first one might take a while, but an experienced programmer can construct new engines fairly rapidly.

Your engine may be able to do quite a bit, but you must admit that it can't do everything. It might not be able to handle arc-based projectiles like the slingshot or bow and arrow for instance. It might not even have a concept of a third dimension for projectile travel. And if those were added, then collision detection through that 3rd dimension and AI handling for those projectiles needs to be adapted.

And script-based AI is generally poor, only suited to simple FSMs, so if you wanted serious improvement in that area, you would probably have to make engine modifications again.

And if you end up making those kind of adjustments, you might as well buff the graphics/UI to show off the expensive art assets and dialogue, right? Since the engine modifications are comparatively cheap in those departments.
Quote:Original post by Argus2
What I said was that engines were comparatively cheap to build. The first one might take a while, but an experienced programmer can construct new engines fairly rapidly.

An experienced programmer could have built the first engine neatly enough to allow additions and modifications, making the engine dissection and reconstruction completely unnecessary.

There are obviously some exceptions out there. Especially cheaper games, very linear games, and games that have a great deal of specific data hardcoded into the engine. These types of games would be a nightmare to modify into a newer version of a game. But handling this sort of thing is the purpose of scripting. It takes a little while longer to get the engine ready for the scripting itself, but in the long run, you'll save huge amounts of time.

Quote:Your engine may be able to do quite a bit, but you must admit that it can't do everything. It might not be able to handle arc-based projectiles like the slingshot or bow and arrow for instance.

The projects are governed by normal physics. All projectiles have an arc. Arrows and rocks would just have a more apparent arc because they travel slower, allowing more gravity to be imposed.

If your point is that the engine can't handle every possible desired addition, then that's a given. And there's nothing stopping the development team from working new behavior into their existing engine if the result will outweigh the work. That's a far cry from creating the revamped engines that you see in most game sequels.

Quote:It might not even have a concept of a third dimension for projectile travel. And if those were added, then collision detection through that 3rd dimension and AI handling for those projectiles needs to be adapted.

The concept of using the same engine implies that you expect the game to play the same way, and there may be features that the engine will be unable to reach for. However, your example is not one of them. Height can be simulated pretty easily for projectiles in a game that has no vertical dimension.

Quote:And script-based AI is generally poor, only suited to simple FSMs, so if you wanted serious improvement in that area, you would probably have to make engine modifications again.

You're just mistaken here. Scripted AI has every bit of potential as hardcoded AI. Script is just like normal programming code. It just exists outside of the compiled game, and is more easily accessible through access and reference, making it much easier to swap and change.

Quote:And if you end up making those kind of adjustments, you might as well buff the graphics/UI to show off the expensive art assets and dialogue, right? Since the engine modifications are comparatively cheap in those departments.

Doing so can also cause your user base to either buy new hardware or avoid buying your game.
Quote:Original post by Kest
An experienced programmer could have built the first engine neatly enough to allow additions and modifications, making the engine dissection and reconstruction completely unnecessary.

Guess all of those programmers who build new engines out there must just be stupid then.
Quote:And there's nothing stopping the development team from working new behavior into their existing engine if the result will outweigh the work. That's a far cry from creating the revamped engines that you see in most game sequels.

I don't think it's much difference at all. If it wasn't worthwhile revamping an engine, developers wouldn't do it. In fact, I bet many game sequels share a lot of code/techniques/designs between engines - you just don't see this as an end user.
Quote:
Quote:And script-based AI is generally poor, only suited to simple FSMs, so if you wanted serious improvement in that area, you would probably have to make engine modifications again.

You're just mistaken here. Scripted AI has every bit of potential as hardcoded AI. Script is just like normal programming code. It just exists outside of the compiled game, and is more easily accessible through access and reference, making it much easier to swap and change.

The actual AI work is almost always implemented in compiled code. Scripts just have a limited interface to the game engine, relying on coded implementations for AI functions. You can't make fundamental AI improvements through script - scripters are just tweaking states that are handled by the coded UI. Feel free to show me some scripts from your engine that disprove this.
Quote:
Quote:And if you end up making those kind of adjustments, you might as well buff the graphics/UI to show off the expensive art assets and dialogue, right? Since the engine modifications are comparatively cheap in those departments.

Doing so can also cause your user base to either buy new hardware or avoid buying your game.

And not doing so can cause the people with the money to buy new hardware to go and buy the games that make use of that new hardware. Don't take my opinion on it though, just have a look at the market. I'm not saying it's a good situation, I'm just saying that people generally re-use what they can, but have to make best use of their art and dialogue assets, which often involves updating their engine.

This topic is closed to new replies.

Advertisement