quote:
What will happen if I do not engage in the prerequisite activities?

You''ll have a much harder time to actually code the game/app. I mean common, just pick up a paper and pen and write down what happens when, doesn''t even have to be in C/C++, pseudo-code is dandy.

quote:Original post by Enokh
You''ll have a much harder time to actually code the game/app.

What do you base that statement on? I''m not asking for disembodied conclusions, I''m asking for the reasoning process that leads to your conclusions. Anyone can throw around dogmatic statements.

quote:
I mean common, just pick up a paper and pen and write down what happens when, doesn''t even have to be in C/C++, pseudo-code is dandy.

Why is it better to scribble pseudo-code than to write actual code?

There are different models for development where not the whole application is designed before starting, like extreme programming, spiral model and others.
You may find yourself more comfortably doing prototyping instead of a full design, that''s also somewhat common and healty practice where you can feel it before a formal design.
At the end of the day you don''t need a full design to start development but you can make your life lot easier if you have beforehand, but again it really depends on the size and complexity of the project.

quote:Original post by SabreMan
However, the volume of books published on a particular topic do not decide, or necessarily even indicate, the merit of the topic. To put it another way, I''d say your line of reasoning is illogical. If you really want to explain why it is important to design before coding, it is insufficient to make an appeal to popularity.

To be honest I was aware of the point you were making, I was just feeling too lazy to elaborate. I agree with what you said to an extent, but I would say it was inconclusive rather than illogical.

quote:Similarly, a response such as `why do architects make building plans before they start building?'' is insufficient. Sometimes metaphor provides a useful reference point, but it does not provide identity. The fact that architects design buildings does not tell us why we should design software. Its proof by false analogy. Programs are not buildings.

I don''t know, there''s a certain amount of leverage in this analogy. Code Complete by Steve McConnell gives a good break down on the various metaphors used in software development, the construction analogy being one of them and gives a strong case for it being appropriate.

quote:So, why should I sit down and design my programs before opening a text editor and hacking some code? What activities should I engage in which constitute `design''? How do I know when those activities are sufficiently complete that I may move onto coding? What will happen if I do not engage in the prerequisite activities?

Well it largely depends on the complexity of the program, a thorough design is most, although not exclusively, applicable in large, complex projects especially when more than one person is involved or the code is going to be maintain over a period of time.

Designing forces you to think clearly about what you are doing and how you going to do it rather than hacking it until it works. Depending on the skill and experience of the programmer this can save a lot of time. Even a just a sketchy high level design can be of great benefit. Hacking away at code in a short sighted manner prevents you from seeing the implications of your code until it''s too late. This isn''t a problem with small projects as you haven''t invested a large amount of time in them but if you spent a month developing an application only to realise that you''ve made a fatal error in your implementation that prevents you from carrying on you''re not going to be best pleased. Thinking it throught before hand can save you a lot of this hassle. Of course, if you design is flawed then it''s not going to be much use.

Mistakes are easier to rectify in the design phase as nothing has been committed to code where even minor modifications can lead to cascading changes throughout the code. A good design doesn''t guaranty a perfect, working application but it helps.

Pre-designed code is generally easier to understand and a follow as it suscribes to a clear, well thought out structure rather than being a mish mash of after thoughts. It''s also more likely to be reusable if planned from the start to be, which could save you time in other projects.

Also, by the time you''ve finished you still know how it all works which isn''t always the case when you just hack something from start to finish and even if you do forget you''ve got the design to look back on which can be more convenient than reading hundreds of lines of comments spread throughout your code.

On large projects architecture of a project is often developed by one group of people and implemented by another in which case the design is needed for communicating what the designers are thinking to the programmers. Or even just for programmers communicating to each other.

With a clear view of what needs to be done it makes it easier to split task between team members. It provides an easy way for team members to know what each other are doing. It also means the interfaces between components are well defined so each programmer can work on their component as an insulated unit before integrating it into the application as a whole. This is often useful even if just one programmer is working on a project.

Possibly one of the most important reasons in team based projects is it acts as documentation for the application. This allows new team members to get up to speed with the source code very quickly and reduces the dependence on knowledge being handed down with can be particularly devastating when an experience developer leaves. In my previous job I developed an API based on legacy code for which the only documentation was the barely commented and badly formatted code and the two architect gurus who weren''t always available. The lack of a design doc in this case made development a pain as I had to read the code in order to determine the functionality of methods and classes I wanted to use.

Any way, they''re just a few of my thoughts on why it''s good to design first. Don''t get me wrong, I''m not suggesting that you should design every project down to the last detail before you start coding and going into pseudo-code for every single function is overly excessive but even a little design can go a long way to improving productivity. If anyone''s really interested in software design issues do a search on the web or read a few books as they''ll describe the benefits far more eloquently than I could.


--
"Never Abandon Imagination" - Tony DiTerlizzi

Hmm, that was a bit longer than I intended. Sorry about that.

--
"Never Abandon Imagination" - Tony DiTerlizzi

I use OO in my games extensively cos that is my background and I don''t really know how else to program. I use a sprite object which has position and velocity as well as other things. Nearly everything subclasses this. Then I have a method which updates sprites locations and checks for collisions. I can pass it every sprite in the game no matter what it is and it will update it whether that be projectiles, particles, characters, items etc. Then I can call sprite.collide() and whatever the actual subclass is will know what to do with itself.
I use a lot of subclassing such as
Sprite->AnimatedSprite->Character->User,
Sprite->AnimatedSprite->Character->NPC,
Sprite->Projectile->Missile etc
and overidden methods:
Sprite->Projectile.impact(impactObject). Subclasses will override this and perform whatever action necessary etc.
You get the idea. I then use Manager classes to process specific groups of items. So a ProjectileManager to process every projectile in the game. Whenever a projectile is launched, I call ProjectileManager.add (projectile) and it is then out of the launchers control and the manager takes care of it for its lifetime. The thing I like about this approach is that I can get everything working at a basic level and then simply expand upon it and add to it in ever more detail. I can create a new type of projectile like a homing missile which will extend Sprite->Projectile and all I need to do is implement the impact() and update() method. Is this not a good way of doing it? I find it works really well.
I''m sure a lot of you would cringe at this gross use of polymorphism but I haven''t had many performance problems yet and I''m using java. I don''t use any upward casting which is really slow and I object pool and reuse just about everything so as to limit runtime object creation. I''m using middleware for the 3D engine so only all the game logic is done this way and I have a 400mhz.
I know OO has a performance impact associated with it but considering how much faster release code c++ is than java and given the processing power of todays computers, I think you can get away with it and still produce a good game.