Sign in to follow this  
dave

What could my next step be?

Recommended Posts

dave    2187
Hi, ace here Ive been working with DirectX for say a year now and C++ a while longer. I have plenty of knowledge behind me for programming in general now. I have also made a fully playable game of 3D Minesweeper and im keen to start engine design and make some more games. The query that lies with me is that, for a long while ive been trying to write a logically layed out engine, but the general class interaction bemuses me. Im not entirely sure, what should be C++ or C, the directX aint a problem. I was given the opinion that the way that teh framework that microsoft wrote for their DX samples wasn't very good, but im yet to create another better alternative. Are there any good engine or advanced C++ books anyone can recommend? Or any advice on how to progress to a higher standard of programming. regards ace

Share this post


Link to post
Share on other sites
ApochPiQ    23061
Well first of all I may be misinterpreting your comment, but you don't really want to mix C++ and C in the same project. Either style is fine, but pick one and stick with it. Trying to blend OOP and procedural programming can get very ugly very fast.

Designing good software is an acquired skill I think. It can help immensely to pick up a book like Design Patterns and get yourself familiar with common, powerful solutions to different design problems. The best way, though, is to learn by experience. Pick a few different projects and just design the solution, but don't actually write any code. For example, come up with a simple set of features for a basic multi-document text editor, and design a set of classes (or functions and modules if you choose to go with a procedural, C-style approach) that will get the job done. Experiment with different designs, and try to foresee what the potential problems and powers of each design will be.

When you get comfortable with this, pick one of your designs (or design a new project) and actually code it. As you go along, look at what problems you encounter that you didn't think of beforehand, and keep records of them. Similarly, if you find out some unexpected, really cool feature of your design that you didn't plan on, record that too. When you're done, look back at your notes and think about how you could have foreseen those problems/bonuses during the design phase.

The more you do it, the better you'll get at predicting the strength of different designs. The key is to be patient and thorough during the planning phase; it is amazing how much difference it makes during the actual programming part. Above all, don't be afraid to ask questions, and don't be afraid to do something "wrong." I think everyone has a secret stash of early designs that they aren't very proud of - I know I do!

Good design skills, and good troubleshooting/debugging skills, are what separates the 6-figure-salary programmers from the code monkeys who get their jobs sent overseas. Having a solid idea of how to design software that is elegant and easy to code will make you a much more valuable programmer in the long term.

Share this post


Link to post
Share on other sites
antareus    576
1. Pick a pet project
2. Begin said pet project
3. Do some initial, basic high-level design. You'll want to research application design. Add objects in as necessary, not right off the bat.
4. Code
5. Redesign and refactor as necessary. Don't introduce unnecessary abstractions or patterns (like singletons) unless necessary
6. Goto 4

Read:
* Design Patterns
* Refactoring, by Martin Fowler
* One book on XP
* Mythical Man Month
* Modern C++ Design
* Large Scale C++ Design
* Code Complete

Share this post


Link to post
Share on other sites
ApochPiQ    23061
Personally I would be very cautious with "Extreme Programming" (aka XP). Usually to me if you have to refactor (fancy jargon alert: this just means take your code apart and redesign something) then your original design was broken. Refactoring is a sign that you missed something during the design phase, and in my opinion is not something to get in the habit of doing. It's fine to redesign things a few times while you're getting the hang of the whole thing, but in "real life" refactoring should be a major red flag. XP can very easily lead you into dangerous and sloppy habits, especially if you don't already have the experience and discipline to design things properly from the beginning.

Of course you won't be able to predict everything from day one, and there's always things that come up that force you to adjust your code. All I want to convey here is that when these things come up your design should be able to handle them without serious changes. Refactoring, in my eyes, encourages programmers to write poor code and then "fix it" as they are forced to. By designing well from the very beginning, the number (and size) of changes you have to make to your code should be absolutely minimal.

Share this post


Link to post
Share on other sites
antareus    576
May I join you on cloud nine?

I recommended XP because it allows you to redesign as you go. This is far more liberating than saying, "well, design is HARD, and the only way to design is to do it over and over. Oh, and if you mess up, you might as well throw it away."

Fred Brooks mentions this in the Mythical Man Month:
Quote:

Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time. Hence plan to throw one away; you will, anyhow.

One site mentions: "The second system can be built bit by bit by replacing components gradually, or by starting afresh with a completely new architecture."

Share this post


Link to post
Share on other sites
dmikesell    157
Quote:
Original post by ApochPiQ
Personally I would be very cautious with "Extreme Programming" (aka XP). Usually to me if you have to refactor (fancy jargon alert: this just means take your code apart and redesign something) then your original design was broken. Refactoring is a sign that you missed something during the design phase, and in my opinion is not something to get in the habit of doing. It's fine to redesign things a few times while you're getting the hang of the whole thing, but in "real life" refactoring should be a major red flag. XP can very easily lead you into dangerous and sloppy habits, especially if you don't already have the experience and discipline to design things properly from the beginning.

Of course you won't be able to predict everything from day one, and there's always things that come up that force you to adjust your code. All I want to convey here is that when these things come up your design should be able to handle them without serious changes. Refactoring, in my eyes, encourages programmers to write poor code and then "fix it" as they are forced to. By designing well from the very beginning, the number (and size) of changes you have to make to your code should be absolutely minimal.


No where in any XP literature is writing sloppy or poor code encouraged. XP encourages, in fact, the most disciplined form of programming I've seen: write tests first, then code. This also makes refactoring a lot easier, because the tests will fail if you refactored incorrectly.

Share this post


Link to post
Share on other sites
marijnh    182
Quote:
Original post by ApochPiQ
Well first of all I may be misinterpreting your comment, but you don't really want to mix C++ and C in the same project. Either style is fine, but pick one and stick with it. Trying to blend OOP and procedural programming can get very ugly very fast.


To an extent this is certainly correct - Do not mix c-style strings with STL strings, or exceptions with c-style memory management for example. But on the other hand there is nothing wrong with mixing C++ classes with more procedural components that hardly use any C++ features at all. Do not get into the java-ish 'everything has to be an object' mindset, it overcomplicates your design.

Share this post


Link to post
Share on other sites
petewood    819
Quote:
Original post by ApochPiQ
Personally I would be very cautious with "Extreme Programming" (aka XP). Usually to me if you have to refactor then your original design was broken.
That's quite a humbling experience. It's good to be humbled.

Quote:
Refactoring is a sign that you missed something during the design phase
also that things have been added, and added and the initial design is no longer visible.

Quote:
and in my opinion is not something to get in the habit of doing. It's fine to redesign things a few times while you're getting the hang of the whole thing, but in "real life" refactoring should be a major red flag.
But the redesign is with the intent of making the code easier to understand, easier to extend, easier to test, etc. It's a good habit to be in.

Quote:
XP can very easily lead you into dangerous and sloppy habits
It is a discipline.

Quote:

Of course you won't be able to predict everything from day one, and there's always things that come up that force you to adjust your code. All I want to convey here is that when these things come up your design should be able to handle them without serious changes. Refactoring, in my eyes, encourages programmers to write poor code and then "fix it" as they are forced to. By designing well from the very beginning, the number (and size) of changes you have to make to your code should be absolutely minimal.
Nirvana is when you can design a whole project and any unforeseen obstacles will already have been accounted for and will have minimal impact. The top gurus in the industry know that this isn't going to happen. They have come up with a simple method of coping with change.

Share this post


Link to post
Share on other sites
antareus    576
Quote:
Nirvana is when you can design a whole project and any unforeseen obstacles will already have been accounted for and will have minimal impact

If this does, by chance, actually happen, it just means that you are not challenging yourself enough.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this