Jump to content

Improving Q3 versus a newer engine


  • You cannot reply to this topic

12 replies to this topic

#1 Jono

Jono

    UberGames Developer

  • UberGames Developer
  • 17 posts

Posted 02 February 2007 - 04:54 PM

With things like motion blur and **** mapping, surely we're moving into the realm where it'd be easier to switch to a "better" engine rather than try and shoehorn all these features into the aging Q3 / EF codebase...

(Which is probably a bad idea since it involves quite a lot of porting effort and wastes Thilo's engine work and TiM's modelling work, and also you'd lose the legal use of EF models, sounds, and such, wouldn't you...)

#2 Abyss

Abyss

    Member

  • Members
  • PipPipPip
  • 52 posts

Posted 02 February 2007 - 06:35 PM

to quote a friend i know who has good insight on this type of thing (or problems in general) "damned right you will..."

#3 Scooter

Scooter

    The Canon Man

  • UberGames Admin
  • 2,545 posts

Posted 02 February 2007 - 08:09 PM

With things like motion blur and **** mapping, surely we're moving into the realm where it'd be easier to switch to a "better" engine rather than try and shoehorn all these features into the aging Q3 / EF codebase...

(Which is probably a bad idea since it involves quite a lot of porting effort and wastes Thilo's engine work and TiM's modelling work, and also you'd lose the legal use of EF models, sounds, and such, wouldn't you...)


LOL you just proved your first statement wrong with your second statement. While it's correct that a newer engine either already has these features or would probably be easier to add them, losing everything we have isn't worth it.

Since we HAVE the Q3 codebase, we have the ability to swap out the aging stuff for new stuff. I don't think we're at the point yet where the codebase can't handle more upgrading. I suspect that plenty of code in D3/Q4 isn't all that different from Q3.

#4 Abyss

Abyss

    Member

  • Members
  • PipPipPip
  • 52 posts

Posted 03 February 2007 - 02:43 PM

Ive honestly tinkered with Q3/Q4 both (the engins and all) and personally i dont think they are that different...how ever i may be wrong when it comes to the mod...or how they handel things...but personally i dont think they are too different...

(DONT QUITE ME ON THAT SINCE IM NOT 100% SURE!! [unless its scooter or someone with them both that is verifying that])

#5 Jono

Jono

    UberGames Developer

  • UberGames Developer
  • 17 posts

Posted 10 February 2007 - 08:05 PM

LOL you just proved your first statement wrong with your second statement. While it's correct that a newer engine either already has these features or would probably be easier to add them, losing everything we have isn't worth it.

Since we HAVE the Q3 codebase, we have the ability to swap out the aging stuff for new stuff. I don't think we're at the point yet where the codebase can't handle more upgrading. I suspect that plenty of code in D3/Q4 isn't all that different from Q3.


By no means was the second statement proving the first wrong. To rephrase it, the point I was making was: which would involve more effort, adding features to Q3 which it was not designed to do (radically, like, um, GLSL shaders or something), or to port the work, redoing some as necessary where rights to use assets are lost, from Q3 to something else?

The main reason I mention this is with projects like Thilo's and various feature ideas/requests which require engineside modifications to Q3, it seems, at least to me, that there are various reasons which might make RPG-X going standalone seem worthwhile... which would also be difficult for Raven assets. If this is going to happen, switching to a new engine at the same time would be beneficial IMO, but probably not at the moment. (This is getting a bit offtopic, but is an interesting point to discuss, perhaps someone could split this please if people want to reply specifically to this.)

#6 Scooter

Scooter

    The Canon Man

  • UberGames Admin
  • 2,545 posts

Posted 11 February 2007 - 07:57 PM

I think this is a worthwhile discussion; it's now it's own thread.

I'll readily admit I haven't looked at the Q3 engine code, but I think it's fairly safe to say that it's at least somewhat modular. That is to say, it has self-contained functions and the inner-workings of those functions can be changed as long as the inputs and outputs don't. Granted, some changes may affect more parts of the code than others, but in theory it should be possible to implement things that the engine is not already capable of (hence the need to implement them). That's how Raven added things like a vehicle system to JKA.

It is indeed possible that some things might be so complicated to add that it would be prudent to consider the option of selecting a newer engine with such features already implemented. The problem then becomes remaking all the assets because we wouldn't be able to use the ones that came with EF. I think that this is possible if you can find the right people, but in my travels I haven't come across a lot of modellers in the EF community. There are modders in some other Trek gaming communities, but I haven't heard of any that are up to the challenge of making character models from scratch.

It's my humble opinion that remaking all the assets would require more man-hours than changing the engine code to suit our purposes. However, we could probably find more people able to work on redoing the assets than work on the coding. Without some solid numbers, we're only guessing whether or not there's enough people to pull it off.

Do we really need to pick one over the other? I think we can work on both without wasting effort. We can work on replacing Raven's assets with our own improved assets without switching engines, and once all assets have been replaced we'll have most of what we need for switching to a newer engine. Raven didn't push the Quake 3 engine to it's full potential when they made EF, partly due to it being so new (EF was based on Quake 2 for a while) and partly due the game being released only on the one CD.

In conclusion, I believe that we need to tackle this in chunks of sufficiently small size that we don't get burned out and end up never finishing it. There have been a lot of mods for EF with smaller ambitions that got cancelled. The fact that RPG-X is still going after all this time is nothing to sneeze at. (We may not be going as strong as before, but we're still going.)

#7 Jono

Jono

    UberGames Developer

  • UberGames Developer
  • 17 posts

Posted 12 February 2007 - 06:05 PM

What he said. :)

Some of the Raven assets, textures mainly, are so terrible and low-res (carpets, for example) anyway that remaking them (especially procedurally, since that sounds, although mathematically quite complicated, like it could be written for Q3 and someone probably already has) would add to the mod significantly either way.

#8 Slayer

Slayer

    Bug Hunter

  • Members
  • 385 posts

Posted 19 March 2007 - 01:57 PM

What it comes down to im guessing is that is it worth it to switch over to this new code base because of certain features. Not all of the EF community has the best computers our there or the best connections. If we look at it from a community standpoint it could possibly alienate members if we switched to a more graphically intense engine. Ive got two pcs one at my dads and moms house and both are on diffrent ends of the spectrum:

Moms:
CPU: AMD Athalon Processor 1.06 GHz :P
RAM: 1024 RAM
GPU: Nvidia 6800 G

Dads:
CPU: Intel P4 2.66 GHZ
RAM: 2048
GPU: Radeon 9800 Pro 512 MB
Im Klingon and a Hanyou Dog Demon...AT THE SAME TIME!
[SIGPIC]Posted Image[/SIGPIC]

#9 TiM

TiM

    Administrator

  • UberGames Admin
  • 3,425 posts

Posted 11 September 2007 - 04:40 PM

Yeah... assets probably shouldn't really be a concern, except maybe the sound FX and map files.

Umm.. but the main thing here is the Star Trek license. If we jumped to a different engine, we couldn't call it Star Trek anymore.

EF: TC got away with this on HL2 only by redesigning EVERY single thing hehe. :)

-TiM

#10 GSIO01

GSIO01

    UberGames Developer

  • UberGames Developer
  • 1,021 posts

Posted 12 September 2007 - 08:23 AM

Did you erver think about switching to EF2 ... the engine used by Ritual was enhanced very much (for example the entity limit seems to be dynamic ... normally it is 1024 but there is an cvar called "maxentities" which changes the limit - max is 4096 though because of ubermap)

Ok I know that the gamecode is different as far as I've seen though in my opinion it's easier ... I started working a month ago with the code and already made some working modifications to it ( like an adminlogin, give a player a weapon, kill a speciefied player, a cloak and so on) and I'm not that good in programming hehe as you are TiM hehe

other features/possible things are:
- c/c++ based scripting language (when working on my rpg enterprise e map for ef2 I found a way to give players the abillity to create missions for rps by including a scriptfile that is used for this in the mapscript and it is all serverside)
- new models/animations wouldn't be a problem as well as all needed plugins are avaible and there even is an example max file with a skeleton and all basic animations
- ingame menus such as a turbolift menu are not a big problem ... they already work in multiplayer (with cheats on only so far, but that can be changed)
- real singleplayer NPCs work in Multiplayer ... most things from SP work in MP
- Ritual already worked on vehicles but did not finish theri work... but they already work: only ground vehicles so far and in multiplayer still bugy

#11 TiM

TiM

    Administrator

  • UberGames Admin
  • 3,425 posts

Posted 12 September 2007 - 03:43 PM

Egggghhhhh.... thought about it hehe.

I have the source code and I've skimmed it a few times.

It's nothing like EF though lol. They essentially gutted Q3 and rewrote it with C++ classes and everything. :)

Some of the basic code (like moving around and stuff) is still the same. So... I might be more convinced if we could just dump EF's code in there so it at least feels a lot better hehe.

I dunno tho... I doubt Ritual will every release the engine code. They're probably in the same boat as Ravensoft on that one.

The beauty with EF is that since we have ioQ3, we have potentially unlimited potential for what we could do (mainly we're limited by programming ability haha).

Also... I think more people have EF than EF2... so it's probably a much wider exposure too.

I won't say no... but I'd say that EF2 has a lot of competition hehe.

-TiM

#12 Chrissstrahl

Chrissstrahl

    Member

  • Members
  • Pip
  • 7 posts

Posted 06 December 2007 - 04:55 PM

If you wish to have fast results and don't care what will be with the mod in about tow or three years you can go to ef2 with no problem.
You will have very heavy script support, even in Multiplayer, and a lot of nice toys in the game. Documentations which explain almost the whole things.
Most of the stuff in the documentation works in multiplayer.

//HZM list of unstable or unsupported commands for ef2 multiplayer scripting

//Chrashes GAME-SV on Linux servers
.setobjectiveshow();

//Chrashes GAME-SV on Linux servers
.loadobjectives();

//Chrash on win & Linux Sv the Game-SV
waitforDialog();

//Ensure there is 'wait(<float>);' within, else sv can chrash on map restart
while()
{...}

//Win SV using String as value and Linux is using Entity. ALTERNATIVE: .follow(e,e);
.watch( entity/string);

//Chrash if no int is given, function does anyway not work correct
getIntFromString();

//Chrash when they can't fine a player to follow
//Teammates (AI/STATE)
Behavior GroupFollow ( 256 , 320 )
//use instead
Behavior CloseInOnPlayer ( "run" , 256 )

//Chrash dedicated sv if noone is on the server
cinematic();

//Chrash (maybe) dedicated sv if noone is on the server
.endCinematic( FALSE )

//Chrash the server when the entity does not exist
trigger( "$entity" );
//Use instead
if(doesEntityExist($entity)){trigger( "$entity" );}
Textures, Models, etc all this you can use and change very easy...
You can realize mods with server side scripting only.
Use the tiki engine which has a lot to offer...

But if you wish to alter some stuff on the engine, ef2 isn't the right game!
EF2 engine code will never be released, now since there is no more ritual.
The ef2 game code which is released allows a lot, to change, but things which are Engine related you can't access by that code.
Improving q3 and making this open source could be very interesting since star trek games should be free to become interesting, I think ef2 isn't the right way then.

On the other hand it makes maybe no seance to work on such a open source project since star trek seams to have heavy losses lately in almost every game :(. EF2 is as death as it never was before, so even I have to say (as an ef2 veteran which had enjoyed to play amlost every day some ef2 multiplayer sine the game came out) the game is really death by now, it's nice for rpg but how long will this last if there are no improvements on the engine for years ?

Examples:
Rcon related code.
Lightning related (Dynamic lightning and shadows, etc) code.
Map and Compiling related code.
Shader and texture related code.
Physics related code.
And a lot more limitations...
---
So it depends on what you plan to do in the future...
I guess porting rpg-x to ef2 could take a half year, this will include a lot new features, but what will be with the quake IO engine in a half year, or a year, or even two years ?

(okay i'm now off for a cup of sleep)
[SIGPIC][/SIGPIC]

#13 TiM

TiM

    Administrator

  • UberGames Admin
  • 3,425 posts

Posted 03 January 2008 - 02:34 PM

I probably should point out, I really don't care about upgrading to a new engine.

For my experience personally, I want to become a better game programmer, and that doesn't happen by moving to a new engine where someone has already done the work. :(

Q3 is awesome since it's a rock-solid engine built by one of the greatest minds in the world.

Now that we have the source code (unlike many of the crazy expensive engines of today), we're free to tinker with it as much as we want, and unlike game engines of today, the source allows us a much greater amount of freedom.

One of the main downsides I can see to the Q3 engine is it's built in C, not C++, so it's definately not as flexible or modular as games are today. But overall, I don't think that makes a difference in quality in any case.

Another thing... I mentioned this elsewhere.... a problem with moving to a new engine is we'd have to ditch the Star Trek license. :P

For now, EF is the most flexible FPS engine that can be used with the Star Trek license (EF2 is more advanced, but since the engine code isn't out, you're pretty much stuck with what it's like now).

But... I doubt we're shoe-horning features in. The Q3 engines renderer is more than capable of being enhanced upon.

A good example is the XreaL project:
http://xreal.sourcef...iki/ScreenShots

I'm friggin jealous of how beautiful these guys pimped out the engine. I'm hoping it might be possible to do the same to ioEF (they have open sourced the code, but ioQ3 is a different fork so I dunno)

At the very least, it shows how pretty Q3 can potentially become.

-TiM



0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users