Thinking of Wulfram II rendering engine upgrade

#1 I played Wulfram back when they were being financed by TEN to develop the game.... Frankly at this point I'd say you might find it easier to start developing a Wolfram III based entirely around the Torque engine.

The biggest challenges you would have with Torque for doing a Wolfram III would be mostly about the skypumps / warping ships in. Other then that.. if you have the art assets in a source format (Max, etc) that could then be re-exported to the Torque format... you could have the basics down in a couple months.

#2 Besides it being against the license, you don't want the rendering code in Torque. It is extemely tighly coupled with the rest of the engine, I don't even think you could rip it out if you wanted to. The network code is the reason to buy Torque not the other way around.

I have practically replaced all the graphics rendering pipeline code in my project because the current pipeline is the performance bottleneck for me to really push my hardware. The default implementation is really tightly coupled into the rest of the game engine, overly complex and very brittle.

If you want just the rendering part of something, look to one of the more modern open source projects on sourceforge Catmother has a nice OO modern ( DirectX 9 ) rendering pipeline, is well designed and documented.

If you want to re-write your entire game; Torque is not be such a bad idea, then again, you are looking at 12 months plus ramp up curve, it is over 350k lines of code to swallow.

I think the gameplay you have is a testiment to not needing boatloads of graphics, but I can guarantee you that if you did have modern graphics support you would attract a larger audience to become converts to the gameplay.

#3 I kind of agree with Jarrod. Torque's rendering is very much integrated with the object system, so its not brilliantly useful compared to just replacing your own render pipeline with a new one (torque is basically an integrated game engine, not a set of replaceable modules).

Of course, get the engine and see! :)

#4 There are plans to keep Torque up to date. :)

I think you might want to buy the engine and take a look at it... You might end up liking the net code enough to want to rewrite things. :)

As far as getting it "just for the rendering code", that's probably not the best reason to buy Torque. Its biggest strengths are its internals, not its 3d rendering code.

#5 I agree with Phil, the source is worth $100US just as a learning exercise if nothing else. Two decent development books would cost at least $100 US!

#6 The networking in wulfram is highly optimized. We did stuff like per-player bit-level optimizations, dead reckoning against last acknowledged object states, per-player prioritized object updates based on estimated client error. It has optimized UDP packet acknowledgement, packet delay smoothing....

Of course, the networking is a bit expensive on the server side, but it's not my goal to replace the networking. I'm not sure how torque does it's networking, but Wulfram is server-centric (in terms of server has most if not all the authority on where objects are).

Though at this point, I guess I could see what would happen if I did replace the entire architecture. Does the torque server trust it's clients? If so how much? I don't know though. I'm not interested in replacing everything seems like a lot of work.

I'm fulltime employed... not working on wulfram during the day. No matter how much I'd like to throw it all out the window (because the code isn't all that great to begin with), I'd be insane to think I can do a wulfram III in my spare time, and complete it.

Hmm...

So I'm fine with replacing the client whole-sale, because most of the client code is related to graphics, sound, and input control. Most of everything else is in a shared library that is linked in (the server and the client), or the server itself.

To stay realistic, if I can find an "engine" that hands me a "graphics, sound, and controller input" environemnt, and one that facilitates with throwing user interface stuff up... I'd be fine with that, even if I had to throw in a layer of glue logic that converts form wulfram entities to torque objects.

So the following approach would not really work so well?

--> use the entire torque engine as such on the client side, but hook in my own networking code. So in some ways, act as if it was a "stand alone game", and marry my networking interface into it, and call it a day.

I mean... it's not like I'd try to tear the code appart. I'd act as if it where a single player type of game, but every client cycle service the network code, and that in turn would tie back into the client engine itself. I mean... that doesn't seem that big of a deal to me.

Hmm... thoughts?

I'll definately look at other rendering engines out there. I may even consider a DX9 solution, but it would be sad to see it not working on other platforms.

I guess when it comes down to it, I'm not ultimately looking for the "perfect technology" or the "best rendering there is".

In terms of the starships warping in and what not... I don't know. There is abit of a problem with having starships visible and having a nice cloudy / atmospheric sky. So I'll probably have to use something more like lower-flying monolyths instead.

But I'll look at other engines / graphics pipelines that are suggested. Ultimately I'm expecting the biggest pain to be to go through the user interface and get it reasonable.

#7 I was considering using crystal space... but I don't think they are really "there yet" in terms of stability. Beyond that the terrain plug-in isn't very exciting, and their new "terrain engine" isn't ready.

The only way I can get this done if I have code that "just works".

Yeah it would be nice to have a well designed OO solution, but you know... Wulfram code itself isn't "well designed OO" either.

#8 I was considering using crystal space... but I don't think they are really "there yet" in terms of stability. Beyond that the terrain plug-in isn't very exciting, and their new "terrain engine" isn't ready.

The only way I can get this done if I have code that "just works".

Yeah it would be nice to have a well designed OO solution, but you know... Wulfram code itself isn't "well designed OO" either.

#9 Any way you cut up making games, it's hard.

I'm not terribly excited about Crystal Space... the code can be quite gross and the core design is weak.

The Nebula Device has some really nice design... though, the development has moved to Nebula2 and is currently quite rocky...

Ogre has a decent (not stellar) scenegraph

CatMother has some good code, though I haven't spent much time with it

Torque is a good investment... and from what I saw of Wulfram, you could make Wulfram II and III with it... though, as others have said, Torque is an engine that *seriously* lacks modularity.

If you do go with Torque, there is a reasonably good community along side you.

-J

#10 @Bernt,

You could take a look at the Reaction Engine. That's just renderring, GUI, input, sound, etc.

T.

#11 The TRIBES Engine Networking Model

TGE is pretty much built around its networking/simulation model. You are going to have a fantastically hard time separating it out and replacing it with your own netowrking code. That said, I do not see why the existing networking model can't meet all of your needs.

I can't see TGE code playing nicely with another engine (not modular). You probably are better off looking elsewhere. Both Nebula or Ogre sound like a good fit for your goals.

#12 I was considering using crystal space... but I don't think they are really "there yet" in terms of stability. Beyond that the terrain plug-in isn't very exciting, and their new "terrain engine" isn't ready.

The only way I can get this done if I have code that "just works".

Yeah it would be nice to have a well designed OO solution, but you know... Wulfram code itself isn't "well designed OO" either.

#13 I haven't messed with Crystal Space in the last year but I have been following its development for at least 4 years (since pretty soon after the project started).

Throughout its development, the project has lacked focus. The contributors tend to be all over the place and tons of unrelated or poorly done stuff has been hacked in. Supposedly last year the main contributors were going to nail down the feature set and drive towards a focused milestone but I still haven't really seen that happen.

The other problem I see with Crystal Space is that it is still very untested. There have been a few simple games built on it but even they haven't been completed. There has never really been a full example that pushes the engine in *all* of its areas. The few times I started to build a game with Crystal Space, I have found gaping holes in the support code, forcing me to implement a lot of low level stuff that would have been done long ago had anyone actually buitl a game with the engine.

There was also never a good starting place. I know a lot of people come to TGE and are horrified that the best way to work is to start with the demo and slowly modify it into their own game but really that is a great way to do things. You already have a tested and working game and don't have to spend gobs of time pulling together tech demos, documentation, and tutorials just to get your game started! Anyone who has truly worked with some of the other "API" oriented engines can probably relate.

Crystal Space has never felt very stable to me. It can be hard to get it to compile (often many hoops to jump through). A lot of the included demos will break somehow if you push them in the wrong way and very often some of the included demos won't even work.

Keep in mind that my work with Crystal Space is a little dated (by about a year) but I wanted to post my impressions of it regardless. I love the concept of a fully open source engine but I just haven't seen it work out with Crystal Space.

#14 Bernt, not to disparage your coding abilities at all, but it is pretty safe to say that the network code in Torque is way more powerful and optomized than what you have now considering when it was written and the hardware it is targeted at.

The network code is WHY I ( and many others ) were drawn to Torque in the first place. Of all the parts of the Torque engine that is the part that has and will stand the test of time the best!

The weakest part of Torque architecturarly is the coupling.

#15 EDIT: That's odd... this was in response to another identical post... which has now mysteriously vanished.

#16 Bernt,

Wulfram looks very interesting and I would like to see it using Torque. I would be willing to donate a copy to you so you can find out if it will work. Send me email at jefft @ garagegames.com (put that all together) if you are interested.

-Jeff Tunnell GG

#17 While Wulfram's networking isn't very flexible, it is highly optimized. It does have it's problems though (server CPU load, and possibly some bugs here and there). I think it would be pretty hard for you to know what Wulfram does in terms of networking optimizations, and it would be hard to come to a judgement on how optimized it is versus that of torque unless you've played both games engines, and maybe took a look at the both sets of code. If you're curious about some things, you can play wulfram II, and in-game hit control-end, and type in 'peek net', it will bring up a bunch of networking related information about how much bandwidth is getting sent to the client, packet delays, appox ping times. etc. etc. There is also a way to monitor what the server is doing in terms of object update prioritization. Ultimately you can play wulfram II over a modem, and things should be just fine.

Just a quick review of what the server does: It has a best guess over what each client thinks it sees, and it has the authoritative object states. The server evaluates the differences, and figures out how much projected pixel error there is per object for each client. It then decides which objects have the most significant pixel error per client, and prioritizes these for an update. When the server decides to send objects to a client, the objects positions are encoded depending on the lowest accuracy needed depending on the view space of the client.

There are exceptions to the above, when distant things are targeted, or when the player is zooming in on something. Some things are specialized such as incoming missles. Other things like caltrops, we don't send the orientation because they are essentially irrelevant for that kind of object.

I mean... a lot of thought has gone into the network optimization for wulfram. It's not flexible. It's not the best thing since sliced bread, but it's highly specific to what the game does, and it IS highly optimized to do the right thing.

Oh yeah, and when a UDP packet is dropped, the server doesn't resend the old information, it figures out what the content was, and re-encodes the objects with new information instead (if such objects still exist).

What I'm saying is, yeah... the networking could probably be improved in several important ways. Perhaps even the approach that Wulfram took isn't the best one (it's quite expesnive server-side). But replacing the networking is not my primary objective. I'm happy to learn that torque has great networking. It does open up the possibillity of me just replacing everything in Wulfram with the torque code, though the only reason I'd do that is if it's faster than other options (or if there are other really overwhelming reasons to do it).

Certainly, it sounds like torques networking might be more flexible and more powerful -- though I'd have to study that. At the moment if I want to add more state to a particular object type, I do have to add in the server-side logic, the networking encoding / decoding, any special cases and optimizations that I'll need, and finally add that into the client side as well. It's a lot of work to add new behaviours. So if torque requires less effort on that front, it would be a good thing for future extensions -- but flexibillity doesn't imply "optimized". There are tradeoffs, and maybe that's okay.

Be that as it may, my primary goal is to get better rendering into wulfram in as little time as possible. Yes I know... writing games take time. I've done it in Wulfram and ShockForce / Wulfram II. But my point is, I don't have a lot of time, and my constraints are what they are.

Thus, I've got a bunch of options, and need to figure out which way to go, which in itself isn't all that easy.

Just out of curiosity... no one has addressed this question yet: If someone hacks a torque client, how bad is that? Meaning does the torque server trust the client on anything?

#18 It's been 6/7 years since I really played Wulfram, I looked at Wulfram II after it went independant, but never really could get back into it.

I understand the wish to keep the current server code as that's where the heart of the game really is.

1. With Torque you could if you wished assemble a team to work on WIII not just go at it alone.
2. Team sizes with Torque could be up to 64 people per side.
3. Torque already has a Hover Vehicle class

Is Torque perfect? Nope, but the community doesn't have a problem with telling someone that Torque may not fit someones need.

The community also doesn't have a problem with helping each other out.

Your limitations with Torque are going to be:

1. Having to re-write the server portion
2. Tweaking the Hover Vehicle class Physics and controls( The current Hover Vehicle can't change altitude)
3. The skypump system
Torque Maps are HUGE in comparison to what you had with Wulfram, they pretty much go on forever. Setting up a grid / checking for the number of skypumps in each grid, warping in ships... That will require a bit of coding.

And I'll be honest... I have at times thought about writing a Wulfram Clone with Torque, based on what I remembered from when I played, but my C++ skills just aren't quite up to par for some of the changes that would need to be made to make it happen.

#19 And no the Server does not trust the client.

EDIT:

Torque uses the same engine that Tribes 2 used (yeah yeah I know you probably already know that), and in the entire time that T2 has been running the closest I've seen to a clientside cheat is when someone figured out how to make their network connection lag, making them seem to warp and jitter for other players.

Anything important is handled by the server. Clients can hack the GUI all they want. It's not going to get them very far.

#20 Yes, yes yes to all the above. What attracted me to torque was:

1. fab net code (t2 is playable w/ a modem)
2. easy for servers to mod the game w/ script
3. secure in that the client doesnt store much, and I havent seen any real cheats for t2.
4. The communitty is helpful, nice, and lately there has been a flurry of activity here w/ the new games and some of the new code.


If you have the art assets, you should definitely give torque a try at least.