   OOP Game Development Question
  I'm curious what is the best way to develop my games.  So far I wrote one very small/limited game, but I did this by creating everything into objects (person, board, opponent), then figuring out how I'm going to put them all together.Now, my question is, is it better to figure out how the game logic is going to work before anything else?Or is it better to start making these classes/objects, then figure out how you're going to implement them?  And make changes to them as necessary?Thanks for your time.[Edited by - BubbaCola on September 9, 2007 9:37:39 AM]
Quote:I'm curious what is the best way to develop my games. One that gets the job done.Quote:Now, my question is, is it better to figure out how the game logic is going to work before anything else?Or is it better to start making these classes/objects, then figure out how you're going to implement them? And make changes to them as necessary?Either way goes (depending on the school - TDD vs. waterfall vs. agile vs...), mix of both can be better.There is never ever "right" way. There are just optimal and sub-optimal compromises for given circumstances. Unless you're really good, experienced and versed in a particular problem domain, be prepared to refactor and rewrite a lot, since you'll have very hard time getting everything right the first time for any non-trivial problem.   ;  [opinion]First you want to figure out how your game is going to play.  Figure it out like it is going to be played with pen and paper.  The formulas, information you need, ect.  Then once that is done move on to class design and interaction.[/opinion]theTroll   ;  Pretty good advice, thanks a lot, guys.   ;  Try writing up a design document before coding anything. It will give you a clear direction on what you need and how it should be done. Creating a design document first has helped me so much it's incredible. I went from having a few loose ideas on how I was going to implement stuff in my game to a clear bird's eye view of the architecture and design. The first game I made, I didn't use a design doc. I just went in and coded as I went along and I did have to go back and change a lot of things. Looking back at it now, I realize how awful the design was. It was still a valuable learning experience of course. Even when you fail you still gain something of value.   ;  I too say to go ahead with a design document.  My friend is not a coder but he likes to design all kinds of things.  What he does, is just throw me design ideas, and ask why they are never put into code.  My answer: "because I have no idea how everything works together, with out a design document."  He just automatically thinks a coder just codes a game based on the game, and not the design of what you have.  Then, if I design something I ALWAYS write it all down and most of my stuff gets put into code A LOT faster.  Also, the design phase should not only be a one day process.  The design phase for lots of my stuff is about 2 weeks long (my games are little, so bigger games will take a lot longer time).;  Great, do you guys have any tips on making a design document by any chance?I have no idea where to get started with that.   ;  > I'm curious what is the best way to develop my games. As has been said before there is not necessarily one best way. In terms of OOP though the basic checks like if you have a base entity make sure anythig that derives from it is actually an entity. Like an aircraft shouldn't inherit wheels just because it has them, an aircraft isn't wheels, though wheels may be a member.> do you guys have any tips on making a design document by any chance?I think reading the thread it's been pretty ambiguous as to what sort of design document you need. I think you need 2 design docs. One for the game you're making and at least one for the code design. When coding your own games the important thing is writing a clear consise design that you can readily understand and modify even if you haven't looked at it in a long time. As far as code design there are a number of structured methods such as SSADM and UML I think both of these if used to the full extent are too much. Personally and professionally I use some spects of UML for code design diagrams but little else comes in usefull.Good luck with everything my main piece of advice is make everythig as consise as possible it means you're more likley to modify and revise the design.   