[q2x] Alive

[Nick Trout]

> > I can see an object oriented style of C there.
> Sadly, if I recall, most of that was a straight translation of the QC
> stuff from Q1 then updated for the new monster types.

I haven't really used QuakeC. I remember having a look at it a few years
ago and not really liking it a great deal. I can't remember why I didn't
like it, I think it seemed a bit esoteric. I remember thinking if you're
going to all this effort to write a compiler then why not invent
something that is easier to use and nicer to read than C - otherwise you
might as well use C.


> > is to make all of the behaviour data (script) driven rather than
> > hard coded.
> 
> Bingo.  In theory, Q2 is architected such that the entire game should
> be loadable from a DLL/script.  Unfortunately the reality so far has
> been that significant modifications still require changes on the
> client, which is just so wrong it boggles me. 

Was src/game included in the client and server? I guess the client needs
to know about the objects because of animation and prediction?

So I assume that your plan is to turn this generic? i.e. so the client
handles objects but the server decides how they behave? Clients can
start a game based on a common script, with a common object resource
database, but thereafter the server is running the show based on client
input (with possible network/latency problems). 


> So my ideal universe consists of the following components:
> 
> raw client (no game specific knowledge)
> raw server (no game specific knowledge)
> client side game logic (cgame.dll in Q3 parlance)
> server side game logic (gamex86.dll)

So based on my assumptions, you could have a q2xgame module which
contains common functionality for client and server, e.g. object
manager, memory manager, math functions etc.

> ref_gl (pure rendering)
> ref_soft (possibly punting this)

Mmmm doesn't seem like an awful lot of sense in supporting software
rendering anymore does there? Can't people who don't have a 3D video
card (are the using abacuses?!) use Mesa GL? Does that have a software
renderer still?


> Q3 achieved much of this via cgame.dll, but John opted to use a VM
> instead of a scripting language (not that I can fault him too much for
> that).  The downside is that making mods became much less accessible
> and portable.  Mods for Quake were immediately portable to all
> architectures because of QC.  Mods for Q2 and Q3 required someone
> recompiling for each target architecture.

Not sure what you mean by "VM instead of a scripting language"; most
scripting languages have a compiler with some form of intermediate code
and a VM to run it on.


> Using a scripting language like Lua, you once again get portable mods,
> AND you get the beauty of using a language that is friendlier than C
> or C++ for newbies.

I think a lot of it depends on how friendly the architecture and
documentation is rather than the syntax, but I agree it would be easier
than C. 


> So all the m_* and g_* will eventually become Lua code.  There'll be a
> gamex86_lua.dll bridge that exports the same interface as the C DLL,
> but it then thunks/dispatches to the Lua scripting system for
> everything else.  I haven't worked out the specifics of how the
> bridging should work, but overall it should be fairly simple.

You'll probably want a lualib.dll which contains Lua and its default
libraries. This way other modules could use Lua as well (for example for
configuration). The bridge, or binding module, will publish a Lua-esque
API for receiving user input and manipulating game objects as you say.


> > there either. So all of the "service objects" that allow script to
> > control the game will need to be exposed. How are you planning on
> > doing this? Are you hand coding or using the newly released tolua5?
> 
> I think hand coding is best, if for no other reason than to make me
> acutely aware of what is being transported back and forth between Lua
> and the game.

I'm just porting my Doris OpenGL tool thing over to Lua 5 and toLua 5 so
I'll see how that goes (still have a couple of things to iron out with
GLUT). Using an auto binding generator can save an awful lot of effort
when writing a large binding and maintaining it. For example it took me
less than an hour to move from Lua 4 to Lua 5 in Doris (another hour of
messing with CVS :( ). You specify exactly what you want to expose in a
package file for toLua. The error handling and binding can be more
efficient and flexible if done by hand though.

Nick