EverQuest in Unity Engine project
 

Hey guys,
I'm an experienced unity programmer and a old school fan of everquest (rallos zek/sullon zek)

I been reading about a few attempts to make a eq client... One guy building his own in C++ and another using unity...

What i want to do is see how much interest/support i could get and id be willing to lead this project and build a new client using Unity.

Why I think unity would be good as it will allow us to compile a client for Mac/Windows/Linux/Web/Android/IPhone how cool would that be? and we wouldnt have to spend alot of time writing a new engine and spend the time just building EverQuest to work with the already sophisticated emulator servers.

This will allow for alot of things, improved graphics options, a true classic theme, as well as improving the code all together to make EQ less hackable, and we can go custom route with it and make a new game based on eq only more modernized. Options are endless but, we all know the eq client now is holding things back.

Please feel free to reply here on your thoughts and message me on skype: bruinp8n

A couple of reasons I want to see this project take of:
- 1) *LINUX* !! ...did I mention LINUX? Sick of windows.
- 2) The client Chase / legality issue in obtaining / server-different-clients-issues are a pita. One client to wrestle with would make life on all sides so much easier.

I really hope this takes off.

Well im all about developing/managing it, but, only if i can get additional support.

Its a pretty safe bet we will never have a non-Sony client, for quite a few reasons but really the only one that matters is the mountain of work is to accomplish something like that.

Also a problem is that nobody has extracted useable animation information from EQ models(or whatever killed Tyen's browser thing, I never really paid attention) and its just not feasible to reanimate every model in Everquest.

If you want to get momentum on this project, you can't wait for others. Start proving your concept and create a plan, its going to be very hard to convince the people with the skills to help unless they can see a way through. Don't worry about the easy stuff either, everybody knows you could reproduce the inventory or compass in Unity without issue but get a pipeline for extracting and importing assets or something like that and you might get something going.

Yea I totally agree, however, before I can really commit myself to a new project I'd have to have a few good men to start with.

I been trying to contact both pixel & tyen... if i can get them both on-board then that should be enough motivation for me to get started.

Problem Solved

http://www.eqemulator.org/forums/showthread.php?t=36726

I don't like being a naysayer, but I'm not sure it's worth the investment time is the largest challenge. It would definitely be a faster production to develop EQ with modern tools compared to development of original EQ, but it would need a lot of time and dedication between many experienced developers (who likely work full time engineering cool stuff for cool amounts of money) to get the ball really rolling.

But if you can make it happen, more power to you.

I think a smarter use of time is developing the PEQ/EQemu source, as it is in a very playable state with great contributions but always available for more development and refinement.

Imagine if we could do edits to the EQ client executable? Things like custom handshakes for network traffic, SSL encryption, improving range of valid numbers to display on client (beyond caps), etc.. the last I checked EQEMU intentionally avoids the client executable to try to stay as legal as possible, but even still, this is what I'd like to see to allow emu servers more capability.

Something that could happen tho if we had our own client is we could eventually re-create our own game that captures the eq nostalgia... We got alot of the server end coding done for it with this project... Could improve it and end up with our own community built game in the end if we did get a client going.

That's pretty much what every MMO company has done basically just they've kept it all closed source and proprietary.

Entire titanium assets will be up for download soonish.

Assets are ezpz to put into unity and we are mainly focusing on the initial connection between eqemu and unity

This is sounding very promising...!

Thanks bro.

OpenSuse 13.1
 

I am going to install OpenSuse 13.1 tomorrow and kick the tires so to speak. Their Open Build Service looks very promising. Point being... this Unity // open client is something I would be only too happy to try to contribute to. I am not a coder, but I will see what I can do for packaging up OpenSuse 13.1 builds etc...

I would also be willing to put work into a User Interface basic "mod" if such a thing would be of interest.

One of the things about OpenSuse 13.1 that is of interest to me is that this will be supported for 3 years :)

Gary

Not sure what the correlation between Unity & OpenSuse is, but if you want to contribute jump into the source I provided on eqbrowser.com and mess around a bit.

Any work connecting Unity to Eqemu source is appreciated.


The GUI we will be using is a plugin called NGUI that I have yet to purchase.

I currently have eqbrowser on a crowdfunding platform so I can raise funds to purchase a few pieces of software/plugins.

I own NGUI, but it goes against it's copyright to release it on an open source project...
If you close the source to only people you give permission to, I could contribute my copy of NGUI.

I took a few minutes playing around with the eqbrowser, seeing how stuff is being done. Since sounds and animations are interesting, wrote a quick mouse raycaster thingie and now you can click stuff.

@ensane I would love to help with the EQEMU/browser support, I just know I don't have enough time due to RL projects.

Here's that demo. (I forked the project and pushed any changes I did)
http://gigaplox.com/eq/web.html

Any help on networking is valuable. I plan on purchasing NGUI way later.


Lol at your build. The NPCs were a good touch, and lol @ dark elf doing a human monk animation with keypress 6. Some hilarious wiggle arms.

Update:

New assets incoming soon, this includes another pass of the NPCs as there are more heads and textures that need to be added.

As shown in Shin's build there were some textures missing, so that's going to be fixed.

More info on this round of Assets soon.

ECOMMONS example - textures, texture maps, zone model, object models, object Locations via XML

Models in .x format - I use http://mofo.pns.to/wibs/#5 to import .x into 3ds max


http://eqbrowser.com/misc/ecommons.rar


http://oi42.tinypic.com/2lj5eog.jpg

A lot of the work could be mitigated by using an already established opensource client.
One example would be "Ryzom" http://www.ryzomcore.org/ One of the interesting things they did was release ALL of their games assets under the CC license.

Worldforge is another one... http://www.worldforge.org/

I mean don't reinvent the wheel guys.

I'll also say that I think there are some issues with unity and linux. The main one that comes to mind (I could be wrong) is that development can't be done on linux you can only target binaries for linux.

-Importing EQ assets and having the client communicate with an Eqemu server has to happen regardless of what we use.
-We are using EQ assets only.
-Both of those clients look like they don't run in a browser.
-Id rather use a platform that is becoming the standard for game development which has employees and updates.

-I don't believe the phrase "reinventing the wheel" is applicable when saying "Move from Unity to some other platform."

Agreed. Though there are advantages in regards to having alternate free to distribute and modify assets. Someone else might be more qualified to discuss the legality of distributing the EQ client assets (and effectively running it in the browser is doing that)

Unity browser extension does not run in linux (as far as I can tell). The advantage of the browser is portability and what you're proposing is not portable. Technology like http://threejs.org/ is far more portable.

That's arguable. Unity has a indie following for sure. Ryzom has employees and if you bothered to look at the technology at all you would see a very active reop https://bitbucket.org/ryzom/ryzomcore/commits/all

Of course it is applicable. You are doing the work other platforms have already done. It's not like i'm says to use say a techX engine.

Going with unity means you exclude certain developers. Specifically any linux developers.

Regardless it's not my project. I can understand why someone familiar with unity might want to stick with it instead of learning something new. Maybe I misinterpreted the reasons behind the project.

I had mostly assumed this was to allow the EQ client to be run on platforms other than ms windows.

Actually Unity does compile to Linux now and unity is far more powerful then Ryzom and will save alot more time with a better pipeline for importing and using are from eq too being able to code and test systems.

Anyways, im working with the EQ browser project now as well and im working on a UI system to load EQ's ui .xml data and recreate EQ's ui within Unity.

We are also working on getting a simple connection to authenticate to and from eqemu and unity.

There should be alot of progress made in the comming weeks, as this develops we may need more help. Right now it would be kind of EQEmu to release us a few of there source files so this process can speed up =P

Unity will compile. The web browser thing does not (a quick google showed that apparently they plan on releasing a plugin for linux, but the requirement for a plugin is broken one)

I haven't actually looked too deep into Ryzom so I can't really say one way or the other. Unity is certainly more flexible as a general purpose engine.

What files? EQEmu code is completely available. https://github.com/EQEmu/Server

If you mean the loginserver crypto stuff - that should be released to the public. I still have never received a clear answer to why it hasn't been. That's another discussion though.

on a side note, I take it this isn't the correct git anymore? https://github.com/eqbrowser/EQBrowser only one commit from 6 months ago.

That is a bummer...

Ryzom is a joke compared to Unity. This is a Unity thread.

I don't care

Unity has received over $17 million in Venture Capital and has more corporate partnerships than any game development platform on the market.

Ryzom has not successfully connected to Eqemu nor does it have EQ's assets nor does it run in a browser. Therefore what you said is false.

Our domain is eqBROWSER, therefore it is safe to assume it will be for the BROWSER.

That is the correct RELEASE git.

You are most likely not going to see a public repository of non-stable or questionable source linked on Eqbrowser.com. When a big milestone is reached, the git is updated, which contains big plays.

Running linux here... no browser plugin. Hopefully they get the linux plugin soonish.

Update-

Basic Summary:
Besides the regular asset/mechanics grind, we can send and receive packets from Unity to an Eqemu server, but we have to do a handshake for each packet (which is our current networking issue).

Advanced Summary:
We are halfway/half-assed through setting up the EQ packet protocol checksum.

The packets are the easy part, but the protocol acknowledgement system is still unimplemented (OP_Ack) which is our current "hangup".

I've included the Prototype's Source below if you want to check it out.

http://eqbrowser.com/misc/EQLoginClient.zip

When you say hangup, do you mean you just haven't done it yet or are you having an active problem with it?

Edit: And the handshake issue, are you having a problem where you have to re-establish the tcp connection for every packet or something? That would be horrendous.

Both

The handshake issue was that we had to re-authenticate every time a packet was sent.

Those problems are now solved and we have the packet sequence pretty much done (sending / receiving).

The networking will be released open-source just like everything else.




We basically took Derision's EQExtractor code and tweaked it for a networking scenario instead of a packet collection scenario. Uses naez's class for sending and derision's constructor to recieve the proto packet

My sending class was just a quick prototype of a UDP client (read: it's pretty shit). It will likely need read/write threads and processing in the main thread in a design pattern that is seen a lot in the server code, so that network I/O will not lag each frame. Actual packet managers will probably need to inherit from this generic UDP client base class so that it can be reused for communications with the loginserver, worldserver and zoneserver (with a different virtual function for each, handling packet opcodes). It's got some utilities in it though that can translate C# structs into a raw byte buffer compatible with C, the Crypto API .dll symbol imports are working (though we still need embed it as a resource or something so it can be loaded by the web client), and I'm told Secrets has the CRC16/32 checksums working now too. Secrets is working on tying the infrastructure together.

It's still kind of a clusterfuck right now but once we get through to the breakthrough point of this network backend and can reliably commmunicate with the server, we should be able to rapidly make progress on a ton of features like tracking movement, attacking, commands like /who and /con etc, adding spawns/other players, and some of the more basic spells like heal and nuke.

I'm looking forward to this project simply because it'll make porting custom content easier. EQEmu is such a robust server solution in it's current form. It'd be nice to see it used for more diverse situations.

Update:

Secrets has generously offered to create an open-source way for developers to create custom clients to connect to an Eqemu server.

I don't believe many will understand how legendary this will be for actual custom client control, but this is a big deal. Secrets will be going down in EQ history as the person that allows any developer to have complete client customization for EQ.






Naez has started with Unity Gameplay Mechanics in relation to the 450 op_codes on the Eqemu server.

For example, you feign death in the game, and the server knows your feign death.






Tyen/Salty is continuing asset implementation into the Unity Engine, starting with Ecommonlands.

Ecommons object XML (rotation, scale, location) into Unity. (this)







Requiem is "thrashing" the server code and also making it more customizable in-game by putting "things" in the database.

Example; having a database editor in-game with additional options such as waypoints and spawns to customize your server.

Let me make it clear Salty: As long as you are wanting to attack Project 1999 and EQEmulator servers, you are considered too mentally unstable to assist in any projects.

If anything is done by myself, it will be open sourced so you could benefit from it. I am not 'working' for you, I am working for everyone.

Exactly how I stated it in my post, and I appreciate your continued contribution towards Open-Source EQ development.

I'll bite.

You may feel I'm "unstable" because I like to demonstrate server-related problems, but the EQEMU code-base is becoming more stable due to what the EQBrowser team found and the information I have provided EQEMU developers. Everyone who has played any Emu server knows things don't get done unless you generate attention.

I have yet to see any asset extraction tool (besides the one we created) that is able to do Models, Animations, Textures, Mats, & XML rot/scale/loc all at once.


I am assisting & contributing openly in custom client development, and have made huge strides, are you?

How to correctly report crash bugs with opcodes: Make a post with which opcodes can be used and how. If you want to provide a proof of concept crash plugin, send the source to one of the devs. If you want to include a tiny snippet, I personally have no problem, but some of the other devs might not.

How not to report crash bugs: Provide a compiled plugin in a public forum without source and not mention which opcodes cause problems.

Note: I like open disclosure on these things, but making it extremely easy for anyone to just grab the plugin and cause havoc is the wrong way to go about it. Calling devs names is also not a good thing. The thing is, more of the problems you've guys found were fixed because of the attacks you performed on servers, not you reporting them responsibly.

I have done what you described, yet the information is hidden from the public, as is anything that could make the project more stable for anyone starting a server.

It's basically the main problem with EQEMU "open-source development."

You want to gather anyone who has the time and expertise, yet keep it hidden from anyone who could contribute.

It's like a frat or sorority. Only the "cool" kids run the stable code, while everyone else is left in the dark.