Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (578)
games submitted by our members
Games in WIP (499)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  Game design patterns, any pointers?  (Read 9397 times)
0 Members and 1 Guest are viewing this topic.
Offline Breakfast

Senior Member




for great justice!


« Reply #30 - Posted 2006-11-29 01:38:38 »

Quote
People are reluctant to apply Software Engineering practices to video game development. When I see video game project, I rarely see any UML or architectural documents.
In the real world a whole lot of stuff gets written without any UML or architecture documents, but I follow your point. I suspect if you look behind the scenes at somewhere like EA you would find a whole load of documentation that produces the solid and predictable sequels that all EA fans have come to know and love.

The problem with that is that if you have your plan and your UML doc and everything else and one of your engine guys comes in and says "hey check out this neat effect I've just found how to do" but it's not in the architecture document or given it's own corner of the UML then it's out, regardless of how much it would add. In games writing more than pretty much any other area of software development you need a bit of room for sponteneity and that is something that Architecture-first development doesn't allow for. My experience is that it's actually too rigid for any non-trivial development task, but I have never worked for a Fortune 100 software company and it probably works great for them.  My view would be that a more Agile approach would be better suited to game development, but then I've never worked for one of the major game development houses either so I have no idea whether or not that is what they are doing, that's just what my programming experience suggests. I can imagine that a comprehensive test suite that you could apply on lots of different hardware and OS combinations would be a big help with the basic QA stuff so your testing team could work on the more sophisticated things.
Offline K.I.L.E.R

Senior Member




Java games rock!


« Reply #31 - Posted 2006-11-29 07:57:48 »

Here's a tip, never do this:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
/**
    * Adds a rule
    *
    * @param rule
    */

   public void add(Rule rule)
   {
      int divisor = rule.ruleNumber % 2; //ruleNumber is final
     
      if (rule == null) {
         return;
      }
      else if (divisor == 0) {
         maxEvenNumbers++;
         super.addSibling(rule);
      }
      else {
         maxOddNumbers++;
         super.addChild(rule);
      }
   }

Vorax:
Is there a name for a "redneck" programmer?

Jeff:
Unemployed. Wink
Offline purpleguitar

Junior Member





« Reply #32 - Posted 2006-11-29 14:03:32 »


The problem with that is that if you have your plan and your UML doc and everything else and one of your engine guys comes in and says "hey check out this neat effect I've just found how to do" but it's not in the architecture document or given it's own corner of the UML then it's out, regardless of how much it would add.

For what it's worth, my limited experience shows that wise application of design patterns yields architectures that are more adaptable to change.  After all, this is one of the major goals of patterns, and reusable code promotes agility.  I think you're looking at two different issues: the application of patterns early in the design process vs. laying down an immutable architecture during the design process.

@lukemasters: I'm curious about your experience.  I observed the same phenomona (lack of good software engineering practices) through a survey of books on game programming, but I do not have much exposure to the commercial development world aside from books.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline lukemasters

Junior Newbie





« Reply #33 - Posted 2006-11-29 14:55:49 »

I'm no game development guru or software development guru. Nor do I have tons of years of experience in gaming. I'm also aware that companies like EA and Ubi might not used architecture or UML document.

But it's not because they don't do it, that we should not. I also am fully aware that a waterfall approach (Architecture-first development) is not adequate for games and software development projects to.

If my project works out, I want to promote an Iterative approach that put the emphasis on an evolutive design, architecture and patterns.
As for agile development, you must remember that Agile does not mean no design. On the contrary if an agile project is done they way it should be done, there should be UML and Architecture documents.

One of the main pitfalls to avoid is developing huge architecture documents. In my opinion architecture documents should be short and sweet.
Offline Mr_Light

Senior Member




shiny.


« Reply #34 - Posted 2006-11-30 12:08:55 »

UML and architectural documents are traditionally about communication.
over the years it has found it's way into the process.

it's diffuculd to express but the short sum of it is that design or documentation has little to do with processes as waterfall agile and that whole pile.

if design is written down or not doesn't mean there's no design anypiece of code is written by some design sure the perspective level and amount of overview differs, but design is there.

documentation is always there from a list of machine code to highlevel  programming language to skeches on a paper. it all discribes the program and is thus documentation for human beeings not or hardly interpaterable doesn't matter it is documentation(yes sure is (piss) poor documentation).

Working togetter is hard no matter what the common consensus is. Esp. in area's without references, such as cutting edge and creative processes.

Quote
In the real world a whole lot of stuff gets written without any UML or architecture documents, but I follow your point.
heh, those must be doing the projects who bring the stats down in one of those carts of standardish group.

1  
2  
3  
4  
5  
      int divisor = rule.ruleNumber % 2; //ruleNumber is final
     
      if (rule == null) {
         return;
      }

because your accessing an object and then you check for null?

Quote
The problem with that is that if you have your plan and your UML doc and everything else and one of your engine guys comes in and says "hey check out this neat effect I've just found how to do" but it's not in the architecture document or given it's own corner of the UML then it's out, regardless of how much it would add.
the problem is in your decision making not in your uml part. next to that your achitecture probely isn't an good achitecture to begin with, it's should guide the program allow parts to work togetter and allowing parts to work if it restricts you from adding or using parts then your "achitecture" goes against everything it's suppose to stand for.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline Breakfast

Senior Member




for great justice!


« Reply #35 - Posted 2006-11-30 13:11:48 »

Quote
the problem is in your decision making not in your uml part. next to that your achitecture probely isn't an good achitecture to begin with, it's should guide the program allow parts to work togetter and allowing parts to work if it restricts you from adding or using parts then your "achitecture" goes against everything it's suppose to stand for.
Look into how games are written by the big companies. They put together a design document, give it to the development house and expect it to be matched exactly. That may not be how we want to imagine it works, but it is how it does work for the majority of professional game developers; here's the document, here is your deadline; build it in time for the Christmas market. No leeway, no room for experimentation. One of the main reasons that when EA bought up Bullfrog a few years back (they were based just round the corner from me) pretty much all the Bullfrog developers, who had been used to a more creative environment, quit within a few months.
Offline Mr_Light

Senior Member




shiny.


« Reply #36 - Posted 2006-11-30 14:37:48 »

EA is wrong on so many levels  Grin lets not start that subject.

A design document is not an achitectural document, thats more a manual or specification as to how your program should be put togetter. a software design document may comtain a chaper or probebly should contain a chapter on architecture but that describes how it fits in one, and usually that one is predefined in the achitectual documentation. We might have had a glitch in our communication there.

that a design document is Law and absolute, well there is nothing against that imo. Thats perfectly fine as it's your nexus or medium for communication between programmers requirements engineers and the likes. If some programmer wants todo something differendly then the document should be changed and then he can follow up. This is the way it should go cause other programmer will be basing there parts on the document and you might get problems glue stuff togetter. Where the problem is that 'the creative programmer' in question is unable to change the document. Which can be because the process is wrong or that the process is based around that programmers don't profide input. Although I'm pritty sure against the latter it can be justified depending on your view, but this is turns into policial mombo-jumbo quite quickly.

In games technical changes often also lead to changes outside technical consideration/implementations so it also has to go around another document(which everyone seems to name differendly)

anyways these process usually get slow esp in big(er) companies and is what the agile movement is out to cut down on. Some are not as transparent to apply in game development I gues as your typical user or usergroups even are difficuld to indentify. And theres the whole the-consumer-doesn't-know-what-he-want-till-he-has-it part. Figuring out what the user want before he knows it probebly makes making games exciting.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline K.I.L.E.R

Senior Member




Java games rock!


« Reply #37 - Posted 2006-12-01 02:39:42 »

It is pretty stupid of me eh?  Grin

Quote
because your accessing an object and then you check for null?

Vorax:
Is there a name for a "redneck" programmer?

Jeff:
Unemployed. Wink
Offline Mr_Light

Senior Member




shiny.


« Reply #38 - Posted 2006-12-01 10:20:56 »

will you trust me wenn I say that thats nothing?  Wink

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #39 - Posted 2006-12-03 01:15:13 »

Look into how games are written by the big companies. They put together a design document, give it to the development house and expect it to be matched exactly. That may not be how we want to imagine it works, but it is how it does work for the majority of professional game developers; here's the document, here is your deadline; build it in time for the Christmas market. No leeway, no room for experimentation.

Huh? Not in the companies I've worked at. The developer writes teh design doc themselves, that's what all those designers are on the payroll for Smiley.

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Eliwood

Junior Member




Stencyl


« Reply #40 - Posted 2006-12-04 01:16:27 »

I think he means a requirements document which spells out all the features and functionality they want, not a technical document.

Offline Breakfast

Senior Member




for great justice!


« Reply #41 - Posted 2006-12-04 16:50:47 »

Almost certainly what I meant. Every organisation I have ever dealt with seems to have a different set of names for the major documents that the development process is built around.
Pages: 1 [2]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (27 views)
2014-04-15 18:08:23

BurntPizza (23 views)
2014-04-15 03:46:01

UprightPath (38 views)
2014-04-14 17:39:50

UprightPath (20 views)
2014-04-14 17:35:47

Porlus (36 views)
2014-04-14 15:48:38

tom_mai78101 (61 views)
2014-04-10 04:04:31

BurntPizza (119 views)
2014-04-08 23:06:04

tom_mai78101 (219 views)
2014-04-05 13:34:39

trollwarrior1 (186 views)
2014-04-04 12:06:45

CJLetsGame (193 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!