Jump to content
  • Advertisement
Sign in to follow this  
jnrprogrammer

sw engineering with games

This topic is 4286 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
Advertisement
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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!