 Hey.. Looks like Xmas should be on us before I get another techfile out. Updates from last techfile, i got some info on halflife lightmaps, so I'll implement the fixes soon, I also got my procedural texture book, which is a brilliant book. I got a hold of David Eberly's book on 3D game engine design, and I have kind of mixed feelings, it does cover the things it does in a rigourous manner (with some people being turned off by its rigorous mathematical approach). But I am kind of dissapointed that he doesnt actually review the whole aspect of engine architecture, rather than diving into the nitty gritty of polygon/sphere intersections and the like. I find it hard to believe that ANYONE thinks that there is a single way of doing 3d engines. I'd really have appreciated a discussion of DIFFERENT approaches towards engine structure, and thier tradeoffs. As far as my projects go, I'm still working on building a viable scene management system, but paying specific attention to the needs of a large scale landscape system. Another thing that I require which other engines possibly wont, is that my renderer is COMPLETELY devoid of logic. The reason for this is that I must be able to decouple the input and logic processing such that it can be handled remotely. Because most of my designs are for massively multiplayer games, it is imperative that the logic has NOTHING to do with the rendering. I'll give you a simple test I use for seeing if this all works: 1) Login to the server with machine A, set it to "input" mode. 2) Login to server with machine B. Set it to "render" mode. Because the information on what to render is ALL coming from the server, I can quite happily control my character (lets say for argument that its a tank) from my "input" machine, and see the rendering coming out on my "render" machine. The advantage of this decoupling of rendering and input etc, is that in effect, you can render the scene in any manner you like. You want to do a top down 2D view? fine, you need a first person view from any player? fine. Of course, this has been going on in the military for MANY years, reading up on DIS is a good starting point. I remember seeing a battle simulation on TV, and being really impressed when a helicoper pilot using a huge helicopter sim was talking you through a simulated battle, and at the same time, you cut to a guy looking at a top down vector graphic type display of the SAME battle, pointing out the strategies they were using. There are thorny issues for ANY networked game, things like wether a client or a server is responsible for collision detections, wether a client can issue any direct commands (rather than a request/response mechanism). Once I get a good looking client renderer more complete, I'll be able to hook into my server system and really try this sucker out. I am really really interested in testing the scalability issues of the server design Ive been working on with a mate of mine, so this should be an excellent testbed. For me personally, there are interesting times ahead. Ive finally realised what it is about games that REALLY excites me, and I hope that I can get enough solid code written so that I can at last start doing the part of games I love (i.e. making the mechanics play, making an immersive experience) rather than having to deal with all this boiler plate code. Anyway, if I dont send another techfile before, have a great xmas yall! Phil. 
|
