OCR Computer Science Help! ASAP

Watch this thread
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
Report Thread starter 3 years ago
#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???
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
Report Thread starter 3 years ago
#2
I swear you did A-level Comp Sci. Any advice?
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.
#3
Report Thread starter 3 years ago
#3
bump
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.
#4
Report Thread starter 3 years ago
#4
lol help
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.
#5
Report Thread starter 3 years ago
#5
???
0
reply
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 3 years ago
#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
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
Report Thread starter 3 years ago
#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
ok thanks
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
Report Thread starter 3 years ago
#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

Quick Reply

Attached files
Write a reply...
Reply
new posts
Back
to top
Latest
My Feed

See more of what you like on
The Student Room

You can personalise what you see on TSR. Tell us a little about yourself to get started.

Personalise

Has advance information helped during your exams?

Yes (111)
68.52%
No (33)
20.37%
I didn't use it to prepare (18)
11.11%

Watched Threads

View All