It's not about PS3, it's about programming on consoles, you obviously have low level access to the hw.
Capcom's "Framework" game engine
- Thread starter one
- Start date
I agree, i see very little actual gain from massive framework... Sure re-use bits and libraries where it makes sense, but even a sequel to an existing game ends up usually enough different stuff that the framework gets in the way.
It depends on the stuff rendered. For instance, "add-blended" particles are trivial, you just render them into black offscreen target and blend that on top of main scene.assen said:
Yes, many effects don't even need MSAA(some do though) - that's why this approach works well - most particles have little to no edges, and use low-res maps to begin with, so you loose almost nothing in terms of fidelity. The worst you can get is artifacts from "cutting" into other scene geometry, where low res edges can become apparent, but there are ways to reduce that too.
But you use Havok, don't you?DeanoC said:
Last edited by a moderator:
Aren't things like Unreal Engine 3 "massive frameworks...?" It seems everyone is in the habit.
It seems everyone is in the habit.Debatable. I'm clearly talking from an agile development perspective here and it's a common misconception, in my opinion, that agile practices are best implemented by experienced programmers. On the contrary, I think you need very experienced programmers to tame the complexity of a Big Monster Framework and bend it to your will, while less experienced programmers work better with clear practices that lead to very simple and mantainable code.
But again, this is my point of view, I'm happy Deano also see things from this point of view, but we are very few in this industry. My opinion is that the game industry is lagging behind when it comes to productive and cost effective software engineering practices and methodologies and need to evolve and embrace change.
Fran/Fable2
Lagging behind?! Considering what I've seen of other IT industries' practices and methodologies, I'm frightened!
From my POV, I'm a big fan of reuseable code. Why reinvent the wheel every game? Anyone who makes use of a library is reusing code. However, I think consoles are a slightly different challenge. The different requirements of a game in limited resources can make one implementation impractical for one game than another. That fancy 3D interface in Game A may consume too many resources for Game B. Still, for the most part any game can be conceptually divided into shared components. They all need a UI engine, IO, sprite system, maybe pathfinding. Having modules you can drop in should make for cheaper games. It might not make for better games, and considering the environments you and Deano find yourselves working, you might be in a better position to value quality over cheapness. For a lot of devs I think the cheapest, quickest solution is the only one they really care for, and reusing code seems a good idea. I suppose though that the effectiveness of the module would make that an easy or hard thing though. A sprite engine that doesn't have certain features needs to be modified, and when you start modifying existing code, it definitely becomes a fair consideration to think about rewriting it to do the job properly. Modifying code, especially old or someone else's, is a darned sight more problematic than writing your own.
Interesting! And incredibly OT
I'll give it another shot though, cause I wasn't very clear the first time. I'm not a fan of writing reusable code, but I'm a big fan of reusing code if it makes sense and saves time. For no reason I would rewrite everything from scratch and reinvent the wheel from game to game. If it makes sense to use Havoc or that memory allocator you wrote last game and worked so well, do it, reuse it.
But this is different from trying to write reusable code in the first place everytime you face a problem, trying to write the Big Framework That Works For Every Game before even knowing what game you have to write and what requirements you will effectively have and what problems you will face in practice.
That Big Framework will have to be flexible, and any tiny bit of flexibility you put in your code must be tested, bugged and maintained even if it's not strictly needed for your game and the problems you need to solve. That's why I'm all against trying to write reusable code in the first place, but I prefer to write The Simplest Code That Could Possibly Work and leave any extra flexibility out untill I really need it. I'm lazy
If after this a bit of code proves to be flexible and robust and tested enough to be promoted to a higher level, than reuse it, it makes a lot of sense and save a lot of time. Requirements change so often and so drastically from game to game and within the life of a single game, that I don't think it's wise to fight this change with a Big Framework, but rather embrace it and put practices in place to adapt as quickly and efficiently as you can. Keeping things simple is one of those practices. I'm pretty sure that writing for reusability is not the cheapest way to construct our software.
And I'm really convinced that the Industry needs to be as lazy and needs to avoid the mistakes already made by other software industries that are evolving. It's just more difficult for us because we need to be creative as well, and being productivity and creative at the same time is a tough challange. Very tough indeed.
Ok, I'm falling into preaching now, but I hope I made myself a bit more clear now, because this is in my opinion one of the biggest challanges to create truly next-gen games.
Fran/Fable2
I'll give it another shot though, cause I wasn't very clear the first time. I'm not a fan of writing reusable code, but I'm a big fan of reusing code if it makes sense and saves time. For no reason I would rewrite everything from scratch and reinvent the wheel from game to game. If it makes sense to use Havoc or that memory allocator you wrote last game and worked so well, do it, reuse it.
But this is different from trying to write reusable code in the first place everytime you face a problem, trying to write the Big Framework That Works For Every Game before even knowing what game you have to write and what requirements you will effectively have and what problems you will face in practice.
That Big Framework will have to be flexible, and any tiny bit of flexibility you put in your code must be tested, bugged and maintained even if it's not strictly needed for your game and the problems you need to solve. That's why I'm all against trying to write reusable code in the first place, but I prefer to write The Simplest Code That Could Possibly Work and leave any extra flexibility out untill I really need it. I'm lazy
If after this a bit of code proves to be flexible and robust and tested enough to be promoted to a higher level, than reuse it, it makes a lot of sense and save a lot of time. Requirements change so often and so drastically from game to game and within the life of a single game, that I don't think it's wise to fight this change with a Big Framework, but rather embrace it and put practices in place to adapt as quickly and efficiently as you can. Keeping things simple is one of those practices. I'm pretty sure that writing for reusability is not the cheapest way to construct our software.
And I'm really convinced that the Industry needs to be as lazy and needs to avoid the mistakes already made by other software industries that are evolving. It's just more difficult for us because we need to be creative as well, and being productivity and creative at the same time is a tough challange. Very tough indeed.
Ok, I'm falling into preaching now, but I hope I made myself a bit more clear now, because this is in my opinion one of the biggest challanges to create truly next-gen games.
Fran/Fable2
Last edited by a moderator:
Panajev2001a
Veteran
IMHO, there is the need for frameworks such as the Unreal Engine (I put under this term all of its components and tools, models importers, DCC tools exporters, level editor, effects editor, etc...).
They can be a great first step when you begin development: your artists, developing on PC's, will have a working renderer and exporting/importing tools running in little time.
From what is told UE is highly modular, with clear interfaces between its building blocks and is very well commented: designed so to speak to enable the developer to replace portions of the engine that they want to better adapt to the problem at hand in that particular game. It is also true, from what I was told, that more than "designed to be reusable" code Unreal Engine usually provides "very straightforward" solutions, so their shadows rendering solution is not the most complex and efficient solution, but maybe a slower implementation that is easier to understand and, for them, to document and implement as bug-free as possible.
Looking at Dead Rising and Lost Planet it is tough to call Capcom stupid for the approach they took as both games look and play great: this Big Framework might be used by them internally as the Unreal Engine might be used by other studios. A big, solid reference point that each game project is free to alter and modify where and if it is needed while gaining a lot of basic starting points that are very useful to get the game off the ground.
They can be a great first step when you begin development: your artists, developing on PC's, will have a working renderer and exporting/importing tools running in little time.
From what is told UE is highly modular, with clear interfaces between its building blocks and is very well commented: designed so to speak to enable the developer to replace portions of the engine that they want to better adapt to the problem at hand in that particular game. It is also true, from what I was told, that more than "designed to be reusable" code Unreal Engine usually provides "very straightforward" solutions, so their shadows rendering solution is not the most complex and efficient solution, but maybe a slower implementation that is easier to understand and, for them, to document and implement as bug-free as possible.
Looking at Dead Rising and Lost Planet it is tough to call Capcom stupid
for the approach they took as both games look and play great: this Big Framework might be used by them internally as the Unreal Engine might be used by other studios. A big, solid reference point that each game project is free to alter and modify where and if it is needed while gaining a lot of basic starting points that are very useful to get the game off the ground.
There might be a coneptual difference between a Framework and an Engine. I'm not sure, but that point ought to be clarified. Thinking of other engines, they tend to be suited to particular types of games, whereas I image a Framework would be more adaptable. But I'm just guessing that.IMHO, there is the need for frameworks such as the Unreal Engine (I put under this term all of its components and tools, models importers, DCC tools exporters, level editor, effects editor, etc...).
Looking at Dead Rising and Lost Planet it is tough to call Capcom stupid
We've always used the word "Framework" to describe the lower level building blocks we share between game.
Things from reusable containers up to resource management and graphics.
The first time I remember someone using the term "game engine" was Quake which really was just Quake without the data.
But I wouldn't expect a clear distinction between the two, what I call a framework someone else might call an engine and vice versa.
Things from reusable containers up to resource management and graphics.
The first time I remember someone using the term "game engine" was Quake which really was just Quake without the data.
But I wouldn't expect a clear distinction between the two, what I call a framework someone else might call an engine and vice versa.
Well, I think middleware is probably more mature outside of gaming and people are used to using lots of third-party apps and libraries, whereas in the gaming community, this is a somewhat more recent phenomenon. It's amazing how much NIH there can be, but it's to be expected that when you have some extremely top-notch coders, they are going to want to write everything themselves regardless of whether or not it's been done before. I can't speak for everyone, but that's my experience anyway.
I've also worked in companies that were heavily dependant upon lots of different vendors for software and that's no good either. So there's good and bad with each approach and neither extreme is desirable.
Hey, I...! I... uh, said something snarky?
I wouldn't call that lazy - it's the distinction between production and R&D code.Fran said:
We could all keep writting pretty and reusable code for every smallest thing, but that way nothing would ever get shipped. And noone would ever write in assembly anymore, because let's face it - those bits are the ultimate non-reusable code segments
That said, sometimes promoting your "lazy implementation" to a higher level requires a complete rewrite - so I do like to consider what are the chances of ever wanting to reuse something before writting it.
So is learning a milion new rules&practices imposed by a massive framework. Fran made a very good point about needing experienced people to tame very large frameworks.Shifty Geezer said:
One of the hardest things for none technical managers to understand is he cost of re-use.
Designing and building a piece technology that can be used by two games costs 3-5x over just building it for your immediate requirements.
Building something totally generic involves 10x+ cost and everyone who uses it to compromise and accept its design principals.
We've had good success with sharing tech that no-one wants to write, notably audio drivers and memory managers. They're hard to do well and no-one wants to write them. We've had good success where there is good agreement on functionality, say intrusive list implementations.
But where there is significant disparity in expectation shared tech has always cost much more than it delivers, even when it's been dictated. This isn't so much programmer stubbornness as it is different viewpoints, I've always said that when it comes to solving programming problems there are many obviously bad solutions but very few obviously good ones.
Designing and building a piece technology that can be used by two games costs 3-5x over just building it for your immediate requirements.
Building something totally generic involves 10x+ cost and everyone who uses it to compromise and accept its design principals.
We've had good success with sharing tech that no-one wants to write, notably audio drivers and memory managers. They're hard to do well and no-one wants to write them. We've had good success where there is good agreement on functionality, say intrusive list implementations.
But where there is significant disparity in expectation shared tech has always cost much more than it delivers, even when it's been dictated. This isn't so much programmer stubbornness as it is different viewpoints, I've always said that when it comes to solving programming problems there are many obviously bad solutions but very few obviously good ones.
Similar threads
- Sticky
