Understanding how idtech3 works by Ethr
This is an IRC chat log from a guy associated with a project i'm working on. I asked him for some advice about the idtech3 engine and he ended up giving me a very long and indepth discussion about how it works. Heres the chat log.
Session Start: Sun Oct 18 19:38:52 2009
Session Ident: madscientist
01[19:38] <Ethr> hey mad
[19:39] <madscientist> hey
01[19:40] <Ethr> you're a bit of an 'expert' right with idtech3 stuff? do u have an email address i could possibly steal and use to contact you if I have any burning questions/things I can't figure out myself? There won't be many i promise :) but theres things I just dont understand in the engine from time to time and i can't find any decent documentation anywhere
[19:41] <madscientist> i don't see a problem here
[19:41] <madscientist> but
[19:41] <madscientist> isn't irc just fine?
[19:41] <madscientist> better even?
[19:42] <madscientist> i can give u my email sure if u want
01[19:42] <Ethr> well if u think its easier :)
[19:42] <madscientist> i think irc works faster :)
[19:42] <madscientist> email is so 90s :p
01[19:42] <Ethr> true true
01[19:42] <Ethr> i guess we're both on most of the time
[19:43] <madscientist> i'm always online
[19:43] <madscientist> just leave me a msg in pm
[19:43] <madscientist> like here
[19:43] <madscientist> i'll reply asap
01[19:44] <Ethr> kool
01[19:44] <Ethr> thanks
[19:44] <madscientist> is this your first time modding?
[19:45] <madscientist> have you worked on any project before?
01[19:45] <Ethr> yes and yes again.... well project of this type (and at the moment im 'leader programmer ... i kinda have mixed feelings about that)
[19:46] <madscientist> i would have loved to give a hand
01[19:46] <Ethr> i looked into et modding like over the month and this ar stuff recently
[19:46] <madscientist> but circumstances dictates otherwise
[19:46] <madscientist> i don't have the time nor the dedication
[19:46] <madscientist> also, i have my own ideas on how to code a game
01[19:46] <Ethr> yeh for me i have the time and i have good reasons for getting involved in a project
01[19:47] <Ethr> i just dont know what does what in xreal/q3
[19:47] <madscientist> well, i can give u a basic overview if u want
01[19:47] <Ethr> i could probably do ok at the abstract level, like what i wanted to do etc... but i dont know what does what so its kinda hard to do it
[19:47] <madscientist> do you know the basic components of the whole game?
[19:48] <madscientist> to navigate your way through the code, for example
[19:48] <madscientist> if you wanted to add a new feature
01[19:48] <Ethr> i get the gist of it, like cgame stuff for client game
[19:48] <madscientist> which parts you'd modify etc
[19:48] <madscientist> okay, i'll name and try to make it easy
01[19:48] <Ethr> ok
[19:48] <madscientist> it's not too hard to grasp
[19:49] <madscientist> to make things simple, q3 is divided into the "engine" and "game"
01[19:49] <Ethr> yup - eiM wants me to stay well away from the engine side of things :p
[19:50] <madscientist> engine would be for example ET.exe rtcwmp.exe quake3.exe
[19:50] <madscientist> etc
[19:50] <madscientist> while the "game" would be the the mod dll that is loaded @ runtime
[19:51] <madscientist> cgame_x86_mp.dll for the client side and qagame_x86_mp.dll for server side
01[19:51] <Ethr> yup
[19:51] <madscientist> you also have ui dll for the menu and related
[19:51] <madscientist> but make the distinction here
[19:51] <madscientist> ui is not same as 2d
[19:52] <madscientist> ui is a seperate component
[19:52] <madscientist> got nothing to do with hud etc
01[19:52] <Ethr> yeh i found that adding a little clock in ET
[19:52] <madscientist> it's *only* the menu that you get when u press "esc"
[19:52] <madscientist> or when u start then game and see the options, play, quit, etc.
[19:53] <madscientist> so, basically, u could completely remove the UI component from the "game"
[19:53] <madscientist> and it will still function fine
[19:53] <madscientist> i won't be talking about ui anymore
[19:53] <madscientist> just cgame and qagame
01[19:53] <Ethr> kl
[19:53] <madscientist> u should find these two as sub folders
[19:54] <madscientist> cgame and game
01[19:54] <Ethr> yeh xreal has them as visual c++ projects
01[19:54] <Ethr> stuff is a bit scattered around tho
[19:54] <madscientist> if you modify only code found in "game"
[19:54] <madscientist> it will be only server side
[19:54] <madscientist> and the client won't have to download or update anything
[19:54] <madscientist> whatsoever
[19:55] <madscientist> and it's good practice never to pack game and cgame together
[19:55] <madscientist> so, that when you release server-only updates such as fixes
[19:55] <madscientist> the client won't have to download anything
[19:55] <madscientist> so, only pack cgame and ui
[19:55] <madscientist> same goes with modifying cgame
[19:56] <madscientist> if u do, nothing on the server needs updating
[19:56] <madscientist> now, there's one important thing to take into consideratioon
[19:56] <madscientist> it's the "bg"
[19:56] <madscientist> these codes are shared between BOTH game and cgame
[19:56] <madscientist> if you do modify these
[19:57] <madscientist> then both codes are updated
01[19:57] <Ethr> aah o
01[19:57] <Ethr> ok* yeh i wondered what bg meant exactly
01[19:57] <Ethr> thought it was background...
[19:57] <madscientist> these usually, include stuffs like animation code, etc
[19:57] <madscientist> that's about it for the game :)
[19:58] <madscientist> the rest is engine
01[19:58] <Ethr> ok
[19:58] <madscientist> you want more?
[19:58] <madscientist> i know i can ramble a lot
[19:58] <madscientist> when i start
01[19:59] <Ethr> lol :p
01[19:59] <Ethr> ok so what information is shared by the server and client
01[19:59] <Ethr> in otherwords if i shoot a bullet, how does the server know
[19:59] <madscientist> only bg*
01[19:59] <Ethr> stuff like that
[19:59] <madscientist> well, i'll have to explain how the engine works then
[19:59] <madscientist> but the most important thing is,
[19:59] <madscientist> if you want to add a new feature
[20:00] <madscientist> or update some
[20:00] <madscientist> to know where to look at
[20:00] <madscientist> and what to modify
[20:00] <madscientist> okay, i'll break down the engine component
[20:00] <madscientist> "engine" is the executable
[20:01] <madscientist> from bottom to top
[20:01] <madscientist> bottom = OS specific code
[20:01] <madscientist> and you should probably never have to edit those
[20:01] <madscientist> this is what allows compatibility across various platforms
01[20:01] <Ethr> i hope not
[20:01] <madscientist> running on linux, windows, etc
[20:02] <madscientist> what the OS specifics code does is simple
[20:02] <madscientist> it handles input
[20:02] <madscientist> and creating a valid rendering output
[20:02] <madscientist> in our case, an opengl window
[20:02] <madscientist> that's all
[20:02] <madscientist> and ofc, audio output
[20:03] <madscientist> u can find these codes in various subfolders
[20:03] <madscientist> such as win32 or unix
[20:03] <madscientist> etc
[20:03] <madscientist> as i said, there should be no need to change those
[20:03] <madscientist> next, you have the "common" code
[20:04] <madscientist> it's called "common" because it's the first OS independent code
[20:04] <madscientist> for example,
[20:04] <madscientist> windows and linux handles keyboard and mouse input differently
[20:05] <madscientist> but process them to the common code
[20:05] <madscientist> which handles and interprets the input
01[20:05] <Ethr> makes sense
[20:06] <madscientist> "common" is is responsible for initializing the "client" NOT to confuse with "client game"
[20:06] <madscientist> client in this case, are the code contained in "client" subfolder
[20:06] <madscientist> basically, client does all the engine processing
[20:07] <madscientist> things like, reading network packets
[20:07] <madscientist> parsing demos and server snapshots on a low level
[20:07] <madscientist> for example:
[20:07] <madscientist> client connects to server
[20:07] <madscientist> server sends a packet
[20:08] <madscientist> client will "decode" it and then notify "cgame"
[20:08] <madscientist> client is also responsible to start cgame on map load
[20:08] <madscientist> and to unload it as well
01[20:08] <Ethr> ok
[20:08] <madscientist> cgame is non-persistant
[20:08] <madscientist> cgame is loaded and unloaded all the time
[20:08] <madscientist> on every map change/load basically
[20:09] <madscientist> so, never use it to keep "data"
[20:09] <madscientist> use cvars
[20:09] <madscientist> or some external files
01[20:09] <Ethr> ah thats interesting
[20:09] <madscientist> okay, one last thing now
[20:09] <madscientist> i said client is reponsible for all client processing
[20:10] <madscientist> that's true but think of it as a "router"
[20:10] <madscientist> in the end, everything goes through client
[20:10] <madscientist> input, packets, commands, etc
[20:10] <madscientist> let's say, cgame wants to render a player
[20:11] <madscientist> it will send a "message" to client
[20:11] <madscientist> and tell it to loadmodelmd3 for example
[20:11] <madscientist> with some arguments
[20:11] <madscientist> it works just like a regular function call in a dll
[20:12] <madscientist> when you're importing
[20:12] <madscientist> it just has fancy names
[20:12] <madscientist> check "syscall"
[20:12] <madscientist> in both cgame and game
[20:12] <madscientist> u can see all the different "functions" that cgame/game can call
[20:13] <madscientist> all, these are redirected to the engine client
[20:13] <madscientist> this is VERY important
[20:13] <madscientist> the whole "game" depends on this mechanism
01[20:13] <Ethr> syscall?
01[20:13] <Ethr> is that a file>?
[20:13] <madscientist> call
[20:13] <madscientist> yes
[20:14] <madscientist> cg_syscalls
[20:14] <madscientist> for example
[20:14] <madscientist> found it?
01[20:15] <Ethr> umm
01[20:15] <Ethr> got it#
[20:15] <madscientist> in cgame
[20:15] <madscientist> check the various syscalls u can make
[20:15] <madscientist> u can set cvars etc
01[20:16] <Ethr> is that all the trap_ stuff?
[20:16] <madscientist> yes
01[20:16] <Ethr> ah kk
[20:16] <madscientist> all the trap_* functions call functions inside the engine client
01[20:17] <Ethr> aah
[20:17] <madscientist> u have to remember that cgame is a dll
01[20:17] <Ethr> yeh i read a forum post somewhere which described them
[20:17] <madscientist> and it needs a way to call functions inside of the engine
[20:17] <madscientist> that's what trap_ are
[20:18] <madscientist> but back to loading the player model
[20:18] <madscientist> now that you loaded it
[20:18] <madscientist> u have to "render" it
[20:18] <madscientist> and cgame will have to call the client to do this
[20:19] <madscientist> and client will call the "renderer"
[20:19] <madscientist> and that's the last major component
[20:19] <madscientist> to the engine
[20:19] <madscientist> u can see the "renderer" subfolder
[20:19] <madscientist> with tr_
[20:21] <madscientist> btw, just as u have the engine client to handle "cgame"
[20:21] <madscientist> u also have engine server to handle "game"
01[20:21] <Ethr> yh i kinda figured
[20:21] <madscientist> there are other components
[20:21] <madscientist> but these are the most important ones you'll need to look at
01[20:21] <Ethr> ok
01[20:21] <Ethr> is there like any documentation for this engine anywhere?
[20:22] <madscientist> hmm
01[20:22] <Ethr> coz i couldnt find any. and do u have any websites/bookmarks u can recommend?
[20:22] <madscientist> i don't really know
[20:22] <madscientist> i've just learned it the hard way i guess
[20:22] <madscientist> maybe someone put something together
[20:23] <madscientist> i know i can sound complicated and hard to get
[20:23] <madscientist> but with time
[20:23] <madscientist> it will all flow together
[20:23] <madscientist> and make sense
01[20:23] <Ethr> yeh i guess
[20:23] <madscientist> the design is very modular
01[20:23] <Ethr> ive learnt alot in just a few days and i guess uve been doing it for a while
[20:23] <madscientist> and u should keep it this way
[20:23] <madscientist> when u code
[20:23] <madscientist> don't go around modifying the whole engine, when the same thing could be done by just editing the cgame
[20:23] <madscientist> for example
[20:24] <madscientist> u asked how a bullet was fired earlier
[20:24] <madscientist> i'll trace it for you here
[20:24] <madscientist> from start to end
01[20:24] <Ethr> ok
[20:24] <madscientist> maybe u'll understand better then
[20:24] <madscientist> let's assume a context first
[20:25] <madscientist> you are in a game
[20:25] <madscientist> and connected to a server
[20:25] <madscientist> and you press "attack" button on your mouse
[20:25] <madscientist> can't make this simpler :p
[20:25] <madscientist> this is what's gonna happen
[20:25] <madscientist> let's assume you're running windows
[20:26] <madscientist> windows will send a message to the game saying mouse button is being pressed
[20:26] <madscientist> win32 specific code will get this and send it to "common"
[20:27] <madscientist> common will interpret it and update the pressed buttons state
01[20:27] <Ethr> ok
[20:27] <madscientist> done,
[20:27] <madscientist> now,
[20:27] <madscientist> the game will render a number of frames per second
[20:27] <madscientist> it starts in common at com_frame
[20:28] <madscientist> which calls cl_frame in client
[20:28] <madscientist> basically, cl_frame is called once every frame
01[20:28] <Ethr> ok
[20:28] <madscientist> and it will check what the state is
[20:28] <madscientist> it will see that the "attack" key is on
[20:29] <madscientist> and will proceed to create a client "command"
[20:29] <madscientist> there's a new command created for every frame rendered
[20:29] <madscientist> say, u have 60fps
[20:29] <madscientist> then you'll have 60 commands per second as well
[20:29] <madscientist> commands contain very little information
01[20:30] <Ethr> is that the same as +attack type commands in game?
[20:30] <madscientist> it contains the movement state and viewangles
[20:30] <madscientist> yes
[20:30] <madscientist> same
01[20:30] <Ethr> ah ok
[20:30] <madscientist> movement would be
01[20:30] <Ethr> so i couldnt do +left and +attack in the same frame? it would take 2?
[20:30] <madscientist> if +forward, etc is being pressed
[20:30] <madscientist> yea
01[20:30] <Ethr> aah
[20:30] <madscientist> so, every command, contains these
01[20:30] <Ethr> thats a bit rubbish :p
[20:31] <madscientist> view angles is created from mouse inputs normally
[20:31] <madscientist> but it goes through cgame etc
[20:31] <madscientist> but let's just assume it's taken directly from mouse to make it simpler
[20:31] <madscientist> so, that's the whole of a command
[20:32] <madscientist> client will send this to cgame AND to qagame
[20:32] <madscientist> now, cgame is local
[20:32] <madscientist> qagame = server you are connected to
[20:32] <madscientist> so, basically
[20:32] <madscientist> every command that is created every frame
[20:32] <madscientist> is sent to the server over the internet
[20:32] <madscientist> and to cgame as well
[20:32] <madscientist> cl_maxPackets controls how many can be sent
[20:32] <madscientist> for example
[20:32] <madscientist> say, u have cl_maxPackets 30
[20:33] <madscientist> this will buffer the commands every even frame
[20:33] <madscientist> and send 2 in one packet
[20:33] <madscientist> to server
[20:33] <madscientist> but that's not important for now
[20:33] <madscientist> thing is
[20:33] <madscientist> cgame will use this command
[20:34] <madscientist> and update the game
[20:34] <madscientist> if you pressed +forward
[20:34] <madscientist> it will move forward etc
[20:34] <madscientist> and qagame will do same on the server
[20:34] <madscientist> this is VERY important
[20:35] <madscientist> and the reason why q3 engine is very smooth and feels great
[20:35] <madscientist> u'll understand why later on
[20:35] <madscientist> (because, basically, server updates the player SAME as client updates, because SAME command was used)
[20:36] <madscientist> now, when server recieve the command, and sees u have +attack
[20:36] <madscientist> it will update the player state to "firing"
[20:36] <madscientist> and depending on various circumstances,
[20:37] <madscientist> it will fire the current weapon
[20:37] <madscientist> say, it does fire a bullet
[20:37] <madscientist> it will do a trace to see it anything was "hit"
[20:37] <madscientist> other players, etc.
[20:37] <madscientist> notice that cgame has nothing to say about this
01[20:38] <Ethr> is that like g_combat.c stuff?
[20:38] <madscientist> only qagame decides what gets hit or not
[20:38] <madscientist> yes
[20:38] <madscientist> g_bullet
[20:38] <madscientist> or something
[20:38] <madscientist> the function
[20:38] <madscientist> i mean
01[20:38] <Ethr> ah kk
[20:38] <madscientist> anyways,
[20:39] <madscientist> let's say u did hit another player
[20:39] <madscientist> it will calculate the damage done
[20:39] <madscientist> etc
[20:39] <madscientist> update stats
[20:39] <madscientist> score
[20:39] <madscientist> and if it died
[20:39] <madscientist> etc, etc
[20:39] <madscientist> lots of triggers
01[20:39] <Ethr> yuo
01[20:39] <Ethr> yup*
[20:39] <madscientist> let's say u hit the player
[20:40] <madscientist> qagame will sent an "event" back to cgame
[20:40] <madscientist> this event might do stuffs like hitsounds etc
[20:40] <madscientist> show blood
[20:40] <madscientist> etc
[20:40] <madscientist> that's the whole of it
[20:40] <madscientist> -_-
01[20:41] <Ethr> aah i see
01[20:41] <Ethr> yeh i read a post bout adding basic hitsounds and said about that
[20:41] <madscientist> oh, engine server component, also have a fixed number of frames per second
[20:41] <madscientist> in ET it's 20
[20:41] <madscientist> u can set it with sv_fps
[20:42] <madscientist> it means, it will update the server state every frame and send "updates" packets to all clients connected
[20:42] <madscientist> dependinf on /snap cvar
[20:42] <madscientist> adding hitsound is easy
[20:42] <madscientist> just check the bullet hit flesh even
[20:42] <madscientist> and make sure the player who attacked is yourself
[20:42] <madscientist> and play sound
01[20:44] <Ethr> yeh
01[20:44] <Ethr> ive just made some very very basic hitsounds work
01[20:44] <Ethr> XD
[20:44] <madscientist> :)
[20:44] <madscientist> check cg_event
01[20:44] <Ethr> yeh makes alot more sense how uve explained it
01[20:45] <Ethr> case EV_HEADSHOT:
01[20:45] <Ethr> DEBUGNAME("HIT HEAD");
01[20:45] <Ethr> trap_S_StartLocalSound(cgs.media.hitSoundHead, CHAN_ANNOUNCER);
01[20:45] <Ethr> break;
[20:45] <madscientist> lol
[20:46] <madscientist> btw Ethr,
[20:46] <madscientist> for now,
[20:46] <madscientist> avoid messing with the engine
[20:46] <madscientist> just stick to cgame and game
01[20:46] <Ethr> trust me i get enough headaches from logic
[20:47] <madscientist> from what i understand
[20:47] <madscientist> u'll have to add new weapons
[20:47] <madscientist> possibly new player models+animations
[20:47] <madscientist> classes
[20:47] <madscientist> limbo
[20:47] <madscientist> hm
[20:47] <madscientist> hud?
01[20:47] <Ethr> yeh
01[20:48] <Ethr> theres a lot of stuff
[20:48] <madscientist> oh and the hardest
[20:48] <madscientist> would be maps :)
[20:48] <madscientist> since you'll have to read in the map entities
01[20:48] <Ethr> thats why i want eim to find some more coders who know whats what, i dont mind helping but i cant lead it
01[20:48] <Ethr> yeh
01[20:48] <Ethr> have to create all the objectives :(
[20:48] <madscientist> this will be hard for you, atm
[20:48] <madscientist> ye
[20:49] <madscientist> that's also why i'm telling to keep things simple for now
[20:49] <madscientist> the others can just
[20:49] <madscientist> model new weapons etc
[20:49] <madscientist> it's just art
[20:49] <madscientist> by from the coder's point of view
[20:49] <madscientist> all weapons could be 3D box for all he care
[20:50] <madscientist> it's the divide between art and code
01[20:50] <Ethr> yeh i keep asking kjell for boxes
01[20:52] <Ethr> thankyou anyway :)
01[20:52] <Ethr> very good insite
01[20:52] <Ethr> insight?
[20:52] <madscientist> yea :p
[20:52] <madscientist> well, if u need anything
[20:52] <madscientist> just ask
[20:52] <madscientist> i'll try to help
[20:52] <madscientist> it's all fine as long as i'm not actually coding :P
[20:53] <madscientist> i'll leave this up to you
[20:53] <madscientist> :)
01[20:53] <Ethr> :)
Session Start: Sun Oct 18 19:38:52 2009
Session Ident: madscientist
01[19:38] <Ethr> hey mad
[19:39] <madscientist> hey
01[19:40] <Ethr> you're a bit of an 'expert' right with idtech3 stuff? do u have an email address i could possibly steal and use to contact you if I have any burning questions/things I can't figure out myself? There won't be many i promise :) but theres things I just dont understand in the engine from time to time and i can't find any decent documentation anywhere
[19:41] <madscientist> i don't see a problem here
[19:41] <madscientist> but
[19:41] <madscientist> isn't irc just fine?
[19:41] <madscientist> better even?
[19:42] <madscientist> i can give u my email sure if u want
01[19:42] <Ethr> well if u think its easier :)
[19:42] <madscientist> i think irc works faster :)
[19:42] <madscientist> email is so 90s :p
01[19:42] <Ethr> true true
01[19:42] <Ethr> i guess we're both on most of the time
[19:43] <madscientist> i'm always online
[19:43] <madscientist> just leave me a msg in pm
[19:43] <madscientist> like here
[19:43] <madscientist> i'll reply asap
01[19:44] <Ethr> kool
01[19:44] <Ethr> thanks
[19:44] <madscientist> is this your first time modding?
[19:45] <madscientist> have you worked on any project before?
01[19:45] <Ethr> yes and yes again.... well project of this type (and at the moment im 'leader programmer ... i kinda have mixed feelings about that)
[19:46] <madscientist> i would have loved to give a hand
01[19:46] <Ethr> i looked into et modding like over the month and this ar stuff recently
[19:46] <madscientist> but circumstances dictates otherwise
[19:46] <madscientist> i don't have the time nor the dedication
[19:46] <madscientist> also, i have my own ideas on how to code a game
01[19:46] <Ethr> yeh for me i have the time and i have good reasons for getting involved in a project
01[19:47] <Ethr> i just dont know what does what in xreal/q3
[19:47] <madscientist> well, i can give u a basic overview if u want
01[19:47] <Ethr> i could probably do ok at the abstract level, like what i wanted to do etc... but i dont know what does what so its kinda hard to do it
[19:47] <madscientist> do you know the basic components of the whole game?
[19:48] <madscientist> to navigate your way through the code, for example
[19:48] <madscientist> if you wanted to add a new feature
01[19:48] <Ethr> i get the gist of it, like cgame stuff for client game
[19:48] <madscientist> which parts you'd modify etc
[19:48] <madscientist> okay, i'll name and try to make it easy
01[19:48] <Ethr> ok
[19:48] <madscientist> it's not too hard to grasp
[19:49] <madscientist> to make things simple, q3 is divided into the "engine" and "game"
01[19:49] <Ethr> yup - eiM wants me to stay well away from the engine side of things :p
[19:50] <madscientist> engine would be for example ET.exe rtcwmp.exe quake3.exe
[19:50] <madscientist> etc
[19:50] <madscientist> while the "game" would be the the mod dll that is loaded @ runtime
[19:51] <madscientist> cgame_x86_mp.dll for the client side and qagame_x86_mp.dll for server side
01[19:51] <Ethr> yup
[19:51] <madscientist> you also have ui dll for the menu and related
[19:51] <madscientist> but make the distinction here
[19:51] <madscientist> ui is not same as 2d
[19:52] <madscientist> ui is a seperate component
[19:52] <madscientist> got nothing to do with hud etc
01[19:52] <Ethr> yeh i found that adding a little clock in ET
[19:52] <madscientist> it's *only* the menu that you get when u press "esc"
[19:52] <madscientist> or when u start then game and see the options, play, quit, etc.
[19:53] <madscientist> so, basically, u could completely remove the UI component from the "game"
[19:53] <madscientist> and it will still function fine
[19:53] <madscientist> i won't be talking about ui anymore
[19:53] <madscientist> just cgame and qagame
01[19:53] <Ethr> kl
[19:53] <madscientist> u should find these two as sub folders
[19:54] <madscientist> cgame and game
01[19:54] <Ethr> yeh xreal has them as visual c++ projects
01[19:54] <Ethr> stuff is a bit scattered around tho
[19:54] <madscientist> if you modify only code found in "game"
[19:54] <madscientist> it will be only server side
[19:54] <madscientist> and the client won't have to download or update anything
[19:54] <madscientist> whatsoever
[19:55] <madscientist> and it's good practice never to pack game and cgame together
[19:55] <madscientist> so, that when you release server-only updates such as fixes
[19:55] <madscientist> the client won't have to download anything
[19:55] <madscientist> so, only pack cgame and ui
[19:55] <madscientist> same goes with modifying cgame
[19:56] <madscientist> if u do, nothing on the server needs updating
[19:56] <madscientist> now, there's one important thing to take into consideratioon
[19:56] <madscientist> it's the "bg"
[19:56] <madscientist> these codes are shared between BOTH game and cgame
[19:56] <madscientist> if you do modify these
[19:57] <madscientist> then both codes are updated
01[19:57] <Ethr> aah o
01[19:57] <Ethr> ok* yeh i wondered what bg meant exactly
01[19:57] <Ethr> thought it was background...
[19:57] <madscientist> these usually, include stuffs like animation code, etc
[19:57] <madscientist> that's about it for the game :)
[19:58] <madscientist> the rest is engine
01[19:58] <Ethr> ok
[19:58] <madscientist> you want more?
[19:58] <madscientist> i know i can ramble a lot
[19:58] <madscientist> when i start
01[19:59] <Ethr> lol :p
01[19:59] <Ethr> ok so what information is shared by the server and client
01[19:59] <Ethr> in otherwords if i shoot a bullet, how does the server know
[19:59] <madscientist> only bg*
01[19:59] <Ethr> stuff like that
[19:59] <madscientist> well, i'll have to explain how the engine works then
[19:59] <madscientist> but the most important thing is,
[19:59] <madscientist> if you want to add a new feature
[20:00] <madscientist> or update some
[20:00] <madscientist> to know where to look at
[20:00] <madscientist> and what to modify
[20:00] <madscientist> okay, i'll break down the engine component
[20:00] <madscientist> "engine" is the executable
[20:01] <madscientist> from bottom to top
[20:01] <madscientist> bottom = OS specific code
[20:01] <madscientist> and you should probably never have to edit those
[20:01] <madscientist> this is what allows compatibility across various platforms
01[20:01] <Ethr> i hope not
[20:01] <madscientist> running on linux, windows, etc
[20:02] <madscientist> what the OS specifics code does is simple
[20:02] <madscientist> it handles input
[20:02] <madscientist> and creating a valid rendering output
[20:02] <madscientist> in our case, an opengl window
[20:02] <madscientist> that's all
[20:02] <madscientist> and ofc, audio output
[20:03] <madscientist> u can find these codes in various subfolders
[20:03] <madscientist> such as win32 or unix
[20:03] <madscientist> etc
[20:03] <madscientist> as i said, there should be no need to change those
[20:03] <madscientist> next, you have the "common" code
[20:04] <madscientist> it's called "common" because it's the first OS independent code
[20:04] <madscientist> for example,
[20:04] <madscientist> windows and linux handles keyboard and mouse input differently
[20:05] <madscientist> but process them to the common code
[20:05] <madscientist> which handles and interprets the input
01[20:05] <Ethr> makes sense
[20:06] <madscientist> "common" is is responsible for initializing the "client" NOT to confuse with "client game"
[20:06] <madscientist> client in this case, are the code contained in "client" subfolder
[20:06] <madscientist> basically, client does all the engine processing
[20:07] <madscientist> things like, reading network packets
[20:07] <madscientist> parsing demos and server snapshots on a low level
[20:07] <madscientist> for example:
[20:07] <madscientist> client connects to server
[20:07] <madscientist> server sends a packet
[20:08] <madscientist> client will "decode" it and then notify "cgame"
[20:08] <madscientist> client is also responsible to start cgame on map load
[20:08] <madscientist> and to unload it as well
01[20:08] <Ethr> ok
[20:08] <madscientist> cgame is non-persistant
[20:08] <madscientist> cgame is loaded and unloaded all the time
[20:08] <madscientist> on every map change/load basically
[20:09] <madscientist> so, never use it to keep "data"
[20:09] <madscientist> use cvars
[20:09] <madscientist> or some external files
01[20:09] <Ethr> ah thats interesting
[20:09] <madscientist> okay, one last thing now
[20:09] <madscientist> i said client is reponsible for all client processing
[20:10] <madscientist> that's true but think of it as a "router"
[20:10] <madscientist> in the end, everything goes through client
[20:10] <madscientist> input, packets, commands, etc
[20:10] <madscientist> let's say, cgame wants to render a player
[20:11] <madscientist> it will send a "message" to client
[20:11] <madscientist> and tell it to loadmodelmd3 for example
[20:11] <madscientist> with some arguments
[20:11] <madscientist> it works just like a regular function call in a dll
[20:12] <madscientist> when you're importing
[20:12] <madscientist> it just has fancy names
[20:12] <madscientist> check "syscall"
[20:12] <madscientist> in both cgame and game
[20:12] <madscientist> u can see all the different "functions" that cgame/game can call
[20:13] <madscientist> all, these are redirected to the engine client
[20:13] <madscientist> this is VERY important
[20:13] <madscientist> the whole "game" depends on this mechanism
01[20:13] <Ethr> syscall?
01[20:13] <Ethr> is that a file>?
[20:13] <madscientist> call
[20:13] <madscientist> yes
[20:14] <madscientist> cg_syscalls
[20:14] <madscientist> for example
[20:14] <madscientist> found it?
01[20:15] <Ethr> umm
01[20:15] <Ethr> got it#
[20:15] <madscientist> in cgame
[20:15] <madscientist> check the various syscalls u can make
[20:15] <madscientist> u can set cvars etc
01[20:16] <Ethr> is that all the trap_ stuff?
[20:16] <madscientist> yes
01[20:16] <Ethr> ah kk
[20:16] <madscientist> all the trap_* functions call functions inside the engine client
01[20:17] <Ethr> aah
[20:17] <madscientist> u have to remember that cgame is a dll
01[20:17] <Ethr> yeh i read a forum post somewhere which described them
[20:17] <madscientist> and it needs a way to call functions inside of the engine
[20:17] <madscientist> that's what trap_ are
[20:18] <madscientist> but back to loading the player model
[20:18] <madscientist> now that you loaded it
[20:18] <madscientist> u have to "render" it
[20:18] <madscientist> and cgame will have to call the client to do this
[20:19] <madscientist> and client will call the "renderer"
[20:19] <madscientist> and that's the last major component
[20:19] <madscientist> to the engine
[20:19] <madscientist> u can see the "renderer" subfolder
[20:19] <madscientist> with tr_
[20:21] <madscientist> btw, just as u have the engine client to handle "cgame"
[20:21] <madscientist> u also have engine server to handle "game"
01[20:21] <Ethr> yh i kinda figured
[20:21] <madscientist> there are other components
[20:21] <madscientist> but these are the most important ones you'll need to look at
01[20:21] <Ethr> ok
01[20:21] <Ethr> is there like any documentation for this engine anywhere?
[20:22] <madscientist> hmm
01[20:22] <Ethr> coz i couldnt find any. and do u have any websites/bookmarks u can recommend?
[20:22] <madscientist> i don't really know
[20:22] <madscientist> i've just learned it the hard way i guess
[20:22] <madscientist> maybe someone put something together
[20:23] <madscientist> i know i can sound complicated and hard to get
[20:23] <madscientist> but with time
[20:23] <madscientist> it will all flow together
[20:23] <madscientist> and make sense
01[20:23] <Ethr> yeh i guess
[20:23] <madscientist> the design is very modular
01[20:23] <Ethr> ive learnt alot in just a few days and i guess uve been doing it for a while
[20:23] <madscientist> and u should keep it this way
[20:23] <madscientist> when u code
[20:23] <madscientist> don't go around modifying the whole engine, when the same thing could be done by just editing the cgame
[20:23] <madscientist> for example
[20:24] <madscientist> u asked how a bullet was fired earlier
[20:24] <madscientist> i'll trace it for you here
[20:24] <madscientist> from start to end
01[20:24] <Ethr> ok
[20:24] <madscientist> maybe u'll understand better then
[20:24] <madscientist> let's assume a context first
[20:25] <madscientist> you are in a game
[20:25] <madscientist> and connected to a server
[20:25] <madscientist> and you press "attack" button on your mouse
[20:25] <madscientist> can't make this simpler :p
[20:25] <madscientist> this is what's gonna happen
[20:25] <madscientist> let's assume you're running windows
[20:26] <madscientist> windows will send a message to the game saying mouse button is being pressed
[20:26] <madscientist> win32 specific code will get this and send it to "common"
[20:27] <madscientist> common will interpret it and update the pressed buttons state
01[20:27] <Ethr> ok
[20:27] <madscientist> done,
[20:27] <madscientist> now,
[20:27] <madscientist> the game will render a number of frames per second
[20:27] <madscientist> it starts in common at com_frame
[20:28] <madscientist> which calls cl_frame in client
[20:28] <madscientist> basically, cl_frame is called once every frame
01[20:28] <Ethr> ok
[20:28] <madscientist> and it will check what the state is
[20:28] <madscientist> it will see that the "attack" key is on
[20:29] <madscientist> and will proceed to create a client "command"
[20:29] <madscientist> there's a new command created for every frame rendered
[20:29] <madscientist> say, u have 60fps
[20:29] <madscientist> then you'll have 60 commands per second as well
[20:29] <madscientist> commands contain very little information
01[20:30] <Ethr> is that the same as +attack type commands in game?
[20:30] <madscientist> it contains the movement state and viewangles
[20:30] <madscientist> yes
[20:30] <madscientist> same
01[20:30] <Ethr> ah ok
[20:30] <madscientist> movement would be
01[20:30] <Ethr> so i couldnt do +left and +attack in the same frame? it would take 2?
[20:30] <madscientist> if +forward, etc is being pressed
[20:30] <madscientist> yea
01[20:30] <Ethr> aah
[20:30] <madscientist> so, every command, contains these
01[20:30] <Ethr> thats a bit rubbish :p
[20:31] <madscientist> view angles is created from mouse inputs normally
[20:31] <madscientist> but it goes through cgame etc
[20:31] <madscientist> but let's just assume it's taken directly from mouse to make it simpler
[20:31] <madscientist> so, that's the whole of a command
[20:32] <madscientist> client will send this to cgame AND to qagame
[20:32] <madscientist> now, cgame is local
[20:32] <madscientist> qagame = server you are connected to
[20:32] <madscientist> so, basically
[20:32] <madscientist> every command that is created every frame
[20:32] <madscientist> is sent to the server over the internet
[20:32] <madscientist> and to cgame as well
[20:32] <madscientist> cl_maxPackets controls how many can be sent
[20:32] <madscientist> for example
[20:32] <madscientist> say, u have cl_maxPackets 30
[20:33] <madscientist> this will buffer the commands every even frame
[20:33] <madscientist> and send 2 in one packet
[20:33] <madscientist> to server
[20:33] <madscientist> but that's not important for now
[20:33] <madscientist> thing is
[20:33] <madscientist> cgame will use this command
[20:34] <madscientist> and update the game
[20:34] <madscientist> if you pressed +forward
[20:34] <madscientist> it will move forward etc
[20:34] <madscientist> and qagame will do same on the server
[20:34] <madscientist> this is VERY important
[20:35] <madscientist> and the reason why q3 engine is very smooth and feels great
[20:35] <madscientist> u'll understand why later on
[20:35] <madscientist> (because, basically, server updates the player SAME as client updates, because SAME command was used)
[20:36] <madscientist> now, when server recieve the command, and sees u have +attack
[20:36] <madscientist> it will update the player state to "firing"
[20:36] <madscientist> and depending on various circumstances,
[20:37] <madscientist> it will fire the current weapon
[20:37] <madscientist> say, it does fire a bullet
[20:37] <madscientist> it will do a trace to see it anything was "hit"
[20:37] <madscientist> other players, etc.
[20:37] <madscientist> notice that cgame has nothing to say about this
01[20:38] <Ethr> is that like g_combat.c stuff?
[20:38] <madscientist> only qagame decides what gets hit or not
[20:38] <madscientist> yes
[20:38] <madscientist> g_bullet
[20:38] <madscientist> or something
[20:38] <madscientist> the function
[20:38] <madscientist> i mean
01[20:38] <Ethr> ah kk
[20:38] <madscientist> anyways,
[20:39] <madscientist> let's say u did hit another player
[20:39] <madscientist> it will calculate the damage done
[20:39] <madscientist> etc
[20:39] <madscientist> update stats
[20:39] <madscientist> score
[20:39] <madscientist> and if it died
[20:39] <madscientist> etc, etc
[20:39] <madscientist> lots of triggers
01[20:39] <Ethr> yuo
01[20:39] <Ethr> yup*
[20:39] <madscientist> let's say u hit the player
[20:40] <madscientist> qagame will sent an "event" back to cgame
[20:40] <madscientist> this event might do stuffs like hitsounds etc
[20:40] <madscientist> show blood
[20:40] <madscientist> etc
[20:40] <madscientist> that's the whole of it
[20:40] <madscientist> -_-
01[20:41] <Ethr> aah i see
01[20:41] <Ethr> yeh i read a post bout adding basic hitsounds and said about that
[20:41] <madscientist> oh, engine server component, also have a fixed number of frames per second
[20:41] <madscientist> in ET it's 20
[20:41] <madscientist> u can set it with sv_fps
[20:42] <madscientist> it means, it will update the server state every frame and send "updates" packets to all clients connected
[20:42] <madscientist> dependinf on /snap cvar
[20:42] <madscientist> adding hitsound is easy
[20:42] <madscientist> just check the bullet hit flesh even
[20:42] <madscientist> and make sure the player who attacked is yourself
[20:42] <madscientist> and play sound
01[20:44] <Ethr> yeh
01[20:44] <Ethr> ive just made some very very basic hitsounds work
01[20:44] <Ethr> XD
[20:44] <madscientist> :)
[20:44] <madscientist> check cg_event
01[20:44] <Ethr> yeh makes alot more sense how uve explained it
01[20:45] <Ethr> case EV_HEADSHOT:
01[20:45] <Ethr> DEBUGNAME("HIT HEAD");
01[20:45] <Ethr> trap_S_StartLocalSound(cgs.media.hitSoundHead, CHAN_ANNOUNCER);
01[20:45] <Ethr> break;
[20:45] <madscientist> lol
[20:46] <madscientist> btw Ethr,
[20:46] <madscientist> for now,
[20:46] <madscientist> avoid messing with the engine
[20:46] <madscientist> just stick to cgame and game
01[20:46] <Ethr> trust me i get enough headaches from logic
[20:47] <madscientist> from what i understand
[20:47] <madscientist> u'll have to add new weapons
[20:47] <madscientist> possibly new player models+animations
[20:47] <madscientist> classes
[20:47] <madscientist> limbo
[20:47] <madscientist> hm
[20:47] <madscientist> hud?
01[20:47] <Ethr> yeh
01[20:48] <Ethr> theres a lot of stuff
[20:48] <madscientist> oh and the hardest
[20:48] <madscientist> would be maps :)
[20:48] <madscientist> since you'll have to read in the map entities
01[20:48] <Ethr> thats why i want eim to find some more coders who know whats what, i dont mind helping but i cant lead it
01[20:48] <Ethr> yeh
01[20:48] <Ethr> have to create all the objectives :(
[20:48] <madscientist> this will be hard for you, atm
[20:48] <madscientist> ye
[20:49] <madscientist> that's also why i'm telling to keep things simple for now
[20:49] <madscientist> the others can just
[20:49] <madscientist> model new weapons etc
[20:49] <madscientist> it's just art
[20:49] <madscientist> by from the coder's point of view
[20:49] <madscientist> all weapons could be 3D box for all he care
[20:50] <madscientist> it's the divide between art and code
01[20:50] <Ethr> yeh i keep asking kjell for boxes
01[20:52] <Ethr> thankyou anyway :)
01[20:52] <Ethr> very good insite
01[20:52] <Ethr> insight?
[20:52] <madscientist> yea :p
[20:52] <madscientist> well, if u need anything
[20:52] <madscientist> just ask
[20:52] <madscientist> i'll try to help
[20:52] <madscientist> it's all fine as long as i'm not actually coding :P
[20:53] <madscientist> i'll leave this up to you
[20:53] <madscientist> :)
01[20:53] <Ethr> :)