Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: WMCoolmon on April 06, 2005, 09:03:46 pm
-
Came up on IRC, now I'm thinking about it and brainstorming.
Not that I feel like even touching the idea of implementation with a 10-foot pole. :p
- Fix ingame joining. This is important. Probably the most important thing, as you can do a lot of the other stuff with SEXPs.
- Longer update times. Necessary if you want the first "M" in MMORPG. Otherwise you're stuck with the usual limit of players.
- Add the ability to save data on players to the code to some sort of file via SEXPs.
- Implement an alternative chat system.
- Probably give some more low level SEXPs, like a "create-ship" SEXP.
- Add the ability to have some sort of means of monetary exchange (Not score; score should be equivelant to powerlevel points)
- Which of course means you'd have to SEXP in the variable with the above player-data save SEXP stuffs.
- Implement code to load the player's curret money level and offer them ship choices. Possibly allow use of SEXPs in the ship selection screen/briefing?
- Set things up so that only nearby ships are displayed/positions updated
That gives you a 'mission' where players can enter, leave, talk with NPCs, gain items...well, that's pretty much it. OTOH, what more is there in a MMORPG? :p
Limitations:
- One map. Duh.
- If you want to change something, you have to take down the server.
- The above assumes that a lot of stuff is hardcoded; you'd need an items.tbl for any sort of flexibility.
- Although, interestingly enough, since it'd be necessary to build the player-item-save code it could probably be made to allow new items to be added dynamically (ie without restarting the server). How you'd work that in with SEXPs, I'm not sure.
- I have no idea how much of the code would have to be made to be more efficient and recycle better. There are some variables that are just constantly incrememented. Not good when we're talking hours and hours of uptime.
- No real way to know what items you've got except with the advanced chat system, unless some sort of windowing stuffs is added to the game (either through another state, or by grafting the new GUI in-game - which is entirely possible but raises mouse control issues.)
-
Interesting, but I must point out - the freespace engine simply wasn't designed for MP; or the requirements for a MMORPG. As much as I hate to sound pessimistic, but it's downright impossible for such a thing to occur with the current mission structure/playing in FS2.
You're basically asking to play a massive-online mission, which on the whole generally move only in one direction, not stagnate and move either-which way.
-
Truth be told, I don't even know if anything beyond the basic rendering system currently in place would even be plausible in an MMO setting. I mean, missions are finite-duration, small, and goal oriented. All things that an MMO is inherently not. Things are created before mission start, and don't persist beyond mission end. It just seems far too different to make work. Though the insight into what it would take to make an MMO game would probably be useful in making multiplayer more dynamic.
-
Another idea (not MMORPG).. a Mission for many Players with unlimited Waves of enemys (different Ships) with a few Capships.. I think this could be interesting a 24/7 Battle Server where everyone can join. :D
I think it was funny when you can choose between 3 Teams.. Terran, Vasudan and Shivans :D
-
What NPC, OTOH and MMORPG stands for? :)
-
Dunno about NPC, but;
OTOH - On the other hand
MMORPG - Massive Multiplayer Online Role PLaying Game
-
NPC - Non Player Character
-
New Plutonium Cockerspaniel......
-
Originally posted by WMCoolmon
- Fix ingame joining. This is important. Probably the most important thing, as you can do a lot of the other stuff with SEXPs.
- Longer update times. Necessary if you want the first "M" in MMORPG. Otherwise you're stuck with the usual limit of players.
- Add the ability to save data on players to the code to some sort of file via SEXPs.
- Implement an alternative chat system.
- Probably give some more low level SEXPs, like a "create-ship" SEXP.
- Add the ability to have some sort of means of monetary exchange (Not score; score should be equivelant to powerlevel points) - Sounds like a minor variation of the persistant variable system could do this.
- Which of course means you'd have to SEXP in the variable with the above player-data save SEXP stuffs. - Yet another reason to use something similar to PVs
- Implement code to load the player's curret money level and offer them ship choices. Possibly allow use of SEXPs in the ship selection screen/briefing? Sounds similar to the Team Loadout code requests I made to Goober. With that you could simply display the cost of each ship in the table and alter the PV holding the players money once the game starts.
- Set things up so that only nearby ships are displayed/positions updated
Would be a lot of work though :) I think we're stuck with the current multiplayer system.
-
Well, I never played any multiplayer-games or can say that I have much knowledge about that or coding, but I have to throw in my 2 cents here:
When you really plan in coding such things, please don't castrate some of the single-player limits again (like you guys did with the max. of rotating subobjects (turrets) in order to upgrade multiplayer, at least so I did understand it. I may be wrong though).
I think that the decision between the possibility in
1) making ships with many multipart turrets
2) against flying one fighter and shooting down another fighter, flown by someone I know
has been made for the false argument. At least that's my personal opinion. So, like I said, pls don't decrease any single-player limits for it again. :)
P.S. Pls don't start a big discussion about the limit of rotational subobjects, I just wanted to point out that example because it pains me personally (I wanted to build a model with about 50 multi-part turrets), but I don't want to direct WMCoolmans Thread in another discussion-route :p
-
I think there is more of a use in getting a GUI for the Massive and RPG stuff, and making the current mission system a bit more dynamic. You'd still fly short, limited duration missions, but you'd be doing so in a MMORPG universe. You'd do a lot of the RPG stuff in a new kind of system, possibly using a combo of the current renderer, the IRC stuffs, and a new GUI thingymagic.
You could do the mission generation with PHP and MySQL for quite a lot of things. Not sure how robust MySQL is for updating stuff a _LOT_, though. We looked into this iwth FSCZ, actually, and now that I've done a bit more PHP and C, I think your best bet is to keep the current missions, but graft a MMORPG interface next to it.
It'd allow quite a lot of stuff to be fixed dynamicly, if you start putting some of the mission generation code in the database. IIRC you can update MySQL while reading, so you could keep all the mission stuffs in the dbase, and only use seperate files for reading the dbase stuff.
The stuff BW and I wrote on the random mission generator (it was in the SCP forum...) might be usefull to give you an idea what I'm rambling on about.
-
Keep in mind I'm not considering doing this at this point. I just started thinking and figured I'd type it up somewhere.
Also, Starman, I bumped the number of rotating subobjects to 50 a few weeks ago.
The hardcoded limits are there because of the way PCs are set up. When they read memory, they don't actually read the exact 27 bytes required for that string you just requested; instead, they grab a block of memory and move it to the ultra-fast CPU memory. All calculations are performed with that ultra-fast memory until a memory address is requested that didn't fit on the CPU memory, so it goes and grabs another block out of the main memory. It's relatively extremely slow; only a couple nanoseconds or so, but 10s of times slower than grabbing it from the fast memory.
To maintain compatibility with the rest of the code, any dynamically allocated blocks have to be grabbed from some random place in the code. That might be right next to the other, non-dynamic stuff, or it could be a couple hundred megabytes away.
Plus, it's easier to code for static sizes and such when you're on a schedule, which Volition was. :p
-
What about respawning (unless it's already there)?
-
If you had a server-change sexp, then it would be possible to have more than one map. The problem would be saving stats/etc.., unless a centralized database is used.
-
Respawning is already there, you'd have to set either an exorbitantly high limit or remove it altogether.
-
I think, if you wanted to create a FS2 based MMORPG, you'd probably have to start from the ground up in much the same way as Ferrium, you could probably use a lot of the graphics engine, but players would have to have accounts on the main server (strangely enough for more or less the reason that Windows moves memory from far away to near to the processor). A whole new trade element would mean a lot more info being sent through the Network.
The player side of the game is more or less like a 'Dumb Terminal' FS2, where you fly around and do stuff. The hard part, I think, would be writing a program to regulate and organise it all on the main server. You'd have to start looking at trade, and let's face it, if your flying a Freespace Freighter on your own and you see Pirates, you may as well abandon ship. So balance would have to be re-allocated to make the game fairer to Freelance traders etc.
It's something I'd absolutely love to see, possibly even consider donating towards keeping a server running for it, but it sounds like a whole new standalone project of a scale similar to the, if not bigger than the SCP itself :(
-
yes.....but with the number of MMORPGs out these days, its somewhat strange to consider that none of the companies have even considered this style of it. Although EVE does come close, it's nothing when you compare it to this kind of fun :D
Hmmmm....
-
Do it like Freelancer.
But you need only one main and constant server.
Njah.