Announcement

Collapse
No announcement yet.

Unvanquished Alpha 44 Brings Many Gameplay Changes

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Unvanquished Alpha 44 Brings Many Gameplay Changes

    Phoronix: Unvanquished Alpha 44 Brings Many Gameplay Changes

    The latest monthly point release to the Unvanquished open-source first person shooter was released yesterday...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Originally posted by Master5000
    Why the fuck would I play this instead of Q3 or UT? The engine sucks, the gameplay sucks, the art direction sucks... everything sucks.
    Given that the game is nothing like Quake 3 or UT, the engine is literally just a modernized version of the ioQuake/Xreal engine, and you've provided no constructive feedback in the past 5+ years it's been in progress for art, engine, or gameplay, I can almost factually state that you're an idiot. Instead, I'll have to settle with it being my opinion.
    Last edited by computerquip; 08 October 2015, 12:05 AM. Reason: Type ETreal instead of Xreal for some reason...

    Comment


    • #3
      Originally posted by siavashserver
      Here is a constructive feedback for you: Use a modern game engine instead of duct taped version of an obsolete engine by todays standards!
      It almost sounds like you made a rational thought. Almost. If you were to provide a major technical flaw with the engine thats inherited from the engine its derived from though...

      Comment


      • #4
        Originally posted by siavashserver
        Here is a constructive feedback for you: Use a modern game engine instead of duct taped version of an obsolete engine by todays standards!
        I consider better engine which provides higher FPS. Xonotic has better engine than Unigine Valley because of 60-80 fps in Xonotic, but only 8 fps in Unigine Valley on HD 530.
        Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

        Comment


        • #5
          Originally posted by siavashserver
          TL;DR: They don't scale up well on 2008+ hardware.

          Quake3 era game engines were designed for single core CPUs and OpenGL 1.x capable graphic cards. What all Q3 based engines do inherit is inability to scale up and use modern hardware efficiently. Doom3 added support for shaders, and BFG edition added multithreading (up to 5 threads, not fully utilized) which is still inefficient on modern hardware.

          Why are they inefficient? On CPU side everything including input, AI, audio, network, occlusion culling and rendering should happen on a single thread in less than 16ms for a smooth 60fps gameplay, while other CPU cores are staying idle. On GPU side it should wait for CPU to draw objects triangle by triangle, while they are capable of drawing lots of objects with a few (multi draw indirect) draw calls with ease.

          So what do these Q3 based engines should do to overcome their limits?
          - Adding support for vertex buffers, shaders and an experimental OGL 2.x backend
          - Further optimizing the OGL 2.x backend
          - Still not fast enough, adding support for instanced rendering and an experimental OGL 3.x backend
          - Further optimizing the OGL 3.x backend and adding some cool eye candy
          - Let's modernize/complicate the engine by switching to C++11/whatever with illusion of having a faster and error free engine
          - Let's add support for a lot of (game runtime unfriendly) image, sound and model formats
          - Let's extend the scripting system further more
          - Failure to optimize the game engine for multi core CPUs because of archaic engine design, not having proper plans and previous knowledge

          Why these kind of engines/projects are not welcome by professional artists?
          - They are very limited and hard to deal with compared to Unity and UE4
          - They are hobby projects
          - Team members come and go
          - There is no proper coordination
          - There is no deadline and they may not get completed at all
          See, that's more productive of a post. There's content and things to reply to!

          The main issue I continue seeing with this is the forgetfulness of the games history. The game was eased into an upgraded engine, they didn't just choose to start updating a 15 year old engine because it looked nice. The game was originally called Tremulous and was a mod for Quake 3. When Quake 3's engine source was released, the game still relied on assets of the game for years. When ioQuake3 finally became interesting and with the help of OSS content providers, the game eventually became free to play under the use of ioQuake3.

          People were happy with this for a long time. After awhile though, things started looking old. Population dropped off from even the usual 40 or so consistent players, and something needed to happen. Then came something called TremZ. TremZ was not unique in that there were quite a few projects intending to upgrade and start Tremulous fresh with new content, models, textures, etc. For whatever reason, TremZ ended up gaining a little bit of momentum. Original thread of introduction can still be found even: http://tremulous.net/forum/index.php?topic=16237.0

          TremZ developed mostly content and during this time, people started running into the ioQuake3's polygon limit. The polygon limit was intended for older hardware that didn't deal with shaders and thus, most performance was determined by how many polygons and textures were on the screen at one time. Some of the newer maps didn't just bump the limit, it destroyed it. During that time, ioQuake's solution wasn't quite in place yet so some decisions has to be made. For those wondering what the solution ioQuake proposed, here: http://wiki.ioquake3.org/Modular_Rendering_System

          I'm still rather fuzzy on the details but TremZ ran into large amounts of drama with one of the main contributors being found to stealing his textures and claiming them as his own. This caused a divide in the community where one side (TremZ) closed up the source and content while still claiming to be working on the project, and the other forked the project to create what would become Unvanquished. This caused some major setbacks in various areas unfortunately but was probably the biggest area of activity for the engine since there was competition. Unvanquished created an engine based on Xreal (http://sourceforge.net/projects/xreal/) and ioQuake3 called Daemon. TremZ developed the engine as a part of the game, rather than a separate entity, and so both the game and engine were called TremZ. No one really knows what direction TremZ went after the split since TremZ closed its source then died off in obscurity.

          Now, what's important to understand is that the engine isn't made for others to use. It's made for Unvanquished. C++ interfaces were added, an OpenGL 3 renderer was added, a scripting language to the game was added eventually (for awhile, the original Quake C scripts were used though), and so on. In retrospect though... there wasn't a whole lot wrong with the initial design of the ioQuake3. The problem to begin with was keeping compatibility so all games that relied on the original Quake 3 engine could still be used. Adding new functionality isn't hard if you are willing to break the interface of the engine. So, as to the question on why didn't they change engines... during that time, there was no professionally maintained engine that was cheap or free for that matter. In addition, they already had the game based on ioQuake3 which was maintained (and still is). They would have looked a whole lot more dumb by either writing an engine from scratch or by switching to another open-source engine that did pretty much the same thing they could and did already do.

          As for your points:
          - Adding support for vertex buffers, shaders and an experimental OGL 2.x backend
          - Further optimizing the OGL 2.x backend
          - Still not fast enough, adding support for instanced rendering and an experimental OGL 3.x backend
          - Further optimizing the OGL 3.x backend and adding some cool eye candy
          Sure. Improve the engine. Nothing wrong with this.

          - Let's modernize/complicate the engine by switching to C++11/whatever with illusion of having a faster and error free engine
          I actually agree and hate the idea of constantly moving C code to C++. I find C code easier to read in general but I generally blame the developer for this... still, this is subjective.

          - Let's add support for a lot of (game runtime unfriendly) image, sound and model formats
          There's not a lot of game runtime unfriendly image formats. You generally store things in a lossless format but what format that is really just preference. The end result is the same. If you want compression, people usually just store images in bitmaps with DXT* compression. It's hard to go wrong here... As for sound and model formats... still not following you. The only difference generally is going to be compression and loading methods. Not sure how these would be "game runtime unfriendly".

          - Let's extend the scripting system further more
          Nothing wrong this... QuakeC was replaced which, in particular, no longer suited the purposes of Unvanquished.

          - Failure to optimize the game engine for multi core CPUs because of archaic engine design, not having proper plans and previous knowledge
          While the first part *might* be valid, the second part is actually insulting to the contributors of the engine. Threading with OpenGL is no simple matter. An optimal situation has been to create similar to what NV_command_list does (http://developer.download.nvidia.com...mmand_list.txt) on the application side. This is what UE does and I'd imagine most in-house engines do to a much lesser extent (seeing as the code is a lot more involved when taking into account all situations). I've seen others do horribly slow context switching (don't ever do that in a real-time engine). But otherwise... you're shit out of luck. It's either you somehow store the state and data of a command and defer it to a later time for a master rendering thread to execute it or you do not have multi-threading with OpenGL. There is very little you can do otherwise. Thankfully, this is pretty much what the Daemon engine does which can be seen here: https://github.com/Unvanquished/Unva...kend.cpp#L5716

          Why these kind of engines/projects are not welcome by professional artists?
          - They are very limited and hard to deal with compared to Unity and UE4
          - They are hobby projects
          - Team members come and go
          - There is no proper coordination
          - There is no deadline and they may not get completed at all
          Aside from the first point (which depends on your experience with the Quake 3 engine tools), the rest are borderline insults. Those are reasons the projects "are not welcome"? You just described like 75% of the open-source projects that are even advertised on this very website.

          Hell, I'm one of those team members that came, fixed exactly one bug, and then went! It's how open-source works and it's been proven to work for decades now. As for proper coordination, I would claim this is not true in the case of Unvanquished. They use a bug tracker (https://github.com/Unvanquished/Unvanquished/issues), communicate over IRC regularly, and even have a wiki documentating the layout of the code, how to contribute, etc.

          Comment

          Working...
          X