Jump to content

Home

Help! General class structures, program flow and some specifics


farren

Recommended Posts

Hi, I'm an experienced UT modder with a lot of UScript and some C++ behind me. There's a whole wack of stuff I'd like to know and I'm hoping someone on this forum can either point me in the right direction (website tuts etc) or help me out. I've looked through the forums sticky readme post on general help and none of them are generalised enough.

 

1. Are there any tuts that clearly lay out the flow of execution of classes in an MP game? e.g. UI class spawns game class, game class spawns player and bot classes, player class spawns weapon collection and so on.

 

2. Any decent tuts on client/server interaction, replication of information and so on?

 

3. In UT its easy to modify only a single class or aspect of a class and compile only that so that multiple overlays (modifiers) can be applied to a single game. With a single batch file that seems to compile everything to QVM, I'm not clear how you do this in JKII/QIII without overlaying EVERYTHING. Am I missing something?

 

4. More specifically, I want to alter swordplay so that the 3rd person camera swings round and shows a side view (Tekken style) when two saber wielders come within a certain range of each other, to try to make swordplay less hack and slash and more skillfull. Also, I want the strafe keys to change to orbiting the other player while still in range.

Which classes would these amendments involve? Obviously I'd need to get a right angle radiant of the line between two players and work out the proximity of players, in addition to moving the camera and trapping and changing the results of keypresses.

 

Anyone able to help?

Link to comment
Share on other sites

well first of all UT and Q3 modding are very different (i ve worked a little on ut engine ..)

 

1> UT is fully object oriented whereas q3 isn't even wrote in a OO language. so forget everything you know about your c++ classes when it comes to q3 coding...

there are no classes in q3 just some structures. there are no class spawning... You just have functions that are called ervery frames, at the begining of a map ... when a player hits a key, at the init of the game, etc...

 

2> for good tutorials check this website out :

http://www.planetquake.com/code3arena/

the tutorials are designed for q3 but you can easily adapt them to jk2.

 

3> In UT you write scripts (utscripts is the language ( i say that for other persons))...whereas in q3 you program a qvm which is a kind of multi platform dll.

So you hav to recompile the qvm everytime you make a change.

but you can work with dlls which are faster to compile (really faster).

 

4> for the saber gameplay look at w_saber.c .

Link to comment
Share on other sites

For the 'tekken style' duelling, you might do several things

 

1) arange for some kind of 'lock on to target thing', combined with a camera-angle change automation, like if the players are duelling, or locked or something, it'll adjust the view angle so both are on the screen or something ....

 

Geez - your idea gave me so many ideas.

 

Anyway, Tchouky's got you set on the right path, so I'll just pipe down.

Link to comment
Share on other sites

Thanks for the assistance. I did just dive right in and found it relatively easy to tweak weapons as a test exercise.

 

I'm still wondering about two things:

 

1. Can you write mods that combine with other mods?

 

2. Can't get debugging using DLL's with visual c++ right, despite following the supplied modding readme to the letter. Its a bit of a pain to compile to QVM every time instead of being about to run debug with command line options for jk2mp.exe for the DLL

 

? :)

Link to comment
Share on other sites

Originally posted by Tchouky

1> UT is fully object oriented whereas q3 isn't even wrote in a OO language. so forget everything you know about your c++ classes when it comes to q3 coding...

there are no classes in q3 just some structures. there are no class spawning... You just have functions that are called ervery frames, at the begining of a map ... when a player hits a key, at the init of the game, etc...

 

Yeah, it's a lot more like actually coding for an actual game instead of inside a engine env. You can see the hardcore programmer thought progress here.

 

1. Can you write mods that combine with other mods?

I believe it's possible, but I have no clue how to do this without the UT type of system. I've seen some mods for JK2 that seem to do it, but those may have been done thru trail and error.

 

2. Can't get debugging using DLL's with visual c++ right, despite following the supplied modding readme to the letter. Its a bit of a pain to compile to QVM every time instead of being about to run debug with command line options for jk2mp.exe for the DLL

 

I had the EXACT same problem. Raven's instructions are incomplete. you gotta set the following command line arguements to get it to work:

 

+set vm_cgame 0

+set vm_game 0

+set vm_ui 0

 

I understand that this is suppose to set those cvars to "2" when they correctly load. However, I beleive I've had cgame compenents claim to be loaded when they aren't.

 

Note: I haven't been able to get this to work with my cgame components. It just loads game only. (I haven't messed with UI yet.)

 

Hope that helps, it took me forever to find that bit of info.

 

Razor Ace

Link to comment
Share on other sites

Yes. I think most games (Like Tomb Raider and Max Payne) use the "camera hugging the wall" technique for that; where camera's target vector will always point straight to the character but in an attempt to keep a certain distance of the character, the camera source will try to go up and still focus the character itself, sometimes it is interesting, most of the times is a pain, but still it's possible.

 

Handling two characters is possible too, like make the camera source orbit the player character and the vector point to the closest enemy character coordinates (You would, of course, also have to specify a range).

 

Handling more characters will complicate things a little bit, because it's not easily possible to point at several characters at the same time and make the game "playable". You could make the camera back-off, but the motion of several characters at the same time would make the game a little hard to play. If you point always to the nearest target, then you'd have a exploit: Players would be able to "sneak" from behind and make a "fast red stance attack" while other two are duelling, making possible an easy kill.

 

I guess one solution would be making fights between two characters only, and making the "Tekken" game type available for duels only too...

Link to comment
Share on other sites

Orbiting might, help but the camera/map problem and the control problem would remain. For anything other than situations where the players are close together in a wide out space, the camera would often not be able to zoom out far enough to see both players at once. Now, if you made special maps for it, it would probably work pretty good.

Link to comment
Share on other sites

No, it doesn't look strange at all. And it's easy - just read up on your cg_view ... or cg_draw ... I did it a long time ago and I forget.

 

With the right mapping and shader know-how, you could even make it a lot more like a fighting game.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...