 Anyway, I've completed the networking, sound, and input and console portion of Try3, and I think the worse is behind (read, no more reading Microsoft docs). DirectSound is pretty easy to use, my code pretty much worked right straightaway. DirectInput took me half a day to get working reliably and for Winsock well, there were some special cases that needed fixing over a course of two days. As usual Microsoft likes to put the carriage before the horse - they seem to implement their tech before first thinking about how the end would want the API/Interface to their tech to look like. Which brings us to the topic I said I would write on in my last tech file… Code Architecture Code architecture is about how you structure your code and it makes the difference between a hack and a truly useful program. I'm not going to go into any lofty theoretical lecture on software engineering, I'm just gonna layout how Try3 is structured. Basically Try3 consist of about 10 to 12 subsystems that provide all the features any game built on top of it would want. These include playing sounds, controlling the graphic accelerator and what else have you. Each of these subsystems is implemented in 4 files. For example, the input subsystem consists of input_al.h, input_al.cpp, input_s.h, and input_win32.cpp. The files with the _al suffix are "abstracted layer" files. The abstracted layer is where I keep all the code that is portable. What goes in here? Well, any internal high-level logic should fit in here nicely since such stuff should be portable. If it's not you better be rethinking your design. The subsystem's interface is defined in the abstracted layer header file. The headers file suffixed with _s are system interfaces or if you prefer a header of stubs. The idea is that if I wanted to port Try3 to Y-Box by a company called Softmicro, I would just need to look at the _s headers and code a .cpp file to implement that interface and voila a ported subsystem, do that enough times and Try3 get ported! Don't need to care about any of that higher-level logic! As you can probably guess by now, the _win32.cpp has all the platform specific code and interfaces. Again using the case of the input subsystem, all DirectInput calls go here. The only calls made to code in input_win32.cpp come from input_al.cpp. And the less interaction there is between the subsystems abstract layer and is system layer counter part the better. Oh and btw, I use mainly C code with a sprinkle of C++ when I need it. IMHO, there's no need to use C++ when you are coding at the subsystem level. The graphic pipeline and main simulation loop are all pretty much procedural. If they are not, there'll probably be performance problems later. I feel the correct place to use OOP is perhaps when implementing a complex game environment with a lot of entities all in action at the same time. The power of objects as interconnected state machines really shines through then! So there you have it, a very brief explanation of how one guy codes his stuff. If this is all old hat to you, I apologize. If anyone has any comments on all this I'd love to hear them. Ok, On To The Next Thing... The Game Originally, I had intended on making an fps kind of game using Try3, where you walk around and other 3D models move around in the same environment as you. Well after my research into animating bipeds using skeletal animation, I realized it would take me way too long to get this done. So I animated models will be added in next game I do maybe. Thus my focus has now shifted to creating a space shooter instead since I can get away with models that need not have movable parts. : ) I'm still wondering what would be a good lighting technique to use since space is mostly black. From what I've seen most space shooters dun have much in the way of lighting, seems to be all ambient lighting in fact. If anyone reading this has any good suggestions please send them my way. Well that's all from me, I'm gonna play with some particles now. : ) Until the next time... Victor. 
|
