Build the zstar client and do
!rootbar
You will need generic.turn.x and generic.thrust mapped to keys to navigate the client.
You will be standing atop an outcropping in some rocky terrain. 90 degrees to your left is the root bar. There are double doors in the front and a door in the back to the storage area. Walk up the steps in the root bar, and there are inn rooms here!
z* is getting much closer to playability. You can now walk around the environment. Walking is implemented in a generic client-side interface that's available to all z* servers.
Aww yeah! We've got a new development release of the zstar "browser" -- zpilot
Thanks to lots of hard work (mostly Art's) we have pushed through the difficult
stage of integrating the Java vm. We now have a very powerful and general client,
with pretty darn good performance. Be gentle on the win32 port, please.
Finally we have integrated the jvm into the 3 major current ports (Linux, win32, Solaris)
Gods of consistent computing be praised. Current estimates are at about a month to
a release that has all major features in (currently working on the schene graph and
java interface / object model. There are still a few minor architecture decisions to be made. -AK
Last night Art created the RPM for Linux - it weighs in at a svelte 2.2 Mb. :) I'm working on making stand alone games easier for the end user. We should have releases for Linux on PPC mac and Solaris on SPARC within a week - anybody got a BSD box we can build on? ;)
Besides ARt's MUD interface, and the example VRML viewer, we now have another app - last night I uploaded ztetris. Please download it and heap constructive criticism upon us!
We are updating to beta. I have scrapped our display engine, and
instead incorporated openvrml. This resolved several problems with
the way we were interacting with opengl, and makes the client
*much* more stable. Everyone should check out openvrml.sourceforge.net.
The z* client now has sound support through libplibsl (PLIB). This enables z* games to
play .wav, and .au clips and background music MODs.
You can now script updates in the client with TCL. I'm hoping that this will make complicated effects easier to manage since z* is all server based. Scripting can be used to offload work onto
the client, and reduce server load, while still keeping the server authoritative. It will be interesting to hear wether anyone wants additional script features built in, or if write-only into the client command buffer is enough.
We are having good success with a lambdaMOO based server, and I have written a simple
game on it which is similar to the Atari 2600 Combat game, but 1st person, and with
chatting. Adam and I were having some fun with this last night, so I decided to put
us up to minor version 1. The lambda database we were using is included for
experimentation in the latest release, but I will probably move it out into it's own
package (so others can download it and have a fairly instant starting point for a
z* game).... read more
We are making progress in the area of loading mesh files.
There is a good screenshot on the zstar.sourceforge.net page
that shows a car mesh loaded into an object. We decided to
use VRML because we knew of a few implementations of it,
but this code is progressing nicely in a shorter time than we
expected.
I have posted a bug fix for the windows port
regarding core dumps when doing memcmp. You
should get the new zpilot.exe . I will probably
be doing frequent updates from CVS even though
it will be stressful for everyone to keep
downloading big 300k binaries. Maybe I'll start
using zip if it ever fills a low density floppy
completely.
There is a working windows port. In order to
build, get the latest cygwin, then do
$ ./configure
$ make
there will be a bin directory with your system
name as usual, with zpilot.exe, txproxy.exe and
modelserver.exe along with libutil.a
This will help us achieve world domination.
There is a MUD proxy for z* in src-java/mudproxy/mudproxy.java . This should enable
z* to be used as a client to an existing MUD where a 3D environment can subsequently
be built in. This is good news, as it enables the whole body of work on MUDs to be
reused in writing games for z*. While I was trying to develop my own game, I realized
that well-known games exist in this genre, and that developing my own was not worth it.... read more
The C version of the client is improving. Now that I've given
opengl a good talking to, and cured my black screen syndrome for the most part, there is something to see, although
not much. Message decoding is in (text mode), and a display
shows up with some implanted objects. Text overlay was
shamelessly ripped from some 'net example code.
I am working on getting the input/chat interface to the place
where it is in the java client, then I will proceed with filling in
all of the bodyless methods of ztarget.... read more
There is a mostly working sample server in zstar/exp (it does chat, responds to hello, etc)
And a client of sorts in zstar/src-java/zstar/client/*.java
There is a web page you will need to edit in zstar/src-java/zapplet.html in order to make the
program work.
The assumptions made with the client and server currently are that you have txproxy running
on some ports with inetd.
These are my /etc/inetd.conf entries:
zsproxy stream tcp nowait arty /chunk/arty/zstar/exp/txproxy txproxy
expserv stream tcp nowait arty /chunk/arty/zstar/exp/txproxy txproxy 10025... read more
We are changing the protocol to make it easier to
extend, as well as making easier for scripts to
speak the protocol.
I will make a new tgz as soon as we have a working
game in the new protocol.
I'm working on learning OpenGL so that I can
eventually wean zstar from Crystal Space. The
nice thing is that we designed it so that
libclient can be backended easily. There are
some javagl ramblings in src-java/zstar/client.
To use movelight.html in src-java, make a jar
file from the classes in javagl, and put the
jar in src-java.
JavaGL can be found here:
http://nis-lab.is.s.u-tokyo.ac.jp/~robin
The obview demo is working.
To run the server:
in directory zstar/src-java:
java zstar.server.servermain [udp-port-no] zstar.utils.obview ctlfile obview_controls.ptx modfile cube.ob texfile obview_textures.ptx
The server will be running...
The client zacs must currently be run in the CS (crystal space) directory. To run:
cd CS ; ./zacs [server-host] [server-port] udp
You may need some different options to make zacs work... Crystal space options are appended
to the end. I run with:
./zacs localhost 5000 udp -sdepth=32 -mode=320x200 -video=software... read more
The z* CVS tree is up and all files are in. Everything checks out and builds correctly.
You will need CrystalSpace expanded in directory CS at the same level as zstar in order
to build zacs.