Beginning

Hello! In my opinion it is best to star with some base classes so you can reuse your code as much as posible. I'm currently building my personal homepage, with some of my game-designs in Visual C++ and DirectX, it's on its early stages, but you can check it here if you're interested


www.geocities.com/j_vitel


[edited by - j_vitel on October 9, 2003 10:40:00 PM]

I''d say try to write it in an incremental way- start with one piece of it, and keep adding to it. Make sure it compiles every time you add a new system in, because not only is it easier to see where things are going, but it''s also important if you ever work with others via source control.

Raj

I would say you create a few base classes. As for not being able to compile until you have the "big picture," you shouldn''t have this problem. You should program such that you CAN compile. For example, the first thing you should do is the graphical interface, then the input, THEN begin work on physics, sound, networking, etc., because if you can''t see what you''ve programmed you could have made thousands of mistakes that''ll take forever to isolate in a large section of code, wheras if you compile as you go it''s much easier to find the problems.

The latest project I started I started from scratch, built an Application class, then a base device class from which I inheritted my graphics device class from, then my input device, then my sound device, and my network device. I then made a base object and a base art class, then a base manager class.

The latest complete project I started with the incomplete version of the project I just finished describing because I had done all that I needed to do, and I intend on all my other projects starting from the base of the project I described, and then incrementally adding on.

Programming such that you can''t compile until you have everything done is next to impossible. You would have to be absolutely perfect, 100% accuracy on typing and had it completely planned out beforehand, and absolutely sure of your equations. In short, you would have to be a programming god to do that form of programming, not even a guru would be capable of doing it.

A similar post was made recently, with very similar terminology ("Do you start with a base class?"). I really think this is the wrong way of looking at it. How you perceive a project counts a great deal in how you design/code it.

Rather than looking at it as a bunch of classes, you really ought to be looking at the whole system as a group of subsystems working together to achieve a goal. From there, you break down the subsystems in to components. Each component might be visualized as a single object or 2+ objects that work together. You also need to work out how each subsystem exposes its functionality, and how much of that functionality you wish to expose.

At this point, you''re ready to decide which subsytem you want to work on first. A good candidate would be something that most/all of the subsytems depend on - the Platform subsystem would be a great if you have one. This might include the entry point, an App class, a Logger, a ResourceManager, or whatever you think belongs in the Platform subsystem.

Using this method, you can work on each subsystem idependently of the others, implementing only the functionality you need for the moment - i.e. there''s no need to implement a TextureManager if you aren''t ready to load textures and texture anything yet. This helps you get some tangible results (visual or otherwise) quickly without stumbling into OO hell (you know, that place where all of your objects are tightly coupled, have a gazillon dependencies, and all the new classes you make are squeezed into the heirarchy where it looks like they might fit).

So if you think in terms of ''Which subsystem should I start with?'' rather than ''Which class should I start with?'', you''ll have a bird''s eye view of the project as a whole. This will help to make the final result easier to maintain and extend. All of it falls apart though if you don''t have a design at the beginning, or at least a clear (as in crystal) vision of the subsystems you''ll need and their interfaces.

i generally start out with an outline of the whole system, and fill in most of it with stub functions and such. so, even when only one part is actually done, the system of a whole still compiles and runs; the empty portions just do nothing, and return an appropriate response as if it had.

I start with a game design document and technical specification.

I believe the two approaches to this are commonly known as ''bottom-up'' and ''top-down.'' Bottom-up is where you go through each system in turn, writing the details, and then writing code to glue those details together. Top-down, on the other hand, has you writing the ''glue'' stuff first, and it just calls functions which are empty (until you get round to writing them).

One advantage of top-down over bottom-up is that you can usually compile and run at all times, and as soon as you write more code that code is actually in use in the game - you''re not writing functions that don''t get called.

Superpig
- saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.
Enginuity1 | Enginuity2 | Enginuity3 | Enginuity4
ry. .ibu cy. .abu ry. dy. "sy. .ubu py. .ebu ry. py. .ibu gy." fy. .ibu ny. .ebu