Client discussion, blue-sky thinking welcome

[Windcatcher]

Recently I mentioned that I (we? us?) plan to release a client sometime this year. While at this point I'm ever-so-slowly trying to climb that huge mountain called 'item icons', I'm still committed to that goal, and a message from someone kicked me into thinking that it might be high time to try to spur a discussion on what a client/server combo should have in it. From what I've read in these forums and what I've seen in the larger EQ community, I think that it's time to leave not just Norrath(tm) but the general game of EQ behind, or at least give ourselves that option. What I'd like to spur people into talking about involves customization, and I know I'm not imaginative enough to work out all the issues by myself.

The thing that kicked me into action was a question regarding whether the client I was planning would support things like AA's or custom GUI setups. I think the real issue is MUCH larger than that, but here's my response (sans anything that would identify the person asking) to give you all a starting point:


It doesn't support AA's at this point because my test server doesn't support them, but I understand your question. The hardest part will be making the GUI configurable, just because it will be a lot of work to create an XML schema and subsystem for building the GUI dynamically. I want to do just that, but the first version probably won't have that yet. I haven't decided if I want to try to borrow from my OpenSpell dynamic GUI code but that would probably be overkill. I might be able to borrow parts of it, though, to speed the process up.

The client is configurable from the standpoint of server versions -- while I test it primarily with EQEmu 0.5.5, I've tested it with other versions as well. It has profiles for several versions and will automatically configure itself based on what it connects to. There is a custom protocol where the client tells the login server what server versions it supports, the login server tells it what's available within those constraints, and they show up for the player. The client uses dynamic opcode lists and packet definitions, and it can support most versions between EQEmu 0.5.5 and EQEmu 0.6.0. The reason it doesn't support 0.6.1 and newer is because the netcode is completely different, but the client has all of its netcode encapsulated in DLL's -- for it to work with newer versions only requires that someone write a DLL that matches the interface of the existing one. At this point I don't have time to figure out how the newer netcode works and write one myself. The netcode is GPL and will be opened up when it's released so others can work on another DLL if they want.

I think the biggest potential for configurability will be in features and ruleset, for instance:
- what gods are available
- what race/class combos are available
- what choices are available for the starting city
- the player stats (for instance, D&D rules use STR, INT, WIS, DEX, CON, CHA and don't have resistances).
- the types of money (for example, D&D1E has pp,gp,sp,ep, and cp, and other games have have fewer types)
- the money conversion rates
- the relevance of player skills (for example, DragonQuest is very different than D&D when it comes to skills)
- Whether grouping is allowed, and its parameters (more than six? less than six? other features or restrictions?)
- Spell memorization rules

I'm not imaginative enough to figure out all of these things. I think there needs to be a forum discussion on what kind of flexibility is desired, and the sooner it happens the better the design and implementation will probably be. All of these things will require changes to the server and the DB and so it should involve the entire community.


I keep thinking of the opening to The Outer Limits ("Do not adjust your television. We control the horizontal. We control the vertical.") With a client/server combination we control the entire equation, and within the constraints of staying away from anything that belongs to SOE there are loads of possibilities if we're imaginative enough to think of them (and if they're the sort of things I can implement with a reasonable amount of effort). This is something that's been on my mind for a while, but I'm so swamped with the minutia of trying to get everything ready that I really can't spare the brain cells for that sort of blue-sky thinking. About the only consolation is that I can plagiarize the hell out of my code, so for instance the dynamic server packet stuff borrows heavily from the Admin Tool (remember that?). Still, it's no substitute for the real kind of thought that this sort of discussion requires and is why I'm posting it now. Better to have this discussion now than at the 11th hour when I'm getting ready to release something. Fair warning: if participation here is anemic then you all shouldn't expect much because I'm oversubscribed as it is. This is a real 'help needed' call.

[mattmeck]

Ability to PVP with different rule sets is almost a must in this community. Give people the ability to do town warfare, have forts etc.


A functional bazaar type zone would be nice too. (cant attack, cast deteremental spells, weight isn't taken into account, maybe a form of the merchant in EQ?)


How about the ability to assign different rule sets to different zones? (PVP in those zones, PVE in those, no fighting in those, GUILD PVP in another, team PVP in another, i can think of a lot of ways this can be used.

I know its asking a lot, but the best thing would be for there to be a way to add new code for rules or whatever and make it easy for people to select and change them, i.e. some way that wont require recompiling with every change.



Wind, I have always loved what you have given this community, but when this is given it will take the cake.

[squire]

I think it's great you are working on this.

An interesting dynamic would be player influence on the faction that controls a region. This is probably a combination of server and client changes, but since you said the sky's the limit, so to speak. Imagine the fun of having a true struggle within the game to where your character can actually liberate or oppress a region. That would add a whole new side of PvP battles.

Customized Spell effects. One person has a funnel for a wind related spell where someone else may have a simple gust of wind.

That's all I got at the moment. If something else strikes me, I'll drop it in here.

[bufferofnewbies]

Having the possibility of all effects run by a 'Rules' type system we have here would be nice, but might be extremely hard to code in without alot of excess processing.

I, myself, have always wanted the ability to turn on AA advancement from level 1. That way if your friends start to level behind you, you dont have to stop playing/ turn off exp (allowable on some servers)/ etc. This would allow exp gain of some sort, even if it wouldnt be much. (Imagine trying to get run1 at level 1 exp gains when the exp check is for level 50, but still.. the option would be there)

Perhaps a way to limit aa paths. (ie: lock this path if you have chosen this other one). This could provide the players with a way to diversify classes (read as: create subclasses based on new aa abilities agined at level xx), while still keeping the core classes available to the majority of the community without having to code new classes themselves.

Of course, we would have the ability to modify the aa gained also, so perhaps it would be viable to set some aa's to be used at earlier levels then. Perhaps a level 20 set, a level 40 set, etc. I have always favored the ability to diversify PC abilities as well as provide more flavor.

I am not sure how hard on the system the rules system is as far as the processing it needs to read sets of them, but if that was possible then I would really like to see that type of setup. Where any condition can be changed by the Admins. Even better would be the option to allow such changes to only take effect in 'designated' locations. Not just zones, but perhaps areas within zones. (IE: you can fight here, but NOT at the bank. You can bind here, but NOT deeper in the zone.)

Perhaps a way to share exp gained across a group of people (so the people who play less still gain just as much as the ones who play more) (IE: 2 players are 'tagged' together: player 1 kills a mob and would get 100xp. That player now gets 50xp, and the other player he is 'tagged' with gains 50xp also.) Ok, that one was stolen blatently from SoD, but only because I really like the intent of the system.

As I have stated many times, I don't really know much about the Coding part of the Emu. And atm, I really am not contributing much to the emu itself due to some outside commitments I am in need of focusing upon. But I do like the work you have done so far with this. It has all looked great and any ability to do what we like to do without the use of the current client would be a godsend. This would also enable us to create login servers for the communities, althought I see that really as a bad thing overall since it would seperate the community apart instead of it being a cohesive unit like now.

[Windcatcher]

I could possibly alter the architecture to support DLL plug-ins so that other people could add support for more kinds of packets, but one issue is cheating. Does anyone have any thoughts? It looks like the bulk of the client will have to be closed-source to prevent cheaters but I'm open to suggestions. I'd like to open as much of it as possible if I can.

[bufferofnewbies]

Possible to add a server side check of allowed plugins?
anything not on the list is ignored by the system, to prevent hack plugins (unless the Admin says its ok and adds it to their list)

[Windcatcher]

I'm definitely open to suggestions (and as it turns out, I need them as I'm not up on how to prevent tampering with software). It's ironic that we find ourselves in a similar boat as SOE but I suppose it's inevitable.

As a side note, I'm just about at the point where I have a basic set of item icons that's barely enough to field a playable game. I make them by building crude models in Anim8or and rendering them--some look pretty similar to live icons and some don't look anything like them (and there's a vast continuum in between). I'm prepared to make my Anim8or files available for people to make more, but I've decided that my time is better spent doing something other than building a set of 1200-1500 icons. I've made around 260 so far, though I have greater variation in some areas than the live set and so the overlap isn't that high. Like I said, it's barely enough, and we can add more over time.

[Dr Zauis]

It would be really awesome if there were buttons on a separate panel or something to create npcs say..even by the dozens and then be able to click on one and drag it to a new location..Hit points and AC could be calculated in a selection of formulas..I would be using the Program everyday just for those tools!

EDIT>>Also to create and place doors/ect..Maybe a way to indicate waypoints..Say cubes(or arrows) with numbers or something..

[techguy84]

It is to my understand that you are talking about a totally different game correct. If thats the case, my personal opinion is that you should try to stick as much to the current rule set, gameplay, whatever you want ot call it, as all the other mmorpg's do. I know some people are like, "why the hell would you clone something", and my reply is that it is time tested and true. WoW copied, EQ2, EQ2 copied EQ1 and WoW, they're all pretty much alike as far as the basics go, then you add in your own little features that will entice people to play yours vs the competiors. I would start by looking at the most popular as of today, and that hands down is WoW, as stupid as it is, it is the most popular.

I speak out of thought though. I personal think that by creating a all new game, using eqemu as the server behind it, you could have a project that will take all the hardwork that everyone has put into this project over the years and make it profitable. That may not be the goal of this, but I was think of something along the lines of Guildwars. Buy the game, never have to worry about subscription fees to play. Any of you that played Unreal knows of the red orchestra mod that floated around. Now look at them, they took their great idea and developed it, essentialy make a brand new game for the shelves. It does go against the open source Idea, but eventually if you have made something of this magnitude, you kinda have to break away from open source, because a good idea that is just given away for nothing is not a good idea at all. Someone else will come along and steal it away and do it anyhow.

I know that I am just rambling on, but I know I would spend $39.95 easliy for something that is great like EQ, but with-out the subscription fee. I did it with GW, and that wasnt even near as great as the orignal EQ.

Anyhow, OpenZone ftw.

[EmanonCow]

GUI <==> Client Shell <==> Client Engine <==> Internet <==> Server
| ^
\-> 3D World -/


GUI talks to the Client Shell via a "text-based" messaging interface, plus a secondary "3d world" interface.

GUI <==> Client Shell
Observers for when something in the player-state has changed.
Command-Requests for when the user tells the GUI to do something. (from "Get my AA" to "tell john he sucks".
3d world interface that renders the game-world and allows for hit-testing. The GUI provides the 3d world with a surface of some kind to render on.

Command-requests return a Future (see wikipedia (http://en.wikipedia.org/wiki/Future_%28programming%29)). The GUI can request to get a message when a future is evaluated.

Observers are just requests to get a message when a value is changed. This is useful for things like HP, Stats, or other displayed items.

Client Shell talks to the Client Engine. It needs to determine if the GUI is talking nonsense, parse the commands and requests into low-level code communication with the Engine, and send messages to the GUI when things it asked for have been changed. The Client Shell can maintain a cached state of the player's stats, or just forward all requests to the server: that is an implementation detail.

Client Engine talks over the internet to the Server. Here is where the opcode and networking stuff comes in.

---

This is all architecture details. But it would cut the messy GUI code away from the opcode, and allow you to code up a crappy-GUI that gets replaced after the project is working, and a GUI that is pretty independant of the game-rules.

---

Now, really blue-sky for game features:
Server-defined currencies. (with trade restrictions)
Server-defined item flags. (Lore, etc)
Server-defined item properties.
Server-defined character attributes.
Server-defined "can equip" rules.
Server-defined "can trade to player X" rules.
Server-defined "can trade to NPC X" rules.
Server-defined equipment slots.
Server-defined "can-put-in-bag" rules.
NPC/game-event Interaction dialogs:
Lists of options
Lists of purchases (arbitrary currency)
Server-defined commands, grouped by server-defined groups. (ie, dzadd, etc)
Pet(s) control dialogs (server-defined list of commands you can give)

That might get too general, and require too much client-server chatter. But much of that doesn't change that rapidly, and can be cached (the fact that right-clicking on an NPC opens a "talk", "pickpocket" or "examine" dialog would have to be told to the client once with the right kind of caching system.)

The Client-Engine should ideally cache some of the information (if the server says it is cacheable).

Maybe the Server would be allowed to send Scripts to the Client-Engine? Then when the user clicks on a dialog, the client could be more responsive, and not have to wait for the server to figure out what should happen. So long as the script isn't trusted (ie, it changes UI-state, not game-state) and the engine relies on the server to confirm the action was legal, it would be safe from cheating.

...

The goal is to be able to have a custom defined set of stats and skills, determined by the particular server. Given that you don't have a hard set of rules for the game, this also means you don't lock youself into a particular set of gameplay.

The server might have to modify the GUI, or the GUI might have to be flexible, to allow for some UI tweaks. But one could instead take the "dialog" approach: the server says "there is a SKILLS button. Clicking on it opens the SKILLs dialog. The SKILLs dialog is a LIST of [ SKILL_CONTROL["SKILL::CLIMB"]...SKILL_CONTROL["SKILL::PARRY"] ] and one BUTTON (CLOSE). SKILL_CONTROL[SKILL_NAME] is a pair [ATTRIBUTE_DISPLAY[SKILL_NAME], SKILL_TWIDDLE_CONTROL]. A SKILL_TWIDDLE_CONTROL is a toggle over 3 options ["CONCENTRATE", "IGNORE", "ATROPHY"].

It won't be pretty, but that is enough information to create a skills dialog with some interactive parts.

Toss version-GUIDs next to each of those, so when the server updates the list of skills, the client doens't display the old one, and when the server doesn't change it, the client doesn't have to rerequest the list of skills from the server.

Start with a basic layout engine. Add in the ability to override a default widget layout by name and version-GUID with a custom one (ie, the GUI would first ask the local CustomGUI-DLLs "do you have a control for SKILL_CONTROL["SKILL_NAME"] version GUID{1234-adfa-baad-f00d1234}? If the CustomGUI-DLL said "yes, with GUID{...}", it would check if it already has that GUID custom control in it's GUI cache (and use the cached one), or use the CustomGUI-DLLs version otherwise. Otherwise it would query the server "so, what exactly is a SKILL_CONTROL[]?".

But that is going too deep. To start with, the GUI would have to be kept in sync with the server, and the server would only tell the GUI what it expects to hear. Faster prototype. Of course, you could deal with this by having a Custom-GUI-DLL with all of the server dialogs pre-loaded in it. Not relying on this this allows you to tweak the gameplay on the server-end without having to update the client manually. It also means that logging into a server with very different character stats works without a problem. A keen server would write a custom-GUI-DLL to make their character stat display look prettier, and different servers could steal each other's custom controls...

You could even be paranoid, and run the Custon-GUI-DLL in a seperate process and/or in a sandbox, so they can't poke into the game memory.

I want someone to be able to create an AA system, a use-based skill system, a buy-abilities-from-an-NPC system, a level-up-and-spend-stat-points system, a raid/group management system, or a build-items-from-raw-materials system all on the same client without having to rewrite it.

Yes, this is blue sky. You did ask. :)

...

What else...

The spell/effect particle engine should be able to get data from the GUI, the Client Shell, and from the Server (indirectly, via the Client Shell). It probably needs to be pretty integrated with the 3d engine if you want effects like "the sword glows" or "a bolt of fire shoots out from your hand and heads towards the target", and not just random nimbus's around characters. ;)

The client should send "I am here, I am here, I am here" packets to the server. In addition, it should sent a trap-door (CRC32) of "the justification of my last 12 seconds of movement and my location at this time" every 5 seconds, and keep track of a complete justification for the last 2 minutes. The server can ask for the actual justification of movement whenever it wants after the fact, which can be checked against the sent CRCs, for internal consistency, and against movement packets that actually arrived at the server.

If the player is move-hacking, it will be hard to generate a justification of movement that lines up with the CRCs, the location packets sent to the server, and the rules of the game. Clients who regularly disconnect when requested for justification packets get flagged as potential cheaters. Clients who give bad justifications are flagged. Clients who seem to move faster than the game thinks is possible are sent requests, as well as clients randomly.

This doesn't prevent movement cheating, but it does make it catchable. :)

In effect, the client is trusted with determining it's location, but it must also provide justification for it's movement when requested.

If justification is expensive to verify, one could even farm it off to another client (pick two random clients, they are unlikely to be both cheating in exactly the same way), store up the details and check it when server load is lower, or just drop it. Heck, one could ignore the justification sent, and just ask out of paranoia. :)

...

That's it for now. Food!

[samandhi]

I think this is a great idea. In my HUMBLE opinion, I would love to see a client that runs MOST of the eq ruleset with a few exceptions.

PVE more easily solo-able
Ability to use any combo of class skills (kinda' like Oblivion)
Ability/skill to talk to your god and even sometimes get an answer (would make for a good storyline booster)
Certain days of the week/month your god blesses you according to your class (draw your own story/conclusion from that)
Certain areas make a certain race/class a little better/stronger/xxxbuff (eg... druid in the woods gets barkskin spell automatically for xxx time)
Wandering merchants
Chop down trees, dig for iron etc... for crafting materials (kinda' like AC2)
Off-the-wall quests that, instead of just killing stuff, you might have to,say, go and pull the hair (used like /emote pull hair [targetname]) of another NPC.
Damagable PVE (eg... trees, rocks, walls)
Change from guilds to religions, where you have to perform some sort of ritual per week/month/year to appease the god of your religion (to build up points that fall away if you dont do the ritual often enough) and that will make you stronger like unlocking the knowlege to build balisa's or something like that. I think this would ultimately swing things more from "money" farming to "power" seeking...

Some ideas I would like to see... I know, some are in direct conflict with others but thought I would put them in anyhow..

[EmanonCow]

Btw, for icons, ever think of grabbing royalty-free clipart?

Another interesting idea is to talk to a weapon/sword maker, and see if you can use images of their weapons in exchange for links to their website. Ie:
"If you would want to buy this weapon for real, visit [clickable url]" as part of the item description.

It doesn't give you volumetric data on weapons, but it might generate decent texture-based weapons or provide a texture base for a weapon...

[John Adams]

/necro'd!

Sorry, just getting back to the world... I love the idea of "emulating" the original game as much as possible as a base, with the (hopefully) simple ability to change things up as much as a server admin prefers. Regardless of the direction of this new server/client, I feel Rev 1 should contain the simplest of all things - base functionality - before adding intricate nice-to-haves like AA, guild wars, FellowshipXP, etc. All great ideas and all desirable.

I'd like to download, setup, login, and kill something. And I'd like it to be fun and challenging. We already know it's going to look marvelous.

[rmanders]

I look forward to this immensely. There any chance the client will be open source?

[Wizardanim]

Ability to use any combo of class skills (kinda' like Oblivion)

I really think on this issue you could take a large step away from the traditional SOE idea of the game.

Based on sam's suggestion, a fully dynamic progression not only through zones (if you plan to implement teirs into zone progression) but class abilities.

Say your a warrior with the chosen ability to heal, youd create a paladin with more melee ability... sort of like oblivion like sam said, where you can create any specific class, or any class in between them. The larger issue here would be balance... and putting restrictions on the classes.

Perhaps even after you reach a certain level your allowed to train once more... if you choose warrior in the preliminary setting (create character) you can then choose wizard, or cleric... as a second class. I know ive heard the idea somewhere before... (nwn?)

Along with this, I think that plugins are a great way to allow the client to progress. Always loved plugins ^^.

Much respect and glad to help anyway I can. Lately ive found I have much free time so expect a cornucopia of models to choose from soon...

~Wiz

[EmanonCow]

Class balance details like that are not coded into the client typically.

The client is just the UI, not the game mechanics. Ideally it would be runnable with an existing (or slightly modified) EQEmu server to start with.