ZDaemon es un juego gratuito para PC del clasico Doom.

Tiene varios modos para jugar.

El modo online es rapido y muy funcionable en este juego

DESCARGAR

Well I’ve been thinking a lot about ZDStack lately, and there’s some big changes I want to make.

Remove logfile dependency.

zserv actually prints its general log to STDOUT, so having it save a general log to disk is entirely redundant. I figured this out while working on 0.9, but since there’s not a direct correllation between player names and their IP addresses/ports, I figured we would have to use the connection log anyway… and since we’re doing that we may as well use the general log and send STDOUT to /dev/null. Well now ZDStack doesn’t use the connection log for anything, instead relying on the ‘players’ command. So there’s really two steps in this:

1. Move ZDStack over to using zserv’s STDOUT for event handling.
2. Make log generation configurable in the config file.

Add timestamps to log events.

Should a user decide they want logs, I won’t simply turn zserv’s general log on. I will add timestamping to all lines. Newer versions of zserv add timestamps to the lines so they won’t need them added. I’m a little fuzzy on the implementation details of this still, but it’s looking more and more like we’re heading towards time-based stats for IDL, and timestamps are required for that.

Really truly and honestly make enabling/disabling features work.

For a number of features, attempting to enable or disable them doesn’t have any appreciable effect. Player => IP logging is disabled in 0.10, and stats are always collected (for plugins, etc.) whether they’re disabled or not. Stats is just my laziness, pushing all the logic changes required for the case where stats are disabled is a lot of work and at the time it didn’t seem worth it to me. Player => IP logging is just dependent upon a change that’s too big for 0.10.

Find a proper storage engine.

A couple years ago PyXSE was my baby. I actually wrote a BitTorrent service using it as a storage backend (TorrentNest!). But it is extremely CPU heavy, and not having looked at the code in years it would probably be more difficult for me to get back into it than it is to just choose a different solution.

Specifically I’m between Tokyo Cabinet & SQLite. Both seem to offer pretty great performance and simple APIs, but that’s not really what’s making this decision hard. It’s more me being torn between what belongs in ZDStack and what belongs in ZDWebStack, and after some thinking I sort of have a vague idea of how I want to do things. For instance, it is dumb that ZDWebStack has to bother the ZDStack process whenever it wants anything. It basically means that ZDStack has multiple responsibilities and it really clutters the code up. What I think I should do is have ZDStack just for process management, event handling and plugins, and pull all the “stats” stuff into separate modules. ZDStack’s RPC interface really ought to just be for process and current game information. Old stuff should be stored somewhere and served up via ZDWebStack (or some HTTP-accessible layer).

Which, sadly, will change the RPC API again. Sigh. Maintaining the wiki for that is a pain in the ass by itself.

Anyway here’s the pros of choosing SQLite:

• Support is included in Python 2.5 and beyond.
• Compiling SQLite itself is very simple.
• It uses a standard SQL/DB-API2 interface, which will make IDL site integration easier.

And pros of choosing Tokyo Cabinet:

• Nice, simple key=>value storage.
• Management process included!

Honestly after I think about it for a while, I don’t like the idea of having 3 daemons for ZDStack (1 ZDStack, 1 storage engine daemon and 1 ZDWebStack). I would rather have just the 2 daemons, and a common library for handling access to the storage engine. Then again that doesn’t exclude Tokyo Cabinet, and its management process is still a feature. For instance, the plan for TotalTrash is to have ZDStack on the Chicago server, and have ZDWebStack on TotalTrash itself (the VPS), to really minimize lag. Some kind of HTTP-accessible layer is required to maintain that sort of setup, and not having to write one is a big plus. On the other hand I don’t think I’m that wild about the API, but it looks easy enough to wrap.

As a side note, Tokyo Cabinet is badass… if only for its changing title on the front page. Look what I got while wildly refreshing the Japanese page:

東京収納棚: あんなの飾りです！偉い人にはそれが分からんのですよ！
Translated by Google Translate: “Tokyo rack: A pretty-like! I’m a big man that beats me!”
東京収納棚: 見える！私にもレコードが見える！
Translated by Google Translate: “Tokyo rack: visible! Record is visible to me!”
ROFL.

Anyway, breaking things out like this would really improve the clarity of ZDStack’s code. Hopefully I get time to do all this!

So after working with the IDL site, I’ve really got a better handle on ZDaemon CTF statistics.

What Are ZDaemon CTF Statistics?

During a CTF match, really only 3 things can happen (that are logged, anyway):

• A player frags/is fragged
• A player touches a flag
• A player returns a flag

All other events are modifications on these basic 3 events; a death is a frag in reverse, a flag capture is a successful flag touch, and so on.

We can then build quite a lot of state into these events. Things like:

• Score
• Home/Enemy Flag State (taken or not taken)
• Whether the player is holding the other team’s flag
• Etc.

The IDL site is doing this, however, ZDStack’s stats are quite a ways behind. I might add this for 0.11; considering 0.10 took me over 8 months to release, I think I can be a little more ambitious in my releases. I’m a little torn between releasing little incremental changes often, or releasing larger changes every 6-8 months or so. I think I find the latter more rewarding, releasing smaller, more frequent changes might cause me to get sloppy in my testing. The original idea is to get all the “features” in by 0.11, so I can then concentrate on the RPC API, stability, logging/debugging/tracing, etc. in the 1.0 release candidates, however, that could all change depending upon how inspired I get.

So I recently bought an Acer P244 Wbii LCD monitor (or rather, my dear sweet mother bought it for me ) and I was using it while attached to my Thinkpad X60 for everything. Everything including ZDaemon. While I wholeheartedly recommend the monitor itself, especially at $270 + free shipping, I have to admit that I instantly became much worse at ZDaemon while playing on it. Having reverted today to playing on the X60’s screen I realize that the proportions on the monitor were probably translating incorrectly to my mouse movements, i.e., I see a bigger distance on the wide 24″ monitor, and my mouse hand moves a bigger distance. I’m sure it’s something I could get used to, but with IDL starting in a couple weeks, I’d rather not throw a bunch of new variables into the mix. Back to laptop screen I go (for gaming anyway)!

Bueno tengo sin jugar zdaemon mucho tiempo
Como un mes eso creo
Al menos eso creo yo xD

cree un clan antes de ir me se llama Bmbs osea bombs
su pagina es www.freewebs.com/bmbsclan
solo avia 3 miembros

-RDX
-Bazookero
-Molotov
mas yo
-Dinamite
Al final el clan se disentegro
pero de todas formas
No me importa
de todas formas
si hubiera estado vivo todavia el clan
sacaria a los dos primeros
-Bazookero
-Molotov
Solo quedaria ederick yo y franz
Como no eh actualizado nada
no existe nada final mente
abandonare esa pagina de
bmbs ya que no ahi clan
talvez lo continue otro dia
pero no se talves tenga otra compu
y talves tenga otra ip
y talves pueda jugar zdaemon  
en ese caso ya no seria noob
seria mejor que todos
pero ya ven ya no pude hacer nada
estoy aqui interesado entre el rpg maker
tambien hago mapas de doom bueno al menos eso es
por mientras estare editando mi pagina