Plan for Joshua Ritter
by Prairie Games · 03/25/2003 (8:23 am) · 15 comments
I am in preproduction on the 3d MUD Dungeon Crawler
The current work is centering around Quake2 (tools appear to be GPL) and Nebula.
I am using Nebula as the core framework because of it's robust package design... for instance, it supports Python, Lua, and TCL out of the box... it can actually be used as a standard Python extension without even recompiling it... a fact which totally blew my mind...
Quake2 will bring a highly efficient network model, world building, and gameplay entities to Nebula.
I put up some "concept" video of the 3d MUD Dungeon Crawler: Video (in DivX format)
I am hopeful people can see what I see :) Dungeon Crawling featuring intense coop play with persistent character building... The video was shot using MicroQ2 ... which is a stripped down version of Quake2 I have been working on... you can read more about it below...
You can download the MicroQ2 source code: HERE
From the Readme.txt:
---
MicroQ2 - A Microscopic Networked 3D Engine built on Quake2 Technology
---
This is a version of Quake2 minus Quake2 ... It should be interesting to anyone looking for great functionality/performance, with a small amount of code to juggle...
I did this in preparation of factoring the code into Nebula from Radon Labs (woot!)
It is a pretty much completely devoid of Quake2 specific game elements and some core systems...
Porting this to other platforms should be pretty easy... I coded/ripped this on win32...
Compiled size comparisons:
Client/Server from 354kb -> 192kb
Gameplay from 388kb -> 124kb
Whats Gone:
1) Sound/CD Audio
2) The Console
3) Temporary Entities/Events/Particles/ClientFX
4) The Screen Drawing Stuff/Hud/Menu System/Etc
5) Clutter wedged in the games entity/state stuctures
6) Lots of Quake2 game code from gamex86.dll
7) IPX network junk
8) Win32 ConProc
9) Software Rendering (temporary hack)
10) Piles of Mission Pack Stuff
11) Weapons, Items, Inventory, Etc, game side and client side
12) Pretty much all hardcoded game stuff in Client/Server
What's There:
1) Networked Client/Server
2) Collision/Physics
3) Basic Entities like Doors/Platforms/Buttons/Triggers
4) Input
5) Client <-> Pluggable Renderer Architecture
6) Server <-> Pluggable Game Architecture
What was pretty much untouched:
1) The OpenGL renderer ... this will be moved into the Nebula Scenegraph (32 bit textures,etc). It will support D3D8(soon D3D9) and OpenGL rendering on Windows, Macintosh, and Linux.
Directions:
You need Quake2 installed...
Yup, the console/menu is completely gone... so you have to drive MicroQ2 from the command line:
MicroQ2 +map base1
or
MicroQ2 +set dedicated 1
or
MicroQ2 +connect 127.0.0.1
If you want to exit from the client you better (or ctrl-alt-del) or have the quit command mapped
to a key
bind x "quit" ->
Also, there is no way to setup your config.cfg from inside MicroQ2 (again, no console or menu) ... so you'll
have to do this either in normal Quake2 or hand edit it...
-Josh Ritter
joshua@actionrpg.com
The current work is centering around Quake2 (tools appear to be GPL) and Nebula.
I am using Nebula as the core framework because of it's robust package design... for instance, it supports Python, Lua, and TCL out of the box... it can actually be used as a standard Python extension without even recompiling it... a fact which totally blew my mind...
Quake2 will bring a highly efficient network model, world building, and gameplay entities to Nebula.
I put up some "concept" video of the 3d MUD Dungeon Crawler: Video (in DivX format)
I am hopeful people can see what I see :) Dungeon Crawling featuring intense coop play with persistent character building... The video was shot using MicroQ2 ... which is a stripped down version of Quake2 I have been working on... you can read more about it below...
You can download the MicroQ2 source code: HERE
From the Readme.txt:
---
MicroQ2 - A Microscopic Networked 3D Engine built on Quake2 Technology
---
This is a version of Quake2 minus Quake2 ... It should be interesting to anyone looking for great functionality/performance, with a small amount of code to juggle...
I did this in preparation of factoring the code into Nebula from Radon Labs (woot!)
It is a pretty much completely devoid of Quake2 specific game elements and some core systems...
Porting this to other platforms should be pretty easy... I coded/ripped this on win32...
Compiled size comparisons:
Client/Server from 354kb -> 192kb
Gameplay from 388kb -> 124kb
Whats Gone:
1) Sound/CD Audio
2) The Console
3) Temporary Entities/Events/Particles/ClientFX
4) The Screen Drawing Stuff/Hud/Menu System/Etc
5) Clutter wedged in the games entity/state stuctures
6) Lots of Quake2 game code from gamex86.dll
7) IPX network junk
8) Win32 ConProc
9) Software Rendering (temporary hack)
10) Piles of Mission Pack Stuff
11) Weapons, Items, Inventory, Etc, game side and client side
12) Pretty much all hardcoded game stuff in Client/Server
What's There:
1) Networked Client/Server
2) Collision/Physics
3) Basic Entities like Doors/Platforms/Buttons/Triggers
4) Input
5) Client <-> Pluggable Renderer Architecture
6) Server <-> Pluggable Game Architecture
What was pretty much untouched:
1) The OpenGL renderer ... this will be moved into the Nebula Scenegraph (32 bit textures,etc). It will support D3D8(soon D3D9) and OpenGL rendering on Windows, Macintosh, and Linux.
Directions:
You need Quake2 installed...
Yup, the console/menu is completely gone... so you have to drive MicroQ2 from the command line:
MicroQ2 +map base1
or
MicroQ2 +set dedicated 1
or
MicroQ2 +connect 127.0.0.1
If you want to exit from the client you better (or ctrl-alt-del) or have the quit command mapped
to a key
bind x "quit" ->
Also, there is no way to setup your config.cfg from inside MicroQ2 (again, no console or menu) ... so you'll
have to do this either in normal Quake2 or hand edit it...
-Josh Ritter
joshua@actionrpg.com
#2
So it has some levels to play :)
- Does refactoring the MicroQ code into nebula require you to release any changes you make to nebula as well?
Quake2 is dual licensed... If it is worth $10k to keep my source closed, I will do so... for the Dungeon Crawler, it is highly likely that I will pay for the license...
[b]- I
03/25/2003 (10:08 am)
- Why do you need Quake 2 installed?So it has some levels to play :)
- Does refactoring the MicroQ code into nebula require you to release any changes you make to nebula as well?
Quake2 is dual licensed... If it is worth $10k to keep my source closed, I will do so... for the Dungeon Crawler, it is highly likely that I will pay for the license...
[b]- I
#3
Phil.
03/25/2003 (10:35 am)
Why do you need 3 scripting languages? isnt one enough?? (joke! honest!!).Phil.
#4
PS: Same goes for 2 rendering APIs (OGL, D3D), multiplatform support (WinLinMac) and of course socks in 5 different colors.
03/25/2003 (11:34 pm)
Phil: Obviously you need 3 scripting languages in order to keep one's dev list free of " scripting language A is better than B" flamewars. ;o) PS: Same goes for 2 rendering APIs (OGL, D3D), multiplatform support (WinLinMac) and of course socks in 5 different colors.
#6
I was evaluating Nebula again lately, too... it IS a really nice and modular render engine, but I was really upset that they still dont have any level editor "pipeline"... like no interior support at all (BSP, portals, whatever), no Quark, Hammer, etc. plugins, ....
And their forums are still pretty dead... guess I should try their IRC channel someday... :P
It's GREAT to see you are going to extend it heavily with Q2 and various other stuff :D
Keep going!! :)
03/26/2003 (9:32 am)
Wow, absolutely awesome, Josh! :DI was evaluating Nebula again lately, too... it IS a really nice and modular render engine, but I was really upset that they still dont have any level editor "pipeline"... like no interior support at all (BSP, portals, whatever), no Quark, Hammer, etc. plugins, ....
And their forums are still pretty dead... guess I should try their IRC channel someday... :P
It's GREAT to see you are going to extend it heavily with Q2 and various other stuff :D
Keep going!! :)
#7
http://nebuladevice.sourceforge.net/cgi-bin/twiki/view/Nebula/NBspNode
It is there for the using (Nebula license) for anyone who might want it as a starting point to make a BSP system that doesn't rely on id's tools.
It very likely won't compile on Nebula anymore without some changes, the code has been rotting for a while now while the Nebula core has been undergoing changes, but any modifications needed to get it up and running with the current Nebula CVS should be minimal.
On the plugin issue, you're right, there isn't much officially available, but Nebula uses what basically amounts to the .obj file format for meshes, and it is very easy to find code to export from obj for many editors, and you can use Nebula's wftools functions within plugins to make sure the triangles are well organized for Nebula while exporting.
03/26/2003 (1:43 pm)
I wrote a Q3-style BSP renderer for Nebula and then abandoned it mostly because of the same tools issue Joshua was worried about for Quake2.... ah well. The source is available online here:http://nebuladevice.sourceforge.net/cgi-bin/twiki/view/Nebula/NBspNode
It is there for the using (Nebula license) for anyone who might want it as a starting point to make a BSP system that doesn't rely on id's tools.
It very likely won't compile on Nebula anymore without some changes, the code has been rotting for a while now while the Nebula core has been undergoing changes, but any modifications needed to get it up and running with the current Nebula CVS should be minimal.
On the plugin issue, you're right, there isn't much officially available, but Nebula uses what basically amounts to the .obj file format for meshes, and it is very easy to find code to export from obj for many editors, and you can use Nebula's wftools functions within plugins to make sure the triangles are well organized for Nebula while exporting.
#8
03/26/2003 (1:44 pm)
As far as the Nebula forums being dead..They've never been nearly as lively as GG since Nebula/Radon has a much different focus, but I suggest you join the mailing list if you're interested in Nebula happenings, since it tends to get used a lot more by the core Nebula developers than the forums do.
#9
Cool.. I looked at nBSPNode ... quality stuff ... could very well influence the Q2 renderer design... Q2 and Q3 are far more similar then most people would realize :)
As for the sourceforge forums on Nebula... yes, the mailing list, or the IRC channel (where development is actively discussed) are great...
-J
03/26/2003 (6:10 pm)
George,Cool.. I looked at nBSPNode ... quality stuff ... could very well influence the Q2 renderer design... Q2 and Q3 are far more similar then most people would realize :)
As for the sourceforge forums on Nebula... yes, the mailing list, or the IRC channel (where development is actively discussed) are great...
-J
#10
You can grab a PyQ2 prerelease HERE
I have some cleaning up to do in the build script, but it should give some ideas how wigged out cool this'll be :)
From the example scripts:
Server Side
Server, Client, GL, and Game extension modules operative... can build from Python distutils or from Visual Studio via automatically generated Workspace...
SWIG is integrated to quickly expose a few key spots... VROOOOOOMMMM VROOOOOMMMM :)
DuNgEoN CrAwLeR .... RAWRRRR!!!!
-J
PS: I took the liberty of removing ' chars from the code above, as they turn into ugliness inside code blocks...
03/27/2003 (9:49 am)
Muhahahaha..... building on the foundation of MicroQ2 ----> You can grab a PyQ2 prerelease HERE
I have some cleaning up to do in the build script, but it should give some ideas how wigged out cool this'll be :)
From the example scripts:
Server Side
import pyquake.q2server as server import pyquake.q2game as game args=[+set,dedicated,1] server.ServerMain(len(args),args) server.SetGameAPI(game.GetGameAPI()) while 1: server.ServerTick()Client Side
import pyquake.q2client as client
import pyquake.q2gl as gl
args=[+connect,127.0.0.1]
client.ClientMain(len(args),args)
client.SetRefAPI(gl.GetRefAPI())
while 1:
client.ClientTick()Server, Client, GL, and Game extension modules operative... can build from Python distutils or from Visual Studio via automatically generated Workspace...
SWIG is integrated to quickly expose a few key spots... VROOOOOOMMMM VROOOOOMMMM :)
DuNgEoN CrAwLeR .... RAWRRRR!!!!
-J
PS: I took the liberty of removing ' chars from the code above, as they turn into ugliness inside code blocks...
#11
@George: thanks a lot man!! :D After some tweaking I got your bsp renderer to work and compile with the latest Nebula CVS...
Awesome!
All I had to do was replace the "gfx/nscenegraph.h" includes with
"gfx/nscenegraph2.h", and because I am not using stlport at the moment I also had to replace
Here is anothe pic with some more textures... ;)
03/27/2003 (11:29 am)
Joshua, I'm speechless! :) That sounds brilliant, gotta try that little thing later... :D@George: thanks a lot man!! :D After some tweaking I got your bsp renderer to work and compile with the latest Nebula CVS...
Awesome!All I had to do was replace the "gfx/nscenegraph.h" includes with
"gfx/nscenegraph2.h", and because I am not using stlport at the moment I also had to replace
//using namespace stlport; using namespace std;and finally add this parser stuff into your bsp.n example file:
# --- # $parser:ntclserver$ $class:nbspnode$ $ver:Wed Apr 04 22:52:14 2001$ # ---Thanks a lot for pointing me to this lovely extension and for shareing your code of course!
Here is anothe pic with some more textures... ;)
#12
No problem, I hope it helps out. As I mention in the comments (I think, its been a while) the texturing system is a bit wonky and filled with some kludges I stuck in there to get standard Quake3 maps to render correctly for testing. It should really be better integrated with the nebula pixelshader/texarray system (which is somewhat similar to the Quake3 pixelshader system at a high level, but fits in as part of the Nebula scenegraph system).
Beware the tool licencing minefield. The best solution might be to adapt the q3 bsp renderer to q2 and then use the q2 tools for compiling (assuming they are, in fact, GPL, which seems to still be a little bit murky). That way your engine code wouldn't be bound by the GPL (assuming you don't rip parts of the Quake2 engine into the current nBsp code), just the tools would be GPL... allowing you to legally use them without paying for a commercial licnese (which isn't the case with the Q3 tools, for now).
All in all, the two BSP formats are very similar, except for Quake3's direct support for bezier curve meshing, which shouldn't be all that hard to backport to Q2, or you could just live without it and do explicit tesselation in your level editor before you save out to .map or whatever intermediate format. In the long run this seems to be what most everyone is doing anyway.
03/27/2003 (1:07 pm)
Stefan, No problem, I hope it helps out. As I mention in the comments (I think, its been a while) the texturing system is a bit wonky and filled with some kludges I stuck in there to get standard Quake3 maps to render correctly for testing. It should really be better integrated with the nebula pixelshader/texarray system (which is somewhat similar to the Quake3 pixelshader system at a high level, but fits in as part of the Nebula scenegraph system).
Beware the tool licencing minefield. The best solution might be to adapt the q3 bsp renderer to q2 and then use the q2 tools for compiling (assuming they are, in fact, GPL, which seems to still be a little bit murky). That way your engine code wouldn't be bound by the GPL (assuming you don't rip parts of the Quake2 engine into the current nBsp code), just the tools would be GPL... allowing you to legally use them without paying for a commercial licnese (which isn't the case with the Q3 tools, for now).
All in all, the two BSP formats are very similar, except for Quake3's direct support for bezier curve meshing, which shouldn't be all that hard to backport to Q2, or you could just live without it and do explicit tesselation in your level editor before you save out to .map or whatever intermediate format. In the long run this seems to be what most everyone is doing anyway.
#13
@George: Yup... Quake2 is far from crusty... much of Q3's work centered around game reorganization with some rendering treats like the shader language/bezier... I honestly think people see some bezier and some UV manipulation and are like WHOA way more high techness!!! :)
-J
03/27/2003 (7:44 pm)
@Stefan: woohoo! My current thought is to use the q2gl renderer (q2's native renderer) for now and at some point make a nQRender exposed to the q2 core via python... giving D3D9 and OpenGL support via Nebula!!! "Porting" all the collison/network/game stuff to Nebula is a lot of work... and due to not having an ideal license not terribly interesting... with the nPython module just glue in at the PyQ2 seams... replacing with better licensed stuff as time/$$$ allows...@George: Yup... Quake2 is far from crusty... much of Q3's work centered around game reorganization with some rendering treats like the shader language/bezier... I honestly think people see some bezier and some UV manipulation and are like WHOA way more high techness!!! :)
-J
#14
Beware the tool licencing minefield. The best solution might be to adapt the q3 bsp renderer to q2 and then use the q2 tools for compiling (assuming they are, in fact, GPL, which seems to still be a little bit murky). That way your engine code wouldn
03/28/2003 (7:47 am)
[quote]Beware the tool licencing minefield. The best solution might be to adapt the q3 bsp renderer to q2 and then use the q2 tools for compiling (assuming they are, in fact, GPL, which seems to still be a little bit murky). That way your engine code wouldn
#15
My overall point was that the Quake3 tools (relevant since this is a Quake3-format BSP renderer) cannot legally be used without a commercial license. The Quake2 tools, if they are GPL, can be.
03/28/2003 (10:19 am)
Yeah that's why I said your engine code wouldn't be bound by the GPL if you just used the Quake2 tools. My overall point was that the Quake3 tools (relevant since this is a Quake3-format BSP renderer) cannot legally be used without a commercial license. The Quake2 tools, if they are GPL, can be.
Torque Owner Yacine Salmi
- Why do you need Quake 2 installed?
- Does refactoring the MicroQ code into nebula require you to release any changes you make to nebula as well?
- I'm guessing this can't be submitted back into nebula cvs, right?
- Are you gonna use nebula 1 or 2 for this?