Testing your C++ capabilities

Yes I know what you mean. What I do is break the "idea" down in to sections and work a section at a time and then tie them together. It helps to not try and think about the "whole" project at once since that can be mind boggling at times.

GRELLIN

"When patterns are broken, new worlds emerge."
Tuli Kupferberg

"Trust that little voice in your head that says "Wouldn''t it be interesting if.."; And then do it."
Duane Michals

I''d try not to focus on which parts of C++ you could put together to make a game, but more which parts will help you solve a particular problem.

I find it useful to just sketch up some class diagrams on a bit of paper before starting to type anything.

Maybe a book like Design Patterns would help too?

---

Why you shouldn''t use iostream.h - ever! | A Good free online C++ book

What your problem is, is a lack of usefull programming experiences. Now before you get hostile, let me explain myself. Usefull programming experiences are anytime you feel there is a need for something in a program your programming for yourself, and you find a way to utilize it.

Usefull programming experiences are not:
school projects
examples from writen sources (ie tutorials, books etc)

Here is why: when your learning about something , like linked lists or polymorhpism you learn a fairly easy example. You might learn about animal sounds for the polymorphism example, or some other demonstration of linked lists, and for all purposes you learn the material well. But when it comes to programming your still using arrays and base classes. Thats because your knowledge of the material is only related to these example problems. It dosnt matter how many employee classes or student classes you make, to really understand the usefullness of classes you must use them for your own purposes.

So here is my suggestion which seems to work with me. Dont start out trying to utilize all these nifty features. Do the problem with the common knowledge you already are familar with. If all you know are classes and array''s, thats all you need to start out. As you progress through the game you will start to come across things that make you say to yourself.."there has go to be an easier way". Thats where you unpolished learning is usefull. You can try out a few things.."maybe deques will work here, or many a binary tree...". If you come to the end and you didnt hit any stumbling points then look through some of the advanced data structures and try to optimize some of your more primative methods with them. Once you learn exactly how you can use these structures, you will be able to see how they can help you before you start programming the next time.

Anyways this really seems to work well for me, and makes sense if you think about it. Try it out and i think you will learn how to use the concepts for your programs, instead of forming your project to the concepts.

I create a document called design notes in which I place all of my thoughts about the design of the application as I develop it. When I want to work on an new part of the project, I begin with something that I *know* exactly how it should work. Examples of this are the user interface (the top level) and stuff that is just too low-level to mess up the design (just above the system level).

To develop part of the project, I just start typing about that part in the design notes document. As I type, I evaluate what I am typing to make sure that it makes sense and that it is easily do-able in Standard C++ (i.e., without nasty hacks). It is also a good idea to keep thinking about how different design decisions will affect performance down the road. You will want to avoid optimizing things at this stage - just focus on getting the design correct - but your design should leave opportunities for easily optimizing those areas that might become bottlenecks.

When you write something that will not work, you have to figure out why and change it in the design notes. Erase a paragraph or two if you must. If you have a mental block on one part of the application, try working on another part. Usually I work on the top a little and then on the bottom for a while, and I repeat this process until the two meet. At the beginning of the next day I start a new "entry" near the top of the design notes document.

When I have fully thought out a class and determined that it will work well in the application, then I begin coding it. Given that classes are usually dependent on other classes, though, it may be sometime before you can compile and test what you have added. With more experience in C++ your dependence on testing between additions will go down quite a bit. This is because you are understanding the mechanics of the language itself and need not test a given class to make sure that it actually has the syntax and semantics that you intended.

Each class ought to encapsulate exactly one thing in the application. This makes for lots of small, self-contained classes that do only one thing and do it well. In something as simple as a text scanner there might be classes representing streams, text streams, token selectors, tokens, name tokens, number tokens, look ahead buffers, moving windows, expressions, etc.

Avoid making monolithic manager classes. Managers are supposed to *manage*, and they work best when that is all that they do. Leave the grunt work to the grunts. Encapsulate all the things that the manager must be responsible into little objects that the manager coordinates to do its work. For example, to most people a "text scanner" is merely a "token manager" and they load the whole thing up with enums and typedefs and everything-else-under-the-sun, but a much better way is to divide all that up into small objects that each take responsibility for one type of task.

Well, you can probably find better advice in the software design forum, and I have to go.

Good Luck!

Yep, necessity is the mother of invention, the best way to learn is to do it for a cause and not for practice. I have found I dig much deeper and learn more if it is something I have found a need for. Once you learn the tools you will never have enough time. I think I am coming to that ''brick wall'' pretty fast, rather than the coder''s block.

I fseek, therefore I fam.

Thanks a lot for the advice people. I wasn''t thinking purely in a game programming sense but I guess I could develop a simple Tic Tac Toe dos game and then upgrade it use the Windows GDI. The problem is I don''t really have the "need" to write any programs and thus I cannot think of any decent projects to get stuck into

Well, if you don''t "need" any programs, why not write something you "want"? In fact, I would "need" quite a few programs but they''re quite simple and tedious to create so I don''t bother with them and create projects that I "want" instead. Games are allways good here. Are you into gaming? Write a fun game! And start small. (Though maybe not too small... something that will keep you occupied at least two months...)

Good luck!

-----------------------------
"Mr Sandman bring me a dream"