Am Mittwoch, 13. Dezember 2006 06:38 schrieb [EMAIL PROTECTED]: > On Tue, 12 Dec 2006 19:50:00 -0500 Christian Ohm <[EMAIL PROTECTED]> > > wrote: > >Things about the code that need changing imo: > > > >- The graphics engine, including the GUI > > Integrating a new gfx engine and GUI will not be a simple task at > all. > It is not just rewriting the code, it is the way WZ handles all the > data, and thus what WZ wants. Take a look at the GUI for example, > and try adding something. > It is a big pain. Reading the old logs, I think it was suggested a > long time ago to replace the GUI, and that task was left to > Devurandom. Then that was dropped do to the complexity of handling > all the support code from what I read. > > This very problem was talked about and it was said that might as > well start from scratch, since that is what you would be doing. I had a look at CEGUI a while ago... It seemed to be a little bloated... (I didn't have a dead look, though.)
Irrlicht was buggy when I tried it and when I told the authors they said something like "It's not our problem, go get a new graphics driver and fix it yourself" (Even though I knew I was using the most current driver, and I had no problems with any other app.) So I have a personal dislike for Irrlicht. > >A new graphics engine needs the models in a compatible format > >which is > >dependent on the engine used, of course. > > Converting all pies + textures to something those can handle is > another big project. > If you look at most engines now, most all textures are in .dds > format, which seems to be the best choice for doing more advanced > rendering. > > >- The network code > > > >I have seen the discussion on the forum about this, I just want to > >address two points: 1. There are libraries that do the stuff you > >have > >talked about, so there's no need to rewrite that (but has all > >disadvantages as listed with the graphics engines). One of those > >is > >RakNet. Unfortunately the author has changed the license from GPL > >to a > >CC license, which might or might not be compatible to the GPL > >(hard to > >say, since the CC licenses were written for artwork, not code; > >additionally, there are references to both the GPL and CC in some > >source > >files). But there are older GPL versions available (if you search > >for > >them). At least in Debian there seem to be no usable networking > >libs, so > >we'd need to do something about that (like including the RakNet > >code). > > I was looking at this: > The Torque Network Library is a robust, secure, easy to use, cross- > platform C++ networking API designed for high performance > simulations and games. The network architecture in TNL has powered > some of the best internet multiplayer action games to date. Whether > you're writing a multiplayer game, developing a complex simulation, > or just need a solid foundation for network apps, TNL will meet > your needs. > > TNL is available under the GNU General Public License (GPL), an > indie license, and a commercial license. The TNL seems not maintained since a looong while. Sure it is probably one of the best network libraries, but if it doesn't recieve any maintainance... > It is C++ though. Can all compilers handle mixed code OK? I know > MSVC can, I think gcc can (or is it gpp? g++?) dunno about mac? G++ can... > There is also hawkNL: > http://www.hawksoft.com/hawknl/ > > >And 2. The float issue. This doesn't only apply to networking, but > >could > >be very important there. As floats are not accurate and can lead > >to > >different numbers on different machines, _no_ part of the game > >state > >should use floats (else the game state drifts apart between the > >machines > >and the game desyncs - perhaps that's the problem right now, I > >don't > >know the network code). Well, that the ideal case if you want to > >stay > >deterministic, I don't know if that's easily doable with any > >graphics > >engine... > > What is the float issue? I must have missed this? All compilers > follow the IEEE standard. Floats are not accurate when the numbers get too big. I think he means that 2 PCs could calculate different numbers due to those inaccuracies. > >- All game data should be externalized so it can be changed easier > > You can edit all the game data now, most are just text files, and > that is pretty easy to change. Changing isn't the hardest part, it > is adding stuff. Look what has to be done to add menu options and > things. Ick. > > >All the magic numbers that are scattered throughout the code > >should be > >migrated into data files and loaded on startup. If the scripting > >engine > >is fast enough, even vehicle behaviour could be scripted, so the > >engine > >just loads the data and executes it, and adding new units etc. > >just > >needs new data files without any code changes. (So we have an > >engine > >with a Warzone mod, and the possibility for completely new mods > >that > >feel completely different - not just the same with different > >models.) > > I don't follow what magic numbers are? Magic numbers like 128x128 pixel tiles (or the "magic 16" tiles in a 512x512 texture page, which drove me crazy). There are probably a lot more of them and more game-logic related ones. Eg the hitradius for certain weapon types, or the weapon categories. > >- General structure > > > >The general structure of the code leaves a lot to be desired... I > >am > >wondering if it's easier to start a new engine from scratch with a > >good > >design, and make a Warzone mod for that than to change the > >existing > >code... > > That is the conclusion that Rodzilla/Grim/Coma/Qanly/Per(?) came to > also. It would be easier to just start a new game. From the last > logs I read, Rodzilla & Grim, Coma,maybe Qanly also, started a new > project using the torque engine. Those logs on wztoys haven't been > updated since july. I don't know what is going on with that. :( > They might have a pretty decent game going on now. Anybody know > anything about it? I haven't heard since _very_ long from Rod or Grim, but I think Rod doesn't have much time, so this leaves Grim alone. As far as I know him, I think he might be still working on it (he loves making games :) ), but I guess alone he is rather progressing slowly. That game is _not_ anything Warzone like, as far as I know and as it runs Torque, it is closed source. I've been told that Quamly had an accident, so I don't think he is working on anything. > http://www.coppercore.net/~wztoys/downloads/warzoneresurrection%20up > %20to%20july1.html > That is the last update talking about things. > > >Anyway, that's the development part. The other part is the > >community - > >people that want to play and mod the game. How is it possible to > >keep > >them interested while doing all those changes? Right now a lot of > >questions are answered "this will change", so people will wait for > >those > >changes to happen, and if they don't happen soon enough, they'll > >lose > >interest. > > I guess that depends on the person, and if they like SP, or like to > do MP. > We can't match what Company of Heroes does in terms of > gfx/sound/presentation. > The biggest issue is the network code, or maybe it was the network > logic from the start that is causing all the issues? I think I > read on some forums about the original code wasn't all that great > to begin with, and they also had pretty much the same issues. Can > anyone test the original game out via lan or whatever to see > exactly what the issues were before? Does the original game even > run on XP? > If the networking stuff can make the game at least playable, then > more people would play it. The rest would be a nice bonus. :) > > >Well, that's it for now. It's just talking again, and I have > >absolutely > >no idea how much time I'll be able to spend actually doing > >something, > >but I hope at least for a constructive discussion. > > Lots & lots of time. Would it be worth it? I guess that is up to > the people doing the actual work, and if they find it fun or not. Rebuilding the engine from ground up was in discussion a lot of times... Actually I wouldn't think it's bad. Question is if the new engine would be any better. ;) I started to work on an engine some time ago, but because I don't know much about such stuff I didn't come as far as I thought... (I read a lot about it in the GameProgrammingGems4, though. ;) ) Also writing a new engine would mean loosing all compatibility, at least for some time. I don't know if everybody likes that... If we go this way I'd say we should use several libraries to handle stuff for us, so we get something done more quickly. I'd prefer OGRE3D for graphics. :) Eihort (OGRE3D 1.3) also is tightened a lot according to the changelogs and quite some unneeded stuff (for a 3d-engine) got removed. We could have a look if we can find a good and small GUI library, as I don't know if CEGUI is not too much. (It needs some XML stuff and whatnot, but it can utilize OGRE3D.) --Dennis
pgpD8EZU02svC.pgp
Description: PGP signature
_______________________________________________ Warzone-dev mailing list [email protected] https://mail.gna.org/listinfo/warzone-dev
