Well, I guess I''ll be startin with 2D . Now then, I gotta make an engine first, but I dunno how to design it. Do you guys make a class that wraps up the entire DirectInput, Direct3D, DirectSound, yada yada yada? And then make a class that does the windows stuff? And then a WinMain file and include all the hocus pocus you just made? -Peter

Depends. Since you''re starting out, I''d say only make a class for your objects, artwork, and anything else that you will have multiple copies of. For things you only have single copies of (Program Instance, Window, Graphics Device, Input Device) use globals.

At a later time you''ll probably want to make class wrappers for the various APIs so that you can make your program independant from the API to allow quicker changes from DX to OGL, from Windows to Linux or Mac, etc.

Heh, I really don't understand what you mean. But this is the approach Jim Adams took in his "Game Core" in his RPG book. I kinda like it though, I prefer my code to be split up.

I just want to make sure I'm not catching onto a bad programming practice. I'm new so I can't tell the good from the bad really. Thanks.

-Peter

[edited by - PoLiSh_Peta on January 15, 2004 6:29:44 PM]

It''s a good programming practice to write wrappers, it just expends time that I wouldn''t recommend wasting when you''re starting out. Your first few programs aren''t likely to be something that you need wrappers for. I would recommend getting comfortable with the APIs before making wrappers for them. Once you sufficiently understand the APIs you can understand the wrappers you are making for them.

I agree, I''d recommend to not spend any initial time making a wrapper, because chances are it''s not going to be the wrapper you need. You''ll learn so much more as you move forward, then have to make changes... You may end up getting bored with the whole tedious process.

What I did was just pick one thing at a time (using D3D as an example), like first get a triangle to draw on the screen, then get 5, then make them move...etc. In each case, it would be something that I could spend time learning in depth about but having no commitment to wrapping it up nicely at the start. Then, later I made the classes for each section I felt comfortable with, while at the same time learning a new concept.

It made it interesting enough for me to continue in my effort. I had one big messy c++ file with variables here and there, all global, but it made it a lot easier when I decided to start wrapping things up because I''d done so much work with the code that I knew the functions by heart. I guess a similar example would be when you are designing a circuit board in college. You learn by using a breadboard or wirewrapping, very unprofessional, but it allows you learn it, and you can later put it into a schematic program and have a real board spun. That''s when you take your time and pay close detail. Just a suggestion of course! Sorry for the over-explanation...I get carried away!

Good luck,
Chris

I have myself a set of classes that deal with graphics (init, sprite rendering in a variety of forms etc), and mouse input (I myself do not use DirectInput for keyboard input). A simple example is included. I could mail them to you if you like.

I see, I see. But is there anything wrong with working from the top down? Learn the entire structure of the engine and work your way down to the itty bitty details of DirectX?

-Peter

If you do top down you likely will never finish. For one thing, top down usually means that you have to completely finish before you can test it. That's BAD. You should always be able to test the code as you go. If you don't, then the first error you hit (and trust me, you WILL have errors) you will have almost no clue as to exactly what caused the problem, whereas if it worked last build and doesn't work this one, you know it's in the code you just added. Always do one chunk at a time. Have plans for what you need to do, but make sure that what you just did works before going on to the next thing. Even if you make a wrapper, start with a wrapper for your graphics, starting with window creation. Test that. When it works, set up some input so that you can press escape to quite (even if it's just WM_KEYDOWN). When that works do the D3D init. When that works you can work on your artwork loaders and objects. Then you can flesh out from there, adding one section at a time and making sure it works. You have to be in the details from the get-go to make sure it works. (Of course, learning the structure is always a good idea but that doesn't even take a day to learn. I can get that from the second section of Enginuity (I think), just making the structure of the engine first and dealing with details later is not wise)

[edited by - Erzengeldeslichtes on January 16, 2004 3:48:24 AM]

Actually top-down is not a bad approach for an initial design. And forget about wrappers, that''s not what you want in this case. If you don''t know why then look for my post in the beginner''s forum regarding the definition of ''wrapper''.

Also, forget about the word ''engine'' for a moment. It''s a metaphor, and not some holy grail. Think in terms of code functionality. What tasks do you need the code to perform? Make a list (blitting sprites, intializing the graphics API, playing aounds and music). Certain engine components should be jumping out at you from this list (Sprite for example) as class candidates. Once you have a task list ready, then you can start thinking at the top level. In other words, how will the game interface with the engine. Will you allow the game to manipulate the engine objects (such as Sprites) directly or should they go through an abstract interface so that you can change the underlying implementation? This all depends upon your requirements. Once you''ve got the interfaces defined, now you can go in and start implementing the details.

Don''t stress out over it. The same software design principles that apply to designing a database abstraction interface apply to designing a game engine. Take your time, read up on software design strategies and patterns. Everyone has their own preferences on how to approach a design, and there is no one right way. Also, no one is going to be able to tell you everything you need to know in a message board post.

The key to learning how to do this stuff is assimilation. Never rely on anyone to show you exactly how to do it. Gain information from as many different sources as possible and *think* about what you read, using code examples as a guide rather than as a ''do it like this'' resource. Then put it to use. Experience implementing the theory you read about will ultimately give you a better understanding, and with time you will develop your own preferences, and some things will just come naturally.

Thanks for all the responses! I don''t see how someone could remember all this code for making even a 2D engine. They must be referencing like crazy or copy and pasting.

-Peter