Client discussion, blue-sky thinking welcome
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: Quote:
|
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. |
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. |
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. |
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.
|
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) |
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. |
DataBase Editing Mode
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.. |
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. |
Code:
GUI <==> Client Shell <==> Client Engine <==> Internet <==> Server 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). 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! |
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.
|
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... |
/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. |
I look forward to this immensely. There any chance the client will be open source?
|
Quote:
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 |
All times are GMT -4. The time now is 07:30 AM. |
Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.