Sign in to follow this  

sw engineering with games

This topic is 4072 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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...


Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Quote:
Original post by Promit
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.
I 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.

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by DaBono
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.
Fair enough.

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.

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 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.

Share this post


Link to post
Share on other sites
Quote:
Original post by Promit
Quote:
Original post by DaBono
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.
Fair enough.

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.

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 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.


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.

Share this post


Link to post
Share on other sites
Yes, but you'll find very few game development studios with CMMI certification.

The needs of an organization are going to influence the amount of pre-planning done as well. Obviously planning in some form is essential, period. But the extent of that planning varies; the extent to which you plan has advantages and disadvantages.

You shouldn't really be comparing the design methodologies of a game development studio to the design methodologies of say, a Department of Defense contractor; this is where the various advantages and disadvantages come into play.

Quote:

I dont see how forging ahead and not designing before you code would remedy this.

There's a difference between planning out the key relationship between subsystems and the details of crucial components, and producing reams of UML that include details of "every forseable" (quotes because this is the part that is never true) method, etc. I don't think Promit is advocated not planning out anything, and for my part I only design on a very coarse level (key relationships, details of what is critical, like I mentioned) and find that to be quite effective -- and I've worked in both of the aforementioned industries. I've never had trouble with this level of design compromise, provided I was given reasonably accurate initial requirements. It gives me a clear path for implementation, but it doesn't get me bogged down in implementation detail before I'm actually implementing anything.

Share this post


Link to post
Share on other sites
Quote:
Original post by Promit
Quote:
Original post by DaBono
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.
Fair enough.

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.

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 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.


I work as a game developer, the requirements are constantly changing as making something 'fun' cannot be designed before hand, it requires prototyping and multiple iterations.
But there should at least be a general outline/design for the global system even if the sub systems all constantly in flux.

In short, if your going to do some initial designing (UML or whateva) i wouldnt waste to much time on it for games.

Share this post


Link to post
Share on other sites
Quote:
Original post by Promit
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.

This is the first time it ever happens since I registered on these board, so forgive me, but I have to disagree with you on this point [smile].

UML is a tool whose goal is to ease communication - and like any other tool you can use it the way you want. I think that you refer to formal methods that happen to use UML (RUP, 2TUP and so on) which are designed to handle complex problems in a complex environment (typically: big companies that have to design early because of their unresponsiveness and limited capabilities to handle fast changes). UML as a tool doesn't enforce the "design first, code last" idiom - you can modify your model at any time.

Regards,

Share this post


Link to post
Share on other sites
Quote:
Original post by Emmanuel Deloget
Quote:
Original post by Promit
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.

This is the first time it ever happens since I registered on these board, so forgive me, but I have to disagree with you on this point [smile].

UML is a tool whose goal is to ease communication - and like any other tool you can use it the way you want. I think that you refer to formal methods that happen to use UML (RUP, 2TUP and so on) which are designed to handle complex problems in a complex environment (typically: big companies that have to design early because of their unresponsiveness and limited capabilities to handle fast changes). UML as a tool doesn't enforce the "design first, code last" idiom - you can modify your model at any time.

Regards,


I agree, saying it's bullshit is harsh. I can see why you would think that if it's been misused at some point.

The point of uml is communication. Even a bastardised form of UML is useful for communicating with a team, as long as every member of the team understands the symbols used in the same way.

Back to jnrprogrammer - A good software engineering practice is good no matter if it's used in game development or elsewhere. If it helps deliver better quality code, or shortens the time to get that good quality code out, then it's a good practice.

The danger is drawing distinctions between game dev and other dev is thinking that just because you are a game programmer means you shouldn't need to bother with this that or the other good practice cos you're too l33t for it. I take things from my day job as a business app programmer to my hobby game dev and back again all the time - allowing yourself different perspectives and an open mind allows you to grow!

Share this post


Link to post
Share on other sites
We have most of our classes and structures in UML on paper. This is mostly for new people, so that they can get an overview of our systems fast. Getting our codebase up has been an iterative process, and we also use alot of prototyping to test gameplay elements.

Share this post


Link to post
Share on other sites
Quote:
So if anything, doing UML after the fact is the best way to use it.


Just because you say so doesn't make it true.

A couple of years ago I worked for a company where we implemented accurate real-time physics into CAD software as a plug-in. We had a couple of simple rules: Put everything in classes (no rogue functions or global variables) and each class had to be generated by the Rational Rose code generation tool. We'd just fill up the empty methods with code. The UML class diagram was our documentation, always reflecting exactly what was found in the source files and always up to date. Now how rare is that?

Share this post


Link to post
Share on other sites
Quote:
Original post by metimmee
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.


I only have just over two years of working experience, but I've seen and worked with three ways of development/management methods in this time:
1) Hack/fix, distribute, get complaints, hack/fix, distribute, get complaints, ad infinitum, no docs
2) Very formal waterfall development process, in 11 months I wrote only a few hundred lines of code.
3) Agile development with a mix of SCRUM and eXtreme Programming, very few docs

Personally, from a developers point of view, I like the Agile method best at the moment. Although I only worked with it for only one and a half month now.

Now, I'm going to disagree with you on your statement that formal design and documenting is "ESSENTIAL". But I will throw you a bone by saying that it depends heavilly on the situation and the project you are working on.

The time I worked with the heavy waterfall process I do believe all the documenting was necesary. The company (ASML) is huge, communicating with other people is near to impossible, testtime is never available, and buildtime even for partial builds went through the roof. Thereby, the system was big and complex and had a lot of functionality and it always had to be stable for a customer.
So, documenting, and overdocumenting, is the only way to keep an insight on how the system works.
But I must also add that the ENORMOUS amounts of documentation made me as a developer never read it.

Now that I'm working with an Agile process I barely write documentation, but I use the unit tests to document the use of functions.
And also because there is so little documentation, and you are forced to explain your code to your colleague (due to pair programming), you implicitly write cleaner, easier to understand code.
Refactoring is used to solve any design anomalies that stand in your way and because you coded everything so nicely that should not have any huge impact (ideally ofcourse).

As for UML, I agree with DaBono. UML is a nice standardised way of documenting, but going overboard with it in a situation where it is not needed leads to nothing but headaches.

I do not know how this all maps to game development, but I guess that game development is quite a dynamic process where requirements can change rapidly, so having a lot of documentation and having to keep in in sync with an everchanging system seems to me more of a hassle than an aid.

Share this post


Link to post
Share on other sites

This topic is 4072 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this