is Everquest 3 news coming soon.....

Discussion in 'The Veterans' Lounge' started by chrisapete, Jul 19, 2020.

  1. MasterMagnus The Oracle of AllHigh

    I wasn't clear about what I meant I quess.

    -I think they are already in a perilous state with the code. Adding more features (whatever they may be) is always a bad idea with 22 year old software.

    -Trust me, any developer will back me up. The longer you go, the more changes you make, the more you cram it full of features, the less you get from source control, and the more time you spend on bug swatting. Todays methods, still applied to the Frankenstein's monster of trying to make spaghetti code object oriented, doesn't fix that. It can help, but code can be forced into a corner of no good place to unravel the changes to, and no good way forward in the state you're in. That's what we call broken code.

    -I'm not a raider, I just didn't want to get into the 'filthy casual' vs. raider issue. I am a firm believer in solo, molo, box, or whatever variety of playstyles there are. It's a forgone conclusion that raiders rule the show now though.

    -I'm proposing a curated game, which means, no more development at all. They stop, at a "well planned and logical moving on point" as I mentioned. The point of curating a game, is to make sure there is a stable version that can be played long into the future, and doesn't keep changing things from the past (or become irretrievably broken).

    -Further development of the original Everquest world, would continue in a newly built game in a modern engine, from level 120. You bring your character from original into new.

    -The goal is not fancy graphics, the old graphics are part of the charm. A great thing to see would be a proper modernization of the original low poly models. This would allow all kinds of cool things to be done, and lighting shaders etc. But honor the idea that this is still EQ1.

    -Another goal is preserving all the items and appearances from the original. So you can bring your character from one game to the other (technically I suppose you'd exist in both).

    What I didn't mention:
    This would allow them to continue on with the current EQ1 and always keep it running. While taking the databases and dumping them into a modern architecture, and everything getting backed up into modern file formats. Before doing any development on a new game, just get everything documented and stored for possible future use. Even if it means taking some time from next expansion. Please just take that time from whatever new 'dragon horde' or other feature you had planned.
  2. Ninelder Augur

    Unfortunately for EQ, the business leaders of "insert company name here," Did not or never understood the appeal of this game. They kept trying and failing to make successful sequels as if this game were a first person shooter.

    More unfortunately they took valuable resources from the cash-cow that is EQ away, squandering so many opportunities to make this game better. All to create sequels that anyone who knew anything about our player-base could foresee to be a bad investment.
    Ferriciean, Qelil, Skuz and 1 other person like this.
  3. Qelil Augur

    Um, the quote leading your post that indicates it is from me, is not from me. I'm not sure how that happened but I will assume it was not intentional. Perhaps it was meant to be part of your reply instead.

    I guess it is worth telling you at this point that you are speaking to a retired senior software engineer who among other things has done work for both IBM and Microsoft, has worked as a consultant rescuing projects in trouble and more.

    Starting with your source control comment above, regardless of feature creep you continue to get exactly what you always get from source control systems.

    So called spaghetti code is for amateurs. I don't know why you even bring that up in this context. Is that supposed to imply something about EQ's code? Have you seen it personally? No, I know you have not.

    You don't rely on source control like it is some editing feature you know, I hope. I am referencing your comment about "code can be forced into a corner of no good place to unravel changes to?" I am glad I have never witnessed the likes of that but then I was fortunate to work with talented people who knew what they were doing on a team that was properly funded to get the work done, including a full staff of quality assurance engineers. Overseeing and directing the efforts of a seasoned, professional team of such engineers is something else I have direct experience with.

    Did you ever read the book titled, "Code Complete" which was published many years ago now by Microsoft Press? That was basically a dissection of a major failed project at Microsoft that got so out of hand, throwing the entire project away and starting over became necessary. That is what we call broken code. It was a complete, unmitigated, expensive disaster where important lessons about software development process and best practices were learned the hard way at Microsoft.

    Ultimately though, where we disagree and perhaps should just agree to do so is in that while you claim the game should be what you call curated, I think it deserves continued development over time. I think your concerns are conservative to a fault to put it mildly and that talented engineers are capable of more than you seem to give them credit for.
    MasterMagnus likes this.
  4. MasterMagnus The Oracle of AllHigh

    Actually yes, I read "Code Complete" back in the day. Was always fond of development books. "About Face" was my favorite.

    You make good points, as I said the first time. The ellipses ... ... mean I snipped your quote and was telling you I agree with much of what YOU said.

    While I haven't seen any more of the code than you have. I've been around since the beginning and consumed enough developer statements to know it was not object oriented, and was spaghetti to start out. Even so, it ran much better than today.

    I'm basing what I say on nothing more. Your mileage may vary.

    You make plenty of good points.

    I've never been in favor of an EQ3 or anything that further fractures the community.

    But with the new owners, and the current state of the game. I think it is a great inflection point at which to talk about maybe securing this game for the future, rather than continually changing things for TLP and changing live to keep a common code base.

    Just my thoughts.
  5. Xianzu_Monk_Tunare Augur

    I don't think that anyone has actually said that anything is unfixable, most of us however have said that it is unfeasible to make the changes. The amount of money and resources required to 'fix' EQ at this point is such that it would lose money to do it. You could have 10,000,000,000 QA's and there would still be buggy code and other issues in the game. They test to make sure that the game works how it is supposed to not to look and find if it is doing things it is not supposed to, and they don't try and find ways to work around intended mechanics. The QA department has always been funded. It is just that the playerbase is always far more creative than any of the Dev's and QA's.

    Even with everything that EQ makes being put back in, there still would not be enough resources to do what people want done. As for the maintenance work, that is always ongoing. The issues over the past year have been a combination of the lockdowns and the maintenance work going on. That makes it complicated when issues come up that need addressed on the fly.
    A dead game is what you would have, not a curated one. There will be no moving on point. What there will be is the introduction of numerous free EQ servers. Darkpaw would be out of business in two years, maybe three. Well before Darkpaw could recreate EQ1 using a modern engine from the ground up as you later suggested. Also, moving existing characters from the original to the new would likely push out the time it takes to create this even further.
    If I had to guess, the spaghetti code reference is due to how some of the EQ Devs and coders post SoL referred to the older code. We have been told that the early EQ code was done very amateurishly; no commenting, generic label usage, etc. After the SoL exodus of Developers and Coders, the remaining ones had to go in and figure out what things did by trial and error in some cases. There are still parts of the game that are tied to this that the Devs are hesitant to change much. Other parts which they have changed, for example the level xp progression, they worked on slowly for years so that they could make sure they didn't make huge screw ups and knew what to expect from the changes they did make.
    MasterMagnus likes this.
  6. MasterMagnus The Oracle of AllHigh

    now as I'm fond of saying...

    ding ding ding, we have a winner
  7. Accipiter Old Timer

    DeMarco and Lister - Peopleware, Waltzing with Bears, Slack

    Good stuff. More for dev managers, project managers, and execs but still worth the read.
    MasterMagnus likes this.
  8. Megazen Elder

    This may be my favorite sentence ever posted on these forums.
  9. Iven Augur

    The game engine could be even more old as it was designed for a racing game and maybe even got used in one.

    Well, nobody did say or wrote this.
  10. Skuz I am become Wrath, the Destroyer of Worlds.

    Did you forget something?

    That's what is flat out wrong, it was wrong in 1999, it's still wrong in 2021.
  11. Skuz I am become Wrath, the Destroyer of Worlds.

    The current engine dates from 2003/2004 since it was rewritten for DX9.

    I am not sure how accurate this information below is but it sounds about right.
    Back in 1999, EverQuest was released with a hybrid DX6/GLIDE graphics engine. (Skuz EDIT: Used in Need for Speed 2) This graphic engine was mainly built off the True3D engine (Skuz EDIT: used previously in "Return to Krondor") and used sky resources found in sky.s3d.

    On November 11th, 2000, the engine was revamped to use DirectX 7. The Velious only new armor textures and full screen user interface were also added at this time.

    On December 4th, 2001, Luclin was released. An upgraded DX8 based graphics engine named "Umbra" was included in the release. This new DX8 engine still used the old sky.s3d file and introduced new features such as back culling (via dpvs.dll), higher resolution textures, and ground foliage. Sky.s3d was updated to add the new skies for the Luclin zones. It took Verant nearly a month of daily patching to sort out the bugs and stabilize the game. Somewhere down the line, the graphics DLL was split out from EQGame.exe into it's own file, EQGfx_DX8.DLL.

    On July 24th, 2002, the XML/TGA based SUITE user interface system was released that enabled the bazaar zone and user interface customization. The SUITE user interface also killed/abandoned the old in-game bulletin board system. The SUITE user interface eventually became mandatory on January 9th, 2003. A couple of new skies were added to sky.s3d for the Planes of Power release. Around the time of Lost Dungeon's release, the ability to specify NPC model loads using zone "_chr.txt" files was added.

    On March 23rd, 2004, Sony Online released the 3rd generation EverQuest engine that required DX9, called "EQGraphics". This engine was contained in a new graphics DLL file, "EQGraphicsDX9.dll". Unlike the first and second generation engines, the EQGraphics engine revamped most of the major data structures behind EverQuest. Sky support no longer used sky.s3d and instead drew all its data from the newly formed "Resources" directory. The default engine graphics format changed from "BMP" to "DDS". A new zone resources format called "EQG"/"ZON" was created for newer zones. "S3D" compatibility was maintained for legacy purposes. The entire collision system was revamped at this time, causing months of collision related issues.

    Also worth a read -
    henry0918, Wulfhere and Jumbur like this.
  12. Iven Augur

    Based on these infos it is good to know that EQ is in a modern state and not based on code from1999.

    Nope. Just read correctly ! Pretty much is not zero. Maybe you could expain to a noob why EQ does create so much CPU loading when running around with a player character in a newer expansion zone while the GPU loading is near zero. Same thing happens during NPC fights. CPU and external graphic card are more than ten years old. Onboard GFX is disabled.
  13. Skuz I am become Wrath, the Destroyer of Worlds.

    I have no idea what you are referring to with "CPU & GPU loading" can you elaborate?

    I have an almost 10 year old PC myself running a 2nd Gen i7 2700k (2011) & an AMD 6870 (2010 cannibalised from my old PC) I run EQ from an SSD to reduce loading times and have 16GB RAM, play in windowed mode on a 27" 1080p IPS panel with 1920 x 1080 resolution, a second panel running at lower resolution.
    my onboard gfx chip is disabled as it will not function with Win 10 as intel never released Win 10 drivers for it.

    I have zero slowdown in modern zones (as far as TBL anyway), getting well over 30FPS on raids most of the time too, my CPU idles at 2% of capacity while writing this post & playing EQ that rises to a fairly stable 10-24% of capacity. RAM goes from 22% to 28%
    I don't run any metrics for the gfx card so no clue what the increase vs idle is on that.
  14. Jumbur Improved Familiar

    Back in the old days 3d-accelerators(before they were called GPUs) had only very specific instructions they could accelerate in hardware. This was pretty much hardcoded("fixed pipeline"), the first generation of 3d-accelerators was limited to texture-mapping and a few blending operations iirc. That means the architecture of the engine did most of the calculations and game logic on the CPU-side.

    This was the case when EQ was first developed.

    With DX8 they introduced shaders, which was short programs that could inject short procedures into the GFX-pipeline, and would allow stuff like bump-mapping and per-pixel-lightning(EQ had this in their DX8 engine, visible in Omens of War and later), but there were some harsh limitations, flow-control and loops was not practical back then and there were no compilers, so it was written in assembly.

    With DX9, compilers started to emerge, and there was better flow-control and support for loops. but there was still not a tradition to move complex calculations to the GPU.
    Hence most DX9 era(and earlier) engines are somewhat CPU demanding, while the GPU sit mostly idle.

    Modern 3d-engines(DX10+) usually moves a lot of calculation(for example collision-detection and physics-handling) from the CPU to a "compute-shader" that runs on the GPU. Everquest's newest game-engine was not designed with this in mind.
    Iven likes this.
  15. Iven Augur

    CPU loading = CPU usage %. I experienced that the CPU can get pretty hot during gameplay while the graphic card core (GPU) does stay always at the same temperature. This does mean that EQ is using the CPU alot more than the GPU. Most of it seems to get caused by the 3D graphics and animations. This is a strong sign that 3D elements do not get calculated by the 3D graphic card processor but instead by the CPU. It got proved so often here in the forums so why do you deny this fact ?

    Thx for you info Jumbur, this is the information that I also have.
  16. Skuz I am become Wrath, the Destroyer of Worlds.

    That's an egregious over-simplification. True the games were CPU intensive.The GPU in even voodoo-era were however busy handling the geometry calculations, texture mapping, mostly sitting idle is not what the GPU were doing at all.
  17. Skuz I am become Wrath, the Destroyer of Worlds.

    It can also mean that your GPU is very strong while your CPU is very weak vs EQ's demands.

    I have a second gen i3 that barely raises a few degrees running EQ (my 3rd box pc), how bad a CPU are you running for it to be getting hot?

    It is worth understanding that EQ's client does much more than just display the game world, MMO in general run a lot of data processing through the CPU that are not directly graphics related because of the asynchronous nature of the EQ client server structure.
  18. Jumbur Improved Familiar

    I thought vertex-calculations were mostly CPU-side, before Nvidia brought hardware-T&L(the first Geforce) to the consumer market? :confused:

    And besides, there were a lot of blending operations in games even then(all the spells/explosions), so old voodoo-cards were not idle back then.
  19. Skuz I am become Wrath, the Destroyer of Worlds.

    Okay I am admittedly no expert on Graphics and 3d Acceleration but 3d accelerators were not sitting idle, they carried out the texture mapping onto the raw polygon meshes the software creates and which the CPU calculates the size shape & positions of and by doing that they speed up the 3d drawing process by offloading that heavy-processing task to GPU. Voodoo cards were basically fast TMU (texture mapping units) initially.

    T&L which is how a 3d image is displayed as a 2d by modifying the calculating so it is only needing to texture map the polygons in view of the observer, (vertex calculations) no point texture mapping onto polygons you can't see so this is an efficiency measure to gain speed in processing what images to show to the players. That part was done in software prior to the cards with hardware T&L but that Texture mapping process was still being done by the graphics card.
    Jumbur likes this.
  20. Iven Augur

    Dual core Athlon X2 4450e (~2x 2200 MHz). One of the infamous energy saving 45W TDP pieces but never got a problem with it in other 10-15 year old 3D games. When I did quit EQ in late 2004 I was using a much weaker single core CPU without much problems. Not that I have much problems today but there can be graphical lag in new zones so that I have to reduce the clip plane. The current graphic card should be more than enough for an old game: ATI Radeon HD 5450 (1GB DDR3, 650 MHz). But as already stated it does not get used much at all by EQ.