Index | FAQ | Search | Memberlist | Usergroups | Profile | Log in to check your private messages | Log in | Register

Upcoming Tutorial: The Seamless Multi-Map World Goto page Previous 1, 2

| Inside3d Forums Forum Index -> Engine Programming

View previous topic :: View next topic
Author | Message
--- | ---
Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Tue Jul 27, 2010 12:06 pm Post subject: |

TODO: Think about this some more and how to make it universally compatible with standard Quake with a mild engine modification like rotating brush models. Rough framework is like this: 1. Since QuakeC support for such a modification would be necessary, have QuakeC somehow tell the engine that a mod wants multimap support --- AND can the QuakeC tell the engine EARLY enough in process?
Or is there a better way? One assumption is that a multimap mod certainly MUST have it's own gamedir. Or would it? (Thinking of sv_progs support here and Universal Server project compatibility).
Ah ... let's just have the engine use a cvar. sv_multimap 1 ... easiest way. Is that cvar name "good"? sv_multimap_travel? sv_persistent_game_world? Whatever ...
Or perhaps better and more natively ... ALWAYS assume multimap support is wanted (ON by default) but if a changelevel doesn't contain a "." then it isn't acted on for that map ... effectively neutralizing the feature for all existing maps but allowing maximum flexibility for future maps.
I mean, this feature looks for an existing "Quake in progress" file and isn't ever going to find it for a traditional Quake map so on by default should be harmless enough. And if the new map name doesn't contain a "dot", it will never be saving one and no existing map names have a "dot" in them.
2. Treat all trigger changelevels with dots in the map name as parsable to extract the name of the spawn point desired.
3. How are save games going to be handled? They practically require their own folder with this.
4. And single player --> new game and typing map in the console would need to clear all the current .qip files.
But there is no reason to have to include all those progsdef.q2 stuff to get this to work ....
/End thinking
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...

Back to top |

Spike Joined: 05 Nov 2004 Posts: 944 Location: UK |

Posted: Tue Jul 27, 2010 12:41 pm Post subject: |

please don't pretend that its a filename extension, as that kinda prohibits other fun stuff (like distinguishing between doom(1) and quake maps). make changelevel accept one or two arguments. arg1 contains map name. arg2 contains startspot. if arg2 is missing, all previous maps are flushed, behaviour is identical to regular quake (doesn't load from archive)
if arg2 is present (or empty, would need to be quoted in this case), the old map is archived and stored somewhere, the new map is potentially loaded.
arg2(or empty) is stored into the new map's startspot string global.
engines that don't support it will not notice the second argument. engines that do can handle it correctly.
the changelevel builtin internally does a localcmd. If it doesn't add quotes, it doesn't technically need modifying, but it should be able to accept two arguments for consistancy.
This is what FTE does. Specifically, old maps are saved to disk, with their names remembered. Maps are reloaded only if they were known. Saved games copys out visted maps.
To make it properly seamless, you also need to be able to carry quad over and the like. FTE supports 64 spawn parms, as well as an alternative mechanism which I'm too lazy to mention.
_________________
What's a signature?
Last edited by Spike on Tue Jul 27, 2010 12:58 pm; edited 2 times in total

Back to top |

mh Joined: 12 Jan 2008 Posts: 909 |

Posted: Tue Jul 27, 2010 12:50 pm Post subject: |

I generally don't like the idea of using cvars for this kind of thing as a player could just pop down the console, change it, and BANG! Bad things happen. The player doesn't even need to be malicious, just simply curious or careless. The cvar system is nowhere near robust enough, and would need engine-side protection added on to it in a manner that prevents this kind of thing from being done but at the same time allows all the default behaviour with other cvars.
Shooting for a pure-engine or pure-QC solution to this is like using a screwdriver to drive in nails. You can do it, but you'll have a hard time and you might create a mess along the way. Better to utilise the strengths and suitabilities of each and get them working together on it.
Likewise going for a fully general solution as V1.0 is a mistake, IMO. You need a simpler V1.0 that can be tested, have all the little wrinkles ironed out, and all the weird edge cases identified and worked around, then build on that experience to implement a better V2.0.
If we start at the most basic level, assuming that the player travelling back and forth between maps is good enough for now, but other entities can wait on V2.0, what we need to do is:

- Save the map state when exiting - the current save code is more or less sufficient for this.
- When loading a new map, look for a saved state. If found, treat that as a load and the current load code is more or less sufficient; if not found just pop the player at the correct start spot (of which more later).
- Modify trigger_changelevel to include a "startspotname" (or whatever the consensus decides is most appropriate) field.
- Modify info_player_start to include the same field.
- During a changelevel (where there is no saved state), link the two and put the player at the right position.
- Find a clean way of implementing save files. Each save file becoming a directory instead is a good start, but there are other interactions that need to be fully worked out (what is you save in s0, progress a little, save again in s1, then changelevel to a map who's state is in s0 is one I can think of right away).

The Quake II and Hexen II systems may not be sophisticated or perfect, but the one thing we do know about them is that they work. They've been field-tested for years among many users, and you can't argue with a pedigree like that.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines

Back to top |

Ranger366 Joined: 18 Mar 2010 Posts: 72 Location: Berlin (Germany) |

Posted: Tue Jul 27, 2010 4:17 pm Post subject: |

This reminds me of the very old MultiMap/World server idea fo Quake. If someone would do this for Quake 2 im going to pay. But thats off-topic. Still this would be really cool for most of everything. But i think my words get ignored here so i will not say the rest i wanted to say for now. I already have enough Karma lost, i think...
Add to Scores:
Ranger366 -1
blarg.
_________________

Back to top |

r00k Joined: 13 Nov 2004 Posts: 483 |

Posted: Thu Jul 29, 2010 6:08 am Post subject: |

I havent read through the majority of this, Spike's method sounds valid. Though, is there a way to use the methods (talking out my ass at the moment) used for SAVED GAME files to save the STATE of the level you are leaving? I'd imagine, you walk up to a closed door, you have to touch the door, or button/lever to open it. This could be the trigger for saving the gamestate, creating a temp file, or drop out point if you quit the game. Im not suggesting using the exact same saved game code but using it as a stencil. Obviously the player_state portion of the game state would NOT be saved to that file, but tucked away somewhere else. Now how this ties into online play who knows, either a SVC_ or such...
Edit: I just read MH's post, sounds like my ass wasnt talking shit after all...

Back to top |

Display posts from previous:

| Inside3d Forums Forum Index -> Engine Programming | All times are GMT Goto page Previous 1, 2
Page 2 of 2

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2004 phpBB Group