sw engineering with games
Author
i know there are common practices and processes to design and build software which i have used myself but was wondering are sw engineering practices and processes followed in game engine design or game design in the games industry?
if sw engineering is used for game engine design or game design are there any resources in particular for the industry?
Just to clarify, which software engineering practices are we talking about? Cause I have very different answeres for whether we're talking about principles like agile development or things like UML.
Personally (and I suspect I'll catch some flak for this), I think UML is bullshit. It represents everything that modern software engineering should not be -- excessively formal, detailed design beforehand that leads to inflexible and overcomplicated systems.
As for use in games and game engines, I don't think any of the pros really do it. The game industry is comparatively messy in that regard. We like to do our own thing, our own way. And that own way usually involves building code whose design is based entirely on experience and not at all on formal methods.
As for use in games and game engines, I don't think any of the pros really do it. The game industry is comparatively messy in that regard. We like to do our own thing, our own way. And that own way usually involves building code whose design is based entirely on experience and not at all on formal methods.
Author
i assume a game engine is very large with lots of subsystems or could call them systems themself e.g graphics engine, physics engine, A.I engine and so on. i cant believe there is no planning or "formal methods" before designing a games engine with in a games company. Maybe some programmers who make games as a hobby
may not need this.
so u saying a company says im gonna make a games engine today andthen the programmers just starts hacking lots of code together
not only do i believe it takes planning there must be a hell of a lot of research gone in to a project of designing a games engine.
ive made software without using uml and thought I'll never need it or use it and it just a waste of time.
i then had to use it for a project and would now say uml is valuable tool i have learnt. It helps with desgin problems u may not have realised, identifying parts of a system u may have missed, delegation of subsystems and many more...
may not need this.
so u saying a company says im gonna make a games engine today andthen the programmers just starts hacking lots of code together
not only do i believe it takes planning there must be a hell of a lot of research gone in to a project of designing a games engine.
ive made software without using uml and thought I'll never need it or use it and it just a waste of time.
i then had to use it for a project and would now say uml is valuable tool i have learnt. It helps with desgin problems u may not have realised, identifying parts of a system u may have missed, delegation of subsystems and many more...
Nobody really sits down to "write a game engine" from scratch these days though either. Mostly what happens is you write something ontop of your last app and slowly you end up with an engine mearly because you have all this code already written. I personally have never used UML for anything since I left uni, and even then I wrote my UML diagrams after my assignments were finished :P Never once used them at work, and our game engines we have there all seem to work fine.
But planning and UML are two different things. I think most engines such as Unreal3 or Source are very well planned, but I don't nessissarily think they used formalised design patterns todo it. Those types of things are very good in an accademic sense but in the real world mostly their too restrictive and pointless. People who write the top notch engines are people who've been doing it for a while - take Doom3 ... Carmack's had his fair share of experience so I doubt he needs to formalise it with something like UML befor he starts. I'm certain he has an idea of what he wants, and how he's going todo it befor he starts but writing out a UML diagram of it seems kind of pointless.
In other IT area's then I think that type of thing is used alot. UML and fancy documents look awsome to managment so they love that stuff. If you give a manager a piece of code that works 100% they'll stare back at you with a blank look in their eyes. Give them some code thats buggy but has a UML diagram, microsoft project file and a fancy word doc describing everything and they'll love it. Its just a different mindset. In games usually you don't have time for the SE crap, coders are higher up the foodchain and most of us don't put alot of stock in that type of thing - design and planning is definatly needed but in a far less formal way.
At least thats how my company works - think about it, discuss, then code. Nothing more and sometimes less :P
But planning and UML are two different things. I think most engines such as Unreal3 or Source are very well planned, but I don't nessissarily think they used formalised design patterns todo it. Those types of things are very good in an accademic sense but in the real world mostly their too restrictive and pointless. People who write the top notch engines are people who've been doing it for a while - take Doom3 ... Carmack's had his fair share of experience so I doubt he needs to formalise it with something like UML befor he starts. I'm certain he has an idea of what he wants, and how he's going todo it befor he starts but writing out a UML diagram of it seems kind of pointless.
In other IT area's then I think that type of thing is used alot. UML and fancy documents look awsome to managment so they love that stuff. If you give a manager a piece of code that works 100% they'll stare back at you with a blank look in their eyes. Give them some code thats buggy but has a UML diagram, microsoft project file and a fancy word doc describing everything and they'll love it. Its just a different mindset. In games usually you don't have time for the SE crap, coders are higher up the foodchain and most of us don't put alot of stock in that type of thing - design and planning is definatly needed but in a far less formal way.
At least thats how my company works - think about it, discuss, then code. Nothing more and sometimes less :P
Quote:Original post by PromitI agree with you that some (academics) advocate to create an enormous load of design before doing anything, making the most simple task a lot of work.
Personally (and I suspect I'll catch some flak for this), I think UML is bullshit. It represents everything that modern software engineering should not be -- excessively formal, detailed design beforehand that leads to inflexible and overcomplicated systems.
However, I disagree that you blame UML for this. UML just specifies how you can draw up designs so that everyone that knows the language understands your design. I could write whole lots of stupid, bloated texts in English, but that doesn't mean English is bullshit.
What is bullshit are those people that designing everything in UML guarantees your program is good.
Disclaimer - I do not work within the games industry, although I am the snr dev for a synthetic training project.
Formally designing and documenting a product is ESSENTIAL. Keeping developers on the leish and forcing them to go through the nause of designing and actually thinking about whats ahead can be tricky in practice though.
The idea that UML or other formal methods of designing leads to an over-complicated product is just plain wrong. If anything its the opposite.
I've found that developers tend equate progress with apparent progress. The two can be quite different. Apparent progress is when the developer, in the early stages gets stuff to happen early on, advocating the "just get on with it" premise. Later on in the project, especially when other developers on the team depend on each others work, the problems and assumptions appear, and before you know it youre changing structure and form.
My central premise is "make each day a step forward". That can only happen if you plan and document.
If a team has any risk management strategy they ought to design and document so that the effect of losing key personnel can be minimised. Also to keep the option of getting in a consultant if the team hits a problem can only be an option if the project is sufficiently documented - do you want to pay a consultant to figure out how your project works and then figure out a solution, or just the latter?
Documenting and designing is not just about what 'is' but also, 'why it is'; in other words the reasoning that goes behind making a particular design decision.
"Game Architecture and Design" and its Software Factory is pretty close to how my team works.
Formally designing and documenting a product is ESSENTIAL. Keeping developers on the leish and forcing them to go through the nause of designing and actually thinking about whats ahead can be tricky in practice though.
The idea that UML or other formal methods of designing leads to an over-complicated product is just plain wrong. If anything its the opposite.
I've found that developers tend equate progress with apparent progress. The two can be quite different. Apparent progress is when the developer, in the early stages gets stuff to happen early on, advocating the "just get on with it" premise. Later on in the project, especially when other developers on the team depend on each others work, the problems and assumptions appear, and before you know it youre changing structure and form.
My central premise is "make each day a step forward". That can only happen if you plan and document.
If a team has any risk management strategy they ought to design and document so that the effect of losing key personnel can be minimised. Also to keep the option of getting in a consultant if the team hits a problem can only be an option if the project is sufficiently documented - do you want to pay a consultant to figure out how your project works and then figure out a solution, or just the latter?
Documenting and designing is not just about what 'is' but also, 'why it is'; in other words the reasoning that goes behind making a particular design decision.
"Game Architecture and Design" and its Software Factory is pretty close to how my team works.
Quote:Original post by DaBonoFair enough.
However, I disagree that you blame UML for this. UML just specifies how you can draw up designs so that everyone that knows the language understands your design.
Quote:Formally designing and documenting a product is ESSENTIAL. Keeping developers on the leish and forcing them to go through the nause of designing and actually thinking about whats ahead can be tricky in practice though.I don't buy it. If you go and design everything beforehand, you'll simply get raped when your requirements change -- and they always do. You need to document what the hell you're doing, obviously, but extensive design beforehand is a waste of time. So if anything, doing UML after the fact is the best way to use it.
The idea that UML or other formal methods of designing leads to an over-complicated product is just plain wrong. If anything its the opposite.
Quote:Original post by PromitQuote:Original post by DaBonoFair enough.
However, I disagree that you blame UML for this. UML just specifies how you can draw up designs so that everyone that knows the language understands your design.Quote:Formally designing and documenting a product is ESSENTIAL. Keeping developers on the leish and forcing them to go through the nause of designing and actually thinking about whats ahead can be tricky in practice though.I don't buy it. If you go and design everything beforehand, you'll simply get raped when your requirements change -- and they always do. You need to document what the hell you're doing, obviously, but extensive design beforehand is a waste of time. So if anything, doing UML after the fact is the best way to use it.
The idea that UML or other formal methods of designing leads to an over-complicated product is just plain wrong. If anything its the opposite.
Changing requirements is something else that has to be managed of course; change costs. I imagine that this is of particular concern for an in-house project.
Remember, the act of designing illicits requirements as it stimulates the dialog between the architect/developers and customer.
Our requirements are linked to design specifications and test schedules. If the requirements need to change, we are able to quickly assess the cost. Before we even started desgin, we had a change management plan in place which the customer signed up to before we proceeded to elaboration.
There are diminishing returns wrt the depth when designing beforehand of course, for some organisations a high degree of control and planning is necessary. For example, we never designed every method/attribute of every class. We extensively described the responsibility of each class, we documented the structure of each part of the project and tested use-cases(yuk) against the candidate structure. We also completed sequence diagrams, showing the interaction between the classes.
The architecture that was generated is pretty stable but at the end of each construction phase, the developers submit change proposals for the architecture document.
I would imagine CMM 5 organisations probably fully design before cutting code.
We were assesed as CMM 3-4 during our last audit. I remember joking that this wasnt a measure of how good we are at developing - just how we manage the project.
Quote:I don't buy it. If you go and design everything beforehand, you'll simply get raped when your requirements change -- and they always do.
I dont see how forging ahead and not designing before you code would remedy this.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
