Advice
Author
I am writing what for me so far is going to be my biggest project. Its a simple game of "Simon Says". Its just displays random numbers on the screen one at a time (using really crude large ASCII graphics - the numbers are made up of asterisks). It shows you one number, you type it. Then it shows you two, you type them. Then three, then four etc. You get the idea.
The speed at which the numbers are shown increases as you reach each level (say each 10 correct guesses.) There will be a high score table saved to disk, which can be reset from the menu at any time.
So , although its simple its quite challenging for me to bring it all together. Its the first "game" I''ve written.
The thing is, for some reason I''m feeling quite guilty that I''m not writing what I would call hyperefficient code yet. I''m just laying the foundations and then will go back afterwards and tighten everything up once I have the groundwork laid. Is this ok? Or should I be writing everything with super efficient code straight off?
Advice please.
only my opinion, but i''d say don''t worry about it.
the point of picking an easy or small or technically not too tricky game as your first or early project is that it should be achievable by you and give you the satisfaction of completion.
this hopefully will allow you to build on success and try something more ambitious next time.
although i would suggest that bad practices are easy to learn and hard to avoid once learned, i''d suggest at your stage of development experience you will be served better by the experience of a finished project of questionable quality, than by a top quality unfinished project.
hope this is helpfull.
the point of picking an easy or small or technically not too tricky game as your first or early project is that it should be achievable by you and give you the satisfaction of completion.
this hopefully will allow you to build on success and try something more ambitious next time.
although i would suggest that bad practices are easy to learn and hard to avoid once learned, i''d suggest at your stage of development experience you will be served better by the experience of a finished project of questionable quality, than by a top quality unfinished project.
hope this is helpfull.
Not the most helpful post here... but...
"I agree with the AP above completely"
=)
~~~~~~~~~~~
Chris Vogel
~~~~~~~~~~~
"I agree with the AP above completely"
=)
~~~~~~~~~~~
Chris Vogel
~~~~~~~~~~~
Me too, I agree with the AP.
IMHO, never ever do this. The important thing is to *solve the problem*. Write code which works and which you understand. When you have a working solution, then go back, profile and pick parts to optimize. You can't optimize algorithms you don't understand and in general it is hard to understand algorithms that have been heavily optimized (including architecture dependencies and what have you).
EDIT: beer english
[edited by - JuNC on September 13, 2002 6:07:23 PM]
quote:
Or should I be writing everything with super efficient code straight off?
IMHO, never ever do this. The important thing is to *solve the problem*. Write code which works and which you understand. When you have a working solution, then go back, profile and pick parts to optimize. You can't optimize algorithms you don't understand and in general it is hard to understand algorithms that have been heavily optimized (including architecture dependencies and what have you).
EDIT: beer english
[edited by - JuNC on September 13, 2002 6:07:23 PM]
You shouldn''t worry know, when you''re experimenting. Come back when you have it done, and totally rewrite it when you know the big picture.
In time you''ll learn that each project needs a complete rewrite either:
- 3 times, if you don''t do any (or non-detailed) planning before starting to code.
- 2 times, if you do good conceptual planning.
- 1 time, if you also have done a similar project before.
- 0 times, not going to happen
You see, while coding you''ll discover a lot of things you didn''t think of when laying the foundation of your code, and your priorities might been wrong. You usually need to do a final rewrite when the program includes all functions/features. If you learn to structure your programming well, you will be able to slice of parts of the code that doesn''t effect each other when they needs to be rewritten.
In time you''ll learn that each project needs a complete rewrite either:
- 3 times, if you don''t do any (or non-detailed) planning before starting to code.
- 2 times, if you do good conceptual planning.
- 1 time, if you also have done a similar project before.
- 0 times, not going to happen
You see, while coding you''ll discover a lot of things you didn''t think of when laying the foundation of your code, and your priorities might been wrong. You usually need to do a final rewrite when the program includes all functions/features. If you learn to structure your programming well, you will be able to slice of parts of the code that doesn''t effect each other when they needs to be rewritten.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
