Back
to top
OCR Computer Science Help! ASAP
Watch this threadPage 1 of 1
Go to first unread
Skip to page:
Rolls_Reus_0wner
Badges:
22
Rep:
?
You'll earn badges for being active around the site. Rep gems come when your posts are rated by other community members.
#1
Hi! I am creating a more advanced version of the renowned game Breakout (BrickBreaker). I have done the analysis already and got full marks which was all good however, I'm stuck on whether to code the game first then do the design after. It would be hard for me to replicate the design completely and I might change my mind later on the design. Has anyone does this before and is it worth finishing it ASAP but at high quality work?
Personally, I would rather code it and make mistakes then do the design.
TLDR - Should I do the Design or Development section first???
Personally, I would rather code it and make mistakes then do the design.
TLDR - Should I do the Design or Development section first???
0
reply
Rolls_Reus_0wner
Badges:
22
Rep:
?
You'll earn badges for being active around the site. Rep gems come when your posts are rated by other community members.
#2
Rolls_Reus_0wner
Badges:
22
Rep:
?
You'll earn badges for being active around the site. Rep gems come when your posts are rated by other community members.
#3
Rolls_Reus_0wner
Badges:
22
Rep:
?
You'll earn badges for being active around the site. Rep gems come when your posts are rated by other community members.
#4
Rolls_Reus_0wner
Badges:
22
Rep:
?
You'll earn badges for being active around the site. Rep gems come when your posts are rated by other community members.
#5
winterscoming
Badges:
19
Rep:
?
You'll earn badges for being active around the site. Rep gems come when your posts are rated by other community members.
#6
Report
#6
Before you've written code, your most useful tools are your requirements and your detailed functional tests. Some up-front consideration about how to solve particular implementation problems (small toy/sandbox code prototypes are helpful) and 'big picture' ideas on a possible architecture of the solution can help you decide the best way to approach the code; for example, whether you want a separate client/server app. It also helps to draw a UI design (for example, using pen+paper or a drawing tool to make some UI mockups), and to look at the system from the user's point of view
However, A detailed design which tries to guess implementation details or tries to guess an un-proven architecture is wasteful of your time until the main components are in-place and you've managed to understand all of your 'unknowns'. - That often means having a fair bit of code in-place which resembles a testable, barebones system, and being in a position where you can confidently guess how the rest of it is going to fit together (i.e. you're not going to throw everything away and rewrite it).
Detailed design documentation doesn't help you understand how to write unwritten code - it's the other way around; the purpose of writing design documentation is to help someone to understand how to read/interpret the already-written code and figure out how it all works.
It's a simple matter of known-vs-unknown. You can't document something that you don't fully know or understand. For example, if you have no idea how you'd write the code for a separate client and server app and get it working, then it's impossible to write it down into a design document. Any effort you spend in trying to do that is really just wasted. Similarly, if you're trying to draw the flowchart for a complex algorithm but don't have anything working to test all your edge cases, then time you spend making that flowchart look neat and tidy for your report will be wasted if you suddenly find out the algorithm is flawed and that you need to restructure it in a different way.
By all means, do use whiteboards and scrap paper to scribble down rough ideas and use whatever means necessary to clarify your thoughts, but don't make pretty documentation until you know it isn't going to change
However, A detailed design which tries to guess implementation details or tries to guess an un-proven architecture is wasteful of your time until the main components are in-place and you've managed to understand all of your 'unknowns'. - That often means having a fair bit of code in-place which resembles a testable, barebones system, and being in a position where you can confidently guess how the rest of it is going to fit together (i.e. you're not going to throw everything away and rewrite it).
Detailed design documentation doesn't help you understand how to write unwritten code - it's the other way around; the purpose of writing design documentation is to help someone to understand how to read/interpret the already-written code and figure out how it all works.
It's a simple matter of known-vs-unknown. You can't document something that you don't fully know or understand. For example, if you have no idea how you'd write the code for a separate client and server app and get it working, then it's impossible to write it down into a design document. Any effort you spend in trying to do that is really just wasted. Similarly, if you're trying to draw the flowchart for a complex algorithm but don't have anything working to test all your edge cases, then time you spend making that flowchart look neat and tidy for your report will be wasted if you suddenly find out the algorithm is flawed and that you need to restructure it in a different way.
By all means, do use whiteboards and scrap paper to scribble down rough ideas and use whatever means necessary to clarify your thoughts, but don't make pretty documentation until you know it isn't going to change
0
reply
Rolls_Reus_0wner
Badges:
22
Rep:
?
You'll earn badges for being active around the site. Rep gems come when your posts are rated by other community members.
#7
(Original post by winterscoming)
Before you've written code, your most useful tools are your requirements and your detailed functional tests. Some up-front consideration about how to solve particular implementation problems (small toy/sandbox code prototypes are helpful) and 'big picture' ideas on a possible architecture of the solution can help you decide the best way to approach the code; for example, whether you want a separate client/server app. It also helps to draw a UI design (for example, using pen+paper or a drawing tool to make some UI mockups), and to look at the system from the user's point of view
However, A detailed design which tries to guess implementation details or tries to guess an un-proven architecture is wasteful of your time until the main components are in-place and you've managed to understand all of your 'unknowns'. - That often means having a fair bit of code in-place which resembles a testable, barebones system, and being in a position where you can confidently guess how the rest of it is going to fit together (i.e. you're not going to throw everything away and rewrite it).
Detailed design documentation doesn't help you understand how to write unwritten code - it's the other way around; the purpose of writing design documentation is to help someone to understand how to read/interpret the already-written code and figure out how it all works.
It's a simple matter of known-vs-unknown. You can't document something that you don't fully know or understand. For example, if you have no idea how you'd write the code for a separate client and server app and get it working, then it's impossible to write it down into a design document. Any effort you spend in trying to do that is really just wasted. Similarly, if you're trying to draw the flowchart for a complex algorithm but don't have anything working to test all your edge cases, then time you spend making that flowchart look neat and tidy for your report will be wasted if you suddenly find out the algorithm is flawed and that you need to restructure it in a different way.
By all means, do use whiteboards and scrap paper to scribble down rough ideas and use whatever means necessary to clarify your thoughts, but don't make pretty documentation until you know it isn't going to change
Before you've written code, your most useful tools are your requirements and your detailed functional tests. Some up-front consideration about how to solve particular implementation problems (small toy/sandbox code prototypes are helpful) and 'big picture' ideas on a possible architecture of the solution can help you decide the best way to approach the code; for example, whether you want a separate client/server app. It also helps to draw a UI design (for example, using pen+paper or a drawing tool to make some UI mockups), and to look at the system from the user's point of view
However, A detailed design which tries to guess implementation details or tries to guess an un-proven architecture is wasteful of your time until the main components are in-place and you've managed to understand all of your 'unknowns'. - That often means having a fair bit of code in-place which resembles a testable, barebones system, and being in a position where you can confidently guess how the rest of it is going to fit together (i.e. you're not going to throw everything away and rewrite it).
Detailed design documentation doesn't help you understand how to write unwritten code - it's the other way around; the purpose of writing design documentation is to help someone to understand how to read/interpret the already-written code and figure out how it all works.
It's a simple matter of known-vs-unknown. You can't document something that you don't fully know or understand. For example, if you have no idea how you'd write the code for a separate client and server app and get it working, then it's impossible to write it down into a design document. Any effort you spend in trying to do that is really just wasted. Similarly, if you're trying to draw the flowchart for a complex algorithm but don't have anything working to test all your edge cases, then time you spend making that flowchart look neat and tidy for your report will be wasted if you suddenly find out the algorithm is flawed and that you need to restructure it in a different way.
By all means, do use whiteboards and scrap paper to scribble down rough ideas and use whatever means necessary to clarify your thoughts, but don't make pretty documentation until you know it isn't going to change
0
reply
Rolls_Reus_0wner
Badges:
22
Rep:
?
You'll earn badges for being active around the site. Rep gems come when your posts are rated by other community members.
#8
I decided I am making a prototype with the very basics of the game. Thrn ill add stuff later. Thankd for the advice
0
reply
X
Page 1 of 1
Go to first unread
Skip to page:
Quick Reply
