[q2x] Alive

[Brian Hook]

> then why not invent something that is easier to use and nicer to
> read than C - otherwise you might as well use C.

The goal of QuakeC was actually to target C programms but in a safe, 
sandboxed environment with managed memory. I think it achieved its 
goals quite well (and, in fact, it got quite a few programmers off to 
a start).

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

The animations, yes, but there were some grosser things that had to be 
shared for no apparent reason -- like muzzle flash offsets.  A lot of 
the shared information was simply because the programmers were lazy 
and didn't want to bother broadcasting/architecting a shared data 
structure -- even though the game is actually setup to do just that!

> So I assume that your plan is to turn this generic? 

I want things to be generic, but not to the point that it stops being 
interesting or good. =) Basically I don't mind it operating under the 
"presume we're an FPS with these types of common properties" model, I 
just get irked when you have to distribute a brand new client just to 
get some animation data.

> 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.

The project is already set up that way, although in shared file form, 
nothing as elaborate as a DLL.  

> Mmmm doesn't seem like an awful lot of sense in supporting software
> rendering anymore does there?

Very low end systems.  The issue isn't hardware capability, it's more 
along the lines of driver stability.  If you were doing a budget title 
aimed at the $20 SKU downloadable games market, the software renderer 
would be very appealing.

But I agree, I'm not quite sure it's relevant these days.

> 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.

i.e. he didn't invent a new scripting language, he actually used the C 
language and just wrote a VM for it.  This was more portable than what 
happened with Q2, but still not as accessible as a higher level 
scripting language.

> 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.

Syntax isn't the concern as much as more basic things like pointers 
and memory management, traditionally the things that new programmers 
bump into right away.

Brian